ERS5632FD VLACP

[Dominik]

Hi

I have in 2 location the same issue with VLACP and connections betwen ERS5632FD and ERS4500.
There are connected in a classic triangle Switch Cluster design.

I use the SW 6.1.6 on the ERS5632FD and SW 5.3.2 on the ERS4500.

I get random VLACP down / up massages in the Log:

Location1:
I    2011-06-22 09:50:20 GMT+00:00 122      Trap:  Smlt Link Down, smlt:3
I    2011-06-22 09:50:33 GMT+00:00 123      Trap:  Smlt Link Up, smlt:3
I    2011-06-22 09:50:33 GMT+00:00 124      Port 0/2 reenabled by VLACP
I    2011-06-22 11:16:49 GMT+00:00 129      Port 0/2 blocked by VLACP until end-partner connection reestablished
I    2011-06-22 11:16:50 GMT+00:00 130      Trap:  Smlt Link Down, smlt:3
I    2011-06-22 11:17:03 GMT+00:00 131      Trap:  Smlt Link Up, smlt:3
I    2011-06-22 11:17:03 GMT+00:00 132      Port 0/2 reenabled by VLACP


Location2:
I    2011-06-20 17:37:39 GMT+01:00 2        Port 0/9 blocked by VLACP until end-partner connection reestablished
I    2011-06-20 17:37:39 GMT+01:00 3        Trap:  Smlt Link Down, smlt:6
I    2011-06-20 17:37:39 GMT+01:00 4        Port 0/12 blocked by VLACP until end-partner connection reestablished
I    2011-06-20 17:37:39 GMT+01:00 5        Port 0/15 blocked by VLACP until end-partner connection reestablished
I    2011-06-20 17:37:39 GMT+01:00 6        Trap:  Smlt Link Down, smlt:9
I    2011-06-20 17:37:39 GMT+01:00 7        Trap:  Smlt Link Down, smlt:12
I    2011-06-20 17:37:52 GMT+01:00 8        Port 0/12 reenabled by VLACP
I    2011-06-20 17:37:53 GMT+01:00 9        Trap:  Smlt Link Up, smlt:6
I    2011-06-20 17:37:53 GMT+01:00 10       Port 0/9 reenabled by VLACP
I    2011-06-20 17:37:53 GMT+01:00 11       Trap:  Smlt Link Up, smlt:12
I    2011-06-20 17:37:53 GMT+01:00 12       Port 0/15 reenabled by VLACP
I    2011-06-20 17:42:39 GMT+01:00 13       Port 0/12 blocked by VLACP until end-partner connection reestablished
I    2011-06-20 17:42:39 GMT+01:00 14       Port 0/15 blocked by VLACP until end-partner connection reestablished
I    2011-06-20 17:42:39 GMT+01:00 15       Trap:  Smlt Link Down, smlt:9
I    2011-06-20 17:42:39 GMT+01:00 16       Trap:  Smlt Link Down, smlt:12
I    2011-06-20 17:42:39 GMT+01:00 17       Port 0/9 blocked by VLACP until end-partner connection reestablished
I    2011-06-20 17:42:40 GMT+01:00 18       Trap:  Smlt Link Down, smlt:6
I    2011-06-20 17:42:52 GMT+01:00 19       Port 0/12 reenabled by VLACP
I    2011-06-20 17:42:53 GMT+01:00 20       Trap:  Smlt Link Up, smlt:6
I    2011-06-20 17:42:53 GMT+01:00 21       Port 0/9 reenabled by VLACP
I    2011-06-20 17:42:53 GMT+01:00 22       Port 0/15 reenabled by VLACP
I    2011-06-20 17:42:53 GMT+01:00 23       Trap:  Smlt Link Up, smlt:12

Both locations worked approximatly for one week without any issues.

Besides the VLACP log messages there are also some scary output on the SMLT Info:
1/1   2   smlt
1/2   3   smlt
1/3   4   smlt
1/6   2   11
1/20   9   8002

1/1   2   smlt
1/2   3   smlt
1/3   4   smlt
1/14   4   7999

Here is the config:
*** VLACP ***
vlacp enable
vlacp macaddress 180.c200.f
vlacp hold_time 0
interface FastEthernet ALL
vlacp port 1-3 timeout short
vlacp port 1-3 timeout-scale 5
vlacp port 1-12 slow-periodic-time 30000
vlacp port 13-15 slow-periodic-time 10000
vlacp port 1-32 ethertype 0x8103
vlacp port 1-32 funcmac-addr 0.0.0
vlacp port 1-32 fast-periodic-time 500
vlacp port 16-32 slow-periodic-time 30000
vlacp port 4-32 timeout long
vlacp port 4-32 timeout-scale 3
vlacp port 1-3,13-15 enable
no vlacp port 4-12,16-32 enable


The mystirous SMLT 1/20 and 1/14 where not configured by me.
When I delete them they come back automaticly and are also show in the running config:

! *** SMLT ***
!
interface mlt 1
ist peer-ip 172.16.1.1
ist vlan 3999
ist enable
exit
interface FastEthernet all
smlt port 1 2
smlt port 2 3
smlt port 3 4
smlt port 6 2
smlt port 20 9
exit

I have a lot of ERS55xx in this setup without any issues. Does the ERS5632FD works that different on the same SW code base ?

I will open a case at AVAYA, if anybody expierenced something similar, give me an update.

THX
Dom

[Jon Hurtt]

