Local VLAN on single switch

[Kevin Dorrell]

I have a Campus network of about twenty Cat4000 switches and a load of Cat2900. I run a VTP domain, with my two distribution switches as VTP servers and all my access switches (including the server-farm switches) as VTP clients.

In my server-farm, I have a new three-way cluster of servers. These three machines must be connected to a production VLAN. They must also be privately interconnected for their heartbeat and synchronisation.

Ideally, I would like to connect the heartbeat interfaces to three ports on the server-farm switch, and have them communicating as an "isolated" "local" VLAN, but without that VLAN being transported to other switches. I don't want to supply a separate switch just for the heartbeat network. Conversely, I do not want to put the server-farm switch in VTP transparent because I want it to participate in the domain. That seems to discount any "community VLAN" solution.

In this context, the server-farm switch could be a CatOS 4000 or an IOS 2900; I need a solution for both, because there are actually two such setups, one near a Cat2900, and the other near a Cat4000.

Does anyone have any suggestions?

Kevin Dorrell (CCNP)

Luxembourg

[milan.kulik · Accepted solution]

Hi Kevin,

AFAIK, you've got two options:

1) configure the server-farm switch as a transparent one

2) create a new VLAN on your VTP server. Put that 3 ports on the server-farm switch to the new VLAN. Disable the new VLAN on all trunks (or at least on all trunks on the server-farm switch) - VTP pruning is not enough.

This way the new VLAN will stay isolated on the server-farm switch and the server-farm switch will still participate on VTP domain. The other switches will know the new VLAN has been created but will not be able to communicate in the heartbeat network.

The command to disable VLAN on trunks are:

sw(config-if)#switchport trunk allowed vlan remove VLANID

on IOS

sw> (enable) clear trunk mod/port VLANID

on CatOS.

Regards,

Milan

[Kevin Dorrell]

Hi Milan,

Thank you for this elegant solution to the problem. It is elegant also because it addresses the problem of what happens if someone decides to re-use the same VLAN id of my "local VLAN" in the VTP domain.

Best regards,

Kevin.