7

I've been asked to assist in the design of a "OOB" management network, but I have a limited number of resources available. I have the following:

  1. 1 Cisco 3750-X stack pair w/ a C3KX-NM-1G network module in each.
  2. 8 Cisco 2960-24TC-L "aggregate" switches.

We run a Layer 2 Collapsed Core network topology with a Cisco 6509-E VSS core. We have 128 access switches connected to our core via 1Gps Port-Channels. It's a mix of copper and fiber uplinks. Fiber to the second floor and copper in our datacenter.

The current thinking by our consultant is to configure the management SVI on each of our access switches with their own VLAN uplinked to our 2690 "aggregate" switches. The aggregate switches will in turn be uplinked to the 3750-X stack via a 802.1q trunk and configured with IP Unnumbered to emulate a Layer 3 link bypassing, in essence, L2 communication between the production access switches. The 3750-X stack will have a Loopback configured for each individual VLAN that the production access switches will use as a Default Gateway.

The idea/concern is that we do not want our management network to pass STP traffic through to the other access switches or risk any sort of network convergence between the two separate networks. Kind of a "Poor Man's" Private VLAN setup.

I'm wondering if this is the best or most efficient way to set this up or if there is a better way to go about it.

8
  • am i understanding this correctly? 128 switches in one vlan?? – Mike Pennington Jun 26 '13 at 19:33
  • On the production network we have over 250 VLANs. On the tentatively designed OOB management network there would be a VLAN per Access Switch that we are managing. (Excluding devices that have a dedicated management interface of course) – JDGray Jun 26 '13 at 19:43
  • what type of spanning tree are you running? pvst, rapid pvst, rstp, or mst? – Mike Pennington Jun 26 '13 at 19:46
  • Rapid PVST (VTP Transparent mode) The decision to create a OOB management network stems from an outage that we had related to STP where we lost all connectivity to our in-band management network. – JDGray Jun 26 '13 at 19:48
  • 1
    rapid pvst is the best spanningtree for this topology... you might even consider a direct thirty bit routed interface on the vss chassis if that could completely eliminate spanning tree altogether... – Mike Pennington Jun 26 '13 at 19:53
7

I know the 3750X's have a management interface on the back which is a 10/100 Fast ethernet port. Its right next to the RJ-45 console port. I also believe that the 2960 switch that you listed there also has a management port on the front of it, above the SFP ports.

Assuming your switches aren't too far away, you could use the management interfaces to manage your devices remotely if you will. Of course you would require additional cabling back to another "management switch" which would likely contain the VLAN required just to manage these devices.

Otherwise, you could also run a terminal server server such as an OpenGear or something of that nature and have the console connections linked back to this device in order to remotely control them if your entire network is having issues or what not.

These management interfaces do operate on their own VRF and will also not participate in STP as they're not running on the active VLAN that is being trunked down to them. However, I have seen it where some organizations like to have the management VLAN on the same subnet as the hosts on the switch. This allows them to ping and check the arp table/mac address table and pinpoint where devices are a bit easier than if it was just a simple L2 network. There are of course pro's and con's to each method, however, given that you wanted to go about a out-of-band method. I would say the management interface is probably is your best direction.

4
  • 3
    You SHOULD have RS232, so OpenGear, old cisco CPE with assync port or comparable. The ON-BAND management interface is optional luxory, it has almost no benefit to managing the switch over the production links. It completely fate-shares same IOS and same control-plane. At least via RS232 you can break it to rommon and reload. – ytti Jun 26 '13 at 6:09
  • 1
    @ytti very true! the on-band management interface also allows you to TFTP and FTP images to help upgrade the switch and etc. I agree that RS232 management should always be present unless you have someone standing-by with a console cable in a dire emergency. – knotseh Jun 26 '13 at 6:17
  • 3
    You can use the production datapath for TFTP/FTP as well. The on-band management interface typically is not ASIC/NPU connected but sits directly in the control-plane, this means you cannot protect it from the device itself. Which means even accidental stuff, like loop in your NMS network could bring down all your devices at once. If you are going to use it, limit access to it in very strict manner from the NMS switch. (the real solution to this is 'CMP', true 'lights out ethernet' using different HW and SW inside the device, alas only few devices in networking world have this) – ytti Jun 26 '13 at 6:38
  • Our Cisco 2960 switches do not have any management interfaces. This is one of my concerns with it being our "OOB" network since the interface that we use on our access switches as the "management" port will still be on the traffic-plane. I tried to sell them on using a console based system for out of band management, but they insisted that they wanted to do it this way in order to facilitate the upgrade of the IOS if need be. However, they did sign off on us running dedicated console cables to each access switch and purchase the console switches, likely Avocent, the next fiscal year. – JDGray Jun 26 '13 at 19:29

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.