Reset Search



Why disabling MAC aging on switches configured with Brocade trunks can prevent connectivity problems?

« Go Back


TitleWhy disabling MAC aging on switches configured with Brocade trunks can prevent connectivity problems?

A trunk can be configured as type Brocade ifitis between the following switches:

1) 8000----8000

2) VDX----- 8000

3) VDX-----VDX

For the first two options,if the trunk type is Brocade,it is recommended to configure mac-age to 0 on both oftheswitches.

Not having this configuration may result in:
Noconnectivity between VDX and 8000 or traffic loss / packet loss between VDX and 8000.
No connectivity between8000 and 8000 ortraffic loss / packet loss between 8000 and 8000.

Consider the following setup with MAC age-out timer configured as default 5 minutes on both VDX and 8000:
(host-1 mac-1; host-2 mac-2)-----VDX-------------------------------8000-----(host-3 mac-3)
(Trunk type Brocade)
In the above scenario, the VDX learns mac-3 from the8000 through the trunk port. In addition,the8000 learns mac-1 and mac-2 from VDX through the trunk port. Mac-1 and mac-2 are learnt locally on theVDX and mac-3 is learnt locally on the8000.
MAC addresses are learned when flooding occurs in the network. MACs will then age out of each switch by default after five minutes of inactivity. This aging out process is not down to the seconds, therefore two switches which learn a flooded MAC at the same time may age out the MAC at different times.
In the above scenario say, mac-2has aged out of the VDXbut the8000 still has mac-2 in its forwarding database. If VDX learns mac-2; again after it has aged out; it will flood the mac (mac-2) on the trunk port to the 8000 and since the 8000 already has mac-2 in it forwarding database,it will drop the packet due to mac source supression. This is because the 8000 had already learnt mac-2 from the same trunk ports and the mac-2 had not yet aged out.

For Brocade trunks, a sequence number is assigned to the packet destined to the VDX by8000.This means that theVDX switch is now expecting to receive a frame with that same assigned sequence number, but ifthe frame never arrives, it results in a sequence hole.
If the VDX multicasts hundreds of frames to the8000, instead of just a fraction of frames, and if the 8000 has Filtering Database (FDB) entries for those multicastedframes then:
- The 8000 will keep dropping the frames
- The problem occurs when the8000 finally does get around to sending a frame over to theVDX; at this point, the sequence ID number expected at theVDX is so far out of range that it will simply drop the incoming frames. The frames will continue to be dropped until the originally expected sequence number is received byVDX. If the sequence numbers are never recieved, this will result in lack of connectivity.

If the above drop and wraparound scenario happens twice within a period of around 5 minutes, it may resultin VDX switch fault signature below. However, ifsource suppressionhappens on the VDX, it will corrupttheTX CRC instead of dropping the frame, which means there will not be a switch fault on the 8000 side:
2011/09/07-00:53:22, [EANV-1006], 659061,, CRITICAL, VDX6720-60, S0,C7: HW ASIC Chip fault. Type = 0x2a, Error = Critical Parity Errors.
2011/09/07-00:53:22, [NSM-1003], 659062,, INFO, sw0, Interface Port-channel 2 is link down
2011/09/07-00:53:22, [NSM-1003], 659063,, INFO, sw0, Interface Vlan 191 is link down
2011/09/07-00:53:22, [NSM-1003], 659064,, INFO, sw0, Interface Vlan 1 is link down
2011/09/07-00:53:22, [NSM-1003], 659065,, INFO, sw0, Interface Port-channel 1 is link down
2011/09/07-00:53:22, [EM-1034], 659066,, ERROR, VDX6720-60, Switch set to faulty, rc=20015.
2011/09/07-00:53:23, [NSM-1017], 659069,, INFO, sw0, Interface TenGigabitEthernet 0/43 is removed on interface Port-channel 2
sw0# sh ip int brief

Interface IP-Address Status Protocol
======================== ========== ==================== ========
Port-channel 1 unassigned up down
Port-channel 2 unassigned up down
Vlan 1 unassigned up down
Vlan 191 unassigned up down

Because of the reason above, it is recommended to configure mac-age to 0 on both the VDX and the 8000 if they are connected with type Brocade trunk (or on both 8000s if two 8000 switches are connected via a type Brocade trunk).

Here are the steps to configure mac-age to 0 (disable mac aging) on both a VDX and an 8000 switch:

VDX(config)# mac-address-table aging-time 0

VDX(config)# do show run | inc mac
mac-address-table aging-time 0

aging-time static
8000(config)#mac-address-table aging-time ?
0 Disable aging
<10-100000> Aging time in seconds (default = 300)

Note: the switch will not fault if the VDX will runNOS 2.1.0 (connected with an 8000via aBrocade trunk) andNOS 2.0.2 whicharebeing released in October 2011. However, even with the new NOSversions, the sequenceIDholes issue, as explained above, will still exist. These issue are not seen when a type Brocade trunk connects VDXs.

Additional notes



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255