3500XL vlan trunking

[weldingkat]

Recently, we expanded our one office suite into four suites, and installed a 3548-XL-EN switch into each suite.

We vlan'd each switch so that ports 1-16 are vlan2, 17-32 are vlan3, and 33-48 are vlan4, and vlan1 (default) still exists.

Each of the four switches connect to each other in a round-robin fashion like so:

Switch A - Gi02 --> Switch B - Gi01

Switch B - Gi02 --> Switch C - Gi01

Switch C - Gi02 --> Switch D - Gi01

Switch D - Gi02 --> Switch A - Gi01

We set each GBIC port as follows:

Administrative Mode: 802.1Q Trunk

Trunk-Allowed Vlans: 1-5,1002-1005

Pruning Vlans: 2-1001

Native Vlan: 1

We are hoping, with the settings above, that ports 1-16 on each switch can see each other but are isolated from everything else.  The same for ports 17-32 and ports 33-48.

This will allow us to plug the accounting server into say, port 1 of switch D, and ports 1-16 on all four switches can see that server without issue, yet all the other ports cannot see it in any way.

Is our thinking correct?  I just wanted to confirm this before we hack up our network and find out the hard way.  Thank you in advance for any thoughts on the matter.

[Leo Laohoo]

Are the VLAN instances created on the VLAN database?

[weldingkat]

Yes, all four switches have the same vlan definitions.

vlan1: default

vlan2: accounting

vlan3: management

vlan4: office

[Sakun Sharma · Accepted solution]

Yes, you are right.

Any device connected within your port 1-16 on any switch will communicate with each other within your 4 switches.

Similarly for other set of VLAN's also if not pruned.

Also, if you are pruning VLAN 2-1001, your VLANs 2-1001 will not communicate between switches, within a switch devices will communicate but between switches they wont, because each switch will not transfer any packet of pruned VLAN over trunk port.

You will require inter-VLAN routing for VLAN's to communicate with each other, without that they will communicate within each VLAN but not among each other.

In case of inter-VLAN routing, you can add security using Access-list, to protect some specific devices in your network.

[paul driver · Accepted solution]

Hello,

Please read this link, it will give you a better understanding of VTP.

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094c52.shtml#vtp_pruning

res

Paul

Please don't forget to rate this post if it has been helpful.

[Leo Laohoo]

Who's doing the routing?

[weldingkat]

I might as well put a picture forth since a visual might be easier.

Currently:

Switch "D" is the server closet switch, and already is segmented into Vlans, but because it was the only switch the GBIC ports were never defined or set.

The firewall has rules that achieve the following:

• all three vlans have public internet access including the mail server
• the Management Vlan can see all three servers.
• the Accounting Vlan can see the accounting server and the office automation server
• the office vlan can only see the office automation server

The firewall also provides DHCP addresses to desktops.  There is no wifi.

All we're really trying to do here is extend Switch "D" by fiber into the other three office suites we are in the process of expanding into, adding Switch "A", Switch "B", Switch "C", so that ports 1-16 on all switches can see each other and only each other, ports 17-32 on all switches can see each other and only see each other, and ports 33-48 can see each other, and only each other.

Any inter-vlan routing is done by the firewall, and that currently works and has for years on just Switch "D".

We're just making Switch "D" bigger by adding "A", "B", "C" and installing them into each suite we've taken over.  They're very small suites - they can comfortably house about 10 employees per suite.

So in summary, we got it "right", other than to set "pruning" on the four switches to "none" instead of 2-1001?

[paul driver]

Hello Freadric,

Adding another 3 switches would work, Only problem with this, is if the curent switch goes down you will also lose all the others.

Yes, turning off pruning in this scenario would be advisable as you have the same vlans serving every switch.

res

Paul

Please don't forget to rate this post if it has been helpful.

[weldingkat]

Hello Paul,

I got it working on the bench, using the three switches that will go into the other suites with our spare/backup firewall.

I find your comment about "losing them all" rather curious because I would have expected a dead switch would only kill access for the users (or servers) attached to that switch with the other three switches still able to communicate with each other.  That's one of the reasons why we're connecting each switch connects to two others, forming a "GBIC Ring" for lack of a better term.

Is there a way around this issue?  Is it a function of the switch OS, the hardware, etc?

We do have a 3508 GBIC-only 8-port switch in storage, maybe connecting all the 3500xl's to that would be a better solution then?

After reading this: http://www.cisco.com/en/US/products/hw/modules/ps872/products_data_sheet09186a00800a1789.html it may apply more to half-duplex rather than full duplex?

Sorry for the tangent, but thank you very much for pointing that out....

[paul driver]

Hello Frederic,

The gigastack would provide resiliency within the stack, and also to the FW  providing you have redundant uplinks but in your picture you don't have that, so lets say switch A goes down, you will lose externel connectivity and intervlan routing..

res

Paul

Please don't forget to rate this post if it has been helpful.

[weldingkat]

Yes, correct.

I misunderstood what you were saying about "losing one switch".

Thank you all for your help