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

Mark Tinka mark at tinka.africa
Tue Aug 29 08:28:53 EDT 2023



On 8/29/23 11:40, Nathan Ward wrote:

> 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 tested the same by pointing 0/0 to another PE via the default VRF, and 
that worked. But the traffic was being forwarded through the remote PE, 
which is not sensible.


> 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.

 From my tests, unknown destination traffic was be pulled into the 
global table, and sent to the remote PE configured as the default 
route's next hop in the VRF, which worked. I am guessing that was label 
switched traffic toward default route next hop.


> 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?

Yeah, the site is remote. Don't have the energy for sexiness :-).


>
> 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.

Interesting, I always wondered what the equivalent for Junos' 
"vrf-table-label" was. Thanks for this :-).

So yes, our default routes point to Null0. I changed that to something 
useful and it still didn't work. It's almost as if the traffic exiting 
the VRF toward the global table wanted to follow a label switched path, 
and not an IP-based path. Not sure whether "label mode per-vrf" would 
have helped to obfuscate the fact that the global table default routes 
pointed to Null0, but it's too late to test now. The box has been 
swapped out.

But this is a good tip. I'll ask the next person who runs into this to 
update this post with their experience.

Mark.


More information about the cisco-nsp mailing list