<div dir="ltr">Are the ports all route-only? Also note that normal SNMP monitoring of CPU is the management module, not the individual LP's. The LPs commonly spike w/o it being very obvious via any standard SNMP monitoring.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 16, 2016 at 12:29 PM, Daniel Stephens <span dir="ltr"><<a href="mailto:ds-lists@ndnx.net" target="_blank">ds-lists@ndnx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="m_-7724477838375358713WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I am not doing any hair-pinning on the device.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I do have icmp redirects disabled on all interfaces, however.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Daniel<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Jody Botham <<a href="mailto:jody@ask4.com" target="_blank">jody@ask4.com</a>><br>
<b>Date: </b>Wednesday, November 16, 2016 at 12:25 PM<br>
<b>To: </b>Daniel Stephens <<a href="mailto:ds-lists@ndnx.net" target="_blank">ds-lists@ndnx.net</a>>, Ryan Harden <<a href="mailto:hardenrm@uchicago.edu" target="_blank">hardenrm@uchicago.edu</a>></span></p><div><div class="h5"><br>
<b>Cc: </b>"<a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a>" <<a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a>><br>
<b>Subject: </b>Re: [f-nsp] Brocade XMR / Juniper iBGP Interoperability<u></u><u></u></div></div><p></p>
</div><div><div class="h5">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Are you doing any hair-pinning of traffic on the XMR in/out a VLAN on the same physical interface? NetIron generates an ICMP redirect by default in this situation which with lots of traffic can kill the lp. Check if you've disabled icmp
redirects.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, 16 Nov 2016 at 17:15, Daniel Stephens <<a href="mailto:ds-lists@ndnx.net" target="_blank">ds-lists@ndnx.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">I will need to capture the debug data when attempting to bring the session back up, but since these two networks are production, I am limited in the time frames I can do so due to it becoming service affecting when the sessions all drop.<br>
<br>
I do not have the exact output of “show cpu lp X”, but graphs I have of the processor on the management module and line cards show both going up to roughly 80-90% during the event.<br>
<br>
Thanks,<br>
Daniel<br>
<br>
On 11/16/16, 12:10 PM, "Ryan Harden" <<a href="mailto:hardenrm@uchicago.edu" target="_blank">hardenrm@uchicago.edu</a>> wrote:<br>
<br>
What does ‘show cpu lp X’ say during the error/failure state?<br>
<br>
/Ryan<br>
<br>
Ryan Harden<br>
Research and Advanced Networking Architect<br>
University of Chicago - ASN160<br>
P: <a href="tel:773.834.5441" value="+17738345441" target="_blank">773.834.5441</a><br>
<br>
<br>
<br>
<br>
> On Nov 16, 2016, at 10:52 AM, Daniel Stephens <<a href="mailto:ds-lists@ndnx.net" target="_blank">ds-lists@ndnx.net</a>> wrote:<br>
><br>
> Hi Jörg,<br>
><br>
> The line card does not reset. Under show logging during the event, the only thing are OSPF neighbor changes when they drop and reestablish.<br>
><br>
> SSH@xmr01#sh ip bgp nei $MX_IP last-packet-with-error decode<br>
> No received packet with error logged for neighbor $MX_IP<br>
> SSH@xmr01#<br>
><br>
> On the upstream carrier BGP neighbor, when it reset, the XMR reported the following –<br>
><br>
> Notification Sent: Hold Timer Expired<br>
> Notification Received: Cease/Connection Rejected<br>
><br>
> Thanks,<br>
> Daniel<br>
><br>
><br>
> From: Jörg Kost <<a href="mailto:jk@ip-clear.de" target="_blank">jk@ip-clear.de</a>><br>
> Date: Wednesday, November 16, 2016 at 11:41 AM<br>
> To: Daniel Stephens <<a href="mailto:ds-lists@ndnx.net" target="_blank">ds-lists@ndnx.net</a>><br>
> Cc: "<a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a>" <<a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a>><br>
> Subject: Re: [f-nsp] Brocade XMR / Juniper iBGP Interoperability<br>
><br>
> Hi,<br>
> does the line card reset?<br>
> Also any output from<br>
> show logging<br>
> or bgp, e.g.<br>
> sh ip bgp neighbors $neighbor last-packet-with-error decode<br>
> may be helpful.<br>
> Jörg<br>
> On 16 Nov 2016, at 17:10, Daniel Stephens wrote:<br>
> Hi everyone,<br>
><br>
> I am having a strange issue with our Brocade XMRs when I attempt to exchange routes between a new set of Juniper MX iBGP peers and was looking to see if anyone had any recommendations.<br>
><br>
> The Brocade XMRs have two line cards, a 20-port 1G and a 4-port 10G card installed, and are running 5.6.0d firmware.<br>
><br>
> We are integrating two existing networks as a consolidation, with the one network running Brocade XMR and the other running Juniper MX routers. The issue surfaced on the XMRs when we removed route filters on the iBGP sessions between the XMR and MX routers.
When lifting the filters and sending routes from the XMR towards the MX, everything is functioning as normal and the MX correctly learn the routes. Our issue becomes when we lift the filter and send routes from the MX towards the XMR. The XMR begins to load
the routes correctly, and at some point during this process, the XMR stops forwarding traffic on the 4-port 10G line card entirely (the card to which the MX routers interconnect), and all BGP sessions associated with that line card flap, and OSPF adjacencies
drop and re-establish.<br>
><br>
> I am using the ipv4-ipv6-2 CAM partition profile on the XMR devices. Total number of routes attempting to be passed is a full table of roughly 610K routes.<br>
><br>
> Even when I remove an XMR unit from service and attempt to load routes from the MX into the XMR, the same anomaly occurs.<br>
><br>
> Any assistance would be greatly appreciated.<br>
><br>
> Thanks,<br>
> Daniel<br>
> ______________________________<wbr>_________________<br>
> foundry-nsp mailing list<br>
> <a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a><br>
> <a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">
http://puck.nether.net/<wbr>mailman/listinfo/foundry-nsp</a><br>
> Jörg Kost<br>
> Hofmeir Media GmbH<br>
> Kranzhornstr. 3<br>
> 81825 München<br>
> Tel: 089/48002910<br>
> Fax: 089/4487505<br>
> <a href="mailto:jk@hofmeirmedia.net" target="_blank">jk@hofmeirmedia.net</a><br>
> <a href="https://www.premium-datacenter.de" target="_blank">https://www.premium-<wbr>datacenter.de</a><br>
> <a href="https://www.xing.com/profile/Joerg_Kost" target="_blank">https://www.xing.com/profile/<wbr>Joerg_Kost</a><br>
> Geschäftsführer: Dipl.-Ing. (Univ.) Stefan Hofmeir<br>
> Handelsregister AG München: HRB 130092<br>
> ______________________________<wbr>_________________<br>
> foundry-nsp mailing list<br>
> <a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a><br>
> <a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">
http://puck.nether.net/<wbr>mailman/listinfo/foundry-nsp</a><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/<wbr>mailman/listinfo/foundry-nsp</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div></div></div>
</div>
<br>______________________________<wbr>_________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" rel="noreferrer" target="_blank">http://puck.nether.net/<wbr>mailman/listinfo/foundry-nsp</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="background-color:rgb(255,255,255)"><p style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:13px;margin:0px"><b><span style="font-size:10pt">James Cornman</span></b></p><p style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:13px;margin:0px"><i><span style="font-size:10pt">Chief Technology Officer<br></span></i><span style="font-size:10pt"><a href="mailto:jcornman@atlanticmetro.net" style="color:rgb(51,51,51)" target="_blank"><span style="color:blue">jcornman@atlanticmetro.net</span></a><br>212.792.9950 - ext 101<br><b><span style="color:black"><br>Atlantic Metro Communications</span></b></span></p><p style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:13px;margin:0px"><i><span style="font-size:10pt">4 Century Drive, Parsippany NJ 07054</span></i></p><p style="margin:0px"><i style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:13px"><span><br></span></i><font color="#333333"><span style="font-size:13.3333330154419px"><i>Colocation • Cloud Hosting • Network Connectivity • Managed Services</i></span></font><br><font color="#333333"><span style="font-size:13.3333330154419px">Follow us on Twitter: <a href="https://twitter.com/atlanticmetro" target="_blank">@atlanticmetro</a> </span></font><i style="color:rgb(51,51,51);font-size:13.3333330154419px">• Like us on <a href="https://www.facebook.com/atlanticmetro" target="_blank">Facebook</a></i><br><a href="https://www.atlanticmetro.net/" style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:13px" target="_blank"><span style="font-size:10pt;color:rgb(87,151,176)">www.atlanticmetro.net</span></a></p></span></div></div></div></div></div>
</div>