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:arsen...@btinternet.com] 
Sent: Tuesday, March 14, 2017 5:57 PM
To: adamv0...@netconsultings.com; juniper-nsp@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, adamv0...@netconsultings.com 
<mailto:adamv0...@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:arsen...@btinternet.com] 
Sent: Monday, March 13, 2017 12:28 PM
To: adamv0...@netconsultings.com <mailto:adamv0...@netconsultings.com> ; 
juniper-nsp@puck.nether.net <mailto:juniper-nsp@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, adamv0...@netconsultings.com 
<mailto:adamv0...@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 list juniper-nsp@puck.nether.net 
<mailto:juniper-nsp@puck.nether.net> 
https://puck.nether.net/mailman/listinfo/juniper-nsp

 

 

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to