Logical understanding for management status on Aggregate Ports when PortType=ACCESS
search cancel

Logical understanding for management status on Aggregate Ports when PortType=ACCESS

book

Article ID: 424049

calendar_today

Updated On:

Products

VMware Smart Assurance Network Observability

Issue/Introduction

This article explains the default logic Smarts refers to manage the Aggregate ports when PortType=ACCESS

Environment

All Supported Smarts releases

Resolution

  • Review the properties of the AggregatePort, specifically the PartOf relationship on the AggregatePort
Command: dmctl -s <AMPM Domain> get AggregatePort :: <Insert AggregatePort Name Here>

Example:
Properties of AggregatePort::AggregatePort-<AGGPort>/<index>:
ComposedOf = { Port::PORT-<Port1>/<index>, Port::PORT-<Port2>/<index> }
ManagedState = MANAGED
PartOf = { Switch::<Swith>, vAggregatePort::<V-AGGPort>/<index> }
  • As per the code-logic defined in the IP/smarts/rules/devstat/sys-setting.asl file, the vAggregatePorts are managed, the composed AggregatePort within this vAggregatePorts get managed:
 foreach obj (sysObj->Underlying) {
                   if (obj->CreationClassName == "vAggregatePort") {
                        if (DEBUG) {
                           print("Set Managed state for vAggregatePort ".obj);
                        }
                        obj->setManagedState("MANAGED");
                       //now set managed state for underlying aggports
                        foreach aggPort (obj->ComposedOf) {
                              if (DEBUG) {
                                  print("Set Managed state for AggregatePort ".aggPort);
                                }
                             aggPort->setManagedState("MANAGED");
                        }

If the AggregatePort is part of a vAggregatePort, then the vAggregatePort becomes the Parent and the child AggregatePorts form the PartOf relationship on the same. 
Hence, the ports that are part of a managed vAggregatePort, the child ports on the same get managed as explained on the code reference above. 

=======================Example Discovery Logs confirm the same=======================
[<Date & Time>] t@<epoch>ProbeCompletedRunner
ASL_MSG-*-ASLP-devstat/sys-setting.asl: Set Managed state for vAggregatePort vAggregatePort::<V-AGGPort>/<index>

[<Date & Time>] t@<epoch>ProbeCompletedRunner
ASL_MSG-*-ASLP-devstat/sys-setting.asl: Set Managed state for AggregatePort AggregatePort::AggregatePort-<AGGPort>/<index>
=============================================================================

Note: These VirtualAggregatePorts are created from combination of AggregatePorts (Logical ports) forming a Virtual Port Channel (VPC), and do not participate in any AggregateLink relationship so it is not expected to have connectivity information. 

[<Date & Time>] t@<epoch>ProbeCompletedRunner
ASL_MSG-*-ASLP-discovery/ic-post-lag.asl: discovery/ic-post-lag.asl MR_Object::AggregatePort-<AGGPort>/<index> is taking part in VPC. So it will NOT be a part of the AggregateLink