[j-nsp] conditional route import

Alexander Arseniev arseniev at btinternet.com
Thu Mar 16 13:41:51 EDT 2017


Hello,

For this usecase "actual forwarding route where one would like to be 
looking at its attributes like IGP metric to a NH" You'd need either ORR 
(it can take IGP view of the client but it cannot match metric value), 
or make PE to export to a RR the iBGP /32 route for that nexthop IP with 
MED==IGP cost, and do all the logic for MED matching & modifying on RR.

Now You are seeing the power of JUNOS, or are You? :-)

Thanks

Alex



On 16/03/2017 15:25, adamv0025 at netconsultings.com wrote:
>
> Ok got you now, so if I get route X to a “RR” and modify its 
> attributes based on existence of route Y _on export_ to other PEs 
> including the PE that was supposed to introduce the route in the first 
> place, then that would work.
>
> But route X is actually used for forwarding, so it would have to have 
> its NH altered to point to the PE that was supposed to advertise it.
>
> And a copy of route X for PE that was supposed to introduce it –would 
> have to have its next hop altered to point to the egress interface.
>
> Ok so this is how it would work for the very basic functionality, i.e. 
> if route Y exist then alter attributes of a route X that is being 
> introduced to a local AS.
>
> Ok so if I kept these trigger routes in a separate trigger VRF, I 
> could use say:
>
> 1.1.1.120 –to set LP=120
>
> 1.1.1.80 –to set LP=80
>
> 1.1.2.200 –to set MED=200
>
> But for a more complex case where route Y is not just some made up 
> trigger route but actual forwarding route where one would like to be 
> looking at its attributes like IGP metric to a NH, then RR might have 
> a different view than the PE that was supposed to introduce the route 
> into a local AS.
>
> adam
>
> netconsultings.com
>
> ::carrier-class solutions for the telecommunications industry::
>
> *From:*Alexander Arseniev [mailto:arseniev at btinternet.com]
> *Sent:* Wednesday, March 15, 2017 4:16 PM
> *To:* adamv0025 at netconsultings.com; juniper-nsp at puck.nether.net
> *Subject:* Re: [j-nsp] conditional route import
>
> My idea is based on what is working in JUNOS today, it is called 
> "conditional EXPORT".
>
> Yes, unmodified route would be visible only on RR and not used for 
> actual forwarding, that's the purpose of modifying it in 1st place, 
> isn't it?
>
> Your idea to make route attribute change to work conditionally on 
> IMPORT requires adding code to JUNOS.
>
> Your choice what You want to use and when :-)
>
> Thx
>
> Alex
>
> On 15/03/2017 10:23, adamv0025 at netconsultings.com 
> <mailto:adamv0025 at netconsultings.com> wrote:
>
>     Although I’d prefer that the router which introduces the route X
>     to a local AS performs the desired attribute changes to the route
>     X, it doesn’t matter whether it’s the PE or a RR –still the same
>     requirement holds true.
>
>     PE or RR(in your example) needs to look into its routing table to
>     see if route Y exist and based on that change attributes of an
>     _incoming _route X.
>
>     Yes I could change attributes of route X while I advertise it to
>     RRs (on export from VRF).
>
>     -but that would make the PE which introduced route X to a local AS
>     oblivion to routing change that’s apparent to everyone else in the
>     AS, which is not desirable
>
>     adam
>
>     netconsultings.com
>
>     ::carrier-class solutions for the telecommunications industry::
>
>     *From:*Alexander Arseniev [mailto:arseniev at btinternet.com]
>     *Sent:* Tuesday, March 14, 2017 5:57 PM
>     *To:* adamv0025 at netconsultings.com
>     <mailto:adamv0025 at netconsultings.com>; juniper-nsp at puck.nether.net
>     <mailto:juniper-nsp at puck.nether.net>
>     *Subject:* Re: [j-nsp] conditional route import
>
>     Hello,
>
>     If You pass this route to BGP RR and do modifications there before
>     advertising it to target PE, where it is installed with modified
>     parameters then You'd achieve Your objective.
>
>     BGP RR in this case plays the role of "external controller".
>
>     You can even have interface peering extended to BGP RR via
>     L2circuit so PE does not even learn the original route, it
>     installs modified one. This avoids the complexities with sending
>     the modified route back to originator PE I mentioned earlier.
>
>     Hope this makes sense.
>
>     Thx
>
>     Alex
>
>     On 14/03/2017 11:23, adamv0025 at netconsultings.com
>     <mailto:adamv0025 at netconsultings.com> wrote:
>
>         Hi Alexander,
>
>         No in my example I need to modify parameters of route X, based
>         on parameters of route Y.
>
>         That seem to be impossible in current versions of network
>         codes (other than via external controller)
>
>         adam
>
>         netconsultings.com
>
>         ::carrier-class solutions for the telecommunications industry::
>
>         *From:*Alexander Arseniev [mailto:arseniev at btinternet.com]
>         *Sent:* Monday, March 13, 2017 12:28 PM
>         *To:* adamv0025 at netconsultings.com
>         <mailto:adamv0025 at netconsultings.com>;
>         juniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>
>         *Subject:* Re: [j-nsp] conditional route import
>
>         Hello,
>
>         You can do it easily in BGP Route Reflector export policy
>         coupled with other features like ORR and NH rewriting.
>
>         There could be complexities with PE config (obviously, the PE
>         would prefer eBGP route direct from CE vs iBGP from RR) but
>         they can be overcome with routing-instances.
>
>         HTH
>         Thx
>         Alex
>
>         On 12/03/2017 10:32, adamv0025 at netconsultings.com
>         <mailto:adamv0025 at netconsultings.com> wrote:
>
>             Hi folks,
>
>               
>
>             Anyone tried to use "if-route-exists" or the "rib has route" condition for
>
>             route import as opposed to the more usual route export or default route
>
>             origination respectively?
>
>             Can't find it documented anywhere and it's not working, but I'm just curious
>
>             what are your thoughts on the concept of general routing behaviour
>
>             programmability using routing information.
>
>             I need the network to reprogram itself based on routing events without the
>
>             YANG/NETCONF complexity.
>
>             And for that I'd need a route and it's specific parameter or a set of
>
>             parameters to be used as an instruction or a trigger.
>
>             I'd like to be able to use a more general from of condition in
>
>             routing-policies (or even forwarding filters or QOS-policies).
>
>               
>
>             Example:
>
>               
>
>             condition_1
>
>             if (route = x.x.x.x/x in VRF A) AND (igp metric to NH < 100)
>
>             then
>
>             condition_1 == TRUE
>
>               
>
>             route-policy 1
>
>             if
>
>             route = y.y.y.y/y AND if condition_1 == TRUE
>
>             then
>
>             set local-preference 120 AND accept
>
>               
>
>             bgp
>
>             VRF A neighbour z.z.z.z route-policy 1 in
>
>               
>
>               
>
>               
>
>             Options:
>
>             The trigger route can be constructed at the trigger router and advertised
>
>             into an intended VRF or to a separate "instructions-VRF", dedicated to
>
>             contain these special purpose routes if we don't want to mix these
>
>             instruction routes with regular routing information.
>
>             Or the trigger route could be a regular routing info with a specific set of
>
>             attributes that we intend to use as a marker of a specific network event
>
>             that we want to act upon in case it happens.
>
>               
>
>               
>
>             I'd appreciate any feedback.
>
>               
>
>               
>
>             adam
>
>               
>
>             netconsultings.com
>
>             ::carrier-class solutions for the telecommunications industry::
>
>               
>
>               
>
>             _______________________________________________
>
>             juniper-nsp mailing listjuniper-nsp at puck.nether.net
>             <mailto:juniper-nsp at puck.nether.net>
>
>             https://puck.nether.net/mailman/listinfo/juniper-nsp
>



More information about the juniper-nsp mailing list