Michael McNamara

technology, networking, virtualization and IP telephony

Avaya IP Softphone 2050 Release 4.2

by

Avaya has released the IP Softphone 2050 Release 4.2 (Build 4.02.62) for the Microsoft Windows PC. This is primarily a maintenance release that includes multiple fix but no new additional features.

  • (101102-26211, wi00838178, wi00828501)
    Corrects an issue running on Windows 7 where the IP Softphone 2050 does not connect to the call server after displaying “Terminal Manager Connect”.
  • (100721-77062, wi00832321)
    Corrects an issue where the IP Softphone 2050 may hang if it receives a call after being idle for several hours and the call is answered immediately.
  • (wi00839244)
    Corrects an issue where the IP Softphone 2050 would crash when clicking “Add Link To” in the Local Directory.
  • (wi00842584)
    Resolves an issue with duplicate audio streams where the Receive audio stream is not reopened after both the Rx and Tx streams have been closed.

The release notes can be found here. You can also find additional information in the IP Phone Fundamentals manual which is here.

Cheers!

Ethernet Routing Switch 8600 Software Release v5.1.5.1

by

Avaya has released software v5.1.5.1 for the Ethernet Routing Switch 8600. It should be noted that Avaya has pulled software release 5.1.5.0 from their website. The release notes indicate that the reason for this was “a datapath issue has been identified that may impact the ability to learn MAC addresses and forward packets for which the source MAC address is unknown. This will only happen if the traffic enters the same LANE as the IST is located on and if the IST occupies the first port in the LANE. Also, this is only seen on card types 8630GBR, 8648GBRS, 8634XGRS and 8612XLRS. (wi00866354)”.

Cheers!

Ethernet Routing Switch 5000 Software Release v6.1.6

by

Avaya has released software 6.1.6 for the Ethernet Routing Switch 5500/5600 series switches.

The following issues have been resolved with this software release;

  • The dhcp-relay agent changed the MAC destination address of acknowledgments from a unicast address to a multicast address (wi00835598).
  • After a reboot, some client ports with active connections would autonegotiate to a lower speed (10/100) than expected (1000).This issue affected some Intel 82556 and Broadcom NICs (wi00555121).

I’ve personally seen issue wi00555121 above while working with a large HP MAS (Medical Archive Solution) implementation. I also believe that someone (either on this blog or in the discussion forums) also brought up issue wi00835598.

The new feature includes VLACP enhancements with support for DOWN and HOLD subtypes which were introduced in 5.1.4.0 software for the Ethernet Routing Switch 8600. The goal of the new VLACP subtypes it to provide a means to allow the core ample time to get up to speed before the edge starts forwarding traffic. I’ve personally seen many an occasion where one Ethernet Routing Switch 8600 in a cluster goes down with minimal packet loss but upon recovery there are all sorts of packet loss and network interruption. This new feature is designed to mitigate that problem by allowing link to come up… VLACP to come active but hold the actual network traffic back until the core is ready to start bridging/routing packets.

VLACP Enhancements – support for DOWN and HOLD subtypes

The VLACP implementation prior to this release did not detect a unidirectional communication outage. A VLACP partner will now send VLACP PDUs with the subtype DOWN (value of 2) when no PDUs are received from its link partner. These PDUs indicate the remote VLACP partner is down and the link partner should logically bring down its port. Shortly after reboot, a VLACP partner will send PDUs with the subtype HOLD (value of 3) to its link partner. In this case, receiving a PDU with subtype HOLD indicates the VLACP partner should logically bring down its port for a VLACP hold time. When receiving VLACP PDUs with HOLD or DOWN subtypes, the VLACP partner will respond with normal PDUs (LACP subtype). The interval between PDUs is configurable by the user. The VLACP support for HOLD subtype is disabled by default, it will be enabled only when a positive value for VLACP HOLD Time is configured. VLACP is an Avaya proprietary protocol and hence this enhancement will not work when connecting to devices from other vendors.

