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, [email protected] 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:[email protected]]
*Sent:* Wednesday, March 15, 2017 4:16 PM
*To:* [email protected]; [email protected]
*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, [email protected]
<mailto:[email protected]> 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:[email protected]]
*Sent:* Tuesday, March 14, 2017 5:57 PM
*To:* [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>
*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, [email protected]
<mailto:[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]
<mailto:[email protected]>;
[email protected] <mailto:[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
