[j-nsp] Next-table, route leaking, etc.

[Nathan Ward]

Sure - there’s a number of solutions like that available. LT, next-table routes, etc. LT means more processing than a next-table, but in some ways is a bit less fiddly.

I’m hoping there’s a way to bypass this entirely - making packets following imported routes work the same whether the exporter of the route is local or remote.

> On 10/02/2020, at 4:27 PM, Larry Jones <ljones at bluphisolutions.com> wrote:
> 
> Try a tunnel (lt) interface.
> 
> 
> -------- Original message --------
> From: Nathan Ward <juniper-nsp at daork.net>
> Date: 2/9/20 6:08 PM (GMT-09:00)
> To: Juniper NSP <juniper-nsp at puck.nether.net>
> Subject: [j-nsp] Next-table, route leaking, etc.
> 
> Hi all,
> 
> Something that’s always bugged me about JunOS, is when you import a route from another VRF on JunOS, the attributes follow it - i.e. if it is a discard route, you get a discard route imported.
> (Maybe this happens on other platforms, I honestly can’t remember, it’s been a while..)
> 
> This is an issue where you have a VRF with say a full table in it, and want to generate a default discard for other VRFs to import if they want internet access. Works great if the VRF importing it is on a different PE, but, if it’s local it simply gets a discard route, so packets get dropped rather than doing a second lookup.
> 
> You can solve this, sort of, with a next-table route, but things can get a little messy, so hoping for something more elegant.
> 
> I’m trying to figure out if there’s a better way to do this, i.e. to make it as though packets following leaked routes behave as though they are from a different router.
> 
> Anyone got any magic tricks I’ve somehow missed?
> 
> --
> Nathan Ward
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp <https://puck.nether.net/mailman/listinfo/juniper-nsp>