You’ll recall from the Ethernet Routing Switch 8600 5.1.4.0 release notes that Avaya introduce a new VLACP subtype on the core side;

VLACP HOLD Enhancement

During SMLT node failure scenarios, traffic loss may be observed in certain scaled SMLT configurations with hundreds of SLTs, hundreds of ports and tens of VLANs. The root cause for the traffic loss was that the ERS8600 ports would come up prematurely at the physical layer causing the remote end to start sending traffic toward the ERS8600 that just came up. On the ERS8600 that just rebooted, the communication between the line cards and the CP may take several seconds in such scaled configurations. This resulted in black-holing the traffic arriving on such ports which were physically up but all operational configuration was not yet performed on those ports by the CP. The VLACP SUBTYPE HOLD feature introduces a new VLACP PDU with a new subtype HOLD to help reduce traffic loss in such scenarios.
The goal of this new implementation is to “hold down” all VLACP enabled links for a specific period of time after a reboot. This prevents remote VLACP enabled devices that understand the new VLACP HOLD PDU from sending data to the ERS8600. This will ensure that all VLACP enabled ports on the ERS8600 have had sufficient time to come up with all operational configuration and are ready to receive and forward the ingress traffic.
ERS8600 switches with 5.1.4.0 release are capable of both sending and receiving VLACP HOLD PDUs. Future code revisions of the Baystack switch family will support receipt and processing of VLACP HOLD PDUs, but will not generate them. Please refer to the applicable product release notes for information regarding product specific software levels required for support of this VLACP enhancement. VLACP is an Avaya proprietary protocol and hence this enhancement in not applicable when connecting to switches from other vendors.
By default, the VLACP HOLD feature will be disabled. The feature is enabled by configuring a positive value for VLACP HOLD Time. The VLACP Hold Time value configured should be selected based on the specific recovery implementation requirements, size and recovery characteristics for your network implementation.

You can find the release notes here. (I’m going to try linking to Avaya’s support website instead of hosting the files myself).

Cheers!

Ethernet Routing Switch 8600/8800 Software Release v7.1

by

Avaya has released software v7.1 for the Ethernet Routing Switch 8600/8800.

The most notable feature in this software release is the inclusion of Shortest Path Bridging  (SPB).

“Release 7.1 of the Ethernet Routing Switch 8800/8600 supports the IEEE 802.1aq standard of Shortest Path Bridging MACinMAC (SPBM). SPBM makes network virtualization much easier to deploy within the Enterprise environment, reducing the complexity of the network while at the same time providing greater scalability.

SPBM eliminates the need for multiple overlay protocols in the core of the network by reducing the core control plane to a single protocol which can provide virtualization services for both layer 2 and layer 3, on a common Ethernet infrastructure using a pure Ethernet technology base. SPBM allows for layering the Ethernet network into edge and core domains with complete isolation between their MAC addresses. This technology provides all the features and benefits required by Carrier-grade deployments to the Enterprise market without the complexity of alternative technologies traditionally used in Carrier deployments (typically MPLS). SPBM integrates into a single control plane all the functions that MPLS requires multiple layers and protocols to support.

SPBM provides any-to-any connectivity in a network in an optimized, loop-free manner. It employs shortest-path trees to each destination, without the long convergence delays experienced with Spanning Tree Protocol. To do that, SPBM uses Intermediate System to Intermediate System (IS-IS) link state routing protocol to learn and distribute network information. IS-IS dynamically learns the topology of a network and uses its inherent knowledge to construct shortest path unicast and multicast trees from every node to every other node in the network. Also, unlike Spanning Tree Protocol, IS-IS does not block ports to provide a loop free topology, so bandwidth is not wasted.

The SPBM components introduced in this release are:

  1. Shortest Path Bridging (IEEE 802.1aq) for simple and safe VLAN extensions across a network. SPBM does not use spanning tree, and all its links are active.
  2. SMLT for dual-homing of non-SPBM switches to a pair of SPB/IST switches.
  3. SPBM/IP for simple and safe VRF extensions across a network infrastructure without OSPF or BGP.
  4. InterISID routing for routing of L2 VPNs in the SPB domain“

