Re: [j-nsp] ipv6 and multihop
2017-03-13 19:41 GMT-03:00 Pedro : > Hello, Hi, > There is support for ipv6 multihop in junos for eBGP ? I don't have L2 or > direct link between ipv6 peers.. ( now i have junos 15.1R2.9 and > 14.1X53-D40.8) Yes, it is: set neighbor 2001:db8::1 multihop ttl xx Regards, -- Eduardo Schoedler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ipv6 and multihop
Hello, There is support for ipv6 multihop in junos for eBGP ? I don't have L2 or direct link between ipv6 peers.. ( now i have junos 15.1R2.9 and 14.1X53-D40.8) any clue will be appreciated best, Pedro ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Output filter on discard interface doesn't work as expected
Am 13.03.2017 15:01, schrieb Michael Hare: Any more details on platform or version you can share? I'm doing this on MPC4 in 14.1 with no issues. I first tested my setup with a virtualized olive, but in the meanwhile i also tried my configuration on MX240 with DPCE running JUNOS 12.3.R8.7 and MX5 (JUNOS 15.1R4.6). Unfortunately no success... Since it's a lab have you tried commit full? Presumably no oddities in syslogs? No oddities in logfiles. commit full doesn't fixed it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Output filter on discard interface doesn't work as expected
Any more details on platform or version you can share? I'm doing this on MPC4 in 14.1 with no issues. Since it's a lab have you tried commit full? Presumably no oddities in syslogs? -Michael > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > Alex D. > Sent: Friday, March 10, 2017 11:17 AM > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Output filter on discard interface doesn't work as > expected > > Am 10.03.2017 16:27, schrieb Karsten Thomann: > > Hi, > > > > Already tried to set the firewall filter as input on dsc.0? > > > Yes, i already tried that. Also no success. > According to the Juniper documentation, it definitely must be applied as > an output filter. > Regards, > Alex > ___ > juniper-nsp mailing list 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
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 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 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
