Michael McNamara

technology, networking, virtualization and IP telephony

Ethernet Routing Switch 5000 Software Release v6.2.0

by

Avaya has released software 6.2.0 for the Ethernet Routing Switch 5500/5600 series switches. In order to upgrade to 6.2 software the switch will already need to be running 6.x software along with firmware (diagnostic software) 6.0.0.6. Switches that are running older software will need to first be upgraded to 6.0 and then to 6.2 software.

Please review the release notes for all the details.

Here are some of the new features;

  • Enterprise Device Manager
  • 802.1AB (LLDP) MED Network Policy
  • 802.1X authentication and Wake on LAN
  • 802.1X or Non-EAP and Guest VLAN on same port
  • 802.1X or Non-EAP Last Assigned RADIUS VLAN
  • 802.1X or Non-EAP with Fail Open VLAN
  • 802.1X or Non-EAP with VLAN name
  • Autodetection and Autoconfiguration (ADAC) Uplink Enhancements
  • Automatic QoS 802
  • Automatic QoS and ADAC Interoperability
  • Cisco CLI commands
  • Content-based forward to next hop (formerly source address-based route selection)
  • DHCP enhancements
  • DHCP option 82 support
  • Dual Syslog Server support
  • EAP/NEAP separation
  • Energy Saver
  • Enhanced QoS engine
  • Filter Limiting
  • Full IGMPv3
  • IPv4 Tunneling for IPv6
  • IPv6 Automatic Address Assignment
  • IPv6 Routing DHCP Relay
  • IPv6 Static Routing
  • MAC Security enhancement
  • Multicast group scaling
  • Multiple Hosts with Multiple VLANs for EAP-enabled Ports
  • PIM-SM support
  • Port Mirroring – Bi-directional monitor port
  • QoS DSCP mutation
  • QoS Egress Queue Shaping
  • QoS Lossless Buffering Mode for Data Center Applications
  • Route scaling
  • Running configuration NNCLI display command enhancements
  • Secure Shell File Transfer Protocol (SFTP over SSH)
  • SFP support
  • Split Multi-link Trunk (SMLT) consistency with the Ethernet Routing Switch 8600
  • Split Multi-link Trunk (SMLT) over Link Aggregation Control Protocol (LACP)
  • Trace command
  • Unicast storm control
  • VLAN Scaling

Here are some of the issues that have been resolved in this release;

  • Q01219391 MAC Address table does not age out all MAC sources learned after the aging time has expired.
  • Q01470123 Passive static device behind a phone displayed as unknown after switch reboot.
  • Q01470123-01 Passive static device behind a phone displayed as unknown after switch reboot.
  • Q01728560 ADAC port configuration types not defined in manual.
  • Q01775378 Error message when disabling spanning tree learning.
  • Q01859874 Typed commands should not be sent remotely when log level is serious or critical.
  • Q01860782 A message is needed to confirm the successful upload of an ASCII configuration to USB with the PUSH button.
  • Q01862906 The Time Domain Reflectometer in the JDM displays an incorrect message for the Pin Short cable error.
  • Q01863512 MAC security Lifetime setting cannot be modified from the JDM.
  • Q01865091 MAC authorized clients are not reauthorized after a former base unit reenters the stack.
  • Q01895467 Some LLDP commands fail when configuring a device with an ASCII configuration file.
  • Q01895723 Metric for external routes jumps to 127174722 when a dummy vlink is created and deleted.
  • Q01906362 An NEAP client can change ports without a link down or age out timer event.
  • Q01909890 QoS-IGMP problems with known and unknown multicast options on 56xx ports.
  • Q01901336 Multicast traffic not forwarded through non-local static routes.
  • Q01923408-02 Management VLAN IP address should always be used in relation to RADIUS.
  • Q01927698 PIM interfaces become disabled on a device.
  • Q01938607 Incorrect error message displayed during software download from an unreachable server.
  • Q01942783 Restoring a device with an ASCII configuration file fails when Layer 3 settings are present.
  • Q01943527 Inconsistency between IPv4 and IPv6 in binary configuration file.
  • Q01945909 Some ARP, OSPF, or VRRP packets are unexpectedly mirrored when using XrxYtx mirroring mode and the monitored port is in the Management VLAN or in SMLT VLANs.
  • Q01946214 MAC addresses are lost when a base unit fails.
  • Q01946284 LLDP-Med does not work in certain circumstances
  • Q01947050 ADAC system message logged after a stack is reset.
  • Q01948343 On a pure 56xx stack, port mirroring mode XrxYtx multiplies unicast traffic on port Y in certain scenarios.
  • Q01950071 VLACP enabling does not work in some circumstances.
  • Q01950147 The EAP-TLS or PEAP-MsChapV2 clients could be unexpectedly transitioned to the EAP Held state on a multihost enabled port.
  • Q01950311 Voice traffic is blocked on a non-base unit when ARP inspection is enabled on a VoIP VLAN.
  • Q01951600 Error performing MIB walk on 5632.
  • Q01954041 LLDP Med-Network-Policies Voice Tagging command issue.
  • Q01955272 PIM OIF may not get installed on IR.
  • Q01956922 Continuous IPv6 ping out stops working after 2147 ICMPv6 messages.
  • Q01978465 Telnet session hangs on ERS 5510-48T during an ASCII configuration download.
  • Q02005019 ACG will fail when ports are added to VLANs if an STG was created, VLANs were added, the STG enabled and then ports added to VLANs (configuration control flexible and 1 port in 2 different VLANs).
  • Q02020938 After booting to default settings the syslog will display the message ASCII failed at line 1. This can be ignored. This only happens after a boot to default settings and not during a normal operation or reset of the switch. This does not affect subsequent ASCII downloads. The successful application of configurations can be confirmed using the show logging command. The bogus message will be the first in chronological order.

