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

[Olivier Benghozi]

I realise I wrote by mistake «next-hop» instead of «next-table» about everywhere :)

> Le 10 févr. 2020 à 05:51, Olivier Benghozi <olivier.benghozi at wifirst.fr> a écrit :
> 
> 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 no-vrf-advertise VRF (config knob normally used in hub and spoke architectures), so it doesn't export its content toward other PEs , but only locally (auto-export).
> 
> Each time we have a discard route in an origin VRF that we need to import in some other VRF (local or not, but let's say local), we create a copy of this route in this special VRF, with a next-hop attribute instead of the discard, and a special community.
> This is this route that is finally imported by other various local VRFs using auto-export (so the import policy is the same for all routes for any MPLS VPN, local routes or not).
> 
> Additionally:
> - all the normal VRFs have a first term in their export policy to prevent the re-export of those special imported routes (based on the special community – this is because no-vrf-advertise imported routes become exportable to other PEs once locally imported in another VRF using auto-export).
> - in all our import policies, importing static (but also aggregate, in fact all but bgp), get its preference changed to more than 5 (default static preference – we use 168 but whatever), so once the next-hop route is imported in the VRF that contains the former discard route, no route loop ensues (the next-hop route is Inactive because of Route Preference).
> 
> Toward the other PEs, the «true» discard route is exported from its VRF.
> 
> 
> In importing VRFs, the imported next-hop route wins over the imported discard route (Inactive reason: Number of gateways).
> 
> 
> The goals behind all this stuff were to:
> - avoid creating a next-hop route in each VRF that needed the route
> - keep the same import/export policy standards for about all the VRFs
> - use the same conf whatever the null/discard route is to be imported in local or distant VRFs (no difference like on IOS/SEOS and so on)
> - use auto-export, so no need for ribgroups (much closer to what was done on other vendors gears)
> 
> 
>> Le 10 févr. 2020 à 04:50, Nathan Ward <juniper-nsp at daork.net <mailto:juniper-nsp at daork.net>> a écrit :
>> 
>> 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 <mailto:ljones at bluphisolutions.com>> wrote:
>>> 
>>> Try a tunnel (lt) interface.
>>> 
>>> 
>>> -------- Original message --------
>>> From: Nathan Ward <juniper-nsp at daork.net <mailto:juniper-nsp at daork.net>>
>>> Date: 2/9/20 6:08 PM (GMT-09:00)
>>> To: Juniper NSP <juniper-nsp at puck.nether.net <mailto: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?
>