You can upgrade to v5.x software if you have an 8691SF/8692SF with at least 256MB of memory. You’ll need at least 16MB of flash memory in order to fit the code on the /flash filesystem.

You can start by looking at this post; http://blog.michaelfmcnamara.com/2009/05/nortel-ers-8600-software-51-available/

I would advise you to review the release notes carefully, along with the release notes of all interim software releases. If you are running in an IST/SMLT configuration you should especially careful as a special upgrade procedure is required to upgrade to 4.1.8.x or 5.1.x from any previous 4.x software or 5.x software.

Good Luck!

Thanks for the information.

As you mentioned I doubt many folks will be looking for PGM support. I’m currently running IGMPv3 on the edge along with PIM-SM in the core to feed the Nortel Contact Center Agent Display (ADD) along with a few other applications and so far so good.

Thanks again for the comment!

As to the ERS-1600 platform, pgm.spm packets are dropped by the routers, breaking the PGM retransmission mechanisms. The ERS-1600 platform also suffers from the same random multicast flow interruptions but at a much higher frequency, minutes instead of hours!!

I expect not many people use PGM on Nortel platform!
I have two cases open for these problems, hopefully we will get a fix soon.

Thought I would give a heads up to anyone thinking of deploying PGM. PIM processes are more stable with 4.1.8.3 and regular multicast traffic is well handled. Though the PIM processes are still pretty touchy about bad things happening (loops, excessive mcast traffic or number of groups) and will not recover gracefully. They will cause high cpu usage until reset or the routers rebooted to gain back a stable platform.

THANKS AGAIN!!

Jim

I happy to hear you like the site. That’s an interesting issue you had. Any thoughts as to the exact problem?

Perhaps you have rate-limiting enabled on the 5510 and not on the 8600?

Thanks for the comment!

Jim

I’m happy to hear that you’ve found this site useful, in the future please feel free to make additional posts over in the forums; http://forums.networkinfrastructure.info/nortel-ethernet-switching/.

I’m not quite sure I understand your first problem (question)… have you added/deleted any VLANS recently that may have caused this problem or did this problem just appear after the software upgrade? While I’m not exactly sure of your problem (you need to describe it better for me) you may have the now infamous ARP/FDB issue where ARP entries don’t get populated properly in one of the ERS 8600 switches. You can usually test for this problem by checking the ARP tables for the destination IP address that you are trying to communicate with. If you see an ARP entry in one switch but not in the other switch you’re going to have issues. You can then verify the problem by disconnecting (admin-down) the uplink on the ERS 8600 switch that doesn’t have the ARP table entry to the 5510 stack. If you can communicate with the destination IP address (ping) after doing this you have the ARP/FDB issue which was originally addressed in 4.1.8.2 and then finally put to bed in 4.1.8.3. A workaround to the problem (other than shutdown down one of the links) is to ping the destination IP address from the ERS 8600 switch itself (the one that doesn’t have the ARP entry) and it will populate the ARP table entry for 6 hours. Please be warned though that this workaround will only work for 6 hours until the switch expires the ARP table entry.

Your second problem (question)… are the calls IP to IP or are they IP to TDM? If an IP users calls another IP users do they hear the OWSP (one-way-speech-path) issue. If the same IP users calls a TDM user (person with a digital or analog phone or extension) do they hear the OWSP? If your problem is with IP to TDM you need to look at the IP path between the phones and the VGMC (Voice Gateway Media Cards). You don’t need to worry so much about the actual Succession 1000 (Meridian) Call Server and Succession Signaling Servers. If the 5510 stack that connects these resources is also connected to a switch cluster (SMLT) then try disconnecting (admin-down) one of the uplinks to one of the ERS 8600 switches and see if that helps… if not restore the link you just disconnected and try the other link. You can also trying pinging the IP phone from the VGMC itself. I would make sure you involve you voice reseller as they should be able to identify if the problem is with the network. So additionally the OWSP is not going to be a QoS fix… you should definitely have QoS configured and running but that won’t fix your problem (unless your running over a T1 line or something slower than broadband).

Please feel free to follow-up in the forums and I’ll try to walk you through the steps.

Cheers!

Q1:
We are running stack with 2 8600 and use IST , with lot of vlan, we got this problem with arp / vrrp request first from one vrrp address and then the other, without any return from the other end, and nothing in the mac table.

We are running ERS 4.1.8.2 (and after reading this page I would upgrade to 4.1.8.3 er newer)

I remember when we where upgrading to 4.1.8.2, we rebooted twice so there should not be any problems or ? maybe that is the problem that it never came up succesful after the upgrade.

We have open a case with Nortel, but in the beginning they have never hear of this problem before, and right now they are looking for issues or work-around.

Q2:
We use a cobber 1 Gb from this 8600 to a Nortel 5510 , where the t-lan, and e-lan for the call-server. (from this 5510 with patch-up to the callserver)

The problem here are that , could it be the above issus with the vrrp / arp boardcast.

We have office around in the Country where they are coming thougth a fiber (no bandwidth limit) to the 8600 and then to the 5510 to the callserver (Meridian) with VoIP phones.

They cannot hear what the person in the other end are saying , but it works fine the other way. So I am looking for configure Qos aswell.

Looking forward to hear from you or another with some help.

Thanks again for a very good blog

Torben

As for the default fdb-aging timer, there should be an option to set the default timer to the new recommended value. Any existing vlans would keep what they have now and would need to be manually changed.
If anyone opens a ticket with them on this issue, get an engineer to submit an enhancement request.