On Mon, 10 Feb 2020 at 05:08, Nathan Ward wrote:
Hey Nathan,
> Anyone got any magic tricks I’ve somehow missed?
Olivier had a cute trick for this. This issue happens because it's the
same route, there is no resolve-on-import and this is something JNPR
is open to implement where you'd have some
To deal with this on MX stuff a way that looked like we did previously on
Redback gears (old beast but at least on them this «just works» with double
lookup), we use a «third part« VRF. This is a dedicated empty VRF on each
router with only a bunch of static next-table routes. It is a
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
Try a tunnel (lt) interface.
Original message
From: Nathan Ward
Date: 2/9/20 6:08 PM (GMT-09:00)
To: Juniper NSP
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,
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
5 matches
Mail list logo
