If your interested in some of the back story behind SMLT you might find the conversation interesting.

Cheers!

It turns out that with the latest generation of switches from Avaya you need to manually enable “stacking” mode on the switches before they will stack. The ports on rear of the switch, usually associated with stacking, can be used as regular ports? Perhaps in a SPB type deployment?

I had to issue the following commands to all three switches;

>enable
#config t
#rear-ports mode stacking
#save config
#reboot

After making that configuration change to all three switches and rebooting them they finally all stacked together.

Learning something new every day!

Cheers!
Mike

Dominik, one of our discussion forum moderators, was a recent guest to the Packet Pushers podcast in Show 210 – SPB Implementation Fundamentals where he discussed his SPB implementations with Ethan and Greg and Ricki Cook.

I’d recommend you give a listen if you are at all interested in how SPB works.

Cheers!

This single client supports the following operating systems (in both 32-bit and 64-bit versions);

•     Windows XP
•     Windows Vista
•     Windows 7
•     Windows 8

The following note is included at the top of the release notes;

When upgrading from Windows 7 GA to Windows 7 Service Pack 1 (SP1) users must remove the Avaya VPN Client prior to upgrading to SP1. Once the upgrade to SP1 is complete, reinstall the Avaya VPN Client.

Users who upgrade from a v10.05 or earlier release to v10.06 may receive the following error
dialogue when attempting to establish an IPSec VPN tunnel – “Activation of VPN Adapter Fa iled”. This issue occurs when the AVC filter a dapter is not upgraded correctly during software installation.

Resolved Issues

• wi00889600 10.06_500 – AVC 10.04.109 Client in SSL Mode Doesn’t Accept Untrusted Self-Signed Cert.
• wi00982245 10.06_500 – AVG IPsec mobility performance is very low.
• wi01069664 10.06_500 – AVC Mobility feature fails when moving from a wireless to a wired connection.
• wi01069666 10.06_500 – Repeated failover between wired and wireless connections may cause mobility failure.
• wi01100993 10.06_500 – VPN Client – PLAP is unreliable on Windows 8.
• wi01100994 10.06_500 – VPN Client – OSK (On-Screen Keyboard) does not launch with client.
• wi01109393 10.06_500 – AVC Client does not work with SSL Protocols TLS1.1 and TLS 1.2.
• wi01131474 10.06_500 – SSL tunnels may be disconnected due to multicast or host routing table entry changes which should have no impact on tunnel security. Changes to multicast and most host routes are now properly ignored.
• wi01138381 10.06_500 – The SwapAdapters option added in 10.06.200 does not take into account the registry path for 64-bit systems.

You should refer to the release notes for all the details, including the interoperability issues.

Note: I’m hosting these files from my own servers so please don’t abuse my generosity by hot-linking to them from other sites or by downloading the files dozens of times needlessly.

AVC32-10.06.500.exe (32-bit – Windows XP, Windows Vista, Windows 7, Windows 8)
MD5: 377d84bb29be2abb1197f2f791dce98b
AVC64-10.06.500.exe (64-bit – Windows XP, Windows Vista, Windows 7, Windows 8)
MD5: 24ac65597ce3ce92099940e7a316ad5c

I’m no longer personally using the Avaya VPN Client. These days I utilize the Juniper Network Connect (and Pulse) client when working remotely. So I’m not really in a position to help everyone with their installation problems. In the past I’ve found that the client will work fine on a fresh OS installation the majority of the time when it wouldn’t work on that same machine prior to the re-imaging.

Cheers!

Let’s look at expanding the topology from our last post adding a Cisco 3750E;

Again, that’s pretty straight forward and isn’t too exciting. Although if we leave every uplink/downlink as a member of VLAN 100 and VLAN 200 we’ll end up with a loop in our topology – not a Spanning Tree Loop. What if we add Multiple Spanning Tree Protocol (MSTP) to our configuration just to make it interesting? Our topology might look like this with 2 instances of MSTP running, one for each VLAN.

We’ll make the Avaya switch the root bridge for CIST. We’ll make the Juniper switch the root bridge for MST 1, and we’ll make the Cisco switch the root bridge for MST 2.

That’s interesting… let’s see what we need to-do in order to configure everything up. I’m going to pickup the configuration as I had it setup in the previous post, LACP Configuration  Examples (Part 4). We’ll need to add another LACP group/pair to our Avaya and Juniper switches as well as configure the Cisco switch. We’ll also need to enable MSTP on each switch, add the VLANs to the correct MSTP instances and set the correct bridge priority for each.

Juniper EX2200-C Switch

configure
set chassis aggregated-devices ethernet device-count 2

delete interfaces ge-0/0/4 unit 0
delete interfaces ge-0/0/5 unit 0

set interfaces ge-0/0/4 ether-options 802.3ad ae1
set interfaces ge-0/0/5 ether-options 802.3ad ae1
set interfaces ae1 aggregated-ether-options lacp active
set interfaces ae1 aggregated-ether-options lacp periodic fast

set interfaces ae1 unit 0 family ethernet-switching
set interfaces ae1 unit 0 family ethernet-switching port-mode trunk
set interfaces ae1 unit 0 family ethernet-switching port-mode trunk vlan members VLAN-100 members VLAN-200

delete protocols rstp

set protocols mstp configuration-name AcmeNetworks
set protocols mstp revision-level 1
set protocols mstp msti 1 vlan 100
set protocols mstp msti 2 vlan 200

set protocols mstp msti 1 bridge-priority 16384
commit and-quit

Avaya Ethernet Routing Switch 5520

config t
spanning-tree mode mst
exit
boot

You’ll need to reboot the switch in order to enable MSTP, so go ahead and reboot before continuing the steps;

config t
vlan ports 25,26 tagging tagAll

interface fastEthernet 25,26
lacp key 25
lacp mode active
lacp timeout-time short
lacp aggregation enable
exit

spanning-tree mstp msti 1
spanning-tree mstp msti 1 add-vlan 100
spanning-tree mstp msti 2
spanning-tree mstp msti 2 add-vlan 200
spanning-tree mstp priority 4000

You’ll notice that the Avaya switch accepts a hexadecimal value for the priority, so 4000 in hex = 16384 in decimal.

spanning-tree mstp region region-name AcmeNetworks
spanning-tree mstp region region-version 1
exit

Cisco Catalyst 3750E Switch

config t
vlan 100
name "192-168-100-0/24"
exit
vlan 200
name "192-168-200-0/24"
exit

interface vlan 100
ip address 192.168.100.30 255.255.255.0
no shut
exit

interface vlan 200
ip address 192.168.200.30 255.255.255.0
no shut
exit

interface gig1/0/13
switchport trunk encapsulation dot1q
switchport mode trunk
channel-protocol lacp
channel-group 1 mode active

interface gig1/0/14
switchport trunk encapsulation dot1q
switchport mode trunk
channel-protocol lacp
channel-group 1 mode active

interface gig1/0/25
switchport trunk encapsulation dot1q
switchport mode trunk
channel-protocol lacp
channel-group 2 mode active

interface gig1/0/26
switchport trunk encapsulation dot1q
switchport mode trunk
channel-protocol lacp
channel-group 2 mode active

spanning-tree mode mst

spanning-tree mst configuration
name AcmeNetworks
revision 1
instance 1 vlan 100
instance 2 vlan 200
exit
spanning-tree mst 2 priority 16384
exit

Let’s have a look at our work and see what everything looks like from both a LACP and Spanning Tree perspective.

Cisco Catalyst 3750E Switch

Switch#show lacp neighbor
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode

Channel group 1 neighbors

Partner's information:

LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi1/0/13 FA 127 54e0.xxxx.d440 5s 0x0 0x2 0x3 0x3F
Gi1/0/14 FA 127 54e0.xxxx.d440 5s 0x0 0x2 0x4 0x3F

Channel group 2 neighbors

Partner's information:

LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi1/0/25 FA 32768 3475.xxxx.a400 14s 0x0 0x3019 0x19 0x3F
Gi1/0/26 FA 32768 3475.xxxx.a400 16s 0x0 0x3019 0x1A 0x3F

Switch#show spanning-tree

MST0
Spanning tree enabled protocol mstp
Root ID Priority 16384
Address 3475.xxxx.a400
Cost 0
Port 496 (Port-channel2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32768 (priority 32768 sys-id-ext 0)
Address 0064.xxxx.4d80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 10000 128.488 P2p
Po2 Root FWD 10000 128.496 P2p

MST1
Spanning tree enabled protocol mstp
Root ID Priority 16385
Address 54e0.322a.d441
Cost 10000
Port 488 (Port-channel1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0064.xxxx.4d80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po1 Root FWD 10000 128.488 P2p
Po2 Desg FWD 10000 128.496 P2p

MST2
Spanning tree enabled protocol mstp
Root ID Priority 16386
Address 0064.xxxx.4d80
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 16386 (priority 16384 sys-id-ext 2)
Address 0064.xxxx.4d80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 10000 128.488 P2p
Po2 Desg FWD 10000 128.496 P2p

We can see that LACP is up and running to both the Avaya and Juniper switches. We can also see that the Cisco switch is the root bridge for MSTI 2 and the root port for MSTI 1 is Port-channel 1 (link to Juniper EX2200-C) while the root port for the CIST is Port-channel2 (link to Avaya ERS 5520). All ports are designated and forwarding traffic.

 Juniper EX2200-C Switch

root> show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/0 Current Fast periodic Collecting distributing
ge-0/0/1 Current Fast periodic Collecting distributing

Aggregated interface: ae1
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/4 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/4 Partner No No Yes Yes Yes Yes Slow Active
ge-0/0/5 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/5 Partner No No Yes Yes Yes Yes Slow Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/4 Current Slow periodic Collecting distributing
ge-0/0/5 Current Slow periodic Collecting distributing

root> show spanning-tree bridge

STP bridge parameters
Context ID : 0
Enabled protocol : MSTP

STP bridge parameters for CIST
Root ID : 16384.34:75:xx:xx:a4:00
Root cost : 0
Root port : ae0.0
CIST regional root : 16384.34:75:xx:xx:a4:00
CIST internal root cost : 10000
Hello time : 2 seconds
Maximum age : 20 seconds
Forward delay : 15 seconds
Hop count : 19
Message age : 0
Number of topology changes : 2
Time since last topology change : 14690 seconds
Topology change initiator : ae0.0
Topology change last recvd. from : 34:75:xx:xx:a4:01
Local parameters
Bridge ID : 32768.54:e0:xx:xx:d4:41
Extended system ID : 0
Internal instance ID : 0

STP bridge parameters for MSTI 1
MSTI regional root : 16385.54:e0:xx:xx:d4:41
Hello time : 2 seconds
Maximum age : 20 seconds
Forward delay : 15 seconds
Number of topology changes : 5
Topology change initiator : ae1.0
Topology change last recvd. from : 00:64:xx:xx:4d:8d
Local parameters
Bridge ID : 16385.54:e0:xx:xx:d4:41
Extended system ID : 0
Internal instance ID : 1

STP bridge parameters for MSTI 2
MSTI regional root : 16386.00:64:xx:xx:4d:80
Root cost : 10000
Root port : ae1.0
Hello time : 2 seconds
Maximum age : 20 seconds
Forward delay : 15 seconds
Hop count : 19
Number of topology changes : 6
Topology change initiator : ae1.0
Topology change last recvd. from : 00:64:xx:xx:4d:8d
Local parameters
Bridge ID : 32770.54:e0:xx:xx:d4:41
Extended system ID : 0
Internal instance ID : 2

Avaya Ethernet Routing Switch 5520

5520-48T-PWR#show lacp port 13-14,25-26
Admin Oper Trunk Partner
Port Priority Lacp A/I Timeout Key Key AggrId Id Port Status
---- -------- ------- --- ------- ----- ----- ------ ----- ------- ------
13 32768 Active A Short 1 12289 8224 32 1 Active
14 32768 Active A Short 1 12289 8224 32 2 Active
25 32768 Active A Short 25 12313 8223 31 282 Active
26 32768 Active A Short 25 12313 8223 31 283 Active

5520-48T-PWR#show spanning-tree mstp config
Maximum Mst Instance Number: 8
Number of Msti Supported: 2
Cist Bridge Priority (hex): 4000
Stp Version: Mstp Mode
Cist Bridge Max Age: 20 seconds
Cist Bridge Forward Delay: 15 seconds
Tx Hold Count: 3
Path Cost Default Type: 32-bit
Max Hop Count: 2000

VLAN members
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
1

Msti Config Id Selector: 0
Msti Region Name: AcmeNetworks
Msti Region Version: 1
Msti Config Digest: 6D:A4:B5:0C:4F:D5:87:75:7E:EF:03:56:75:36:05:E1

5520-48T-PWR#show spanning-tree mstp msti config 1
Msti Bridge Regional Root:  40:00:54:E0:xx:xx:D4:41
Msti Bridge Priority (hex): F000
Msti Root Cost:             10000
Msti Root Port:             MLT 32
Msti State:                 Enabled

VLAN members
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
100

5520-48T-PWR#show spanning-tree mstp msti config 2
Msti Bridge Regional Root:  40:00:00:64:xx:xx:4D:80
Msti Bridge Priority (hex): F000
Msti Root Cost:             10000
Msti Root Port:             MLT 31
Msti State:                 Enabled

VLAN members
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
200

5520-48T-PWR#show spanning-tree mstp msti port role 1
Port Role State STP Status Oper Status
---- ---------- ---------- ---------- -----------
13 Root Forwarding Enabled Enabled
14 Root Forwarding Enabled Enabled
25 Alternate Discarding  Enabled Enabled
26 Alternate Discarding  Enabled Enabled

5520-48T-PWR#show spanning-tree mstp msti port role 2
Port Role State STP Status Oper Status
---- ---------- ---------- ---------- -----------
13 Alternate Discarding  Enabled Enabled
14 Alternate Discarding  Enabled Enabled
25 Root Forwarding Enabled Enabled
26 Root Forwarding Enabled Enabled

We can see from the output above that ports 13,14 are Alternate Discarding for MSTI 1 while ports 25,26 are Alternate Discarding for MSTI 2.

In the output we can see which port is the root bridge port for each switch, we can also see the MSTP config digest which should match on every switch in the topology. In order for the configuration to be valid the MST region name, version and config selector need to match along with correct VLAN IDs matched to the correct MST instance.

Cheers!
Image Credit: New York City Brooklyn Bridge by Diogo Ferrari

In the past I’ve demonstrated how to connect an Avaya Ethernet Routing Switch 8600 to an Avaya Ethernet Switch 470, an Avaya Ethernet Routing Switch 8600 Cluster to an Avaya Ethernet Switch 470 via SMLT, an Avaya Ethernet Routing Switch 8600 Cluster to a HP GbE2c(Blade Technologies) via SMLT, and even an Avaya Ethernet Routing Switch 5520 to Cisco Catalyst 3750E.

In this post I’ll demonstrate how to establish an LACP 802.3ad link over 2 Gigabit interfaces between an Avaya Ethernet Routing Switch 5520 and a Juniper EX2200C switch. This isn’t really rocket science but I’m continually getting questions from all four corners of the globe regarding LACP configurations.

Sample Topology

This is a pretty simple topology, we’ll connect ports 13 and 14 on the ERS-5520 to ports ge-0/0/0 and ge-0/0/1 on the EX2200-C respectively. We’ll create VLANs 100 and 200 and assign them IP interfaces in the 192.168.100.0/24 and 192.168.200.0/24 networks respectively. We’ll test connectivity by pinging from one switch to the other on each VLAN.

Avaya Ethernet Routing Switch 5520

Here’s the configuration for the ERS-5520;

vlan ports 13,14 tagging tagAll

vlan create 100 name "VLAN-100" type port
vlan create 200 name "VLAN-200" type port

vlan members remove 1 all
vlan members add 100 13,14
vlan members add 200 13,14

interface vlan 100
ip address 192.168.100.10 255.255.255.0
exit
interface vlan 200
ip address 192.168.200.10 255.255.255.0
exit

ip routing
interface fastEthernet 13,14
lacp key 1
lacp mode active
lacp timeout-time short
lacp aggregation enable
exit

Juniper EX2200-C Switch

Here’s the configuration for the EX2200-C;

set vlans VLAN-100 vlan-id 100
set vlans VLAN-200 vlan-id 200
set interfaces vlan unit 100 family inet address 192.168.100.20/24
set interfaces vlan unit 200 family inet address 192.168.200.20/24
set vlans VLAN-100 l3-interface vlan.100
set vlans VLAN-200 l3-interface vlan.200

delete interfaces ge-0/0/0 unit 0
delete interfaces ge-0/0/1 unit 0
set chassis aggregated-devices ethernet device-count 1
set interfaces ge-0/0/0 ether-options 802.3ad ae0
set interfaces ge-0/0/1 ether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast

set interfaces ae0 unit 0 family ethernet-switching
set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
set interfaces ae0 unit 0 family ethernet-switching port-mode trunk vlan members VLAN-100 members VLAN-200

That’s really all there is to it… hopefully it’s pretty straight forward.

Troubleshooting

If you want to make sure that LACP is up and running there are a few commands you can use;

Juniper

root> show interfaces ae0 extensive
Physical interface: ae0, Enabled, Physical link is Up
  Interface index: 143, SNMP ifIndex: 531, Generation: 146
  Link-level type: Ethernet, MTU: 1514, Speed: 2Gbps, BPDU Error: None,
  MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
  Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth needed: 0
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x4000
  Current address: 54:e0:xx:2a:d4:43, Hardware address: 54:e0:xx:2a:d4:43
  Last flapped   : 2012-08-25 10:41:06 UTC (01:35:06 ago)
  Statistics last cleared: Never
  Traffic statistics:
   Input  bytes  :              2101034                 3056 bps
   Output bytes  :              1566394                 2032 bps
   Input  packets:                19178                    2 pps
   Output packets:                11909                    0 pps
   IPv6 transit statistics:
    Input  bytes  :                   0
    Output bytes  :                   0
    Input  packets:                   0
    Output packets:                   0
  Input errors:
    Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0,
    Policed discards: 0, Resource errors: 0
  Output errors:
    Carrier transitions: 2, Errors: 0, Drops: 0, MTU errors: 0,
    Resource errors: 0

  Logical interface ae0.0 (Index 65) (SNMP ifIndex 533) (Generation 145)
    Flags: SNMP-Traps 0x40004000 Encapsulation: ENET2
    Statistics        Packets        pps         Bytes          bps
    Bundle:
        Input :          2936          0        176682            0
        Output:            94          0          7163            0
    Link:
      ge-0/0/0.0
      ge-0/0/1.0
    LACP info:        Role     System             System      Port    Port  Port
                             priority          identifier  priority  number   key
      ge-0/0/0.0     Actor        127  54:e0:32:xx:d4:40       127       1     1
      ge-0/0/0.0   Partner      32768  34:75:c7:xx:a4:00     32768      13 12289
      ge-0/0/1.0     Actor        127  54:e0:32:xx:d4:40       127       2     1
      ge-0/0/1.0   Partner      32768  34:75:c7:xx:a4:00     32768      14 12289
    LACP Statistics:       LACP Rx     LACP Tx   Unknown Rx   Illegal Rx
      ge-0/0/0.0              5708        5699            0            0
      ge-0/0/1.0              5708        5699            0            0
    Marker Statistics:   Marker Rx     Resp Tx   Unknown Rx   Illegal Rx
      ge-0/0/0.0                 0           0            0            0
      ge-0/0/1.0                 0           0            0            0
    Protocol eth-switch, Generation: 162, Route table: 0
      Flags: Trunk-Mode

root> show lacp interfaces
Aggregated interface: ae0
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-0/0/0       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/0     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/1       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/1     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State
      ge-0/0/0                  Current   Fast periodic Collecting distributing
      ge-0/0/1                  Current   Fast periodic Collecting distributing

It’s always a good idea to have a look at the MAC or forwarding table to see what it looks like;

root> show ethernet-switching table
Ethernet-switching table: 7 entries, 2 learned
  VLAN              MAC address       Type         Age Interfaces
  default           54:e0:32:xx:d4:41 Static         - Router
  VLAN-100          *                 Flood          - All-members
  VLAN-100          34:75:c7:xx:a4:41 Learn       2:02 ae0.0
  VLAN-100          54:e0:32:xx:d4:41 Static         - Router
  VLAN-200          *                 Flood          - All-members
  VLAN-200          34:75:c7:xx:a4:42 Learn       1:50 ae0.0
  VLAN-200          54:e0:32:xx:d4:41 Static         - Router

Avaya

5520-48T-PWR#show lacp stats 13,14
Port 13   -------------------------------------
          LACPDUs Rx:             5784
          LACPDUs Tx:             6631
          MarkerPDUs Rx:          0
          MarkerResponsePDUs Rx:  0
          MarkerPDUs Tx:          0
          MarkerResponsePDUs Tx:  0
          UnknownPDUs Rx:         0
          IllegalPDUs Rx:         0
Port 14   -------------------------------------
          LACPDUs Rx:             5784
          LACPDUs Tx:             6631
          MarkerPDUs Rx:          0
          MarkerResponsePDUs Rx:  0
          MarkerPDUs Tx:          0
          MarkerResponsePDUs Tx:  0
          UnknownPDUs Rx:         0
          IllegalPDUs Rx:         0

5520-48T-PWR#show lacp port 13,14
                                  Admin Oper         Trunk Partner
Port Priority Lacp    A/I Timeout Key   Key   AggrId Id    Port    Status
---- -------- ------- --- ------- ----- ----- ------ ----- ------- ------
13   32768    Active  A   Short   1     12289 8224   32    1       Active
14   32768    Active  A   Short   1     12289 8224   32    2       Active

5520-48T-PWR#show lacp aggr
Aggr ID Trunk Status   Type   Members
------- ----- -------- ------ -------------------
8224    32    Enabled  LA     13-14

Let’s see what the forwarding table on the Avaya switch looks like;

5520-48T-PWR#show mac-address-table
Mac Address Table Aging Time: 300
Number of addresses: 4

   MAC Address    Vid  Source          MAC Address    Vid  Source
----------------- ---- -------      ----------------- ---- -------
34-75-C7-XX-A4-00    1              54-E0-32-XX-D4-43    1 Trunk:32
54-E0-32-XX-D4-44    1 Trunk:32     34-75-C7-XX-A4-41  100
54-E0-32-XX-D4-41  100 Trunk:32     34-75-C7-XX-A4-42  200
54-E0-32-XX-D4-41  200 Trunk:32

We need to determine what’s “Trunk 32” so we issue the following command;

5520-48T-PWR#show mlt 32
Id Name             Members                Bpdu   Mode           Status  Type
-- ---------------- ---------------------- ------ -------------- ------- ------
32 Trunk #32        13-14                  Single DynLag/Basic   Enabled Trunk

Cheers!

The purpose of this post is to provide some simple examples of how you can start automating today. These are not glamorous solutions hence the poor man slogan but they should help provide some idea of what’s possible. There are plenty of open-source and commercial solutions out there, one that’s been receiving some extra press these past few months is Puppet.

In my current organization we deploy a lot of equipment and we usually do so on a very tight timetable where we have hours, not days or weeks to turn up a closet or a remote site. So our time is extremely precious but more so we can’t afford to be troubleshooting erroneous configuration errors that could easily be avoided with some simple automation. Like numerous organizations before us we too had Microsoft Word Templates and Excel macros and formulas but we almost always ran into problems with the human element of the equation.

I took a small 1Gbps CentOS Linux guest with a LAMP (Linux, Apache, MySQL, PHP) stack and started throwing together some Perl, PHP and JavaScript code. The outcome was a pretty powerful example of what’s possible without a big capital investment or some consulting company reaching their quarterly sales goal on your dime.

Here are three simple examples which are adoptions of each other, adding additional features as time allowed and the solutions matured.

Juniper SRX – VPN Branch Offices

While we were migrating our remote branch offices (31+ locations in all) to Juniper SRX Service Gateways we quickly realized we needed a more reliable solution than building the configuration by hand.  We had a Microsoft Word template that had various fields marked {RED}, the field engineer would perform a search-n-replace to ultimately build the configuration. In our first few conversions we had a number of typos in the configuration that caused use to overrun our scheduled maintenance window. How can we make configuring the Juniper SRX easier for our field engineers? What about a web based portal that takes in the assorted variables and outputs a working configuration?

The solution was really quite easy and has been done by others before. The field engineer plugs in a few values and the Perl/PHP application spits back a complete configuration for both the branch office Juniper SRX 210H and the main office Juniper SRX 650. The initial version of the application required the field engineer to enter a random 128 character shared key, later versions of the application automatically generated a random shared key for use in the configuration. This approach completely eliminated any other configuration issues during the migration project and is now part of our standard process for a new greenfield site.

Avaya Ethernet Routing Switch 4850GTS-PWR+

On the heals of that migration we had a very large expansion project underway at our largest facility. The physical construction called for the installation of about 63+ Avaya Ethernet Routing Switch 4850GTS-PWR+ switches. In order to help streamline the configuration process and help eliminate configuration errors I built an adaption of the earlier application above to fit the requirements for this project. In this project I expanded the functionality of the original application by adding JavaScript code to perform client side data validation. If the field called for an IP address, then the JavaScript code would only submit the data to the server if the field passed validation. It was pretty straight forward and simple but we took the original solution and improved on it.

APC UPS/PDU Management Cards

In that same expansion project we also identified the need to streamline the configuration of the American Power Conversion (APC) UPS’s and PDUs that we were deploying throughout the infrastructure. If you’ve ever worked with them you know they can be somewhat difficult to quickly and easily configure. Our field engineers were spending on average 1 hour to configure each device and often there were inconsistencies in the configuration depending on which field engineer had performed the configuration. So we came up with a new streamlined process which allows the engineer to complete the task in about 15 minutes. The field engineer manually configures a DHCP reservation (manual DHCP) utilizing the MAC address of the management card within our Infoblox IP address management solution. Once the UPS or PDU is online and communicating with the network the field engineer plugs in a number of variables into the web browser and the Perl application will output the configuration. In this case we decided to take this solution one step further by having the Perl application actually program the configuration into the device. The Perl application will generate the configuration and then will make a FTP call to the actual asset and upload the configuration. The only thing left for the field engineer was to perform some simple tests once the task was complete, to verify that the asset was reporting, sending SNMP traps, to our management platform. And even that last step could have probably been easily automated.

My Thoughts

There are a number of frameworks that I could have used in writing these applications but I decided to keep it simple (this time around). The point here is to just provide an example of what’s possible. There are quite a few tools and solutions in the market place that already leverage SNMP, NET-CONF, XML, SOAP APIs, etc to help provide integration between systems as well as management and automation.

Wouldn’t it be great if the last application accepted the MAC address of the APC UPS/PDU and made an automated call to Infoblox and automatically created a DHCP reservation for that asset? Thereby streamlining the process even further? There’s nothing stopping me from doing that other than the time and energy it takes to code the solution and then test it appropriately.

I’m not ready right now to release the actual code but if enough people request I will work to creating sanitized copies and release the code under a GPL license.

Let me know what your doing around automation.

I recall a number of interesting posts a few years back where some folks had completely automated how they inventory and on-board their IP phones. They were using bar code scanners to collect the information from the outside of the box and then had an automated process for taking that information and creating the necessary configuration files for a zero-touch installation, including the actual node and TN information for the Avaya Communication Server 1000. That was a pretty neat example of automation in my opinion and obviously saved them a lot of time and effort.

 Cheers!

This single client supports the following operating systems (in both 32-bit and 64-bit versions);

•     Windows XP
•     Windows Vista
•     Windows 7
•     Windows 8

Resolved Issues

• wi01107642 – SSL Mode Tunnels Do Not Disconnect.

You should refer to the release notes for all the details, including the interoperability issues.

Note: I’m hosting these files from my own servers so please don’t abuse my generosity by hot-linking to them from other sites or by downloading the files dozens of times needlessly.

AVC32-10.06.301.exe (32-bit – Windows XP, Windows Vista, Windows 7, Windows 8)
MD5: d256bdd829119dbb05beaf5fd9378aea
AVC64-10.06.301.exe (64-bit – Windows XP, Windows Vista, Windows 7, Windows 8)
MD5: f7266ea28723decf6d6ead3ba7009134

I’m no longer personally using the Avaya VPN Client. These days I utilize the Juniper Network Connect (and Pulse) client when working remotely. So I’m not really in a position to help everyone with their installation problems. In the past I’ve found that the client will work fine on a fresh OS installation the majority of the time when it wouldn’t work on that same machine prior to the re-imaging.

Cheers!

The application was the original suspect, and since I wrote it years back I was asked to look at the problem. Whenever we add a new model of switch, be it a Cisco Nexus 2248TP or Avaya ERS 4850-GTS-PWR+  there’s usually some tweaking involved to make sure that everything works properly. That’s the price you pay by writing your own software solutions. This time around however it became clear pretty quickly that something else was wrong. Initially I was puzzled since every snmpwalk I performed on the ERS 4850 returned the proper values. It wasn’t until I crafted a command line with multiple SNMP OIDs (just like the script) that I was able to observe the problem.

The problem appears to be related to how the Avaya ERS 4850-GTS-PWR+ handles SNMP queries with multiple SNMP OIDS included in the same request. If I perform a SNMP query for each of the following OIDs in the same request I get the same incorrect ifInOctets value back for each port.

• 1.3.6.1.2.1.2.2.1.1.38 – ifIndex
• 1.3.6.1.2.1.2.2.1.10.38 – ifInOctets
• 1.3.6.1.2.1.2.2.1.3.38 – ifType

Notice how the value is the same for every port, although if I re-query the switch it will provide a different value for every port. In short the incorrect value breaks the application since it appears that every port is changing daily and no ports are ever becoming idle.

root@roo ~]# snmpgetnext -v2c -cpublic sw-icr3-psyc.acme.org ifIndex.1 ifInOctets.1 ifType.1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifInOctets.2 = Counter32: 1106547808
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)

[root@roo ~]# snmpgetnext -v2c -cpublic sw-icr3-psyc.acme.org ifIndex.2 ifInOctets.2 ifType.2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifInOctets.3 = Counter32: 1106547808
IF-MIB::ifType.3 = INTEGER: ethernetCsmacd(6)

[root@roo ~]# snmpgetnext -v2c -cpublic sw-icr3-psyc.acme.org ifIndex.3 ifInOctets.3 ifType.3
IF-MIB::ifIndex.4 = INTEGER: 4
IF-MIB::ifInOctets.4 = Counter32: 1106547808
IF-MIB::ifType.4 = INTEGER: ethernetCsmacd(6)

If I issue a SNMP get next for just the single OID then the switch returns the correct value;

[root@roo ~]# snmpgetnext -v2c -cpublic sw-icr3-psyc.acme.org ifInOctets.1  
IF-MIB::ifInOctets.2 = Counter32: 3903266154

[root@roo ~]# snmpgetnext -v2c -cpublic sw-icr3-psyc.acme.org ifInOctets.2
IF-MIB::ifInOctets.3 = Counter32: 2492668434

[root@roo ~]# snmpgetnext -v2c -cpublic sw-icr3-psyc.acme.org ifInOctets.3
IF-MIB::ifInOctets.4 = Counter32: 792830238

The result is the same whether I use SNMP v1 or SNMP v2c.

The script itself really isn’t concerned with precision, we actually only record the last 6 digits of the counter. If we were concerned about precision we might have to start utilizing ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6) since this is a 10/100/1000Mbps switch port and the counters might wrap between polls.

I’ve only seen the problem on the Avaya ERS 4850-GTS-PWR+ switch running HW:10 FW:5.6.2.1   SW:v5.6.3.024. I have not observed this problem on any other models including the Avaya ERS 5000, 4500, 470 or 460 switches.

Avaya confirmed the presence of the bug today and will be escalating the case to design.

I’m curious if Solarwinds or other management platforms have stumbled upon this bug.

Cheers!

Update: Monday, August 26, 2013

I’ve learned that Avaya will address this bug in software release 5.6.4 which is due out anytime now. ;)

This single client supports the following operating systems (in both 32-bit and 64-bit versions);

•     Windows XP
•     Windows Vista
•     Windows 7
•     Windows 8

Resolved Issues

• wi01066387 Removal and re-installation of the VPN Client did not restore VPN adapter configurations (such as MTU) to system defaults.
• wi01069254 AVC SSL Tunnel mode may randomly fail to retrieve the banner.
• wi01076085 The Avaya VPN Client was previously unable to handle fragmented UDP frames resulting in data loss. This functionality has been added.
• wi01082043 VPN Client Does Not Send UDP Keepalives In NAT Environments.
• wi01086545 Manual Removal Instructions to Repair Broken Windows 8 Installation.
• wi01090553 VPN Client Route Monitoring for SSL Tunnel Mode is inconsistent or not working as expected.
• wi01090556 The VPN Client disconnects a user due to detected route table changes (via route monitoring) if the client machine’s local area connections renew their DHCP lease while a tunnel is active – and the DHCP server returns a default gateway value (normal in most environments).
• wi01105916 Changes introduced by wi01059319 in 10.06.200 may result in the client returning error “General System Problem.” This has been resolved.
• wi01090812 AVC/SSL connection drops while roaming when original metric lower than VPN adapter.

You should refer to the release notes for all the details, including the interoperability issues.

Note: I’m hosting these files from my own servers so please don’t abuse my generosity by hot-linking to them from other sites or by downloading the files dozens of times needlessly. Since May 5, 2013 the Avaya VPN Client downloads have accounted for ~ 36.8 GB of traffic from this site.

AVC32-10.06.300.exe (32-bit – Windows XP, Windows Vista, Windows 7, Windows 8)
MD5: 8e1d5f590022cd92d9d9f0636c063114
AVC64-10.06.300.exe (64-bit – Windows XP, Windows Vista, Windows 7, Windows 8)
MD5: 0eed78b62efad94da8e9c9d6f070cf49

I’m no longer personally using the Avaya VPN Client. These days I utilize the Juniper Network Connect (and Pulse) client when working remotely. So I’m not really in a position to help everyone with their installation problems. In the past I’ve found that the client will work fine on a fresh OS installation the majority of the time when it wouldn’t work on that same machine prior to the re-imaging.

Cheers!

The credit for the workaround goes entirely to @MatzeKS.

Cheers!

I can’t tell you how it irks me to hear people say “it’s the networks fault” when they have absolutely no clue as to how anything works and have no data to support their wild claims. I would think a lot more of them if they just said, “I’m sorry, I haven’t got a frigging clue what’s happening here but can you help me?” And of course the problem always needs to be resolved yesterday as if the building itself was on fire.

We have multiple Avaya Aura Contact Center (formerly Nortel Symposium) installations. At one of these locations we began receiving trouble tickets that the Agent Desktop Display (ADD) which is a small software application that listens to a Multicast stream and displays a ticker tape banner showing the contact center queue details was quietly closing after only a few minutes of running on the local desktop/laptop. The local telecom technician verified that the problem only occurred on a specific floor, the users on the other floors had no issues or problems. A quick check of the core Avaya Ethernet Routing Switch 8600 and edge Avaya Ethernet Routing Switch 5520s indicated that IGMP and PIM were configured and working properly.

Note:A few years back now I detailed how to configure IGMP, DVMRP and PIM for Multicast routing.

I asked the local telecom technician to perform a packet trace so I could see what was happening on the wire. The packet trace indicated that the desktop/laptop was issuing an IGMP leave request and was closing the HTTP/TCP socket it had open to the web server so that was proof enough for me that the application was silently crashing and the operating system was cleaning up all the open ports and IGMP sessions.

6376 2013-05-16 07:47:46.052281 10.1.46.144 10.1.38.55 TCP     54   3317 > 80 [RST, ACK] Seq=4467 Ack=10430 Win=0 Len=0
6377 2013-05-16 07:47:46.052595 10.1.46.144 224.0.0.2  IGMPv2  46   Leave Group 230.0.0.2

The actual Multicast stream from the application/web server was fine;

6353	2013-05-16 07:47:43.995183	10.1.38.55	230.0.0.2	UDP	511	Source port: 1031  Destination port: 7040
6354	2013-05-16 07:47:43.995502	10.1.38.55	230.0.0.2	UDP	502	Source port: 1025  Destination port: 7050
6355	2013-05-16 07:47:43.995885	10.1.38.55	230.0.0.2	UDP	813	Source port: 1026  Destination port: 7030
6356	2013-05-16 07:47:43.996301	10.1.38.55	230.0.0.2	UDP	860	Source port: 1032  Destination port: 7020
6357	2013-05-16 07:47:43.996505	10.1.38.55	230.0.0.2	UDP	343	Source port: 1033  Destination port: 7060
6358	2013-05-16 07:47:43.996726	10.1.38.55	230.0.0.2	UDP	331	Source port: 1027  Destination port: 7070
6359	2013-05-16 07:47:43.996886	10.1.38.55	230.0.0.2	UDP	153	Source port: 1028  Destination port: 7110
6360	2013-05-16 07:47:43.997048	10.1.38.55	230.0.0.2	UDP	153	Source port: 1034  Destination port: 7100
6361	2013-05-16 07:47:43.997199	10.1.38.55	230.0.0.2	UDP	135	Source port: 1030  Destination port: 7090
6362	2013-05-16 07:47:43.997371	10.1.38.55	230.0.0.2	UDP	135	Source port: 1036  Destination port: 7080
6363	2013-05-16 07:47:43.997525	10.1.38.55	230.0.0.2	UDP	127	Source port: 1035  Destination port: 7120
6364	2013-05-16 07:47:43.997647	10.1.38.55	230.0.0.2	UDP	127	Source port: 1029  Destination port: 7130

The packet trace did show some odd UDP broadcast traffic from one specific desktop that happen to be running GE’s Centricity Perinatal (CPN). This is a software application used to monitor Labor & Delivery, the Nursery and the NICU. We use it to actually monitor, chart and graph the strips put out by the fetal monitors. There’s a software component of the GE CPN solution called B-Relay which is the piece of software that floods the VLAN with all those UDP broadcasts. Unfortunately this UDP flooding is by design and is required for the application to function properly.

6205	2013-05-16 07:47:26.710685	10.1.47.210	10.1.47.255	UDP	251	Source port: 1759  Destination port: 7005
6206	2013-05-16 07:47:26.853810	10.1.47.210	10.1.47.255	UDP	822	Source port: 1760  Destination port: 7043
6211	2013-05-16 07:47:28.215486	10.1.47.210	10.1.47.255	UDP	60	Source port: 1783  Destination port: 7013

Looking at the packet traces I quickly noticed that while there are multiple destination ports they are overlapping between 7001 and 7999. I would theorize that the GE CPN software was eventually hitting a UDP port that the ADD software was listening on and since it was a broadcast packet it tried to process the data and was quietly choking and crashing. I shutdown the Ethernet port connecting the GE CPN desktop and had the local telecom technician run his test again. He called back about 30 minutes later to let me know that everything was working fine and that whatever I had done had fixed the problem. Well it wasn’t really fixed because now I had to figure out how to get both applications to co-exist.

The solution was to isolate the GE CPN desktops to their own VLAN so that the UDP broadcasts wouldn’t hit the closet VLAN where the Contact Center users resided. Another possible solution might have been to try and change the UDP ports that either GE CPN or Avaya ADD software was using but that change would have probably taken weeks if not months. I was able to spin up a new VLAN in about 30 minutes and get everyone back up and running again.

Have you got a story to share? I’d love to hear it!

Cheers!

This time around though I quickly found that the sysObjectIDs for the ERS 4800 series switches were missing from SYNTOPICS-ROOT-MIB contained in the most recent software release, v5.6.2.

I received confirmation this morning from Avaya that the SNMP MIBS are missing the proper information and as released don’t include any of the actual sysObjectID OIDs for the Ethernet Routing Switch 4800 switch models.

You can find an updated copy of the SYNOPTICS-ROOT-MIB here. Just replace this file with the SYNOPTICS-ROOT-MIB.mib that is included in the 5.6.2 software release.

You’ll notice that also included are the VSP 7000 and Ethernet Routing Switch 3500 series switches.

This SNMP MIB includes support for the following OIDs;

-- ERS 48xx Series
sreg-ERS-48xx OBJECT IDENTIFIER ::= { registration 78 }
sreg-ERS-4826GTS-PWR-PLUS  OBJECT IDENTIFIER ::= { sreg-ERS-48xx 1 }
sreg-ERS-4850GTS-PWR-PLUS  OBJECT IDENTIFIER ::= { sreg-ERS-48xx 2 }
sreg-ERS-4826GTS           OBJECT IDENTIFIER ::= { sreg-ERS-48xx 3 }
sreg-ERS-4850GTS           OBJECT IDENTIFIER ::= { sreg-ERS-48xx 4 }

-- VSP 7xxx Series
sreg-VSP-7xxx OBJECT IDENTIFIER ::= { registration 79 }
sreg-VSP-7024XLS  OBJECT IDENTIFIER ::= { sreg-VSP-7xxx 1 }

-- ERS 35xx Series
sreg-ERS-35xx OBJECT IDENTIFIER ::= { registration 80 }
sreg-ERS-3526T              OBJECT IDENTIFIER ::= { sreg-ERS-35xx 1 }
sreg-ERS-3526T-PWR-PLUS     OBJECT IDENTIFIER ::= { sreg-ERS-35xx 2 }
sreg-ERS-3524GT             OBJECT IDENTIFIER ::= { sreg-ERS-35xx 3 }
sreg-ERS-3524GT-PWR-PLUS    OBJECT IDENTIFIER ::= { sreg-ERS-35xx 4 }
sreg-ERS-3510GT             OBJECT IDENTIFIER ::= { sreg-ERS-35xx 5 }
sreg-ERS-3510GT-PWR-PLUS    OBJECT IDENTIFIER ::= { sreg-ERS-35xx 6 }

Cheers!

I didn’t attend the recent Avaya Technology Forums in Florida or any other official event recently so the message immediately raised my suspicions such that I left the message alone until this morning. A quick search via the Internet revealed that I wasn’t the only person to receive this curious message. That said I could certainly see more than a few people believing the message to be genuine if they had some interaction with an Avaya employee or partner at the ATF or any other official function or venue which we hear about weekly from this same Twitter account.

I decided to pursue the actual HTTP link and see where it went. The original link was from Bit.ly which is a link shortening service. These services popped up overnight with the success of Twitter and social networking sites like Facebook to help save space and characters. Unfortunately they have a significant security downfall, in that you don’t really know where the link goes until you actually visit it. See the story by David Weiss entitled, “The Security Implications of URL Shortening Services” for a good explanation. The link from Bit.ly relayed me to twpitter.com which was immediately reported as a web forgery on Mozilla’s Firefox. Mozilla’s Firefox 3 and later incorporates built-in Malware and Phishing protection in participation with Google.

The name of the site was itself very suspicious, twpitter.com. Having a quick look at the WHOIS database told me all that I needed to know.

[Querying whois.verisign-grs.com]
[Redirected to grs-whois.hichina.com]
[Querying grs-whois.hichina.com]
[grs-whois.hichina.com]
Domain Name ..................... twpitter.com
Name Server ..................... dns9.hichina.com
dns10.hichina.com
Registrant ID ................... hc292727277-cn
Registrant Name ................. yong yi
Registrant Organization ......... yi yong
Registrant Address .............. Shang Hai City
Registrant City ................. Shang Hai
Registrant Province/State ....... Shang Hai
Registrant Postal Code .......... 200000
Registrant Country Code ......... CN
Registrant Email ................ liwei553@hotmail.com
Administrative ID ............... hc292727277-cn
Administrative Name ............. yong yi
Administrative Organization ..... yi yong
Administrative Address .......... Shang Hai City
Administrative City ............. Shang Hai
Administrative Province/State ... Shang Hai
Administrative Postal Code ...... 200000
Administrative Country Code ..... CN
Administrative Email ............ liwei553@hotmail.com
Billing ID ...................... hc292727277-cn
Billing Name .................... yong yi
Billing Organization ............ yi yong
Billing Address ................. Shang Hai City
Billing City .................... Shang Hai
Billing Province/State .......... Shang Hai
Billing Postal Code ............. 200000
Billing Country Code ............ CN
Billing Email ................... liwei553@hotmail.com
Technical ID .................... hc292727277-cn
Technical Name .................. yong yi
Technical Organization .......... yi yong
Technical Address ............... Shang Hai City
Technical City .................. Shang Hai
Technical Province/State ........ Shang Hai
Technical Postal Code ........... 200000
Technical Country Code .......... CN
Technical Email ................. liwei553@hotmail.com
Expiration Date ................. 2014-03-09 01:42:03

Looks like the miscreants are up to their old tricks, although you can’t really trust WHOIS either.

Later in the afternoon I received a follow-up  tweet from an Avaya employee;

This is the new attack vector of the miscreants, utilizing trusted sources for spreading their wares. This includes trusted websites along with email and twitter contacts. I was disappointed that I didn’t receive any follow-up from either Avaya or Avaya Innovations. Normally I wouldn’t bother writing a post up about such a trivial matter but I got the impression that Avaya or whoever is managing the Avaya Innovations account was just going to ignore it entirely and pretend that it never happened. Well it did happen and you put our followers at risk! Avaya should at a minimum inform all those users of the issue and provide advice if they happened to visit the link before it was blocked. I took the action of reporting the link to Bit.ly via email.

Cheers!

I was extended an invite to attend the ATF 2013 but unfortunately due to some health issues I was unable to make the trip.

If you were unable to attend the Avaya Technology Forum 2013 last month you can view the presentation material over on the Network Infrastructure Forums.

Here’s a suggestion to Avaya… have the presentations video recorded for later playback. You could even live stream a few of the keynotes and feature discussions.

Thanks to Matthias and sharing the files and Avaya for allowing us to host the presentations.

You can see the list of presentations over on the Network Infrastructure Forums.

Cheers!

Here’s the configuration template that I’m currently using today for the Avaya Ethernet Routing Switch 5500, 4800 and 4500 series switches. This is essentially a best practices configuration for a typical closet/edge switch (Layer 2) with ADAC/LLDP-MED for completely automated, zero-touch IP telephony deployments.

With the firmware that currently ships with the Avaya 1100 and 1200 series IP phones you only need to unbox the phone and connect it to the network. You’ll also need to make sure that you have your provisioning files setup properly but you can easily attain a zero-touch configuration for greenfield deployments.

Please note there are a some options in this post which are only available in the later software releases for each switch model. These commands were tested on an Avaya Ethernet Routing Switch 4850GT-PWR+ running 5.6.2 software.

We need to be in privileged mode before we can enter configuration mode;

enable
configure terminal

Let’s start by setting the read-only and read-write passwords (the default usernames are RO=read-only and RW=read-write)

cli password read-only ropassword
cli password read-write rwpassword
cli password serial local
cli password telnet local

If you don’t care to see the banner when connecting via telnet then disable it;

banner disable

If you are working with an Avaya Ethernet Routing Switch 5000 series switch let’s disable the UI button on the outside of the switch. This feature is only available on the ERS 5000 series switches so this command won’t work with the ERS 4000 series switches.

no ui-button enable

Let’s set VLAN control to autopvid, this will instruct the switch to change the PVID to the VLAN assigned to the port for access (UntagAll) ports.

vlan configcontrol autopvid

If we have 2 or more switches in a stack configuration we’ll utilizing ports on both switches for our uplinks, 1/48 and 2/48. If we only had a single switch and not a stack of switches we would use 47 and 48. We need to enable 802.1Q trunking (TagAll) and filter (drop) and untagged frames that might accidentally be sent across the port.

vlan ports 1/48,2/48 tagging enable
vlan ports 1/48,2/48 filter-untagged-frame enable

As a best practice you should never use VLAN 1, too many reasons to list here. By default ever port is a member of VLAN 1 so let’s remove VLAN 1 from all ports;

vlan members remove 1 ALL

Let’s create a management VLAN and add that VLAN to our 802.1Q uplinks;

vlan create 200 name "10-107-255-0/24" type port
vlan members add 200 1/48,2/48

Let’s create a (default) closet VLAN and add that VLAN to all the ports in the stack;

vlan create 10 name "ICR1_1stFloor" type port 
vlan members add 10 1/ALL,2/ALL

Let’s create a voice VLAN which we’ll using in our ADAC and LLDP-MED configurations and we’ll add that VLAN to our uplinks;

vlan create 11 name "Voice" type port voice-vlan
vlan members add 11 1/48,2/48

This single client supports the following operating systems (in both 32-bit and 64-bit versions);

• Windows XP
• Windows Vista
• Windows 7
• Windows 8

Resolved Issues

• wi01041435 – Traffic to overlapping network of Split net and Local net got blocked.
• wi01031645 – AVC SwapAdapter feature does not reprioritize the VPN Adapter binding order for SSL tunnel types.
• wi01011920 – AVC may Orphan NetBT NameList registry entries if ungracefully terminated.
• wi01047768 – NVR interoperability – banner issues with specific IP address pool for Windows 7 users
• wi01043584 – Installing AVC over same version in silent mode causes error
• wi01058523 – AVC 10.06.104 IPSec Tunnels might drop during server initiated rekey
• wi01049421 – Unsigned EAC Miniport Driver Blocked by Windows XP OS. A new binder.exe utility has been included in the installation directory (default: %ProgramFiles%\Avaya\Avaya VPN Client) on Windows XP systems to assist with remediating this issue.
• wi01056647 – AVC may crash when connecting through an unstable wireless access point
• wi01059319 – Sometimes WINS Servers may not take effect in Windows XP
• wi01068400 – Dial-up not working properly on 32 bit platforms
• wi01028196 – AVC fails to properly identify Windows XP x64 operating system which may result in improper client operation
• wi00951988 – Unsupported Installation Change is not disabled properly.

Activation of VPN Adapter Failed

wi00928966 – Users who upgrade from a v10.05 or earlier release to v10.06 on Windows XP may receive the following error dialogue when attempting to establish an IPSec VPN tunnel – “Activation of VPN Adapter Failed”. This issue occurs when the AVC filter driver is not upgraded correctly during software installation.
As a precautionary measure, rebooting the machine before an upgrade installation is highly recommended. If the problem does occur, the workaround would be to uninstall and then reinstall the client. Please note, uninstall will remove all profiles and configurations. If users want to carry them over to the following reinstallation, they can use the Import/Export feature to export them before uninstall and import them back after reinstallation. For more details about the Import/Export feature please see Section 7 of this document.)

You should refer to the release notes for all the details, including the interoperability issues.

AVC32-10.06.200.exe (32-bit Windows XP, Windows Vista, Windows 7, Windows 8)
MD5: 006e21051924d92634b62600c071418b
AVC64-10.06.200.exe (64-bit Windows XP, Windows Vista, Windows 7, Windows 8)
MD5: 34c860667260ce196139521196fca946

Cheers!

Let me start with some definitions and then we’ll move on from there;

• MLT (MultiLink Trunk) a proprietary bonding protocol to bond two or more physical links into a single virtual link between two switches.
• DMLT (Distributed MultiLink Trunk) a proprietary bonding protocol to bond two or more physical links into a single virtual link across multiple cards or switches (in a stack configuration) between two switches.
• SMLT (Split MultiLink Trunk) a proprietary bonding protocol to bond two or more physical links into a single virtual link between two core cluster switches and a single edge/distribution switch.
• SLT (Single Port Split MultiLink Trunk – formerly S-SMLT for Single Split MultiLink Trunk) a proprietary bonding protocol to bond two physical links into a single virtual link between two core switches and a single edge/distribution switch. This is just an SMLT with only two ports maximum – one from each core/distribution switch.
• IST (InterSwitch Trunk) a proprietary bonding protocol between two core cluster switches that allows them to deploy SMLT or SLT topologies to edge/distribution switches. This is just an MLT which is used to bridge the VLANs between the two cluster switches. The IST also provides a transport for the two cluster switches to exchange ARP and FDB/MAC table information.

You can use MLT or DMLT between two switches in what I would refer to as a traditional trunking application. A Distributed MultiLink Trunk provides additional redundancy by spreading the links out across multiple line cards or switches in a stack depending on the switch model/configuration. An MLT/DMLT is Avaya’s proprietary equivalent to Cisco’s EtherChannel or PortChannel feature. An Avaya MLT or DMLT configuration can interoperate with Cisco’s EtherChannel or PortChannel configuration.

It’s important to point out that Avaya switches will (by default) only send out BPDU frames on the lowest number if index of a MLT or DMLT trunk. This can be overridden in newer software releases with the command “mlt 1 bpdu all-ports“. Cisco switches will send out BPDU frames on all ports in an EtherChannel or PortChannel configuration.

You can use SMLT or SLT between two cluster switches and a single edge/distribution switch or stack essentially creating a triangle topology without the need for Spanning Tree. Both links between the core and edge/distribution are actively forwarding traffic.  An SMLT/SLT is Avaya’s proprietary equivalent to Cisco’s Virtual PortChannel feature. When do you use one over the other, SMLT or SLT? The later software releases only allowed between 32 and 64 MLTs per switch. If you had more than 31 edge switches you would run out of available MLTs, so Avaya came up with SLT – you can have as many SLTs as you have ports in the switch. SMLT will allow you to bond between 2 and 8 ports into a single virtual trunk on each cluster switch while SLT is designed to allow two ports max (one per cluster switch).

It’s important to note that you can utilize LACP with MLT, DMLT or SMLT ports just a you can with PortChannel groups.

The majority of closets I deploy utilizing SLT in the cluster core although there are a few closets that require more than 2 x 1Gbps uplinks so for those we utilize a SMLT configuration allowing up to 16 x 1Gbps links between the core cluster switches and edge/distribution switches.

Spanning Tree Protocol and IST/SMLT

Avaya has not extended the functionality of the Spanning Tree Protocol to run over an IST/SMLT topology. You can’t run STP between your core cluster switches and your edge switch/stack. That doesn’t mean that we can abandon STP altogether. It’s critical that Spanning Tree be utilized on all the edge ports in FastStart (PortFast) mode to eliminate the possibility of anyone accidentally creating a loop between any two ports in the edge switch. I also recommend that BPDU filtering be enabled on all edge ports along with Broadcast and Multicast rate-limiting.

Virtual Link Aggregation Control Protocol (VLACP)

In an Avaya network there is a special secret sauce that helps to bring everything together providing timely failure detection and recovery in an MLT, DMLT, IST, SMLT and SLT topology. VLACP is a lightweight heartbeat protocol utilized between two Avaya switches to detect Layer 2 connectivity issues between two endpoints. The trick these days isn’t detecting a failure but knowing when to restore a failed path taking into account the time it takes to rebuild routing and forward tables. VLACP is an Avaya proprietary protocol so it will only work between two Avaya switches.

If you’d like to know more about VLACP or how to configure it you can read my article entitled, Is VLACP right for me?

Cheers!

References: Switch Clustering using Split Multi-Link Trunking (SMLT) with VSP 9000, ERS 8600/8800, 8300, and 5000 Technical Configuration Guide

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

The following issues have been addressed in this software release;

• VRRP transitions are observed when the port state of SLT/SMLT links changes [ wi00965416 / wi01021008 ]
• CPU MGMT Port locks up occasionally and requires reboot while under high traffic loads [ wi00996256 / wi01021014]
• Retina Scan causes FTP sessions to hang in CLOSE_WAIT state [wi01010232 / wi01020995 ]
• TCP/IP Instability during and after a DOS like network scan [wi00999478 / wi01020994 ]
• Egress queue draining improvements for 8683XLR [ wi01030286 / wi01030289 ]
• “configure add bgp network” causes software license violation to be seen [wi01014784]
• ACLI: Access-policy-SNMPv3 configuration disappears after re-boot [wi01018223]
• Inconsistent ACL/ACE behaviour is observed on 8648GTRS module [wi01014728]
• ACLI: Set a port to forced speed & duplex, enable the verify-config boot flag, save the config and reboot the box. After the reboot, error occurs at the time of loading config.cfg and all the cards are taken offline [wi01020972]
• show fulltech can be disallowed if SSH session is stranded during execution [wi01020662]
• 8692 with rev54 OOB Management port shows up as up/active with nothing connected [ wi00908274 / wi00976833 ]
• A buffer memory leak accompanied by ‘rcIpBootPReply failed to send broadcast DHCP response. No circuit for src IP 0.0.0.0, VLAN 0, IFINDEX 641’ is seen [ wi00999447 / wi01023659 ]
• Connectivity issues occur when OSPF External Routes are learnt [wi01002839 / wi01013382]
• Non ICMP routed traffic is discarded if destination is actually on ingress VLAN [wi00973648 / wi00990346 ]
• Incorrect XFP type shown sometimes in logs when XFP was unplugged / plugged [ wi00995034 ]
• RSMLT IP/MAC addresses are not always correctly spoofed. [ wi00936870 / wi00990309 ]
• MSDP INFO messages filling up the logs. [ wi00928703 / wi00990311 ]
• V5 to V7x Upgrade: V5 ACLI route-map definitions cause partial config loss after upgrade. [wi00985414 / wi00991133]
• ERS 8600 5.1.7.0: Arp entries not getting aged out but keep getting refreshed. [ wi00989668 / wi01013379 ]. As part of this fix, also added support for Port/ VLAN->IP>ARP->ForcedRearp [ wi01030298 ]
• ACLI: IP Static Multicast ARP entries defined on an MLT are lost after a reboot [ wi01023009 ]
• IPVPN-Lite: BGP Redistribution Propagates Default Route with incorrect next-hop Address [ wi01024321 ]
• Missing “show spanning-tree config” support on ERS platform [ wi01004049 ]
• Error messages are seen with AA1419049-E6 on 8634 [ wi00908211 / wi00991546 ]
• Request to hide unknown community string names from syslog [ wi01029822 ]
• Syslog message are sent using LAST created CLIP Interface IP address instead of the first configured CLIP address [ wi01026441 ]
• Constant GBIC inserted message scrolling on 8630 with “49” part. [ wi01001887 / wi01030252 ]
• ERS8800 Radius CLI Profile is not working with SSH but its working fine via Telnet [ wi00945536 / wi01030176 ]
• L3VSN connectivity issue at customer site after migrating OSPF to SPBM [wi01018732 / wi01033808 ]
• ERS8800 with CP card 8895SF registered 3 consecutive core dump. Device running on s/w 7.1.3.0. SOP init problem [ wi01011887 ]
• 8648 line card gets rebooted when AA1419043 inserted [ wi01014221 / wi01035891 ]
• Need to have the MLT-id included in the “show LACP interface MLT” command [ wi01032546 ]
• ERS 8600: 5.1.4: 8683 XLR ingress Lane lockup [ wi01000004 ]
• ERS 8600: 5.1.x/7.1..x; High CPU/High buffer utilization caused by Dual AC-input Power Supply [wi01002565 ]
• 8600:v7.1.3 or higher: ACL problem: NextHopReachableRedirect – Redirection works ok for the case when the redirection dest is reachable but when the redirection dest is not reachable the filter does not stop redirecting [wi01013834 ]
• A core may result when running the command “show isis spbm multicast-fib” when using the filter i-sid or nick-name [ wi1033200 ]
• CFM : LBM packet with Spbm Ethertype 88a8 as well as 8100 being generated if the default “spbm ethertype” is changed to 88a8 [ wi01035918 ]
• ERS8600 7.1.3.x: Links may not come up between 8648GBRS with Copper pluggables to 8648GTRS [ wi01027175 / wi01029009 ]
• ERS8600: 1GB SX pluggables in 8630GBR may not report proper type and Vendor [ wi01027179 / wi01029009 ]
• RSMLT holdup timer not counting in edge support scenario and peer mac is made local permanently [ wi01028907 ]
• 8895 could reset when LACP is globally disabled on adjacent node [ wi01026059 ]
• Enhancement request to reset SF when FAB Memory Full detected [ wi01004464 ]
• Egress queue draining for R modules [ wi01011220 ]
• R module code could accidentally drop into the RS module mirroring code [ wi01011222 ]
• The R modules do not treat PAUSE frames in their default configuration but rather pass them on to the CPU with QoS 7 [ wi01011225 ]
• Routes rejected after deleting/re-adding BGP in VRF route-policy. [ wi00564356 / wi00990365 ]
• ERS8600 / acli mode / “show ip ipfix flows” parameters do not work in ACLI mode [ wi00891540 / wi00938144 ]

I took note of the reference to a possible data loss condition to a LANE if a single port within that LANE changes speed/duplex;

When we are running multiple ports configured in the same lane, we see momentary traffic loss on other ports in the lane, when the operating speed/duplex changes on one of the ports. If the operating speed/duplex remains same as before, there is no traffic loss. For example, if we pull a SFP and plug it back in, and the speed/duplex remains same as before, we will not see traffic loss. The reason for this is that every time a port speed changes, we need to re-configure lane specific shapers. This is the case if we are re-configuring Egress Queue Sets and configuring port shapers also.

Please refer to the release notes for all the details.

Ethernet Routing Switch 8600 Software Release v5.1.8.3

Avaya has released software v5.1.8.3 for the Ethernet Routing Switch 8600/8800.

The following issues have been addressed in this software release;

• VRRP transitions are observed when the port state of SLT/SMLT links changes [ wi00965416 / wi01021010 ]
• CPU MGMT Port locks up occasionally and requires reboot while under high traffic loads [ wi00996256 / wi01012500 ]
• Retina Scan causes FTP sessions to hang in CLOSE_WAIT state [wi01010232 / wi01013377 ]
• TCP/IP Instability during and after a DOS like network scan [wi00999478 / wi01008869 ]
• ERS 8600/8800: OSPF getting stuck in INIT state after CPU-switchover in HA-mode for Legacy 1G modules [ wi01034553 ]
• ERS 8600-5.1.8.1: Fiber ports on the Legacy cards do not come UP after a CPU-switchover in HA-mode [ wi01038139 ]
• Egress queue draining improvements for 8683XLR [ wi01030289 ]
• ssh logging is improved to more clearly indicate the session login and logout info [wi01021847 ]

Please refer to the release notes for all the details.

Cheers!

This single client supports the following operating systems (in both 32-bit and 64-bit versions);

• Windows XP
• Windows Vista
• Windows 7

Resolved Issues

• wi01009468 BSOD (Blue Screen of Death) may occur on Windows 7 multi-core machines if Symantec Endpoint Protection v11.x is installed.
• wi01002823 AVC 10.04.108+ Incompatibility with AT&T 4G USB Modem
• wi01011943 AVC “Display Warning” or “Disconnect” Limitation. Previously the VPN client would be abruptly terminated if a user attempted to shut down or restart the host machine. Now the tunnel is gracefully disconnected prior to shut down or restart.
• wi01032791 Disconnect the VPN tunnel when AVC service is closed/stopped

Open Issues

• wi01011920 AVC may Orphan NetBT NameList registry entries if ungracefully terminated. The workaround is to clear the NetBT NameList or gracefully terminate the VPN Client before rebooting or restarting the host PC.
• wi01031645 AVC SwapAdapter feature does not reprioritize the VPN Adapter binding order for SSL tunnel types.

Interoperability

• McAfee ViruScan v8.8
• Microsoft Internet Explorer v8
• Microsoft Windows 7 IPv6 6to5 Adapter Duplicates
• Avaya NetDirect Client
• DNS Binding Priority with Windows Operating Systems

You should refer to the release notes for all the details, including the interoperability issues.

AVC32-10.06.104.exe (32-bit Windows XP, Windows Vista, Windows 7)
AVC64-10.06.104.exe (64-bit Windows XP, Windows Vista, Windows 7)

Cheers!

I tested the process Friday and it worked as advertised. Here’s how I set everything up… please bare in mind there are many many ways to set this up so the following example is just how I decided to set everything up.

Avaya Ethernet Routing Switch 5520s

I configured the edge/closet Avaya Ethernet Routing Switch 5520s running software release 6.2.4 exactly as I’ve previously documented in this blog post. We’ll be using ADAC/LLDP-MED to assign the IP Phones a voice VLAN and to set the proper QoS tags.

DHCP – Infoblox

With that done I turned my efforts toward DHCP. I created a DHCP range in the voice VLAN with two special settings. I created a filter on the IP range to check for the DHCP vendor option “Nortel-i2004-A”. This will help make sure that only IP phones are provided an IP address from this DHCP range. Next I added DHCP option 244 with the following value,

Nortel-i2004-B,prov=http://10.1.20.1/avaya/sitea;

That’s all I did for the DHCP component, the magic comes in the next step.

HTTP/TFTP Server

In my example I used a CentOS Linux server at 10.1.20.1 which had Apache running with a directory structure of /var/www/html/avaya/sitea. In that folder I had the following files; system.prv and sitea.prv (this file was actually blank). You can deploy the provisioning files via HTTP or TFTP. You can utilize Microsoft’s IIS or whichever web server you’re more comfortable with. Please refer to the references listed at the end of this document for additional steps to get IIS to recognize the .prv files

Here’s what I put in the system.prv file;

file=zdt;
zone=sitea;
s1ip=10.1.2.40;
p1=4100;
a1=1;
r1=10;
s2ip=10.1.2.40;
p2=4100;
a2=1;
r2=10;
vq=y;
vcp=3;
vmp=4;
vlanf=y;
pc=y;
pcs=a;
pcd=a;
dq=n;
lldp=y;
stickiness=y;
cachedip=n;
igarp=n;

I chose to configure the Avaya IP Phones around a geographic basis. Within each location all the IP phones are configured identically but the settings can vary from location to location depending on the model and on the actual CS1000E for that site. I chose to break them down using different directories and then set DHCP option 244 to the appropriate directory for that site. In one voice VLAN the DHCP server might return “Nortel-i2004-B,prov=http://10.1.20.1/avaya/sitea;” but in another voice VLAN the server might return “Nortel-i2004-B,prov=http://10.1.20.1/avaya/siteb;” Utilizing the different directories allows me an easy way to control the different settings per geographic location. It also makes troubleshooting much easier and straightforward.

Testing

With everything setup I preceded to test my configuration. I unboxed a new Avaya 1120e IP phone and connected it to Avaya Ethernet Routing Switch 5520. The IP phone powered up and appeared to pull a DHCP address from the voice VLAN – I believe the factory configuration now has LLDP-MED enabled by default, that’s the only way the Avaya IP phone would have gotten a DHCP address from the voice VLAN. I purposely didn’t create any DHCP ranges in the data VLAN just to see how the Avaya IP phone would react. With an IP address the IP phone read the DHCP option 224 and proceed to download system.prv, sitea.prv and 00AABBCCDDEE.prv (the MAC address of the actual IP phone). After reading the provisioning files the IP phone rebooted itself and eventually came back up to a NODE and TN prompt which was expected. Once the technician entered the NODE and TN the IP phone upgraded itself to the version of software that we had loaded on the CS1000E. It rebooted again and came right up without any additional intervention.

You can eliminate technician needing to enter the NODE and TN information by creating REG entries with the MAC address of the IP phone and the NODE and TN information in the provisioning files – you can find additional information regarding the REG entries in the references below. Since this is a greenfield installation I thought it would be more work to actual document the MAC address of each IP phone than it would be if the technicians just went cube to cube configuring the proper NODE and TN information for each user.

Cheers!

References;

Avaya IP Phone Fundamentals for Communication Server 1000
Avaya IP Telephony Deployment Technical Configuration Guide

• Windows XP
• Windows Vista
• Windows 7

Resolved Issues

• wi01003255 – Split Tunnel Failure on Windows 7
• wi00860526,wi00972868 – Mobility for IPSEC doesn’t work properly on Windows 7 and XP.
• wi00947857 – IPsec split tunneling mode enabled_inverse_local does not enforce its restrictions on sessions already established before the tunnel was created.
• wi00956803 – Cached VPN adapter drivers not cleaned up on Windows 7
• wi00995550 – Disconnecting a tunnel may cause service crash
• wi00981906 – Fetching banner from different AVG when DNS Round Robin used
• wi01006672 AVC may Orphan DNS Suffix Entries if ungracefully terminated.

New Outstanding issues

• wi01011920 – AVC may Orphan NetBT NameList registry entries if ungracefully terminated. The workaround is to clear the NetBT NameList or gracefully terminate the VPN Client before rebooting or restarting the host PC.

New Known Issues

• wi00928966 – Users who upgrade from a v10.05 or earlier release to v10.06 on Windows XP may receive the following error dialogue when attempting to establish an IPSec VPN tunnel – “Activation of VPN Adapter Failed”. This issue occurs when the AVC filter driver is not upgraded correctly during software installation. As a precautionary measure, rebooting the machine before an upgrade installation is highly recommended. If the problem does occur, the workaround would be to uninstall and then reinstall the client. Please note, uninstall will remove all profiles and configurations. If users want to carry them over to the following reinstallation, they can use the Import/Export feature to export them before uninstall and import them back after reinstallation. For more details about the Import/Export feature please see Section 7 of this document.)
• wi00951988 – Component modification after installation is not supported.
• wi00932075 – Canceling uninstall in the middle may cause faulty rollback.

You should refer to the release notes for all the details.

I will continue to host the client files on my website.

AVC32-10.06.022.exe (32-bit Windows XP, Windows Vista, Windows 7)
AVC64-10.06.022.exe (64-bit Windows XP, Windows Vista, Windows 7)

Cheers!

Ethernet Routing Switch 8600 Software Release v7.1.3.3

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

There have been a flurry of software releases recently from Avaya in both the 5.x and 7.x code branches. The following notation in the 7.1.3.3 release notes gives me pause;

When we are running multiple ports configured in the same lane, we see momentary traffic loss on other ports in the lane, when the operating speed/duplex changes on one of the ports. If the operating speed/duplex remains same as before, there is no traffic loss. For example, if we pull a SFP and plug it back in, and the speed/duplex remains same as before, we will not see traffic loss. The reason for this is that every time a port speed changes, we need to re-configure lane specific shapers. This is the case if we are re-configuring Egress Queue Sets and configuring port shapers also.

Please refer to the release notes for all the details.

Ethernet Routing Switch 8600 Software Release v5.1.8.1

Avaya has released software v5.1.8.1 for the Ethernet Routing Switch 8600/8800.

There are a number of different bug fixes and there’s a reference to a potential issue when using the out-of-band network (management) port on the CPU/SF itself.

The out-of-band (OOB) management port of an ERS8600 switch does not have STP, SLPP or other loop prevention mechanism integrated as a line card port does. In the event of line rate broadcast traffic coming into the OOB management port due to a network loop that involves the OOB management port, users may see high CPU utilization that affects switch‟s functionality.

I don’t personally use the out-of-band network ports on the CPU/SF. Although I do cable all the serial/console ports on the CPU/SF to an MRV terminal server which I can either dial into remotely or connect to over the network via SSH/telnet.

I’m curious how many people are using the OOB Ethernet network port on the CPU/SF itself?

Please refer to the release notes for all the details.

Ethernet Routing Switch 4000 Software Release v5.6.1

Avaya has released software v5.6.1 for the Ethernet Routing Switch 4000 Series.

There are a number of new features along with quite a few bug fixes. In particular this problem was reported in the discussion forums by one or our members;

• (wi00961451, wi00964606, wi00998809, wi00958930) MAC Security, Access Violation Trap: When MAC Security Access Violation traps are enabled on the port, the trap is now correctly generated as a result of a MAC security violation and it now displays the correct port index (s5SbsViolationPortIndx) is contained in the message.

Please refer to the release notes for all the details.

You’ll find more details from @Telair over on the discussion forums.

Ethernet Routing Switch 2500 Software Release v4.4.1

Avaya has released software v4.4.1 for the Ethernet Routing Switch 2500 Series.

Please refer to the release notes for all the details.

Cheers!

Ethernet Routing Switch 8600 Software Release v7.1.3.2

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

• Every 5 seconds, on a timer, the CPU sends the clock time to all the line cards. A timer was created each time a card came online, so when there are multiple IO cards, multiple messages were sent every 5 seconds to all cards. Eventually a lockup resulted, and when it was detected by the CPU, the chassis was reset. (wi00996291)

Please refer to the release notes for all the details.

Motorola RFS7000 WiNG v5.2.21 Software Release

You may also want to review software release 5.2.3 and 5.2.4 before deciding to check out software release 5.2.21 which was intended to resolve several MESH issues with the AP7131.

RFS Controllers with WiNG v5.2.21 can adopt and provision the following 802.11n and legacy Access Points:

Dependent Access Points:

• AP621
• AP650
• Legacy: AP300

Adaptive/ Independent Access Points:

• AP6511
• AP6521
• AP6532
• AP7131 (Including the D-mode SKUs)
• AP7161

You should check over the release notes for all the details.

Cheers!

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

• L3VSN default route was not correctly installed in the RTM when it was received via ISIS. As a result L3VSN traffic that needs to use the default route was being dropped. This problem is specific to L3VSN only. It did not affect GRT default routes via ISIS. (wi00996566)

Please refer to the release notes for all the details.

Avaya IP Softphone 2050 Release 4.3

Avaya has released the IP Softphone 2050 Release 4.3.081 for Microsoft Windows.

There is specific mention of support for 64bit versions of Microsoft Windows 7 and Microsoft Windows Vista;

Important Note : It is strongly recommended to install the next updates for Microsoft Windows 7 to the PC
including the specific updates noted below. Failure to install these Windows 7 updates may cause the
2050 IP Softphone to crash or not work as intended.
KB981679 (part of Service Pack 1 for Windows 7)
KB979303

The following issues are resolved;

• wi00715416 External – Improved robustness of Licensing Server in releasing licenses, if IP Connection drops
• wi00903652 External – Issue with node-locked licensing not working with CS1000 R7.5 and 2050 R4.2
  wi00906095
• wi00867565 External – Error message when starting IP Softphone on Windows 7
• wi00908928 External – Graphics issue on Windows 7
• wi00896132 External – Dual stream recording does not work properly with 2050 after a call is transferred to the 2050
• wi00951184 External – 2050 reverts to PC speaker and soundcard instead of USB device when PC is restarted
• wi00889263 External – SR 1-1462175541: IP Softphone trace route shows only final destination, not intermediate hops.

Please refer to the release notes for all the details.

Cheers!