You can review the configuration guide around SPBM here.

You fine the release notes here along with an upgrade document here.

Cheers!

UNIStim Firmware Release 5.0 for IP Deskphones

by

Avaya has released UNIStim firmware 5.0 for their IP deskphones;

  • 0621C8A for the 2007 IP deskphone
  • 0623C8A, 0624C8A, 0625C8A, 0627C8A, 0626C8A for the 1110, 1120E, 1140E, 1150E and 1165E IP deskphones
  • 062AC8A for the 1200 series IP deskphones

This release of firmware adds support for the following features;

  • Support for wideband (G.722) codecs on 1120E, 1140E, 1150E, 1165E, 1220, and 1230 IP Deskphones.
  • Support for Avaya Notification Solution (ANS) and Avaya Push API which provides the ability to push text, graphics, and audio messages to 1100 Series, 1200 Series and the 2007 IP Deskphones.
  • Support for a Wireless Markup Language (WML) browser for 1140E, 1150E, and 1165E IP Deskphones.

Product Advisement for UNIStim 5.0 related to Zero Touch Provisioning:

For customers who have pre-configured the REG entries (which includes the MAC address, the TN, and Node) within the provisioning file to enable Zero Touch for the IP Deskphones, be advised that a problem can occur related to parsing of the REG entry that may result in the IP Deskphones not coming up as expected, and instead continuing to reboot when UNIStim 5.0 is loaded onto the units. The issue will impact IP Deskphones that have been pre-configured for Zero Touch and where the REG lines still exist in the REG entry. This is a known issue that will impact IP Deskphones that have a matching MAC address already pre-configured in the REG entry. This issue will be fully addressed in the upcoming UNIStim 5.1 maintenance release expected in March 2011, and customers may want to delay updating IP Deskphones and Call Servers until that time due to this issue.

In the interim, to avoid this issue the following workaround is recommended: Before loading UNIStim 5.0 onto the IP Deskphones, customers are advised to add a comma before the semi-colon of the REG entry. If UNIStim 5.0 is already loaded, and the issue exists (where the phones continue to reboot instead of coming up), the customer can then add a comma as specified above and the IP Deskphones will come up.

Example: reg= 0021e1ff59cb cs1k s1 3380 096 00 00 18,;

I also recently had a discussion with another telephony expert around the issues of running a PC at 100Mbps (connected to the IP phone) when the 1100 series IP phone is connected to the network via 1Gbps or vice-versa. Here’s the relevant blurb from the release notes that details the problem.

Throughput may be slow for large file transfers on conversions from GigE to 100Mbit (applies to the 1120E, 1140E, 1150E and 1165E IP Deskphones)

In networks in which a PC is connected to the IP Deskphone’s PC port and the PC’s NIC speed is 100Mbit but the network speed is at GigE, large file transfers to the PC can take quite a long time. This is an issue with large file transfers only. Due to the speed mismatch between the phone’s two ports the buffers in the phone can overflow resulting in retransmissions. Although the IP Deskphones support Ethernet flow control (802.3x), the support is only implemented on the phone’s PC port, not on the phone’s network port. Ethernet flow control is a mechanism were the IP Deskphone can request a brief “pause” from the transmitting Ethernet device if the IP Deskphone buffers are about to overflow.
Ethernet flow control cannot be implemented on the phone’s network port, since it impacts the phone’s voice quality. As a result, in environments were the network is GigE but the PC NIC is only 100Mbit, large file transfers from the network to the PC can take quite a long time. On the other hand, since Ethernet flow control is implemented on the phone’s PC port, in environments were the PC NIC is GigE but the network is only 100Mbits, large file transfers should be well managed by the phone’s Ethernet flow control mechanism.

You can find the release notes on Avaya’s website along with the actual firmware/software for the IP phones.

Cheers!

Recent Posts

Categories

SUBSCRIBE BY EMAIL