Re: [j-nsp] About ISIS export policy behavior

Hi, Adam. Thanks for the clarification. This is really confusing. -PLX On 2/1/16, Adam Vitkovsky wrote: >> Pyxis LX >> Sent: Sunday, January 31, 2016 8:17 AM >> >> Hi, All. >> >> I'm a little confused by the default ISIS export behavior in JUNOS. >> >> According to

Re: [j-nsp] juniper-nsp Digest, Vol 159, Issue 8

I don’t know whether it is officially supported or not, but I was able to get v6 working in a lab environment with MC-LAG, even with OSPF3 running and working over it as well. In v4 world you must configure VRRP to have the ARP sync work properly (this bit us on a MC-LAG running OSPF where one

Re: [j-nsp] QFX mc-lag and v6 ND

On 05/02/16 14:40, Adam Vitkovsky wrote: -that's the only occasion the internet where NDP and MC-LAG in listed the same sentence, which is not a good sign on its own. But no explanation about how it is done, especially the part about how the ND Cache is maintained between the LAG members, which

Re: [j-nsp] Slow performance of the KRT queue

Welcome to running a full table on the MX104. This is exactly what we found when lab testing the devices. After months of working with JTAC we never found a workaround. After several software updates and major configuration changes there was never a way to resolve the issues. During a major

Re: [j-nsp] About ISIS export policy behavior

I always understood export for a link state to apply to external only. Internal routes have to be flooded for correct protocol operation, minus certain rules for L1/L2 or for ospf stubby areas, but filtering these internals is not done with policy. In this context the doc link makes sense.

Re: [j-nsp] Slow performance of the KRT queue

Hey vincent, Good to see you on the list :) I think you've already read all threads of the long history of krt queuing issue, on juniper (specialy this one http://www.gossamer-threads.com/lists/nsp/juniper/40739). I have to say, that even if the design problem remain, two minutes isn't

Re: [j-nsp] Slow performance of the KRT queue

❦ 5 février 2016 18:25 +0100, Raphael Mazelier  : > Hey vincent, > > Good to see you on the list :) Hey Raphael! Is there some way to not advertise the default route in OSPF during the convergence time? Like a criteria: don't advertise this route when the KRT

Re: [j-nsp] Slow performance of the KRT queue

On 5 February 2016 at 19:25, Raphael Mazelier wrote: Hey, > I have to say, that even if the design problem remain, two minutes isn't > that bad. In the first day of MX80 with flowing enabling it took age from > the rib syncing down to the fib (friends report 20min in the

Re: [j-nsp] Acx5048 vpls vlan-id

Aaron Thanks a lot Our problem is related to pass more than one vlan to the same vpls instance. We have some projects here that depends of it We will talk with juniper TAC and PLM to see the software roadmap of this box There is no chance to use this box in projects with this limitation,

Re: [j-nsp] Slow performance of the KRT queue

Hey! I have been helped off-list by Jeff who suggested to disable damping. I had the following bits in my configuration: set policy-options policy-statement v4-PUBLIC-DAMPING term 1 from route-filter 0.0.0.0/0 upto /16 damping damp-timid set policy-options policy-statement v4-PUBLIC-DAMPING

Re: [j-nsp] Slow performance of the KRT queue

Le 05/02/2016 19:32, Saku Ytti a écrit : I think the fundamental problem here is that these fixes are attempting to make the symptoms less pronounced, rather than address the problem. Yep. But it is better than nothing. I view the problem as desync of software and hardware state, we can

Re: [j-nsp] QFX mc-lag and v6 ND

Hello Karl, > Karl Brumund > Sent: Thursday, February 04, 2016 8:56 PM > > We're seeing an issue with a pair of QFX3500s, configured with MC-LAG > towards servers and IPv6 Neighbor Discovery. > qfx1 and qfx2 have mc-ae towards servers. If qfx1 sends NS, a server may > reply on the bonded mc-ae

Re: [j-nsp] understanding interface encapsulation, family ... and more

Hello, Aaron (Thu 2016-02-04 21:04:40 -0600) : > I'm a cisco guy coming into the juniper world. I'm trying to understand all > these different interface family and encapsulation options.. > [...] > Is there a good book/class for this SP Layer 2 understanding of > Junos ? I guess chapter 2 of

Re: [j-nsp] ip(v6) options

On 4 February 2016 at 22:38, Daniel Verlouw wrote: Hey > http://kb.juniper.net/InfoCenter/index?page=content=KB30719=search > > just came online. Coincidence? :-) No. I was being difficult customer and wanted the changed behaviour documented. I think virtually no Juniper

Re: [j-nsp] ip(v6) options

On Fri, Jan 29, 2016 at 09:11:38PM +0200, Saku Ytti wrote: > Hey, > > > > Isn’t there a requirement that packets with IP options needs to be punted > > to the CPU for processing (process switched) (on every hop) > > Although I'd be interested to know if it's the LC CPU or RE CPU handling > >

Re: [j-nsp] Juniper EX2200 virtual-chassis

Hey Matt, we have couple of EX2200 VC running in our infra. JUNOS version 12.3R3.4. Few things to keep in mind: 1. JUNOS should be same on both switch 2. Make your VC as 'preprovisioned', so that 'you' can decide what part the new member will play in VC.

Re: [j-nsp] understanding interface encapsulation, family ... and more

Le 05/02/2016 09:44, Emmanuel Halbwachs a écrit : Hello, Aaron (Thu 2016-02-04 21:04:40 -0600) : I'm a cisco guy coming into the juniper world. I'm trying to understand all these different interface family and encapsulation options.. [...] Is there a good book/class for this SP Layer 2

Re: [j-nsp] QFX mc-lag and v6 ND

Thanks Adam. On Fri, Feb 5, 2016 at 3:46 AM, Adam Vitkovsky wrote: > Hello Karl, > > > Karl Brumund > > Sent: Thursday, February 04, 2016 8:56 PM > > > > We're seeing an issue with a pair of QFX3500s, configured with MC-LAG > > towards servers and IPv6 Neighbor

Re: [j-nsp] QFX mc-lag and v6 ND

> Karl Brumund > Sent: Friday, February 05, 2016 2:20 PM > > Thanks Adam. > > On Fri, Feb 5, 2016 at 3:46 AM, Adam Vitkovsky > > wrote: > > > Hello Karl, > > > > > Karl Brumund > > > Sent: Thursday, February 04, 2016 8:56 PM > > > > > > We're seeing an issue with a