Management to VRF Interface on 1841 relying on default route

Question

I couldn't find this in any of the bug lists, has anyone come across this scenario before:
I have an 1841 router, running: c1841-advipservicesk9-mz.124-25f
This router has multiple loopbacks in different VRFs, loopback 0 is in the global context, loopback 1 is in the "ADMIN" VRF (there are multiple other VRFs, but there is nothing special or unique in the config between them, so I'll just stick with loop1, the behaviour is the same for all VRFs)
The routing table contains an all-zeros route:
show ip route vrf ADMIN
Routing Table: ADMIN
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is 10.254.144.13 to network 0.0.0.0
     10.0.0.0/8 is variably subnetted, 330 subnets, 7 masks
B       10.254.156.104/30 [20/0] via 10.254.144.13, 3d23h
[etc etc]
10.254.144.13 is the next hop for all networks in the ADMIN VRF, this router is not dual attached.
My PC sits behind a firewall outside the MPLS network, the VRFs in the MPLS network rely on a default all-zeros route into the firewall - hence there is not specific route for the subnet my PC is on.
From my PC, I can ping the Loopback1 address, however I cannot get to any management services (ssh, telnet, http or https) via loopback1. When I add a static route for my PC (/32) (or for the entire 10.0.0.0/8 network - which is my current work around), I can then ssh or telnet etc to Loopback1.
Loopback0 (in the global context) works fine regardless of if it's relying on the all zeros route or not.
Anyone seen this before? It appears to be a bug in the IOS that management services do not look at the default route within a VRF?

Answer 1

You can generate a default route with the following command:
neighbor 1 default-originate
and you need to have a default route in the routing table. This will get the PE to generate a default route to the CE.