I would highly recommend you review the release notes for all the details. There are a lot of known issues that should be thoroughly reviewed before you made any decisions about upgrading.

There was one section that caught my eye on page 11 of the release notes;

Currently when ADAC is operational, a user can not change the non-ADAC VLANs on the port (without disabling ADAC, changing the VLAN and then re-enabling ADAC), which leads to usability issues that limit the deployment of ADAC.

The ADAC enhancements provide the ability to change the non-ADAC VLANs on a port irrespective of the ADAC status of the port. Any such changes in the underlying port VLAN assignment are saved as normal to NVRAM and ASCIII configurations.

I posted about this issue with ADAC way back in August of 2008. This one issue has been a real bear and the only real issue we’ve experienced with our ADAC deployments. While it might be the only issue, it can create some enormous problems if the engineers are following the procedure to disable ADAC, make the VLAN change and then enable ADAC again. I’ll be very interested to see if this problem is finally resolved.

I spent a few minutes playing with Enterprise Device Manager but I think this change will drive more folks to the CLI interface where Avaya/Nortel has alot of work to-do. I’m also excited to see that Avaya/Nortel is finally bringing together their Automatic QoS and ADAC features, I’m curious to see what changes they’ve made an how I might be able to tweak my switch configurations to better automate the deployment of IP telephony.

Cheers!

Factory Reset Nortel IP Phone

by

I know I’ve been asked this question quiet frequently and I finally got around to digging up the answer. Here are the details from the Nortel technical configuration guide with a few grammar changes and some formatting thrown in.

You can factory reset a Nortel IP phone that is already running UNIStim firmware release 3.0 or later.  You will need to be running the following firmware at a minimum for this procedure to work;
IP 1110 (0623C6E), IP 1120E (0624C6E), IP 1140E (0625C6E), IP 1150E (0627C6E), IP 1210 (062AC6E), IP 1220 (062AC6E), IP 1230 (062AC6E), IP 2001 (0604DCD), IP 2002 (0604DCD), IP 2004 (0604DCD), and IP 2007 (0621C6D).

The UNIStim firmware release 3.0 for IP Phones introduces the ability to restore an IP Phone to a “factory default” configuration. This can be useful when redeploying an IP Phone from one location to another, when starting to use an IP Phone with unknown history, or to reset to a known baseline configuration.

With UNIStim firmware release 3.0, and greater, the following keypad sequence is used to reset all provisioning parameters to a “factory default”:

