Yet another vlan best practices question.

[GRANT GATHAGAN]

I've inherited a system that was set up using vlan1 for management and user data, and I'm trying to reconfigure it to follow best practices with regard to vlans.

The main campus is a mix of 3524XL's tied to a 6506 with a SUP1A router engine.

The 6506 is set up in hybrid mode, with the switch running CATOS 6.4(21) and the SUP1A engine running IOS 12.1(27b)E3.

That campus also has a 3750E, which is connected to the SUP1A through trunking the SUP1A's 2 gigabit GBIC's.

The 3750E serves as an aggregation switch for all of our servers and is also connected to our ASA5520, for all external traffic.

Two remote campuses are a mix of 3750's and 3524's.

What I've read leads me to believe I should:

1) Configure the switches with a native VLAN other than vlan1 or any vlan carrying user data/voice traffic. A common practice seems to be creating and using vlan999.

2) Create a new vlan for data traffic and reconfigure the switchports accordingly.

3) Create a new vlan for management, assign a new IP subnet to that vlan and give each switch an IP address on the new subnet.

That allows my many existing users/servers to retain their existing IP addresses, separates the switch management from both user data and vlan1, and puts untagged traffic on its own vlan as well. 

So far, so good.

Here's where it gets a little foggy for me:

Once the SUP1A engine has an IP off of the new management subnet, it will automatically route data between the various vlans, which seems to defeat the whole purpose of putting the switches on their own vlan and IP subnet.

Telnet sessions don't support the "switch console" command, so I cannot access the SUP1A thorugh the 6506 unless directly connected.

So when it comes to routers, does one simply not set them up for access through the management vlan/ip subnet?

[Peter Paluch · Accepted solution]

Hello Grant,

1) Configure the switches with a native VLAN other than vlan1 or any  vlan carrying user data/voice traffic. A common practice seems to be  creating and using vlan999.

This is correct. The native VLAN should be different from VLAN1 and should otherwise be absolutely unused. Note that also, there should be no SVIs created for this VLAN on any switch. Simply put, this VLAN is there just to make trunks happy with a different native VLAN and otherwise, it is avoided.

2) Create a new vlan for data traffic and reconfigure the switchports accordingly.

This is correct. User traffic should be carried in VLANs that are neither VLAN1 nor native VLANs on any trunk.

3) Create a new vlan for management, assign a new IP subnet to that vlan and give each switch an IP address on the new subnet.

This is correct. Again, the management VLAN should be distinct from VLAN1, from any native VLAN and from any other user VLAN (data VLANs, voice VLANs, ...).

Once the SUP1A engine has an IP off of the new management subnet, it  will automatically route data between the various vlans, which seems to  defeat the whole purpose of putting the switches on their own vlan and  IP subnet.

It is true that as soon as you create a SVI for the management VLAN and assign an IP address to it, a multilayer switch can start routing data from and into it. This does not defeat the purpose of the management VLAN, though, because of various reasons:

• You may need to access the management VLAN from stations in different VLANs. In that case, the ability to route into and from the management VLAN is an absolute must.
• A management VLAN can always be isolated from routing into/from other VLANs by simple ACLs placed on SVIs of the management VLAN. In this case, switches can only be managed by stations directly connected into the management VLAN. Note that this would require the station to be dedicated just for management, as it would not be able to access different VLANs itself. Hence, this scenario is possible and quite secure but not practical.
• More commonly, the management VLAN is configured so that there are no access ports placed into the management VLAN. This means that the stations accessing the management VLAN are in different VLANs themselves, and must have routed access into the management VLAN. This means that the flow of traffic into (and from) the management VLAN can be easily controlled by ACLs on the couple of multilayer switches that also have a SVI for the management VLAN.
• Also note that for multilayer switches, any VLAN for which there is an active SVI with an IP address configured should be considered a management VLAN. This means that the idea of a contained, closed and protected management VLAN applies best to Layer2 switches incapable of routing themselves.

I am not sure if this clarifies any of your doubts - please feel welcome to ask further!

Best regards,

Peter

[GRANT GATHAGAN]

Thank you for your response, Peter

Thank you also for confirming my conclusions and giving me far more detail with regard to the routing question.

I have been in this field for over 20 years, but have no formal training.

Occasionally I will come across an issue and wonder if that lack of training leads to my missing something that would be glaringly obvious to one who has that education.

[Peter Paluch]

Hello Grant,

You are heartily welcome!

Regarding the formal training - that is a delicate topic and I have no simple answer on that. I would say it depends very much on how the training was led. There are trainings focused on practical skills, and there are trainings focused on principial facts. My view is somewhat biased here because I work as a university teacher so I do see things from a very theoretical, principial perspective and I tend to think about them from different ends, but I often lack the real-life experiences. That is actually why I try to stay active at Cisco Support Community - to keep a connection to the real world and real-life issue.

In any case, I would be always glad to answer your questions, and the Cisco Support Community is blessed by having many networking experts - I am sure that you will have most of your questions answered.

Best regards,

Peter

[GRANT GATHAGAN]

Aloha Peter,

I've another set of questions related to the same vlan discussion we had earlier.

These go back to my comments about a lack of formal training...

I use EIGRP on my switches.

Since my current configuration utilizes vlan1 for user data, management traffic and any protocol exchanges between switches, my EIGRP configuration is set to monitor that same subnet.

As a refresher, I want to use vlan 999 as my native vlan, avoid using vlan1 for user data, use vlan 30 for my data, vlan 100 for VoIP phones and use vlan 20 as my management vlan.

When I move my management VLAN to VLAN 20, I will begin using a different IP subnet for accessing the switches.

I assume that I need to modify my EIGRP configuration to monitor the IP subnet of the management vlan.

Likewise, I assume that I will need to change any default route settings on my switches to also utilize the new management IP subnet.

Lastly, I assume that in order to communicate with my ASA firewall, I will now have to assign an IP address from the management subnet to its managemant interface, and connect that interface to a switch port that has been assigned static access to the management vlan.

Are those assumptions correct?

My confusion lies in looking at what a user's computer, now running its data on vlan 30, needs to see in order to access the internet, for instance.

Right now, everybody sees every thing; there's not deliniation between user data and management traffic.

I recognize that the individual computers have a default route that points to the router's SVI for that data vlan.

If my assumptions are correct, how does a switch's knowledge of it's neighbors in the management subnet help route the traffic that's in the data vlan/subnet?

Or does the routing protocol need to continue looking at the IP subnet that handles the user's data?