Limitations of MAD

The operating limitations of this feature are listed below:

• MAD will work with other vendor downstream/upstream devices that have an IEEE 802.1AX (formerly 802.3ad) standards-based LACP trunk to the VSF pair. MAD cannot work with non-LACP and DT-LACP trunks that Provision OS supports today.

• MAD should be configured when a VSF virtual chassis is active and not after a VSF virtual chassis split. Configuring MAD after a VSF split has occurred would not help detecting multiple-active fragments for the current split event.

• Upon a split and once a fragment has been determined to become inactive, it cannot subsequently become active if the originally determined ‘active’ fragment goes ‘down’. This is because the front plane (non-VSF) ports of the inactive fragment would have been brought ‘down’ and there is no way to do an LLDP-MAD subsequently.

• The MAD assist device (downstream or upstream device) and the VSF device must belong to the same IPv4 subnet for MAD to work. This would be validated at the time of MAD configuration (in the UI).

• The downstream/upstream helper device must support SNMPv2 and be able to handle ifTable MIB object GET requests via SNMPv2 (RFC 2863). For the first VSF release, LLDP-MAD will not work with SNMPv3.

• Determination of the active/inactive fragment via MAD would take up anywhere between 2-6 seconds.

• If management VLAN is not configured on a device, then LLDP MAD ports can be a part of any VLAN.

• If management VLAN is configured on a VSF switch, then LLDP-MAD ports should be a part of management VLAN.