I am in 100% agreement that you should open a ticket on this, it is very bizarre (especially the smlt info)... But the code base is the same for all ERS 5000 (there are some documented limitations on feature sets with the ERS 5500 (ie 5510).. good luck and let us know how it goes...

[Michael McNamara]

While the software release on the ERS 4500 is a little old the other odd behavior would hint to an issue with the ERS 5632.

Have you tried rebooting the switch? I'm guessing yes since you're reporting the problem at two different sites.

Software release 6.2.2 is now available if your interested in trying an upgrade.

https://support.avaya.com/css/P8/documents/100141431

Cheers!

[hosh]

iam a coworker from dominik....

this is the answer from AVAYA

As mentioned earlier  VLACP shuts the ports  i.e blocks all  traffic on the ports other than VLACPDU’s so that the VLACP state can be revived 
 
This problem does not concern as such with the deployment of 5632’s or deployment with VLACP. The  problem here refers to the working of VLACP
in an environment where VLACPDU’s could possibly be missed due to traffic  across a link .  In an environment where VLACP fails due to the traffic in the
 network we use an iterative method of using long timers and increasing the timeout scale. In case we see VLACPDU’s being missed across a link in the presence of traffic.
 
In a lab environment  these problem would however be difficult to notice .Avinash had this set up running  in his labs for a day   and did not notice any such problems.
Similar problems have been  noticed  in other cases too where we have tried the measure of increasing the VLACP timers and increasing the timeout  scale.
 
This does not concern a  software bug as the VLACPDU’s are being generated and transmitted across the links . The functioning of VLACP does not affect
the other software processes  and is functioning smoothly  without traffic .
 
However  the 55xx switches  does have higher buffer capacity per port than the  56xx series of switches .This would explain the problem not happening
with 5530 switches but being noticed in 5632 switches . However please do note that ERS56xx cases have higher stack bandwidth  and thus would be more useful
when used in a stack .

we updated the 5632FD to 6.2.2.023 but the Problem was noct solved

the workaround is to change the VLACP settings from short timers to long timers - now there is no flapping

but the network at all is a little bit spooky!
we have serious problems with PXE boot - (EnteoServer for DHCP and PXEBoot)
- the client requested ip IP from DHCP succesfully
- the client requested the PXE server succesfully
- the client should request a file from TFTP (same server) nothing happend
if the client ist on the same Vlan and on the same Switch it works (different Vlan same problem)
(dhcp-Relay is configured on both coreERS, VLANs, SMLT etc looks good so far)

anybody an idea?

greets

[Flintstone]

Hi Hosh,

Have you tried using a Sniffer to check DHCP/TFTP requests and responses?

CheerZ

[hosh]

yes

we could see the dhcp requests and so on.
in the correct setup the client starts with tftp read request
in the "wrong" setup the client will not start the tftp read request.

what i see is a little ARP mistake on te CoreERS

the enteoSRV ist connected with two interfaces (windows teaming, we are not the admins of the server)
- the ip ie 192.168.1.20 has the following MAC ie aa:aa:aa:aa:aa:aa
- the aktiv interface is on Switch 2
- the passiv interface ist on Switch 1
now the ARP entry points to the switch with the passiv Interface also the the forwarding entry
- Swtich 1 know the MAC on his uplinks - perfect circle for me but why

[Flintstone]

Hi hosh,

As a work around; If I understand correctly, have you tried removing the passive interface?

CheerZ and good luck

[hosh]

we are currently testing this and other setups

we dont pull of the cable but i shut down one of the switchports to the Server.
if both client an server are connected to the same switch i works.
if they are connected on the different switches it works if one uplink of the smlt Connection is shut down.

again the smlt configuration looks good so far.
the admins deconfigure in this moment the teaming on the server, i have no other idea at this point...

[Michael McNamara]

You might want to confirm how the server administrators are configuring the NIC teaming? I use Network Fault Tolerant (NFT), however, they might be trying to use TLB (Transmit Load Balancing) which should also work.

Good Luck!

[hosh]

the deconfiguration of the teaming had no effect (positiv).

but i found something in the software release notes for version 6.2.3 (we use at the moment 6.2.2)

newbielink:http://support.avaya.com/css/P8/documents/100146170 [nonactive]

IST Peers FDB table were out of sync (wi00892974)

what du you think

p.s Adapter/network fault tolarente is what the admins use for the server.

[Michael McNamara]

It's probably worth a shot... when you examine the MAC/FDB and ARP tables are they out of sync on both switches? (do they conflict with each other?)

Cheers!

[hosh]

big suprisse
on December 21st avaya released a new update for the ers 5000 (6.2.4) - we udate yesterday the two core 5632 with the DHCP-Problem and guess what happend - it works!!
Avaya dit some work on teh DHCP-relay software (When dhcp-relay is disabled on the VLAN, the switch sends duplicate DHCP acknowledgments (wi00965089)) and we think they fixed another problem by the way.

short report of our problem:
2 ers 5632 core switches with slt uplinks to 4548 stacks and single switches
some vlans and L3 at the core - one vlan for server, second for clients etc dhcp relay for the client vlan target server in the server vlan. the server (Enteo v6 software delivery) dhcp incl PXE server.
the client was prepaired and restart, we could see at the packet sniffer that dhcp was successful and at a point when the client should start with a tftp request nothing happens. we tested the same setup with a ERS 1624 in the core and it works. now with the new update and the same setup it just works.

wish you all a great new year