[j-nsp] MX80 stops forwarding after enabling inline flow sampling

Abhi vyaaghrah-eng at yahoo.com
Wed Jul 16 01:34:05 EDT 2014


More on this i think it important as many folks may run into this.

this PR only address the current limitation in sampled and rpd communication by the workaround mentioned PR but it does not address the limitation of reading from file itself which causes sampled to slow down in first place.

Their is enhancement targeted for 14.2 which changes how the rpd and sampled communicating address the fundamental limitation of reading route records from file.
 
regards
abhijeet.c



On Tuesday, July 15, 2014 8:06 PM, Scott Granados <scott at granados-llc.net> wrote:
 

>
>
>I found more to bring this thread home.
>
>The problem I had was covered in PR963060.  
>    Basically, a condition would take place where the sampled process would block the programming of the PFE and would break forwarding.  Lots of kernel veto messages were recorded in the log and the path from the RE to the PFE was blocked.  Several releases are available with the fix in place.
>
>Thanks
>Scott
>
>
>
>On Jul 10, 2014, at 12:19 PM, Justin M. Streiner <streiner at cluebyfour.org> wrote:
>
>> On Wed, 9 Jul 2014, Scott Granados wrote:
>> 
>>>     I have an interesting problem.  I have an MX80 where I wish to 
>>> enable inline flow sampling.  I used the kb entry as a template and 
>>> configured.  When setting the table size the PFE rebooted which is 
>>> expected but when it came back online forwarding stopped.  I rebooted 
>>> again and had the same issue with the exception of after about 20 
>>> minutes forwarding started to work.  Looking at the logs there seemed 
>>> to be throttles from the kernel to the PFE and issues that look like 
>>> ipsec trying to find a phase 2 policy that might have been causing the 
>>> delay.  However, ipsec isn’t enabled on this box and there is an actual 
>>> ACL that should block ipsec sessions from establishing so I think this 
>>> might be a false signal.  Anyone ever see this sort of long delay or 
>>> have any ideas where I should look further.  I’ve engaged TAC but am 
>>> looking for things to test in the mean time independently.  Anyone seen 
>>> this before or have any ideas?
>> 
>> What version of code are you running?  I haven't seen this problem, but I 
>> don't have any MX80s specifically. I haven't seen this behavior on a pair 
>> of MX480s running 12.3R6.6.
>> 
>> I have a pair of MX5s I could test with, but I havne't had a chance to get 
>> them set up in our lab yet.
>> 
>> jms<ATT00001.c>
>
>
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>


More information about the juniper-nsp mailing list