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, [email protected] 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:[email protected]]
*Sent:* Monday, March 13, 2017 12:28 PM
*To:* [email protected]; [email protected]
*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, [email protected] <mailto:[email protected]> 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 [email protected] 
<mailto:[email protected]>

    https://puck.nether.net/mailman/listinfo/juniper-nsp


_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to