[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