[afnog] Fw: Re: how to aconfigure a vlan

[Mark Tinka]

On Tuesday 17 November 2009 01:43:23 pm teklay gebremichael 
wrote:

> Thank u Mark for helping me and i appreciate ur fast
> response. hoping u will help me further, i will elaboret
> my problem a bit.

Always glad to help where I can :-).

> we have three capuses. two of the campuses have cisco
> 6509 switches and the other campus has a cisco 4506
> switch as core switches.

Are you able to advise what supervisor modules you have in 
these boxes, as well as what line cards are installed? These 
platforms have a number of restrictions depending on what 
hardware you plug into the chassis. Knowing what you have 
would help in identifying what's possible, and what isn't.

> all the intercampus liks are
> optical fiber which are in a triangular fashion...

So, a ring architecture. Good. I won't ask how you're 
handling protection (STP, perhaps), although I'm curious.

> and are
> all owned by our university.

Good, so no 3rd party contractors/service providers to 
hassle with. Makes things a little smoother.

> all the links are working.
> in the main campuse, there are 15 VLANs (subents) created
> on 6509 core switch (all other L2 switches in all
> campuses are cisco 2950 and 2960).

Okay, pretty standard. I'm guessing all Layer 3 services are 
handled by the 6509's and 4506, right?

> so in the main campus,
> it is only the 6509 switch which is in vtp server mode.
> and in the other campuses, the core switches are in vtp
> mode server, where as the other switches are in client
> modes.

Alright.

Well, my only advice is "be very very careful" when using 
VTP. It has caused many a network to melt down into nothing 
for a number of reasons. In one case, a customer was 
attached to an edge switch running VTP, and they managed to, 
unknowingly, transmit a PDU that reconfigured the entire 
VLAN database and brought the entire network down (I say 
entire because the edge switch doubled as a core switch).

We've seen that in a small-to-medium sized network, manually 
configuring VLAN's, i.e., by hand, is a good balance between 
security and scalability. Of course, as the network grows 
(especially if you're a Metro-E service provider), different 
methods need to employed.

As you scale, I would have recommend the use of other 
control planes, but I'm not sure what which stage in the 
"development cycle" your network is, and do not want to 
digress from what you need NOW.

> we use rip v2 as routing protocol to communicate
> each subnet in one capuse with others in other campuses.

Would recommend considering something more scalable and 
modern, e.g., OSPF or IS-IS.

> so, when we want to create a new vlan on any of the
> campuses, we just create it on the respective core
> switch.

Which is to say, VLAN's today do not span farther than the 
campus in which they are created, right?

> so, right now, i don't have any problem in
> creating a working vlan with the architecture i am
> telling u now.

Pretty stock.

> here is the problem i faced.
>
> i am asked to create one vlan with a network id of
> 192.168.20.0/24. computers in this valn don't need to be
> connected to the Internet but should communicate with
> each other being at different campuses...

No problem; I'll call our mystery VLAN, VLAN 100.

(having stayed away from VTP all my life), go to each core 
switch at each of the campuses and:

	a) add VLAN ID 100 to the VLAN database.

	b) create an SVI for VLAN 100.

	c) ensure the 802.1Q trunks on the ring are forwarding VLAN
	   100.

When you finish that, VLAN 100 should now be available at 
all 3 campuses. Next step is to go the affected edge 
switches at each campus, and:

	a) add VLAN ID 100 to the VLAN database.
	
	b) decide which ports will be a part of VLAN 100.

	c) ensure the 802.1Q trunks between the core and edge
	   switches are forwarding VLAN 100.

Plug your servers into the edge switches as appropriate, and 
assign them addresses out of the '192.168.20.0/24' per your 
needs.

> but the servers
> that the computers are connected to will be connected to
> the university network and hence to the Internet. so,
> this vlan should be vissible in the 10.128.0.0/16 campuse
> and in the 10.130.0.0/16 campuse.

No problem - both the 6509's and the 4506 support IP routing 
(as I'm sure you already know).

Since you'd have already created an SVI on each core switch 
in the preceding steps, just assign them, each, an IP 
address out of the '192.168.20.0/24' space. You could assign 
each core switch like so:

	* 6509_1 = 192.168.20.254/24
	* 6509_2 = 192.168.20.253/24
	* 4506_1 = 192.168.20.252/24

You've probably noticed, from the above, that all 3 switches 
are in the same VLAN (VLAN 100), meaning that all the 
computers configured with this address space are also in the 
same broadcast domain. This means that, technically 
speaking, any computer could use any of the above core 
switch IP addresses as a default router.

However, to keep things simple, and keep traffic from 
circulating around the network unnecessarily, you can 
configure each computer to use the default gateway of the 
core switch physically closest to it (ordinarily, I'd have 
used a separate subnet for each campus, but I'm not sure as 
to your design requirements).

So since you have RIP running across your network (you 
really should consider using link state routing protocols), 
all your core switches know about all the IP networks you're 
running in the network. When the computers in VLAN 100 need 
to talk to each other, the core switches will forward the 
traffic as switched Ethernet frames in a single broadcast 
domain. When the computers in VLAN 100 want to talk to the 
servers in the 10.x/16 space, the core switches will forward 
the traffic as routed IP packets to the correct destination, 
using the information populated by RIP.

And you should be good to go...

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20091118/ff0b9d75/attachment.pgp>