Faced the same issue and found out that generated route works in my
case. It may be not flexible enough if multiple active next-hops exist
at the same time in the routing-instance, but it's ok for simple
primary-backup scenario.
Kind regards,
Andrey Kostin
-------- Original message --------
From: Nathan Ward <juniper-...@daork.net
<mailto:juniper-...@daork.net>>
Date: 2/9/20 6:08 PM (GMT-09:00)
To: Juniper NSP <juniper-nsp@puck.nether.net
<mailto:juniper-nsp@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?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp