Michael McNamara

technology, networking, virtualization and IP telephony

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 5000 Software Release v6.1.5

by

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

The following issues have been resolved;

  • The new unit config control feature (NUQC) did not work properly, for instance, when a third unit was added to the stack, it was not correctly configured (wi00554951).
  • A SW exception in the SNMP task that caused a base unit reset is now addressed (wi00554965).
  • An EAP enabled port with User based Policy configured timed out when a PC client went to sleep mode (wi00554946).
  • With LACP configured, some times the standby links were not properly recognized (wi00600984).
  • Some times POE powered IP phones would get the wrong VLAN ID after a stack reset (wi00686407).
  • A security vulnerability to DoS attack has now been fixed (wi00496350).
  • A memory leak that caused stack instability is resolved (wi00555049).
  • The LACP link was not properly removed from the aggregation during a unidirectional link failure (wi00488102).
  • A static route that went inactive, did not recover until a unit reset (wi00692259).
  • A log message was not generated when SLPP disabled a port (wi00554966).
  • The DHCP snooping entries were not properly removed with IP source guard configured (wi00554988).
  • The OutDiscards were wrongly counted as filtered packets (wi00692574).
  • Some times the GBIC info was not displayed on remote units if the GBIC was removed (wi00555110).
  • With EAP enabled ports at default values, the authentication failed on the first attempt (wi00691680).
  • The RIP updates with the destination address of 255.255.255.255 were not recognized (wi00703945).
  • Certain laptops did not work properly with DHCP snooping enabled (wi00733255).
  • Some VRRP Configurations were lost when a non-base unit was powered off and then the base unit was powered off/on (wi00731771).
  • The static ARP entries were removed after clearing ARPs or a power loss (wi00733359).
  • When a SFP was connected to a non-base unit and then removed, it would still show up at its original location (wi00827484).
  • The switch became unresponsive when displaying PIM configuration in “show running-config” (wi00555038).
  • A problem with updating the remote GBIC info caused a SW exception, this issue is now resolved (wi00824536).
  • Some times rebooting the non-base unit caused a broadcast storm on remaining DMLT links (wi00496279)
  • The Dynamic ARP inspection/DHCP snooping blocked certain clients during PXE boot (wi00692082).
  • The Switch becomes unresponsive when displaying PIM configuration (wi00555038).

As always I strongly suggest you review the release notes if you are interested in deploying 6.1.5 to your production network.

Cheers!

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!

Traffic Filters and ACLs for the Ethernet Routing Switch 5000

by

1105094_15304690There have been a few recent comments on the blog and a few questions on the discussion forum around how ACLs (traffic filters) work on the Ethernet Routing Switch 5520. I thought I would take a few minutes to dive into the subject and perhaps either answer some of those questions or foster some additional discussion. Let me get right to the most popular question.

Is the Ethernet Routing Switch 5510/5520/5530 capable of performing basic IP filtering? Yes.

Prior to software release 5.0 you had to-do all filtering in QoS policies. It seems a lot of confusion comes from the fact that in order to perform IP filtering similar to an ACL in a Cisco router you had to create a QoS policy. With the release of 5.0 software you can now create fairly straight forward ACLs. You can only do this from the CLI or WEB interface, there’s no support for ACLs in Java Device Manager.

Let me walk you through a simple example.

I started with a ERS-5520-PwR and factory reset the switch I gave it a management IP address of 192.168.1.50 (VLAN 1);

5520-48T-PWR(config)#ip address switch 192.168.1.50
5520-48T-PWR(config)#ip default-gateway 192.168.1.1
5520-48T-PWR(config)#ip address netmask 255.255.255.0

I created VLAN 100 and moved ports 13-48 to VLAN 100 making sure to set the PVID;

5520-48T-PWR(config)#vlan members remove 1 13-48
5520-48T-PWR(config)#vlan create 100 type port
5520-48T-PWR(config)#vlan members add 100 14-48
5520-48T-PWR(config)#vlan ports 13-48 pvid 100

I enabled IP routing on the switch (remember out of the box it’s just a Layer 2 switch);

5520-48T-PWR(config)#ip routing

I enabled IP routing for VLAN 1 and then gave VLAN 100 an IP address/interface;

5520-48T-PWR(config)#interface vlan 1
5520-48T-PWR(config-if)#ip routing
5520-48T-PWR(config)#exit

5520-48T-PWR(config)#interface vlan 100
5520-48T-PWR(config-if)#ip address 192.168.100.1 255.255.255.0 2
5520-48T-PWR(config-if)#ip routing
5520-48T-PWR(config)#exit

Let’s just making sure that everything looks right before we get the real meat of this post;

5520-48T-PWR#show vlan ip
==============================================================================
Vid  ifIndex Address         Mask            MacAddress        Offset Routing
==============================================================================
Primary Interfaces
------------------------------------------------------------------------------
1    10001   192.168.1.50    255.255.255.0   00:1F:0A:CE:XX:40 1      Enabled
100  10100   192.168.100.1   255.255.255.0   00:1F:0A:CE:XX:41 2      Enabled
------------------------------------------------------------------------------
% Total of Primary Interfaces: 2

The two IP interfaces are configured properly and have routing enabled. Let’s make sure that the routing table is correct;

5520-48T-PWR#show ip route
===============================================================================
                                        Ip Route
===============================================================================
DST             MASK            NEXT            COST    VLAN PORT PROT TYPE PRF
-------------------------------------------------------------------------------
0.0.0.0         0.0.0.0         192.168.1.1     10       1    1     S  IB     5
192.168.1.0     255.255.255.0   192.168.1.50    1        1    ----  C  DB     0
192.168.100.0   255.255.255.0   192.168.100.1   1        100  ----  C  DB     0
Total Routes: 3
-------------------------------------------------------------------------------
TYPE Legend:
I=Indirect Route, D=Direct Route, A=Alternative Route, B=Best Route, E=Ecmp Route, U=Unresolved Route, N=Not in HW

Here’s where the real work starts. I created an ACL named “testacl” and then assigned it to port 23.

5520-48T-PWR(config)#qos ip-acl name testacl src-ip 192.168.100.0/24 protocol 6 dst-port-min 80 dst-port-max 80
5520-48T-PWR(config)#qos ip-acl name testacl drop-action enable
5520-48T-PWR(config)#qos acl-assign port 23 acl-type ip name testacl

In the statements above I created an ACL that will allow traffic sourced from 192.168.100.0/24 to a destination TCP port of 80 to pass unrestricted while blocking (dropping) all other traffic. I’ve assigned that ACL to port 23 where I have a test PC connected to the switch.

Let’s just pretend that you forgot to allow DNS (UDP/53) queries in your IP filter so let’s back out the ACL and recreate it.

First we need to determine the ACL number that was assigned to our ACL called “testacl”.  We can do that by issuing the following command;

5520-48T-PWR#show qos acl
Id               Name              State   ACL  Unit/Port Storage
Type             Type
_____ ____________________________ ________ ____ _________ ________
1     testacl                      Enabled  IP   1/23      NonVol

We also need to know how many rules are in the IP ACL that’s being referenced above. We can do that with the following command;

5520-48T-PWR#show qos ip-acl

Id: 1
Name: testacl
Block:
Address Type: IPv4
Destination Addr/Mask: Ignore
Source Addr/Mask: 192.168.100.0/24
DSCP: Ignore
IPv4 Protocol / IPv6 Next Header: TCP
Destination L4 Port Min: 80
Destination L4 Port Max: 80
Source L4 Port Min: Ignore
Source L4 Port Max: Ignore
IPv6 Flow Id: Ignore
Action Drop: No
Action Update DSCP: Ignore
Action Update 802.1p Priority: Ignore
Action Set Drop Precedence: Low Drop
Type: Access List
Storage Type: NonVolatile

Id: 2
Name: testacl
Block:
Address Type: IPv4
Destination Addr/Mask: Ignore
Source Addr/Mask: Ignore
DSCP: Ignore
IPv4 Protocol / IPv6 Next Header: Ignore
Destination L4 Port Min: Ignore
Destination L4 Port Max: Ignore
Source L4 Port Min: Ignore
Source L4 Port Max: Ignore
IPv6 Flow Id: Ignore
Action Drop: Yes
Action Update DSCP: Ignore
Action Update 802.1p Priority: Ignore
Action Set Drop Precedence: Low Drop
Type: Access List
Storage Type: NonVolatile

Now we can remove the ACL from port 23 and then delete it from the switch;

5520-48T-PWR(config)#no qos acl-assign 1
5520-48T-PWR(config)#no qos ip-acl 2
5520-48T-PWR(config)#no qos ip-acl 1

Now we’ll rebuild the ACL allowing DNS queries to the broadband router;

5520-48T-PWR(config)#qos ip-acl name testacl src-ip 192.168.100.0/24 protocol 6 dst-port-min 80 dst-port-max 80
5520-48T-PWR(config)#qos ip-acl name testacl src-ip 192.168.100.0/24 dst-ip 192.168.1.1/32 protocol 17 dst-port-min 53 dst-port-max 53
5520-48T-PWR(config)#qos ip-acl name testacl drop-action enable
5520-48T-PWR(config)#qos acl-assign port 23 acl-type ip name testacl

Now that we have our filter let’s see what it looks like (I’m not a fan of this output format);

5520-48T-PWR#show qos ip-acl

Id: 1
Name: testacl
Block:
Address Type: IPv4
Destination Addr/Mask: Ignore
Source Addr/Mask: 192.168.100.0/24
DSCP: Ignore
IPv4 Protocol / IPv6 Next Header: TCP
Destination L4 Port Min: 80
Destination L4 Port Max: 80
Source L4 Port Min: Ignore
Source L4 Port Max: Ignore
IPv6 Flow Id: Ignore
Action Drop: No
Action Update DSCP: Ignore
Action Update 802.1p Priority: Ignore
Action Set Drop Precedence: Low Drop
Type: Access List
Storage Type: NonVolatile

Id: 2
Name: testacl
Block:
Address Type: IPv4
Destination Addr/Mask: 192.168.1.1/32
Source Addr/Mask: 192.168.100.0/24
DSCP: Ignore
IPv4 Protocol / IPv6 Next Header: UDP
Destination L4 Port Min: 53
Destination L4 Port Max: 53
Source L4 Port Min: Ignore
Source L4 Port Max: Ignore
IPv6 Flow Id: Ignore
Action Drop: No
Action Update DSCP: Ignore
Action Update 802.1p Priority: Ignore
Action Set Drop Precedence: Low Drop
Type: Access List
Storage Type: NonVolatile

Id: 3
Name: testacl
Block:
Address Type: IPv4
Destination Addr/Mask: Ignore
Source Addr/Mask: Ignore
DSCP: Ignore
IPv4 Protocol / IPv6 Next Header: Ignore
Destination L4 Port Min: Ignore
Destination L4 Port Max: Ignore
Source L4 Port Min: Ignore
Source L4 Port Max: Ignore
IPv6 Flow Id: Ignore
Action Drop: Yes
Action Update DSCP: Ignore
Action Update 802.1p Priority: Ignore
Action Set Drop Precedence: Low Drop
Type: Access List
Storage Type: NonVolatile

That’s a basic ACL filter using Layer 3 parameters. There is a Technical Configuration Guide available from Nortel/Avaya that provides additional examples and covers Filtering and QoS configuration of the Ethernet Routing Switch 5500 series switches. The guide is a little dated by still a very useful resource in my opinion.

Cheers!

Reference;
2008_04_01_Filters_and_QOS_Configurati0on_for_Ethernet_Routing_Switch_5500_TCG_NN48500559.pdf

Avaya Technical Configuration Guide for IPFIX

by

Avaya has released an updated technical configuration guide detailing how to configure IPFIX on the Ethernet Routing Switch 4500, 5000, 8300 and 8600. The document goes into detail documenting how to configure the different switch models. It also covers Avaya’s IP Flow Manager (IPFM) in significant detail.

I’m curious if anyone out there is using Avaya’s IP Flow Manager and has any thoughts and/or comments to share.

I remember a few folks either here or on the forums commenting that they were using nTop to collect the IPFIX flow information. Anyone have any thoughts about nTop/nProbe?

Cheers!

Image Credit to Network World

Recent Posts

Categories

SUBSCRIBE BY EMAIL