Sanely leaking a locally sourced default route from one VRF into another (IOS)

[jlixfeld]

I have an edge-facing PE router that has a full table inside vrf inet.  That edge PE speaks MP-BGP as an RR to a few other PEs that don't have the capacity to handle a full table but need access to the world via vrf inet.  Those PEs receive internal+default from this edge PE to facilitate that reachability.  This default route is a static default to null 0 with a network statement for 0.0.0.0.  This all takes place on said edge-PE and works fine and dandy.

The issue now is that I have vrf resi that I need to anchor to this edge-facing PE router and vrf resi needs access to the world via vrf inet too.  The other devices inside vrf resi could be considered managed CEs for all intents and purposes.  These managed CEs speak ISIS to the PEs, so I use default-information originate inside the ISIS process in vrf resi to give the CEs a clue.

I've leaked the default from inet into resi using a combination of 'import route-target' statements and 'import map' statements on the PEs as required.

What's happening though is that inside vrf resi on the edge-PE, the leaked default from vrf inet is pointing to null 0.  This effectively black holes the traffic inside vrf resi when the desired behaviour was to use that leaked default to pull traffic from vrf resi into vrf inet where it has a longer match to the destination:

*Dec 11 01:05:47.362: IP: s=200.0.0.1 (FastEthernet2/1), d=13.13.13.13, len 100, input feature

*Dec 11 01:05:47.362:     ICMP type=0, code=0, MCI Check(62), rtype 0, forus FALSE, sendself FALSE, mtu 0

*Dec 11 01:05:47.366: FIBipv4-packet-proc: route packet from FastEthernet2/1 src 200.0.0.1 dst 13.13.13.13

*Dec 11 01:05:47.366: FIBfwd-proc: resi:0.0.0.0/0 proces level forwarding

*Dec 11 01:05:47.370: FIBfwd-proc: depth 0 first_idx 0 paths 1 long 0(0)

*Dec 11 01:05:47.370: FIBfwd-proc: try path 0 (of 1) v4-ap-Null0 first short ext 0(-1)

*Dec 11 01:05:47.370: FIBfwd-proc: v4-ap-Null0 valid

*Dec 11 01:05:47.370: FIBfwd-proc: Null0 no nh type 3  - deag

*Dec 11 01:05:47.370: FIBfwd-proc: ip_pak_table 2 ip_nh_table 65535 if Null0 nh none deag 1 chg_if 0 via fib 0 path type attached prefix

*Dec 11 01:05:47.370: FIBfwd-proc: resi:0.0.0.0/0 not enough info to forward via fib (Null0 none)

*Dec 11 01:05:47.370: FIBipv4-packet-proc: packet routing failed

*Dec 11 01:05:47.370: IP: tableid=2, s=200.0.0.1 (FastEthernet2/1), d=13.13.13.13 (Null0), routed via RIB

*Dec 11 01:05:47.370: ICMP: dst (13.13.13.13) host unreachable sent to 200.0.0.1

So obviously my methodology is flawed.  Is there a better way for me to do this?

Thanks in advance for any insight.

[Mohamed Sobair]

Hello,

This is due to the next-hop which is unreachable by the Edge PE in vrf resid.

Obviously, the RR edge PE doesnt change the Next-hop attribute when it advertises the default to the Other PEs into VRF resid.3  from VRF inet.3.

What you need to do is to change the next hop attribute when advertising this default from the Edge PE to the other PEs using a route-map.

Regards,

Mohamed

[jlixfeld]

Hi,

Thanks for the info.  I should have been more clear.  The default route in vrf inet is anchored on the same PE that is anchoring vrf resi.  This isn't a BGP issue because there is no announcement of this default route, it's just the route being leaked from one VRF to another on the same PE.

[Mohamed Sobair]

Then You need to leak both ways.  When vrf resid recieves a default from vrf inet, vrf inet doesnt know how to route traffic back to vrf resid, this is because it doesnt have info about vrf resid subnet source. You need to leak vrf resid Source Subnet into vrf inet as well to have connectivity.

Regards,

Mohamed

[jlixfeld]

That's already been done.  VRF inet has reachability to vrf resi.  I can verify this by doing a debug ip packet detail and debug icmp.  The issue lies on the PE where the default is being leaked.  The debug in the original post is taken from that very PE on the packets coming back from the host in vrf resi trying to reach the source again in vrf inet.

[Mohamed Sobair]

The Debug logs shows that vrf resi source recieves ICMP destination host unreachable message from the router for destination 13.13.13.13.  The router send this message to the ICMP source if its only doesnt know how to reach the destination (13.13.13.13).

I can see from the FIB enties it tries to route packet sourced from 200.0.0.1 to dst 13.13.13.13 using a default route 0.0.0.0/0, However this default points to Null0. Why is it so? You need to check if the nexthop on this VRF (resid) The original nexthop when the default is imported is not changed whether is reachable or not. when Vrf resid doesnt know how to reach the nexthop OR the next hop doesnt know how to route packet back to source 200.0.0.1 , it will lead to packet being dropped.

However, the issue here rely on VRF resid which have a default pointing to Null0, why is it so?

Regards,

Mohamed

[p-smallwood]

Hi jlixfeld,

Did you find a solution to this?

Regards,

Peter