[j-nsp] how to leak aggregate/generated routes while modifying next-hop

[Olivier Benghozi]

Hi,

I actually use such a method (but with static discard routes, not generated/aggregate), with auto-export feature for local import/export (no rib groups). The goal was to import routes using communities, basically the same way for local and i-MP-BGP routes, without having local routes throwing the traffic to discard. For reference, this "just works" in our Ericsson/Redback SmartEdges gears without any trick (there's an additional destination lookup once the packet "enters" a VRF), but I had to find this tricky method on our Juniper gears.


The solution I implemented:
the original static route (next-hop: discard) in the former originating VRF is still there (and exported to other PEs if needed, as before). This route is also imported locally by other VRFs that want it, but stays inactive in them (see below).
an additional and completely separate VRF ("aggregate" VRF, poorly named since it only contains static routes) :
dedicated to such static routes generation, with next-table bla.inet.0 instead of next-hop or discard.
configured with no-vrf-advertise (so those special routes are never advertised to other PE from this VRF, they stay local)
with appropriate community configured on these static routes so they are imported by the targeted local VRFs (of course)
with a generic special community, recognized by all VRFs in their export policy, so those routes are not re-exported to other PEs once there are imported in a VRF (since I use no-vrf-advertise, that inverts the normal way of doing with primary/secondary tables)
this solution also allows to have a route to table X and a route to table Y, with each ones importing them (normally you cannot commit a config if in a VRF X you have configured a static route to next-table Y, while in the VRF Y you have configured a static route to next-table X)



Here is an example of a default route that we originally wanted to export from an "Internet" VRF to a "srv" VRF (here the first route comes from the "special" VRF, and the second one from the "originally originating VRF for this route", that is the "Internet" VRF. The first one is the active one because of "Number of gateways"; found by experimentation but it acts the way I needed :)
Preferences are here at 170 since I change all locally imported routes to 170 as if they were coming from another PE (to be consistant with other brands of PE we have; and to be sure that a "special route" doesn't compete with the "former route" in the "Internet" VRF in this case). Useless lines are deleted.

In the importing VRF:

srv.inet.0: 119 destinations, 228 routes (119 active, 0 holddown, 0 hidden)
0.0.0.0/0 (4 entries, 1 announced)
        *Static Preference: 170/-54001
                Next hop: 
                Next table: internet.inet.0
                Next-hop reference count: 8
                State: <Secondary Active Int Ext>
                Communities: xxxxx:65100 target:xxxx:1
                Primary Routing Table aggregate-1.inet.0
         Static Preference: 170/-54001
                Next hop type: Discard
                Next-hop reference count: 52
                State: <Secondary Int Ext>
                Inactive reason: Number of gateways
                Communities: target:xxxx:1
                Primary Routing Table internet.inet.0



In the "original" VRF, those default routes are like this (the active one is exported to other PEs):

internet.inet.0: 556815 destinations, 1780712 routes (556298 active, 16 holddown, 7026 hidden)
0.0.0.0/0 (4 entries, 1 announced)
        *Static Preference: 5
                Next hop type: Discard
                Next-hop reference count: 52
                State: <Active Int Ext>
         Static Preference: 170/-54001
                Next hop: 
                Next table: internet.inet.0
                State: <Secondary Int Ext>
                Inactive reason: Route Preference
                Communities: xxxxx:65100 target:xxxxx:1
                Primary Routing Table aggregate-1.inet.0


And in the "aggregate" VRF (the real route active in the "srv" VRF):

aggregate-1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop: 
                Next table: internet.inet.0
                Next-hop reference count: 8
                State: <Active Int Ext>



Probably other methods may be simpler, but once you find something that works without issue... :)



regards,
Olivier Benghozi


> Le 16 nov. 2015 à 14:59, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> a écrit :
> 
> Hi folks,
> 
> Is there a method of leaking aggregate/generated routes to other VRFs so that the next-hop is modified to actually point to table where the agg/gen routes where created rather than bit bucket please?
> 
> Thank you.
> 
> adam