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

[Arie Vayner]

Would something like this work?

https://learningnetwork.cisco.com/s/question/0D53i00000KstGrCAJ/ios-xr-leaking-the-routes-between-vrf-and-global-rib

On Tue, Aug 29, 2023, 7:49 AM 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/
>