[*][*][7][3][6][3][9][MAC][#][#]

Where the MAC corresponds to the MAC address of the IP Phone which can be found on a label on the back of the IP Phone.

Since a MAC address can contain the letters A through F, the letters A, B and C can be entered via the [2] key on the dial pad, and letters D, E and F can be entered via the [3] key.

For example, an IP Phone with MAC address 00:19:E1:E2:17:12 would be reset to “factory default” when the sequence **73639001931321712## is entered on the keypad.

Cheers!

Upgrading the i2002 Phone Firmware

by

i2002_ip_phoneWe’re preparing to deploying 300+ i2002/i2004 IP telephones over the next few weeks. In preparation for this deployment we decided to upgrade the current IP phone firmware from 0604DBG to 0604DCG. The site has a Nortel Succession 1000M Call Server with 3 Succession Remote Gateway (SRG) 50s providing local PSTN and E-911 services at three remote facilities.  We have done this dozens of times in multiple locations and never really had an issue (except when ‘filter-unregistered-frames‘ was left enabled on the switch ports). This time, however, we came across a problem that caused all 12 i2002 IP phones at one remote site to get stuck in a continual loop trying to upgrade. It took us quite sometime to isolate the problem and come up with a solution although a little background is necessary to understand the problem.

[ad name=”ad-articlebodysq”]When Nortel originally released the ADAC (Automatic Detection And Configuration) feature in the Nortel Ethernet Routing Switch it required the switch to be pre-programmed with all the possible MAC addresses that an IP phone might connect with. The switch applied a dynamic configuration to any switch port where ADAC was enabled and the MAC address of the device was within the ADAC MAC address table range. In the article entitled, Nortel ERS 5520 PwR Switch, I documented a list of MAC address ranges to add to the ADAC configuration. In a subsquent article entitled, ERS 5520 Switch v5.1 Software, I surmised that it was no longer necessary to maintain the ADAC MAC address table.

It would now appear that my assumption was totally wrong.

The remote site that had the problem never had the ADAC MAC address table updated beyond what is in the default configuration. When the phone booted into BOOTC mode to perform the upgrade it wasn’t sending the necessary LLDP information to the switch so the switch wasn’t adding the voice VLAN to the port. The only problem was that the phone was using the voice VLAN tag and original IP address so while it’s requests made it to the server the phone never recieved an answer because the voice VLAN was not a member of the port that the phone was connected to. Once we added all the MAC addresses to the ADAC table everything starting working properly. Now when the IP phone booted into BOOTC mode ADAC immediately recognized the MAC address and applied the voice VLAN to the switch port allowing the IP phone to communicate with the SRG50 and the Succession 1000M Signaling Server.

no adac mac-range-table
adac mac-range-table low-end 00:0a:e4:75:00:00 high-end 00:0a:e4:75:ff:ff
adac mac-range-table low-end 00:13:65:00:00:00 high-end 00:13:65:ff:ff:ff
adac mac-range-table low-end 00:14:c2:00:00:00 high-end 00:14:c2:ff:ff:ff
adac mac-range-table low-end 00:16:ca:00:00:00 high-end 00:16:ca:ff:ff:ff
adac mac-range-table low-end 00:17:65:00:00:00 high-end 00:17:65:ff:ff:ff
adac mac-range-table low-end 00:18:b0:00:00:00 high-end 00:18:b0:ff:ff:ff
adac mac-range-table low-end 00:19:69:00:00:00 high-end 00:19:69:ff:ff:ff
adac mac-range-table low-end 00:19:e1:00:00:00 high-end 00:19:e1:ff:ff:ff
adac mac-range-table low-end 00:1b:ba:00:00:00 high-end 00:1b:ba:ff:ff:ff
adac mac-range-table low-end 00:1e:ca:00:00:00 high-end 00:1e:ca:ff:ff:ff
adac mac-range-table low-end 00:22:67:00:00:00 high-end 00:22:67:ff:ff:ff

The short story here is that you need to maintain the ADAC MAC address table if you want to avoid any IP phone firmware upgrade issues.

As a side note you also need to make sure that you disable filter-unregistered-frames on all switch ports.

I’ve inquired with Nortel about this problem but I’m still waiting for a response. It’s quite possible that this issue has already been “discovered” and will be resolved in a future release (or even resolved in this release).

Cheers!

Nortel Discovery Protocol

by

The Nortel Discovery Protocol (NDP) formerly called SynOptics Network Management Protocol (SONMP) is a data link layer (Layer 2) network protocol for topology discovery of Nortel devices. It’s very similar to the Cisco Discovery Protocol (CDP) if only just a little simpler.

I’ve used the Nortel Discovery Protocol on a number of occasions to help document and troubleshoot problems within a network. While Nortel’s Java Device Manager (GUI) provides support for displaying the topology table it leaves some very vital information out, specifically the remote card and port from where the connection is originating. You can however, view that information from the CLI interface of Nortel’s Ethernet Switches (ES) and Ethernet Routing Switches (ERS).

Here’s an example of the topology table from an Ethernet Routing Switch 5530 stack which is Split MultiLink Trunk (SMLT) connected to a cluster pair of Ethernet Routing Switch 8600s;

5530-24TFD#show autotopology nmm-table
LSlot                                                                     RSlot
LPort IP Addr          Seg ID  MAC Addr     Chassis Type     BT LS   CS   RPort
----- --------------- -------- ------------ ---------------- -- --- ----  -----
0/ 0 10.102.255.65   0x000000 00159BEACC00 5530-24TFD       12 Yes HTBT    NA
1/23 10.102.1.5      0x000406 0004387070E8 Passport 8610    12 Yes HTBT   4/ 6
2/47 10.102.1.6      0x000406 000FCDF1E0E8 Passport 8610    12 Yes HTBT   4/ 6

You can see from the information above that ports 1/23 and 2/47 on the ERS 5530 connect to port 4/6 on the ERS 8600 Core A (10.102.1.5) and port 4/6 on the ERS 8600 Core B (10.102.1.6).

Looking at one of the core ERS 8600 switches we can see the following topology table;

ERS8600:5# show sys topology

================================================================================
Topology Table
================================================================================
Local                                                                     Rem
Port  IpAddress       SegmentId MacAddress   ChassisType      BT LS  CS   Port
--------------------------------------------------------------------------------
0/0  10.102.1.5      0x000000  000438707000 ERS8610          12 Yes HtBt  0/0
1/1  10.102.1.6      0x000101  000fcdf1e000 ERS8610          12 Yes HtBt  1/1
1/5  10.102.255.19   0x00012f  001e7e7b0c01 mBayStack4500-48GT-PWR 12 Yes HtBt  1/47
1/6  10.102.255.35   0x000130  000cf73c25c1 mBayStack470     12 Yes HtBt  1/48
1/7  10.102.255.60   0x00012f  0014c733e401 mBayStack5520-48T-PWR 12 Yes HtBt  1/47
2/20 10.102.1.9      0x000201  001d427b7040 ERS8610          12 Yes HtBt  2/1
4/1  10.102.1.6      0x000401  000fcdf1e0c0 ERS8610          12 Yes HtBt  4/1
4/4  10.102.255.45   0x000119  0011f9abc541 mBayStack470-24T 12 Yes HtBt  1/25
4/6  10.102.255.65   0x000117  00159beacc00 mERS5530-24TFD   12 Yes HtBt  1/23
4/7  10.102.255.75   0x000132  000e40eb4031 Passport1648     12 Yes HtBt  1/50
9/1  10.102.255.25   0x000119  00802deb6150 mBayStack450     12 Yes HtBt  1/25

You can see from this table that there are quite a few edge/closet switches connected to this specific ERS 8600 and you can quickly and easily identify which ports they are connected to.

Cheers!

Is Nortel on the rebound?

by

It sure looks that way these past few weeks. I generally try to keep all the posts here very technical and absent of opinion but there’s been a lot of attention lately on how Nortel appears to be starting to emerge from the watery hole it’s been in for the past six years. While their product lines for the enterprise have been fairly successful, Nortel has struggled financially ever since the 2002 dot-com financial bust.

We utilize both Nortel and Motorola at my current place of employment, and have done so for the the past 12 years, ever since I started with the organization. Six months ago I was asked, “what will happen with our data, voice and wireless networks if Nortel and/or Motorola go under?” It was and still is a very valid question from an enterprise standpoint. My answer was simple and straightforward, “we’ll cross that bridge when and if we come to it”.

nortel_energyIt would seem that Nortel has recently decided to take off the gloves and come out swinging with a very big marketing campaign around their lower power consumption.

Larry Dignan posted an article entitled, “Can Nortel pull an AMD on Cisco?”

Jason Hiner posted an entry on his blog entitled, “Nortel claims that it is siphoning network customers away from Cisco“.

While there might be some “inflated” marketing claims in Nortel’s pitch it would appear that the basic claims are true and accurate. There were some interesting videos posted on YouTube from the recent Interop 2008 convention.

I will say that I have been very happy with both Nortel and Motorola. They have provided cost effective, reliable solutions for some very demanding business critical applications.

I would also agree that Cisco makes some really great products. It just seems that they need a few competitors to keep them honest these days with respect to price and service.

You can see “The Nortel Tax Relief Plan” for yourself.

Cheers!

Recent Posts

Categories

SUBSCRIBE BY EMAIL