Back to Home

Create dedicated Cisco management interface

It is a best practice to have your production network devices connected to their respective production networks and also to an out-of-band network, for strict management purposes. Most Cisco switches, such as a Cisco Nexus 5k or a Cisco Catalyst 2960-S have a built-in physical management interface. This interface is often different from the other interfaces on the switch, in that it has it’s own default gateway to keep the out-of-band routing self-contained in the out-of-band network. On the Cisco Nexus, the interface is assigned to a default management VRF.

Not all switches have this dedicated management interface implemented in hardware, so we can create one, mocking the intended design of a physical management interface. To do this, we have to do a few things (this method is intended for use on L3 catalyst switches):

  1. Dedicate an interface on the switch for management purposes, to be connected to your out-of-band and/or management network.
  2. Create a separate “management only” routing/forwarding table, aka VRF
  3. Assign your dedicated interface to use this management VRF, via SVI

On the Cisco Catalyst, when licensed for VRF usage, this can be achieved. I am using a 3560-CX running IOS 15.2, which does not have a dedicated managment interface.

To start, you need to prepare you physical interface. You need to assign it to your respective management/OOB VLAN, my example uses VLAN 10.

sw1.lab1#conf t
sw1.lab1(config)#int gi0/9
sw1.lab1(config-if)#description "Management VRF intf"
sw1.lab1(config-if)#switchport mode access
sw1.lab1(config-if)#switchport access vlan 10
sw1.lab1(config-if)#exit

Next, we need to prepare the VRF before associating our new interface to it. Note that I create the vrf definition and then I enter the IPv4 address-family, entering the address-family is mandatory and your VRF will not route/forward IPv4 traffic if this does not exist. If you intend to use IPv6 for management on this switch, also add it’s address family.

sw1.lab1(config)#vrf definition management
sw1.lab1(config-vrf)#address-family ipv4
sw1.lab1(config-vrf-af)#exit-address-family
sw1.lab1(config-vrf)#exit

Now that the definition is created, we can add a route to our new VRF! Since this is for strict management purposes and we don’t need to inter-vlan route, we only need to add a default route, which will mock the default-gateway command used on a Catalyst switch with a dedicated physical management interface.

sw1.lab1(config)#ip route vrf management 0.0.0.0 0.0.0.0 10.10.0.1

With this method, we are utilizing a SVI, so this needs to be created (for the respective VLAN). If it has not been created already, create it and assign it to your new VRF with the ‘vrf forwarding VRFNAME’ command

sw1.lab1(config)#int vlan10
sw1.lab1(config-if)#vrf forwarding management
sw1.lab1(config-if)#ip add 10.10.0.100
sw1.lab1(config-if)#end
sw1.lab1#wr mem

This complete the configuration and you should now be able to reach your switch via the new management VRF. Note that if you had the SVI created before adding it to the VRF, it may have deleted IP related information such as IP address, etc. and also, this traffic will be routed using your new default route which you added to the management vrf, so make sure that the next hop device that you set is able to route back to the intended management workstation.

If you have any questions or comments, please leave them below!

Moved blog to jekyll on nginx on docker

Intro to IPv6 BGP peering