Out-of-band management provides a way to log into your network devices without going through the same network through which the data travels.

There are several reasons you might want to do this, security being the most common reason. If you have any routers, switches, or firewalls that directly handle internet traffic, it’s a very bad idea to have these devices open to management access from arbitrary internet addresses. There are ways to lock things down so that only you can access these devices over the internet. But it’s better still if there’s no management interface presented to the internet at all.

Sometimes people use out-of-band management for internal networks as well, just to ensure that production application traffic never mixes with management traffic.

Another common reason for out-of-band management is to allow emergency access to physically remote devices in case the primary network becomes unavailable. It’s often really handy to have a special back door you can use to troubleshoot whatever problem has broken your main network.

You might want to use out-of-band management if an external company is managing some or all of your network devices. It prevents the external company from accessing the data on your network, while still allowing them to access the network devices.

There are three main ways of doing out-of-band management. Selecting the right method depends on your goals.

1. Modems

One traditional out-of-band management method is to connect a modem to the console port of the network device. This method has several obvious limitations. It requires that you have a phone line and modem for every device being managed, so it doesn’t scale well. You can only log in to a few devices at one time. And it’s extremely difficult to secure modem lines. Even if you have user IDs and strong passwords on every device, anybody who can guess or stumble across your modem phone number can at least prevent you from accessing it by just tying up the phone line.

In some cases, people will have the modem physically turned off when not in use. Somebody at the remote site must turn it on to allow access. Turning a modem off addresses the security issue, but makes it even harder to get access when you need it.

Also, modems and phone lines tend to be very slow. If you have to download new firmware into the device this way, you’ll need a lot of patience. And each time you’ll have to cross your fingers that it doesn’t drop the call halfway through the download.

2. Terminal servers

A terminal server is a device with a lot of low-speed asynchronous serial interfaces. You then connect these serial interfaces to the various network devices in the remote location. This is most useful when there are lots of devices to manage. The terminal server itself could be a special purpose appliance like an Avocent device, or it could be just a router (like a Cisco 3925) with a couple of high-density, low-speed async serial modules.

Access to the terminal server is usually over a separate network, although you could just as easily connect a modem to the terminal server and connect to it over a phone line. An Ethernet connection is the most common method. Typically each port is given a TCP port number. You Telnet to the IP address of the terminal server on the port number that corresponds to a particular device console connection.

For both the modem and terminal server out-of-band management options, you configure the console port of the network device exactly as you would for a normal terminal (or laptop) connection:

!
line console
 login
 exec-timeout 5 0
!

It’s crucial to include an “exec-timeout” on the console when using either a terminal server or modem. If you don’t, the line might hang for some reason, and you’ll never be able to get back in. Or, even worse, if you disconnect but the device doesn’t end the session properly, the next person logging in will just take over your session without having to enter any credentials, which isn’t exactly secure.

3. Separate management network

The trick with putting your management interfaces on a different network is arranging to make these interfaces inaccessible from the main network. This is easier for some devices than others. For example, on a pure Layer 2 switch that doesn’t do any routing, all you need to do is assign the management switched virtual interface (SVI) to the VLAN that lives in the management network.

!
interface vlan100
 ip address 10.1.1.100 255.255.255.0
!

Note that I really don’t like using VLAN 1 for my management interface, even though that’s the default. VLAN 1 is the usual default native VLAN on a trunk interface. If my management VLAN is the same as the native VLAN, the management interface is exposed to a possible VLAN hopping attack. It’s a hard attack, but it’s still good practice to avoid exposure.

The best way to create an out-of-band management interface on a Cisco ASA firewall is to use a separate virtual firewall context for management. However, in the case of a firewall, you can also take advantage of the greater control over access control lists (ACLs) to simply block management traffic (SNMP, Telnet, SSH) from using the interfaces in the main network.

ACLs aren’t a perfect solution because the firewall’s routing table includes routes to both the main network and the out-of-band management network. So there could be situations where it’s difficult to separate the management traffic from the production network.

For routers, the ideal solution is to put the management network in a different virtual route forwarding (VRF) instance. The exact configuration required to do this depends on the device type. On Cisco Nexus devices, it looks like this:

!
interface mgmt0
  ip address 10.1.1.2/24
!
vrf context management
  ip route 0.0.0.0/0 10.1.1.1
!

Implicit in this configuration is the fact that all of the other interfaces will be associated with the default or some other VRF.

Configuring multiple VRFs in a router just means it has multiple routing tables. Packets received on a Layer 3 interface (or VLAN interface) associated with one VRF are routed according to that VRF’s routing table. So creating the management interface in the management VRF effectively isolates its traffic to this separate management network.

On an IOS device that supports VRF configuration (which depends on the feature set), you could configure interface FastEthernet0/0 as a management interface in a separate VRF as follows:

!
ip vrf management
 rd 100:1
!
interface FastEthernet0/0
  ip address 10.1.1.2 255.255.255.0
  ip vrf forwarding management
!
ip route vrf management 0.0.0.0 255.255.255.0 10.1.1.1
!

If your IOS device won’t accept these commands, you don’t have the VRF-lite or MPLS feature sets. In that case, enabling out-of-band management over a LAN interface will pretty much require setting up very careful ACLs and possibly also some policy routing.