13

We are going to deploy a campus network with approximately 50 switches (Core, Agg, Access). Some of them will be L2 (20), and others will be L3 (30). We are thinking about how to manage these devices:

  1. A big VLAN across all switches. Easy to deploy, easy addressing, but big L2 broadcast domain.
  2. Management VLAN for L2 switches. To access core and aggregation switches use routed (or SVI) interfaces.

What would you prefer to use in your network?

  • 8
    I can't imagine any scenario in which one VLAN spanning 50 switches could ever be considered a good design decision. It is not a case of if, but when, someone will make a loop on that VLAN and lock you out of half of your switches in an instant. – jwbensley May 24 '13 at 8:43
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 8 '17 at 9:31
5

As you said, it matters on how many devices we're talking about, but aside from that, what you should avoid if at all possible is only having "in-band" management of your devices. You don't want to have your management traffic riding the same network as your production traffic. If not all of your switches have a separate Ethernet interface for management, that's fine, but nearly every single piece of equipment out there has some form of serial console. USE IT. Especially as a backup for in-band management. This will save your ass if a device falls off of the planet. I'm also suggesting using a completely separate physical infrastructure for management connectivity to your equipment. This applies doubly for serial console access. If you're using one of your interfaces on your switches (that's not a dedicated management interface), that's also not as big of a deal, as long as you've got a separate network to connect it to.

50 devices isn't too unreasonable of a footprint to use a single VLAN (again, assuming you are not doing in-band management) and have one broadcast domain for - you may be trying to optimize too early at this stage. If your core switches are modular boxes then they should most definitely have Ethernet management interfaces - I would advise you to use those rather than an SVI or a physical routed interface.

edit: my personal preferences basically outline what I've advised above: always serial consoles. Use dedicated Ethernet management interfaces where applicable. If dedicated Ethernet management interfaces are not available, then burn a physical port on the box, but always always always a separate network, for serial consoles at the absolute minimum.

| improve this answer | |
  • For example, I have SUP7L-E for 4500E chassis. This sup has dedicated Ethernet management port. What shoud I do to manage device: access via SVI or connect this mgmt port to LineCard port in management VLAN. Last variant seems to be strange, as for me. – Эдуард Буремный May 24 '13 at 8:43
  • Sorry, I guess I should have clarified - there should be a completely separate physical network used for managing your kit. I'll amend my answer now. – John Jensen May 24 '13 at 8:45
3

This really depends on the network, but I would lean towards the L2 VLAN. While some have expressed concerns about a loop on the VLAN, but in 12 years on big networks, I haven't EVER seen a loop created on a network management VLAN.

Not to say it couldn't happen, but generally people who know enough to set up a management VLAN generally know enough not to be causing loops on the network. Most loops I have come across are on user VLANs where an end user connected/configured something incorrectly or when a server admin misconfigures link aggregation/redundancy on their server or misconfigures a VM environment.

Moving to a L3 approach does avoid that particular problem, but it is also easy to screw up a routed network as well. Yes, you can take precautions, but I stick with KISS when I can and routing is more complex than switching. Shall we start listing the major incidents that have occurred due to routing problems being introduced to the internet?

Ultimately, as John Jensen has pointed out, you should definitely have an OOB management system as well, however I would generally refer to this as a backup to in-band management. Generally speaking I don't recommend changing speed settings on a console port (when it comes to recovery situations, having to figure out if a console port is default, changed or changed incorrectly can be a pain), and even at 115k baud, console ports can be too slow (and many vendors default to 9600 baud).

| improve this answer | |
  • Does VRF alleviate your concerns of using L3? What other advantages are there to doing L2 over L3 here. I wouldn't think you would want L2 spanned across a large network. – generalnetworkerror Jun 27 '13 at 3:00
1

I would use a separate management VLAN as our colleagues already stated, then traffic vlans as many as required. Furthermore I would be more careful how are you going to interconnect all these switches, what software version run on each device (you have to be sure you run a stable version and most of all do know any reported bug), then plan other things: how do you configure trunks, etherchannels and of course "STP".

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.