[c-nsp] "next-table" Equivalent for IOS XR - Default Route into Global Routing Table

[Fraser McGlinn]

Would this be a case where vasi-left and vasi-right interfaces are appropriate? Essentially same as an LT in Junos.
Not as elegant for sure, but should function.

Cheers,
Fraser

> On 29 Aug 2023, at 4:48 pm, Mark Tinka via cisco-nsp <cisco-nsp at puck.nether.net> wrote:
> 
> Hi all.
> 
> I've been racking my brain trying to implement an equivalent feature in IOS XR 6.7.1 similar to Junos' "next-table" feature.
> 
> Essentially, I am trying to point all unknown destinations from within a VRF toward the local global table for resolution. In Junos, it's as easy as:
> 
>   static {
>             route 0.0.0.0/0 next-table inet.0;
>         }
> 
>   rib VRF.inet6.0 {
>             static {
>                 route ::/0 next-table inet6.0;
>             }
> 
> In IOS XR, we have:
> 
> vrf VRF
>   address-family ipv4 unicast
>    0.0.0.0/0 vrf default
> 
> vrf VRF
>   address-family ipv6 unicast
>    ::/0 vrf default
> 
> The Junos one works straight out of the box.
> 
> IOS XR is a bit more petulant.
> 
> And if you look at the VRF FIB, the route exists:
> 
>     S*   0.0.0.0/0 [1/0] via 0.0.0.0 (nexthop in vrf default), 00:15:06
> 
> But CEF says it is a "drop", likely because there is no associated output interface.
> 
> The most I could do was to point the static route out via "vrf default", but to another PE device that carries the DFZ (with its Loopback address as the target). This works well, but surely cannot be expected to be a lasting solution, because the router on which this VRF is configured already carries the DFZ. So why send the traffic to another PE router and cause it to handle traffic it should not be handling?
> 
> I've given up and just swapped the IOS XR box with a Junos one, and fixed the issue that way.
> 
> But for posterity, has anyone ran into this and came up with a working solution, or is IOS XR just deficient in this regard? I don't understand the point of being able to point default to the global table in a VRF, and then not be able to actually use it. Thanks.
> 
> Mark.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/