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

[Nathan Ward]

On 29/08/2023 at 6:48:32 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.
>

I spent a bit of time working on this problem years ago, and ultimately
there didn’t end up being any ideal solutions. Looking at rancid, it looks
like 7+ years ago. We ultimately ended up on JunOS, too.

We were learning a default from an eBGP peer on the same node, so we were
able to leak that in to the other VRF and get more or less what we wanted -
but it wasn’t ideal.
I can’t recall if it would do a route lookup in the VRF that had the eBGP
peer or not, I have a funny feeling it did what we wanted it do, though.
Obviously for packets coming from other PEs following that default, it
would work as desired (we were running per-VRF labels). Perhaps you could
experiment with that. If it does a route lookup, you could run a BGP
session over a hand-bag cable so that you have an eBGP default you can leak
- and in theory only traffic that doesn’t match your DFZ routes would go
down that link. Messy, but, might work?

>From memory, if you create a static default and leak that, it follows
wherever that default goes, and doesn’t follow the logic you would expect
for label mode per-vrf - so if it’s a default to null, the packets get
dropped. Default to a vrf with a next-hop - packets go out to that next-hop.

--
Nathan Ward