Cisco 2901 Router - Creating a Management Interface

[thomas.talley]

Can a Management Interface be created for a Cisco 2901 router? We have a class C network subnet'ed into four networks, one of which is the "Management Network" supporting radius, syslog and ssh.

Thanks

Tom

[Peter Paluch]

Hi Thomas,

Cisco routers of this type do not usually have a dedicated physical management interface. Any interface with an IP address, be it a physical interface or a virtual interface (such as subinterfaces, Dialer interfaces or VLAN interfaces) can be considered a management interface.

However, there is a way of tightening this down. Entering the following sequence of commands in the global configuration mode will cause the FastEthernet0/0 interface to be declared as the only management interface:

control-plane host
 management-interface FastEthernet0/0 allow

With this command, the only management access to this device will be available through this particular interface using any management plane protocol available. In addition, you can limit the list of supported protocols by entering its name after the allow keyword - this is the list of supported protocols as displayed by my 12.4T IOS:

R1(config-cp-host)# management-interface Fa0/0 allow ?
  beep    Beep Protocol
  ftp     File Transfer Protocol
  http    HTTP Protocol
  https   HTTPS Protocol
  snmp    Simple Network Management Protocol
  ssh     Secure Shell Protocol
  telnet  Telnet Protocol
  tftp    Trivial File Transfer Protocol
  tl1     Transaction Language Session Protocol
  tls     Transport Layer Security Protocol
  <cr>

You can designate multiple management interfaces in the control-plane host section.

You can also use a standard ACL to be applied to line vty section using the access-class acl-name in command to limit the access to Telnet and SSH based on source IP addresses. The use of this ACL is independent of the management interface feature described earlier, and they can be combined if necessary.

Best regards,
Peter

[thomas.talley]

It is more of a need to meet government security requirements. It defines RADIUS, syslog, ssh, etc. as management traffic that has to be isolated in its own network. I need to comply. As noted, the 2901 does not have a dedicated Management Interface. I tried to use the second gigethernet port, put when attempting to assign an ip address, it would error with “ip overlap” (something like that). I have tried using vrf. Was able to assign an appropriate ip address and ssh to the router. But it seems that the router could not initiate a connection (i.e. RADIUS auth). I will try the control-plane option.

Thanks

Tom

[Peter Paluch]

Tom,

I do not believe that the definition of the management interface in the control-place section will affect Syslog or RADIUS traffic. Please do have a try, though.

In any case, just as you have noted, you cannot have two routed interfaces of a router in the same IP subnet unless they are in different VRFs. I am not entirely sure why you would want to have two interfaces in the same IP subnet, though, as you have stated in your original post that you have a C-sized network split into four subnets and one of them is the management network - so I assume that these subnets are non-overlapping.

The RADIUS and Syslog traffic will be routed to the destination server according to the routing table. We could definitely set up the routing so that the respective servers are either reachable only via the interface in the management network only. Using the VRFs is even better but unfortunately, while the Syslog can be pointed to a particular IP address in a particular VRF, I have not found any command to limit the RADIUS operation to a particular VRF. Perhaps a solution here would be to do an opposite design: Leave the management and control plane traffic run in the global routing table, and put all user interfaces into a separate VRF. The split will thus be accomplished even despite the lack of VRF-aware RADIUS configuration.

Best regards,
Peter

EDIT: I was wrong regarding the RADIUS and its lack of VRF-aware configuration. There is a way of doing that:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_aaa/configuration/xe-3s/sec-usr-aaa-xe-3s-book/sec-per-vrf-aaa.html

[thomas.talley]

Hi,

The "management-interface FastEthernet0/0 allow" CLI is not available on the 2901 Router. There are only three commands available under "control-plane host".

I will dig deeper into the vrf option.

Thanks

Tom

[Peter Paluch]

Tom,

One more comment. The notion of a management interface is mostly concerned with remote managing of the device, and thus the list of protocols available with the management interface feature is limited to protocols such as HTTP(S), SNMP, Telnet, or SSH. Neither Syslog nor RADIUS is among them because they are not concerned with managing the device. There is, in fact, nothing to tighten down with Syslog or RADIUS because they are not used to access and configure the router, quite the contrary: the router is using them to provide information about itself or request authentication services.

Best regards,
Peter

[Richard Burts]

Perhaps Tom might want to look into the possibility of specifying the source interface used for Radius, and/or syslog, and/or SSH, and/or Telnet, and/or TFTP, and/or FTP, and/or SNMP, and/or whatever protocols are of concern. And if he manages to get an interface configured to be in the "management" subnet then he can specify that IP as the source IP for those protocols.

Tom has not supplied much information about his network and its topology. If there are 4 subnets and if he wants the router to be a part of each subnet then either he needs to use 4 interfaces on the router or he needs to connect a router interface to a switch interface configured as a trunk and have the 4 vlans carried on the trunk. In either case I do not see a problem with configuring one interface to belong to the "management" vlan/subnet. And by specify the source interface for the management protocols he will have isolated the protocols to that subnet.

HTH

Rick

[Peter Paluch]

Hi Rick,

Thank you very much for joining!

I am not entirely sure if specifying the source interface would help - I will explain my thoughts and please correct me whenever I go wrong in my thinking.

Specifying a source interface only causes the source IP address to be borrowed from the specified interface. It does not mean that the packets will be sent out that interface as well. The egress interface is always determined by looking up the destination and the next hop information in the routing table.

In other words, specifying the source interface does not affect the path the packets will go out - it can only influence the path the packets will come back. To make sure the packets go out only through the management interface can be done by simple routing, perhaps even creating /32 routing table entries for the individual servers pointing out the management interface directly, and another set of the same /32 entries with a higher administrative distance pointing to Null0 in case the management interface goes down (to make sure the management traffic does not spill out into other network, possibly because of summarization or default routing). Interestingly enough, if using these static routes, the egress interface is "nailed" to be the management interface - in which case it does not make much difference to specify the source interface at all.

It appears that the VRF approach would be probably the most sane approach, provided that all services can be forced to operate in that VRF. Interestingly enough, some Cisco platforms with built-in management Ethernet interface automatically place it into a hardwired VRF for management (I recall some 3750-X doing this if my memory serves me).

Best regards,
Peter

[Richard Burts]

Peter

You make interesting and valuable points. I agree with your analysis.

HTH

Rick