[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