Re: [j-nsp] BGP add-path on QFX
❦ 30 janvier 2017 13:47 +0100, Vincent Bernat : > No ideas on what can be wrong with your configuration :( > We run add-path on most MXes without any problems. Just tried with QFX > (not running bgp actually), add-path command is not hidden for me and > commit > check succeeds: Thanks for checking, that's helpful! In fact, I am using routing instances. Like you, I can get add-path send/receive outside a routing instance, but inside, add-path is hidden. I assumed this was independent of the routing instance (configured type virtual-router), so I didn't bother to check that. Does "set routing-instances rr1 protocols bgp group apath family inet unicast add-path ..." complete for you? >>> >>> Looks like routing-instances is the difference. Within routing-instance >>> add-path does not complete for me too, neither on QFX nor on MX. >> >> So, I am trying to not use routing instances. Is there a way to tell a >> BGP group to use a different primary RIB than inet.0 (for family inet >> unicast)? There is the rib-group directive but it enforces that the >> first member of the rib-group to be the primary RIB. > > In fact, I will switch to using logical-systems. The option is available > in this case and works fine in lab. But logical systems don't seem to be supported on a QFX 5100 (commands accepted, but no logical systems created)... :-/ -- No violence, gentlemen -- no violence, I beg of you! Consider the furniture! -- Sherlock Holmes ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP add-path on QFX
❦ 30 janvier 2017 11:45 +0100, Vincent Bernat : >>> > No ideas on what can be wrong with your configuration :( >>> > We run add-path on most MXes without any problems. Just tried with QFX >>> > (not running bgp actually), add-path command is not hidden for me and >>> > commit >>> > check succeeds: >>> >>> Thanks for checking, that's helpful! >>> >>> In fact, I am using routing instances. Like you, I can get add-path >>> send/receive outside a routing instance, but inside, add-path is >>> hidden. I assumed this was independent of the routing instance >>> (configured type virtual-router), so I didn't bother to check that. >>> >>> Does "set routing-instances rr1 protocols bgp group apath family inet >>> unicast add-path ..." complete for you? >> >> Looks like routing-instances is the difference. Within routing-instance >> add-path does not complete for me too, neither on QFX nor on MX. > > So, I am trying to not use routing instances. Is there a way to tell a > BGP group to use a different primary RIB than inet.0 (for family inet > unicast)? There is the rib-group directive but it enforces that the > first member of the rib-group to be the primary RIB. In fact, I will switch to using logical-systems. The option is available in this case and works fine in lab. -- The surest protection against temptation is cowardice. -- Mark Twain ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP add-path on QFX
❦ 27 janvier 2017 20:08 +0300, Alexandre Snarskii : >> > No ideas on what can be wrong with your configuration :( >> > We run add-path on most MXes without any problems. Just tried with QFX >> > (not running bgp actually), add-path command is not hidden for me and >> > commit >> > check succeeds: >> >> Thanks for checking, that's helpful! >> >> In fact, I am using routing instances. Like you, I can get add-path >> send/receive outside a routing instance, but inside, add-path is >> hidden. I assumed this was independent of the routing instance >> (configured type virtual-router), so I didn't bother to check that. >> >> Does "set routing-instances rr1 protocols bgp group apath family inet >> unicast add-path ..." complete for you? > > Looks like routing-instances is the difference. Within routing-instance > add-path does not complete for me too, neither on QFX nor on MX. So, I am trying to not use routing instances. Is there a way to tell a BGP group to use a different primary RIB than inet.0 (for family inet unicast)? There is the rib-group directive but it enforces that the first member of the rib-group to be the primary RIB. There is also "topology", but the documentation says that routes are still placed in the default RIB. -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plauger) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP add-path on QFX
> From: Vincent Bernat [mailto:ber...@luffy.cx]
> Sent: Friday, January 27, 2017 2:41 PM
>
> ❦ 27 janvier 2017 14:17 GMT, :
>
> >> I am using some QFX as route reflectors and would like to use BGP
> >> add-path feature. The documentation says that QFX is a supported
> >> platform[0] while the feature explorer says no QFX has support for
> that[1].
> >>
> >> [0]:
> >>
> http://www.juniper.net/techpubs/en_US/junos16.1/topics/example/bgp-
> >> add-path.html
> >> [1]: https://pathfinder.juniper.net/feature-explorer/feature-
> >>
> info.html?fKey=3294&fn=For+internal+BGP+(IBGP),+advertise+multiple+pa
> >> t
> >> hs+to+a+destination
> >>
> >> I have upgraded some QFX to 16.1R3 but there is no difference with
> >> 14.1X53-D40: add-path is an hidden command and only "receive" is
> >> available ("send" is not accepted):
> >>
> >> set protocols bgp group batman family inet unicast add-path send ...
> >>
> >> I have also tried on MX104 running 14.1R8. Feature explorer says this
> > should
> >> be supported since 13.2R2. But I am in the exact same situation:
> >> add-path is a hidden command and only "receive" is available.
> >>
> >
> > Is the RR use in MPLS-VPNs environment or just pure L3-IPv4/6
> environment?
> > If it's MPLS-VPNs environment, then you don't need add-path.
>
> It's in a pure L3-IPv4/IPv6.
>
> > Also if ORR is supported on QFX by any chance you might want to try
> > that instead of add-path.
> > Does it take the below?
> > set protocols bgp group batman optimal-route-reflection
>
> Yes, it's accepted. But my goal is to get load balancing to a set of hosts,
> not
> optimal path (all routes are equal in my setup). My understanding of the
> above option is that it still selects only one route.
Actually never mind, in pure IP environment you'd still need
add-path/diverse-path feature to get the alternate ORR paths across to clients.
But actually the whole purpose of ORR was to distribute primary as well as
alternate/backup paths, but in an optimal way, as opposed to brute force *all
paths(Type1 RDs) or inefficient primary/backup paths(add-paths).
The Junos configuration actually allows for manual definition of primary and
backup virtual location.
(hoping for automatic and/or policy-based primary and best backup selection in
future).
*The number of paths advertised with this approach can actually be scaled down
with careful assignment of RDs among given set of AS-exits.
adam
netconsultings.com
::carrier-class solutions for the telecommunications industry::
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
