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

[Adam Vitkovsky]

Hi Oliver,

I see, but if you manually created a static route with the correct next-table in the special/dedicated "aggregate" VRF, wouldn’t it be then easier to just manually create the static route in the particular service VRF itself?
But I agree this way you define the routes just once and then leak tem to all the local VRFs that need them.

I’m looking for something automatic (but I guess I’d have to stick with manually defined routes)
I found out I can do the following but it does not work:

set policy-options policy-statement TEST_DEFAULT_ROUTE_INJECTION_FIB term DEFAULT from route-filter 0.0.0.0/0 exact
set policy-options policy-statement TEST_DEFAULT_ROUTE_INJECTION_FIB term DEFAULT from rib TEST_DEFAULT_ROUTE_INJECTION.inet.0
set policy-options policy-statement TEST_DEFAULT_ROUTE_INJECTION_FIB term DEFAULT then next-hop next-table INTERNET.inet.0
set policy-options policy-statement TEST_DEFAULT_ROUTE_INJECTION_FIB term DEFAULT then accept

set routing-options forwarding-table export TEST_DEFAULT_ROUTE_INJECTION_FIB

It does not alter the next hop for some reason



adam

> From: Olivier Benghozi [mailto:olivier.benghozi at wifirst.fr]
> Sent: Monday, November 16, 2015 3:19 PM
> 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) :
> o dedicated to such static routes generation, with next-table bla.inet.0
> instead of next-hop or discard.
> o configured with no-vrf-advertise (so those special routes are never
> advertised to other PE from this VRF, they stay local) o with appropriate
> community configured on these static routes so they are imported by the
> targeted local VRFs (of course) o 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) o 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
>
>
>
>               Adam Vitkovsky
>               IP Engineer
>               Tel: 0333 006 5936
>
>
>



        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.