Symptoms:
This article explains how to turn off aggregate port discovery in Smarts IP Manager 9.2.2 so that it behaves as Smarts IP 8.x did for Cisco Devices, where aggregate ports were discovered as Interfaces.
Smarts IP Manager version 9.2.2 discovers aggregate ports as port objects and does not instrument them for fault monitoring, unless the aggregate port object can be determined to be physically connected to another aggregate port on another device in the topology where Smarts would then create an
AggregateLink. If the other end of the
AggregateLink is not in the Smarts IP Manager topology or cannot be discovered for some reason, this
AggreateLink will never be created, which means the aggregate port will not be instrumented for fault monitoring by default unless set to EXPLICITLY_MANAGED.
In Smarts IP Manager 8.x, objects which are discovered as aggregate port objects in Smarts IP Manager 9.2.2, are discovered as
Interfaces instead, and are always instrumented for fault monitoring. Depending on the device, this may be the more desired behavior than the default behavior in Smarts IP Manager 9.2.2.
Example: Smarts IP 8.xThe following shows Smarts IP Manager 8.x discovery where index
106 is made up of indexes
5,
55,
56,
57, and
6, and
106 is discovered as an Interface:
In the above example, index
106 will be instrumented for fault monitoring by default along with index 5, 55, 56, 57, and 6, since they are all interfaces.
Example: Smarts IP 9.2.2 LACP discoveryThe following example shows LACP discovery of the same index
106 above, but the index is discovered as an AggregatePort instead:
In the above example, since the AggregatePort is not determined to be connected to another AggregatePort in the topology, no
AggregateLink is created. Because of this, only the Interface indexes of
5,
55,
56,
57, and
6 would be instrumented for fault monitoring by default since they are Interfaces, but the AggregatePort
106 will not.
Example: Smarts IP 9.2.2 PAGP discoveryThe following example shows the Smarts IP 9.2.2 PAGP discovery of index
621 where this index is made up indexes 59, 60, 61, 62, 63, and 64:
In the above example, since the AggregatePort is not determined to be connected to another AggregatePort in the topology, no AggregateLink is created. Because of this, only the interface indexes of 59, 60, 61, 62, 63, and 64 will be instrumented for fault monitoring by default since they are interfaces, but the AggregatePort 621 will not.