<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: When it rains it pours!</title>
	<atom:link href="http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/</link>
	<description>technology, networking and IP telephony</description>
	<lastBuildDate>Tue, 07 Feb 2012 12:06:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Tom</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1511</link>
		<dc:creator>Tom</dc:creator>
		<pubDate>Wed, 09 Dec 2009 19:48:16 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1511</guid>
		<description>We use 4.1.8.3 on our ERS 8600&#039;s and run ~60 VLANs, IST, SMLT, PIM-SM, RIP, SYSLOG, etc.    Things have been fairly stable, but it&#039;s because of reported problems as discussed in this thread that we have held off on upgrading to 5.x.x.x.  Ever since last year when we found the VLACP timeout issue after installing an ERS 45xx software update (yes, we found that problem and it was a pain) - see http://www.michaelfmcnamara.com/files/VLACP%20timeout%20issue.pdf - I&#039;ve been very careful and leery about software upgrades on core switches.  We will continue that policy until I feel more confident that the Nortel ERS 8600 software releases are stable.

About the only problem we have had is some sort of bug with DHCP Guard which caused no end of problems.  The solution was to disable DHCP Guard, but long-term, we need to figure this problem out.

But not all is lost.  The latest ESM software release is very nice and fixed some nagging bugs. CS1000 6.0 looks very solid, and our SRGs are running with no problems at all.  We are very committed to Nortel over the next 5-7 years, but we will continue to move with deliberation when we touch any of the core switches.</description>
		<content:encoded><![CDATA[<p>We use 4.1.8.3 on our ERS 8600&#8242;s and run ~60 VLANs, IST, SMLT, PIM-SM, RIP, SYSLOG, etc.    Things have been fairly stable, but it&#8217;s because of reported problems as discussed in this thread that we have held off on upgrading to 5.x.x.x.  Ever since last year when we found the VLACP timeout issue after installing an ERS 45xx software update (yes, we found that problem and it was a pain) &#8211; see <a href="http://www.michaelfmcnamara.com/files/VLACP%20timeout%20issue.pdf" rel="nofollow">http://www.michaelfmcnamara.com/files/VLACP%20timeout%20issue.pdf</a> &#8211; I&#8217;ve been very careful and leery about software upgrades on core switches.  We will continue that policy until I feel more confident that the Nortel ERS 8600 software releases are stable.</p>
<p>About the only problem we have had is some sort of bug with DHCP Guard which caused no end of problems.  The solution was to disable DHCP Guard, but long-term, we need to figure this problem out.</p>
<p>But not all is lost.  The latest ESM software release is very nice and fixed some nagging bugs. CS1000 6.0 looks very solid, and our SRGs are running with no problems at all.  We are very committed to Nortel over the next 5-7 years, but we will continue to move with deliberation when we touch any of the core switches.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1506</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Tue, 08 Dec 2009 22:16:01 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1506</guid>
		<description>Chuck  

We were not experiencing actual LANE lockups on 81612XLRS with 5.0.1. The group of  four 10gig ports in LANE one would stop transmitting packets, but was still receiving them. Links up.  No errors. We were lucking VLACP logically brought the affected ports down (although they were physically still up)  and the SMLT peer took over.  Without VLACP the traffic would have been black holed.</description>
		<content:encoded><![CDATA[<p>Chuck  </p>
<p>We were not experiencing actual LANE lockups on 81612XLRS with 5.0.1. The group of  four 10gig ports in LANE one would stop transmitting packets, but was still receiving them. Links up.  No errors. We were lucking VLACP logically brought the affected ports down (although they were physically still up)  and the SMLT peer took over.  Without VLACP the traffic would have been black holed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1505</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Tue, 08 Dec 2009 21:58:48 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1505</guid>
		<description>bylie on December 4, 2009 - 2:26 am 

Are you running SLPP.  In 5.0.1 with SLPP enabled the cpu buffer (99%) filled up on one side of the cluster causing the peer CPU to spike at 100%.  This caused instability in the IST.  If you globally disable SLPP, the problem goes away.  This was due to the SLPP MAC address being placed in the forwarding table twice. 


We tested that this is fixed in 5.1.1.1  and 5.0.5</description>
		<content:encoded><![CDATA[<p>bylie on December 4, 2009 &#8211; 2:26 am </p>
<p>Are you running SLPP.  In 5.0.1 with SLPP enabled the cpu buffer (99%) filled up on one side of the cluster causing the peer CPU to spike at 100%.  This caused instability in the IST.  If you globally disable SLPP, the problem goes away.  This was due to the SLPP MAC address being placed in the forwarding table twice. </p>
<p>We tested that this is fixed in 5.1.1.1  and 5.0.5</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1504</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Tue, 08 Dec 2009 21:53:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1504</guid>
		<description>&quot;ARP issue on a ERS 8600 switch cluster running 4.1.8.0&quot;

Was fixed in 4.1.8.3   How can you manage so many versions of code? We&#039;re always on the same code base with clusters and even stand alones now.</description>
		<content:encoded><![CDATA[<p>&#8220;ARP issue on a ERS 8600 switch cluster running 4.1.8.0&#8243;</p>
<p>Was fixed in 4.1.8.3   How can you manage so many versions of code? We&#8217;re always on the same code base with clusters and even stand alones now.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1503</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Tue, 08 Dec 2009 21:50:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1503</guid>
		<description>We only use VRRP when we have to.  We use RSMLT which helps when SMLT converges when an 8600 in the cluster is coming back up.  The problem is you can only have 32 SMLTs per RSMLT instance.  We found this out the hard way.  If you go over 32 it cause instability in the IST and things go nuts.  A couple of VLAN (like the managment one) have way more than 32 SMLT instances.

We do have unique VRRP IDS across the switch.</description>
		<content:encoded><![CDATA[<p>We only use VRRP when we have to.  We use RSMLT which helps when SMLT converges when an 8600 in the cluster is coming back up.  The problem is you can only have 32 SMLTs per RSMLT instance.  We found this out the hard way.  If you go over 32 it cause instability in the IST and things go nuts.  A couple of VLAN (like the managment one) have way more than 32 SMLT instances.</p>
<p>We do have unique VRRP IDS across the switch.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chuck</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1501</link>
		<dc:creator>Chuck</dc:creator>
		<pubDate>Tue, 08 Dec 2009 17:01:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1501</guid>
		<description>We&#039;ve been a Nortel customer for over a decade and have used the 8600 since its initial release.  We&#039;ve also beta tested just about every single release since then and have been through more than our share of problems.  The SMLT rearchitecture of 4.1.8, 5.0.1 and 5.1 has been a rough ride.  5.1.1.1 finally fixes most of our issues with IST and box instability.  We are still working on one more issue that seems to be related to HA-CPU &amp; PIM/IP Multicast that causes the IST to go down when disconnecting an SMLT edge link.  With PIM disabled, the issue disappears.  We also have an 8612XLRS in use on 5.1.1.1 and have not experienced any LANE lockup issue.</description>
		<content:encoded><![CDATA[<p>We&#8217;ve been a Nortel customer for over a decade and have used the 8600 since its initial release.  We&#8217;ve also beta tested just about every single release since then and have been through more than our share of problems.  The SMLT rearchitecture of 4.1.8, 5.0.1 and 5.1 has been a rough ride.  5.1.1.1 finally fixes most of our issues with IST and box instability.  We are still working on one more issue that seems to be related to HA-CPU &amp; PIM/IP Multicast that causes the IST to go down when disconnecting an SMLT edge link.  With PIM disabled, the issue disappears.  We also have an 8612XLRS in use on 5.1.1.1 and have not experienced any LANE lockup issue.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SilverMachine</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1500</link>
		<dc:creator>SilverMachine</dc:creator>
		<pubDate>Tue, 08 Dec 2009 12:32:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1500</guid>
		<description>Hi Michael,

No, they are not runnig 5.1.1.1 code with 8612XLRS modules.  No LANE lock-ups until now. They are running 5.1.1.1 code for more than 2 weeks without problems.  

Concerning DHCP Relay Agents on a cluster running 5.1.1.1 code: This IP should not be the same as configured for Virtual IP Address (VRRP). It will start a broadcast storm (DHCP Offers packets) on the IST link!!

Best Regards!</description>
		<content:encoded><![CDATA[<p>Hi Michael,</p>
<p>No, they are not runnig 5.1.1.1 code with 8612XLRS modules.  No LANE lock-ups until now. They are running 5.1.1.1 code for more than 2 weeks without problems.  </p>
<p>Concerning DHCP Relay Agents on a cluster running 5.1.1.1 code: This IP should not be the same as configured for Virtual IP Address (VRRP). It will start a broadcast storm (DHCP Offers packets) on the IST link!!</p>
<p>Best Regards!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael McNamara</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1498</link>
		<dc:creator>Michael McNamara</dc:creator>
		<pubDate>Tue, 08 Dec 2009 03:07:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1498</guid>
		<description>Hi Mark,

I&#039;m happy that another Nortel customer is running 5.1.1.1 software without any issues. Also happy to hear that you haven&#039;t experienced any LANE lockups on 5.1.1.1 software. 

That&#039;s an interesting comment regarding the SuperMezz cards and SLPP. Do you use VRRP in your configuration? Do you have unique VRRP IDs across the switch cluster? I ask because there is a known issue that we discovered last May that may be related. In short you need to have unique VRRP IDs across the switch, you can&#039;t use VRRP ID 1 for VLAN 1 and VRRP ID 1 for VLAN 2, VRRP ID 1 for VLAN 3, etc.

Thanks for the comment!</description>
		<content:encoded><![CDATA[<p>Hi Mark,</p>
<p>I&#8217;m happy that another Nortel customer is running 5.1.1.1 software without any issues. Also happy to hear that you haven&#8217;t experienced any LANE lockups on 5.1.1.1 software. </p>
<p>That&#8217;s an interesting comment regarding the SuperMezz cards and SLPP. Do you use VRRP in your configuration? Do you have unique VRRP IDs across the switch cluster? I ask because there is a known issue that we discovered last May that may be related. In short you need to have unique VRRP IDs across the switch, you can&#8217;t use VRRP ID 1 for VLAN 1 and VRRP ID 1 for VLAN 2, VRRP ID 1 for VLAN 3, etc.</p>
<p>Thanks for the comment!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1496</link>
		<dc:creator>Ben</dc:creator>
		<pubDate>Tue, 08 Dec 2009 02:58:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1496</guid>
		<description>The Cisco VSS solution has worked excellently in our environment.  Unlike the ERS8600 it operates 100% as one logical switch similar to a stack of Nortel 5510s or Cisco 3750s.  We have redundant fiber to all of our closets and have them setup as Machine EtherChannels (MECs) which is similar to SMLT, but in my experience works a lot better.  There is only one active supervisor between the two chassis and the active/active detection is done both by the VSS (SMLT) links as well as by a dedicated heartbeat link.</description>
		<content:encoded><![CDATA[<p>The Cisco VSS solution has worked excellently in our environment.  Unlike the ERS8600 it operates 100% as one logical switch similar to a stack of Nortel 5510s or Cisco 3750s.  We have redundant fiber to all of our closets and have them setup as Machine EtherChannels (MECs) which is similar to SMLT, but in my experience works a lot better.  There is only one active supervisor between the two chassis and the active/active detection is done both by the VSS (SMLT) links as well as by a dedicated heartbeat link.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael McNamara</title>
		<link>http://blog.michaelfmcnamara.com/2009/12/when-it-rains-it-pours/#comment-1495</link>
		<dc:creator>Michael McNamara</dc:creator>
		<pubDate>Tue, 08 Dec 2009 02:56:55 +0000</pubDate>
		<guid isPermaLink="false">http://blog.michaelfmcnamara.com/?p=1143#comment-1495</guid>
		<description>Hi Udo,

Thanks for the comment. It would seem that a lot of folks are happy with 5.1.1.1 software, however, I will warn you that I&#039;ve heard about issues with the 8612XLRS modules. You might want to contact Nortel support to inquire about any known issues with the 8612XLRS modules if you haven&#039;t already installed them.

Cheers!</description>
		<content:encoded><![CDATA[<p>Hi Udo,</p>
<p>Thanks for the comment. It would seem that a lot of folks are happy with 5.1.1.1 software, however, I will warn you that I&#8217;ve heard about issues with the 8612XLRS modules. You might want to contact Nortel support to inquire about any known issues with the 8612XLRS modules if you haven&#8217;t already installed them.</p>
<p>Cheers!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Served from: blog.michaelfmcnamara.com @ 2012-02-08 16:36:21 by W3 Total Cache -->
