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. _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
