Out-of-band (OOB) network interface configuration guidelines

Unanswered Question
Nov 26th, 2008


More and more Cisco switches have a dedicated RJ45 management interface (ie. C3750E, C3120X, etc..). Are there any best-practises on how to use/configure these ports ?

1) These interfaces typically do not participate in routing. So my default route, received through IGP, typically points to an inband production interface.

Does this mean that packets are received on the OOB interface, but are sent inband ? In a layer2 environment, does my "ip default-gateway" command need to point to OOB or inband ?

2) Is it recommended to have both an inband and out-of-band management ip address ? A loopback in L3 environments or a dedicated management VLAN in L2 environments ? How to deploy both without running into problems (see below)

3) We use TACACS authentication with verification of the source ip address. For this, we have to fix the source ip address with the "source-interface" option for telnet,ssh and tacacs. How to deploy the oob-interface in this environment ? When the OOB or production interface is lost, will we loose TACACS connectivity to the switch, because the source ip address changes and is now refused ? Do we need to add all switches into tacacs with two ip addresses: inband mgmt and outbound mgmt address ?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
leciscokid Wed, 05/04/2011 - 19:17

First, we  need to identify that Out of Band means "not in the data-plane of your network."

e.g. this is not for remote access outside the Management Lan, nor is it supposed to be routable. All of those Management interfaces can share a similar IP plan, however they should be in the same broadcast domain, and reachable only via a bastion host that is physically connected to that VLAN, with no SVIs or any egress L3 interface out of the Management LAN. Most legacy designs do not factor in this level of security, and thus it's difficult to deploy new devices in this fashion since typically your ACS boxes will be on a Server VLAN, or hanging directly off the core in a Services LAN.

You should have a segmented, L2 only environment for your OOB management interfaces. Meaning, that if you need some type of ACS connectivity, or any other type of connection to those Management interfaces, you should design your AAA infrastructure accordingly. Lock down AAA to that interface, and point the TACACS server group to a host on that L2 only network. SSH configs should have ACLs applied such that only traffic sourced from that bastion, would be allowed to connect.

For example, if you're running OSPF, and your source address is Lo0, then you could also have an Lo1 with an ip of, which is non-routable, and only accessible via the Management LAN. Perhaps your AAA server may have a L2 only Leg into this LAN, with an interface address of Your advertised address space may be in the /16 space, and shared to your Peers via the IGP. However, there would be no way to telnet, SSH, etc. into those devices from any 192.xxxx source. Because you've locked it down to only the 5.x.x.x network.

Remember, an interface, logical or otherwise, can participate in a LAN within it's own broadcast domain, without any routing, by nature of ARP, and broadcasts. So it doesn't need a route, or gateway, or a routing protocol. If a frame is sent on that management LAN, destined for 5.5.5.x, the interface will hear that frame, and will respond, since it's locally connected.

Also, in the case where you need to provide multiple interfaces to source specific apps from (e,g, routing protocol updates, AAA, or tunnel interfaces.) best practice generally dictates that you provide a separate loopback interface for these functions.

The management interfaces are there because of the need to physically segregate those management interfaces into an Out of band scenario. Otherwise there would be no purpose in making that physical change to the device, to add a management only interface. We could simply use a loopback on the device, which could be accessed via the ingress port from the LAN.

You should not allow, nor should you want, the ability to SSH from the production network, into any device. Design your monitoring, AAA, and logging solutions to accommodate the Management LAN only for those functions, and let the routing protocols network services like NTP ride the production wire.

Message was edited by: leciscokid, type-o


This Discussion