Single Cisco IOS device in a remote DC, I have an OOB connection delivered into the rack (length of Cat5e into my rack from another onsite providers rack, who have diverse routes from my own, in and out of the building) which is simply a L3 connection to the Internet, a /29 is delivered down it.

VTY access via Telnet or SSH is typically limited by an access list to on-net devices, with IPs local to the network/AS. This remote router is in a PoP with long-haul Ethernet circuits back to the core network. The OOB connection would be used in emergencies by off-net devices (such a broken link, dead IGP, etc), with connections coming from potentially any IP or Autonomous System around the world.

If we theorise that the device is configured as below, with the OOB interface configured with a public IP from the OOB connection provider;

Interface Fa0/2
 Descriptioc OOB Connection
 ip address
line vty 0 4
 access-class 10
access-list 10 remark ACL-ON-NET-MANAGEMENT-IPS
access-list 10 permit

My question is essential two really;

How do I handle a scenario during which the devices has a L3 melt down, and it can't route traffic out of the PoP because IGP has collapsed or similar; the routing table has emptied its self now containing only locally connected routes. If I'm on holiday and connect to the OOB IP from some Hotel Wi-fi, traffic isn't going to have a route back to my remote IP if IGP has collapsed and the devices have lost their peers.

I could put the OOB interface Fa0/2 into a VRF and add a static 0/0 route via the OOB provider gateway address within the /29 they have assigned to me. I could change the vty statement to be:

 access-class 10 in vrf-also

To allow management access from the VRF interface, but this will clash with my ACL. I would need to add 0/0 to the ACL, removing the point in having the ACL. Can I keep the ACL as it is, but allow any IP to connect when connecting to the OOB interface specifically?

Perhaps I can use a route-map some how to route any traffic that come in from the OOB interface back out via that gateway? Or don't use a VRF, and add a route to the default table with metric 254, and add an ACL outbound on the OOB interface that only allows out traffic coming from TCP 22 from that interface's IP (so SSH management traffic). That way only management traffic would be allowed out? I'm lost for idea's here.

  • are you using two-factor auth (such as Secure-ID) or just simple username-passwords for authentication to this router? – Mike Pennington Jul 27 '13 at 17:43
  • I'm sorry but there's something i can't understand. How could you avoid 0/0 in ACL 10 if you're wondering how to connect form $HOTEL room? – Marco Marzetti Jul 28 '13 at 10:16
  • @MikePennington Just username and password for now, to keep things simple whilst testing – jwbensley Jul 28 '13 at 11:42
  • @MarcoMarzetti I don't know how I can avoid that? This is my conundrum, can I have a separate ACL for an interface in a VRF? – jwbensley Jul 28 '13 at 11:43
  • 1
    Does this ACL 10 appear on all your VTYs, if not maybe a 'jump host' approach. Also if you are connecting back from a Hotel, what ever you are connecting to is giving you an IP address on your network – fredpbaker Jul 28 '13 at 17:33

Depending on the hardware you're talking about you should take different considerations.

For instance Cisco provides a dedicated set of port/RAM and flash for OOB access on SUP2T, so you would be able to access to your device even when RP hangs. OTOH, in some Juniper boxes, the management port is attached directly to the RE and so you should easily hang your router from there.

That said, I would recommend you to put a management CPE between your devices and your OOB internet access and set up a GRE tunnel between it and your central management server.

| improve this answer | |
  • Sadly logic does not allow for me to have my desired scenario. A separate device is required (and probably best). Cheers. – jwbensley Aug 6 '13 at 11:57

I'm dealing with similar issues. From my experience the best thing is to have a dedicated management processor which is always accessible and independent of Sup/routing engine. You did not specify what type of router you have. In your situation i would rely on a small ASA (5505 maybe?), connect it back to back with this router's OOB interface and bring up SSL VPN. No need for a default route, except if you want to do some monitoring via this connection. And you still need the ACL on the VTY lines.

| improve this answer | |
  • In this scenario, I agree with fredpbaker that a jump box is probably the way to go. This is a good idea though, so thanks for this idea. If it is more than one device I need access to (just one, is not very common) then I do go down this route of a seperate device, but user a serial server instead. – jwbensley Jul 30 '13 at 22:20

Your Answer

