![]() |
SYSTEM ADMINISTRATOR GUIDE 52/1543-CRA 119 1170/1-V1 Uen A | ![]() |
Copyright
© Copyright Ericsson AB 2009. All rights reserved.
Disclaimer
No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
Trademark List
SmartEdge | is a registered trademark of Telefonaktiebolaget L M Ericsson. | |
NetOp | is a trademark of Telefonaktiebolaget L M Ericsson. |
This document describes the operations, administration, and maintenance (OAM) of Ethernet bridges that link wide area networks (WANs) and metropolitan area networks (MANs). To enable providers and users to monitor Ethernet connectivity faults and quickly determine their location, the SmartEdge router supports IEEE P802.1ag, connectivity fault management (CFM).
In this document, the term CFM identifies the type of Ethernet OAM implemented by the SmartEdge router. This section provides a short description of Ethernet service management, the SmartEdge CFM implementation, definitions, SNMP support, supported circuits, a table of operations commands, and a description of the operating system CLI command modes.
The SmartEdge CFM implementation provides service management of the Ethernet and Ethernet emulating interfaces of the SmartEdge router. SmartEdge CFM allows service providers and end users to individually manage their Ethernet service instances on the SmartEdge router.
The mechanisms that the SmartEdge router uses to monitor customer instances for Ethernet faults are based on IEEE P802.1ag PDU messages:
A customer service instance, also called an Ethernet Virtual Connection (EVC), is the service that is sold to a customer and is designated by its service-VLAN (S-VLAN) tag or entire port. SmartEdge CFM enables the service provider to know if an EVC has failed and provides tools to rapidly isolate the failure.
The CCM is a multicast unidirectional heartbeat message used for fault detection. The maintenance association endpoint (MEP) broadcasts CCMs to check the continuity of the maintenance association (MA). By default, loss of three consecutive CCMs is reported as a MA connectivity fault.
LBM and LBR are unicast bidirectional request and reply messages used for fault detection and verification. The simplest form of LBM-LBR is a ping message with a static MAC address.
The multicast request (LTM) but unicast response (LTR) messages are used for fault isolation and path discovery. LTMs are initiated by MEPs. The LTM traverses the bridged Ethernet networks hop by hop.
Each maintenance point along the path examines the LTM and takes the following actions:
The following terms are used to describe the SmartEdge CFM implementation:
Local MEPs can be classified as up or down:
Figure 1 illustrates concepts described in this section:
Table 1 lists the SNMP MIB tables that report the MAs, MDs, and MEPs managed by the SmartEdge router.
Table |
Description |
---|---|
dot1agCfmMdTable |
MD table. Each row in the table represents a different MD. |
dot1agCfmMaNetTable |
MA table. Each row in the table represents an MA. An MA is a set of MEPs, each configured with a single service instance. |
dot1agCfmMepTable |
MEP table. |
dot1agCfmLtrTable |
Extension of the MEP table that contains a list of LTRs received by a specific MEP in response to a LTM. |
dot1agCfmMepDbTable |
MEP database, which is a database maintained by every MEP, that contains information received about other MEPs in the MD. |
Table 2 lists the notification (trap) that the SmartEdge router sends to the SNMP management entity whenever a MEP loses or restores contact with other MEPs.
Trap |
Description |
---|---|
dot1agCfmFaultAlarm |
The CFM Fault Alarm is sent whenever a MEP loses or restores contact with other MEPs. The notification contains the object ID (OID) of the MEP that has detected the fault. |
When a maintenance associate endpoint has a defect condition, such as a loss of CCMs, an SNMP notification with the highest-priority defect is triggered and reported. However, the CFM trap content shows the local maintenance association endpoint index as zero and the dot1agCfmMepHighestPrDefect as none (0), which is incorrect. Use the SNMP get-next operation to obtain the values of the dot1agCfmMepHighestPrDefect MIB object.
The MIB value for the dot1agCfmMepHighestPrDefect object shows text, defRDICCM(1), other than the correct text, defRemoteCCM(3). Ignore defRDICCM(1) for the dot1agCfmMepHighestPrDefect object.
Transmission of Ethernet-OAM loopback messages does not populate values to the following MIB objects:
Transmission of Ethernet-OAM link-trace messages does not populate values to the following MIB objects
The CFM database incorrectly reports the value of the dot1agCfmMepTransmitLbmMessages MIB object as always equal to zero.
The different states of the MIB object, Dot1agCfmFngState, such as fngDefect(2), fngReportDefect(3), fngDefectReported(4), fngDefectClearing(5), are not available. SNMP status for Dot1agCfmFngState is always reported with the value fngReset(1) regardless of its actual status.
The local MEP index of the remote MEP database table in IEEE8021-CFM-MIB is always zero (0) instead of the associated local MEP ID.
The value of the dot1agCfmMepLtmNextSeqNumber object is incorrect when running loopback transmission messages (LTMs). The object, dot1agCfmMepLtmNextSeqNumber, is increased by running LTMs, but it should in fact be independent of LTMs.
This section describes the circuits that support CFM MPs.
A maintenance point (MEP or MIP) can be configured on a circuit on a physical Ethernet port.
CFM PDUs pass over the cross connection and are processed by the MPs in the MA on both sides of the cross connection.
Each Ethernet circuit can be associated only with a single MA.
The circuit can be part of a bridging group, or it can be cross-connected to another circuit or to a VLAN-based circuit.
A maintenance point (MEP or MIP) can be configured on an VLAN-based circuit (that is, an 802.1Q PVC, an 802.1Q tunnel, or an 802.1Q PVC in an 802.1Q tunnel). The PVC must use the MAC address of the physical port or system. The VLAN can be part of a bridging group, or it can be cross connected to another VLAN or to a circuit.
CFM PDUs pass over the cross connection and are processed by the MPs in the MA on both sides of the cross connection.
Each VLAN-based circuit can be associated with only one MA.
Processing of CCMs is supported on the port bound to a 802.1Q tunnel, but not on the C-VLAN or S-VLAN-based circuits.
You can configure maintenance points (MEP or MIP) on link groups of the following types. The link group ports can be configured simply as bundled ports or with aggregated 802.1Q PVCs (VLANs) or 802.1Q tunnels:
When link groups are configured for CFM, only one port in the link group bundle transmits CFM PDUs.
CFM can be configured on a L2VPN circuit; that is, MPs can be configured on VLAN-based circuits cross connected to a virtual leased line (VLL) in the L2VPN circuit. CFM PDUs pass over the cross connection and VLL and are processed by the MPs in the MA on the VLAN based-circuits on both ends of the cross connection.
A VLL is a pseudowire that uses an L2VPN circuit to provide point-to-point service between two network nodes over a packet network that supports MPLS. Use the xc (cross connect) command to attach the local VLAN-based circuit to the VLL pseudowire. In SmartEdge router documentation, the connection between the local circuit and the pseudowire is sometimes called a cross connection, although in a more general sense the connection between the two nodes over the pseudowire could also be called a cross connection.
You can configure MPs on the VLAN-based circuits that are attached to the pseudowire, but because the pseudowire has no physical interface, you cannot configure MPs on the pseudowire itself. See Figure 2
CFM can be configured on VLAN-based circuits cross connected to a VPLS pseudowire. CFM PDUs pass over the cross connection and pseudowire and are processed by the MPs in the MA on the VLAN based-circuits on both ends of the cross connection.
You can configure MPs on the local VLAN-based circuits attached to a pseudowire, but not on the VPLS pseudowire itself.
To configure a CFM instance, its MD, maintenance points, and MA parameters, and to troubleshoot and determine the status of CFM, see the following sections.
The following rules apply to the configuration of an CFM Instance, its MD, and its Maintenance Points:
Perform the tasks described in Table 3 to configure SmartEdge system maintenance points of a maintenance domain.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Give a name to the CFM instance. |
Enter in global configuration mode. | |
2. |
Enter the name of the MD for which the SmartEdge CFM instance is a component. |
Enter in CFM configuration mode. | |
3. |
Enter the MD level of the maintenance domain specified in step 2. |
Enter in CFM configuration mode. | |
4. |
Create a list of (MIPs) in the MD and associate each MIP with a physical port or interface. |
Enter in CFM configuration mode. A maintenance point not having a domain service access point, but connected to MEPs in this domain, should be configured as a MIP. | |
5. |
Optionally disable the responses of maintenance points in the MD specified in step 2 from responding to LTM PDUs. |
Enter in CFM configuration mode. | |
6. |
Create an MA in the MD specified in step 2. Repeat this step for every MA in the MD. Continue with Table 4 for every MA created. |
Enter in CFM configuration mode. |
Use the show configuration cfm command to see the resulting CFM configuration.
Perform the following tasks described in Table 4 to configure the parameters of a SmartEdge MA.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Create a list of remote maintenance endpoints (MEPs) in the MA, and give each MEP its own ID (MEPID) in the MA. |
Enter in MA configuration mode. The mesh of MEPs forms a single C-VLAN or S-VLAN. | |
2. |
Bind each MEPID with a local physical interface or port, and specify the MEP direction. |
Enter in MA configuration mode. Repeat this step for each and every MEPID in the MA:
| |
3. |
Enable CCM and enter the CCM configuration mode. |
Enter in MA configuration mode | |
4. |
Configure CCM connectivity fault failed frames criteria. |
Enter in CCM configuration mode | |
5. |
Configure the interval between sending CCM PDUs. |
Enter in CCM configuration mode |
If a link fails, you can troubleshoot the problem through CFM link trace and loopback testing. These commands are listed in Table 5.
Task |
Root Command |
---|---|
Initiate the CFM link-trace test |
|
Initiate the CFM loopback test |
|
Initiate CFM debugging |
|
Clear CFM loopback and link-trace counters |
(1) Use no linktrace to
disable linktrace responses.
(2) Use no loopback to
disable loopback responses.
The following example shows a successful loopback test.
[local]Redback(config-if)#ethernet-cfm loopback from 2/11 vlan-id 1 to 00:30:88:02:f2:d8 level 2 circuit: 2/11 vlan-id 1, handle: 2/11:1023:63/1/2/14, vlan id: 1, inner vlan id: 0ethernet-cfm loopback from 2/11 vlan-id 1 to 00:30:88:02:f2:d8 level 2 CFM loopback in progress... source mac: 00:30:88:02:82:88, cct: 1/10/1/0, data: timeout is 1 second !!!!! -----CFM Loopback statistics----- 5 loopback packets sent, 5 packets received, 0.0% packet loss round-trip min/avg/max = 0/2/4 ms
The following example shows a working linktrace test.
[local]Redback(config-if)#ethernet-cfm linktrace from 2/2 vlan-id 100 to 00:30:88:02:f3:23 level 5 ethernet-cfm linktrace from 2/2 vlan-id 100 to 00:30:88:02:f3:23 level 5 CFM linktrace in progress... cct: 1/1/100/0, data: 1 00:30:88:12:3d:86 4 ms 2 00:30:88:02:f3:23 8 ms CFM linktrace completed.
The following example shows a linktrace test that failed after completing one hop.
[local]Redback(config-if)#ethernet-cfm linktrace from 2/2 vlan-id 100 to 00:30:88:02:f3:23 level 5 ethernet-cfm linktrace from 2/2 vlan-id 100 to 00:30:88:02:f3:23 level 5 CFM linktrace in progress... cct: 1/1/100/0, data: 1 00:30:88:12:3d:86 4 ms 0 * CFM linktrace could not be completed. (Reason : timeout)
Use the following CLI commands in Table 6 to monitor link status and the CFM database. Examples of the output fields displayed by these commands are found in the reference pages for these commands.
Task |
Root Command |
---|---|
Show the CFM information for a specified circuit |
|
Show the current CCM database |
|
Show the status of MDs |
|
Show the status of MAs |
|
Show the status of local MEPs |
|
Show the status of remote MEPs |
|
Show the status of MIPs |
This section provides examples of configuring MEP.
The following example show how to create an 802.1Q PVC attachment circuit on port 5/1 and cross-connect it to an L2VPN pseudowire. The local MEP is configured on the 802.1Q PVC:
[local]Redback(config)#context local [local]Redback(config-ctx)#interface foo [local]Redback(config-if)#ip address 200.2.2.2/24 [local]Redback(config-if)#exit [local]Redback(config-ctx)#l2vpn [local]Redback(config-l2vpn)#xc-group bar [local]Redback(config-l2vpn-xc-group)#xc 5/1 vlan-id 300 vpn-label 5000 peer 100.1.1.1 ! [local]Redback(config-ctx)#port ethernet 5/1 [local]Redback(config-port)#no shutdown [local]Redback(config-port)#encapsulation dot1q [local]Redback(config-port)#dot1q pvc 300 [local]Redback(config-dot1q-pvc)#l2vpn local ! [local]Redback(config)#ethernet-cfm instance-3 [local]Redback(config-ether-cfm)#level 5 [local]Redback(config-ether-cfm)#maintenance-association green [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma-ccm)#exit [local]Redback(config-ether-cfm-ma)#mep-remotelist 12 [local]Redback(config-ether-cfm-ma)#mep-local 102 5/1 vlan-id 300 direction up ! [local]Redback#show config cfm ! Building configuration... Current configuration: ! !Ethernet connectivity fault management configuration ! ethernet-cfm instance-3 level 5 domain-name instance-3 maintenance-association R&D ccm mep-remotelist 11 mep-local 101 5/1 vlan-id 300 maintenance-association green ccm mep-remotelist 12 mep-local 102 5/1 vlan-id 300 end
Figure 3 illustrates a simplified network of two nodes (A and B), where CFM reports the failure of any of the four links between the nodes. This type of CFM configuration is applicable to link groups, where the four links are in the link bundle:
For the A-B segment of the network, the example configures four maintenance associations (vlan1-vlan4) in the same domain. Link failures are detected through CCM PDUs.
Link failure detection is configured on nodes A and B in the following sections.
Create CFM instance-1 and MD abc in it. Each CFM instance can have at most one MD level and one MD name:
[local]Redback(config)#ethernet-cfm instance-1 [local]Redback(config-ether-cfm)#level 2 [local]Redback(config-ether-cfm)#domain-name abc
Create MA vlan1, which corresponds to the Ethernet VLAN between cct1 on node A and cct5 on node B. There is one link per Ethernet port: cct1 is 5/1 on node A and cct5 is 9/1 on node B. The local MEP on one instance (node) is the remote MEP on the other; that is why the local MEP ID on instance-1 matches the remote MEP ID on instance-2:
[local]Redback(config-ether-cfm)#maintenance-association vlan1 [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 101 [local]Redback(config-ether-cfm-ma)#mep-local 11 5/1 direction down
Create MA vlan2, which corresponds to the Ethernet VLAN between cct2 on node A and cct6 on node B, where cct2 is 5/2 and cct6 is 9/2:
[local]Redback(config-ether-cfm)#maintenance-association vlan2 [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 201 [local]Redback(config-ether-cfm-ma)#mep-local 21 5/2 direction down
Create MA vlan3, which corresponds to the Ethernet VLAN between cct3 on node A and cct7 on node B, where cct3 is 5/3 and cct7 is 9/3:
[local]Redback(config-ether-cfm)#maintenance-association vlan3 [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 301 [local]Redback(config-ether-cfm-ma)#mep-local 31 5/3 direction down
Create MA vlan4, which corresponds to the Ethernet VLAN between cct4 on node A and cct8 on node B, where cct3 is 5/4 and cct7 is 9/4:
[local]Redback(config-ether-cfm)#maintenance-association vlan4 [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 401 [local]Redback(config-ether-cfm-ma)#mep-local 41 5/4 direction down
Create CFM instance-2 and MD abc in it. Each CFM instance can have at most one MD level and one MD name:
[local]Redback(config)#ethernet-cfm instance-2 [local]Redback(config-ether-cfm)#level 2 [local]Redback(config-ether-cfm)#domain-name abc
Create MA vlan1, which corresponds to the Ethernet VLAN between cct1 on node A and cct5 on node B. There is one link per Ethernet port, cct1 is 5/1 on node A and cct5 is 9/1 on node B:
[local]Redback(config-ether-cfm)#maintenance-association vlan1 [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 11 [local]Redback(config-ether-cfm-ma)#mep-local 101 9/1 direction down
Create MA vlan2, which corresponds to the Ethernet VLAN between cct2 on node A and cct6 on node B, where cct2 is 5/2 and cct6 is 9/2:
[local]Redback(config-ether-cfm)#maintenance-association vlan2 [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 21 [local]Redback(config-ether-cfm-ma)#mep-local 201 9/2 direction down
Create MA vlan3, which corresponds to the Ethernet VLAN between cct3 on node A and cct7 on node B, where cct3 is 5/3 and cct7 is 9/3:
[local]Redback(config-ether-cfm)#maintenance-association vlan3 [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 31 [local]Redback(config-ether-cfm-ma)#mep-local 301 9/3 direction down
Create MA vlan4, which corresponds to the Ethernet VLAN between cct4 on node A and cct8 on node B, where cct3 is 5/4 and cct7 is 9/4:
[local]Redback(config-ether-cfm)#maintenance-association vlan4 [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 41 [local]Redback(config-ether-cfm-ma)#mep-local 401 9/4 direction down
In the example illustrated by Figure 4, the SmartEdge router monitors whether or not there is a loop for the circuit with interface 5/1 on router A:
The down MEP at cct continuously sends CCM PDUs. If there is a loop, it receives the CCMs back and reports a circuit fault:
[local]Redback(config)#ethernet-cfm teleportics [local]Redback(config-ether-cfm)#domain-name teleportics.com [local]Redback(config-ether-cfm)#level 5 [local]Redback(config-ether-cfm)#maintenance-association sp [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 101 [local]Redback(config-ether-cfm-ma)#mep-local 11 5/1 direction down
In the example illustrated by Figure 5, a single customer service instance (C-VLAN) connects port 5/1 on bridge A to port 6/1 on bridge D. Service provider bridge B and C maintain the S-VLAN service instance, which encapsulates the customer C-VLAN:
The following is the CFM configuration for subscriber bridge A. The instance-1 service instance contains a single MA name R&D. From the point of view of bridge A, R&D is terminated by the local MEP (11) at port 5/1 and a remote MEP (101) on subscriber bridge D:
[local]Redback(config)#ethernet-cfm instance-1 [local]Redback(config-ether-cfm)#level 5 [local]Redback(config-ether-cfm)#domain-name redback.com [local]Redback(config-ether-cfm)#maintenance-association R&D [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma-ccm)#exit [local]Redback(config-ether-cfm-ma)#mep-remotelist 101 [local]Redback(config-ether-cfm-ma)#mep-local 11 5/1 direction down
The following is the CFM configuration for subscriber bridge D. Subscriber bridges A and D monitor the customer service instance (instance-1). From the point of view of bridge D, R&D is locally terminated by MEP (101) at port 6/1 and remote MEP (11) on subscriber bridge A:
[local]Redback(config)#ethernet-cfm instance-1 [local]Redback(config-ether-cfm)#level 5 [local]Redback(config-ether-cfm)#domain-name redback.com [local]Redback(config-ether-cfm)#maintenance-association R&D [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 11 [local]Redback(config-ether-cfm-ma)#mep-local 101 6/1 direction down
In the following configuration of provider bridge B, the instance-2 service instance monitors the S-VLAN between local MEP (31) at port 4/2 on bridge B and remote MEP (301) on bridge C. The provider MD level 4 must be lower than the subscriber MD level:
[local]Redback(config)#ethernet-cfm instance-2 [local]Redback(config-ether-cfm)#level 4 [local]Redback(config-ether-cfm)#domain-name sbc.com [local]Redback(config-ether-cfm)#maintenance-association bayarea [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 301 [local]Redback(config-ether-cfm-ma)#mep-local 31 4/2 direction up
The following configures port 4/2 on bridge B in the redback.com domain as a MIP in the instance-1 at MD level 4:
[local]Redback(config)#ethernet-cfm instance-1 [local]Redback(config-ether-cfm)#level 5 [local]Redback(config-ether-cfm)#domain-name redback.com [local]Redback(config-ether-cfm)#mip 31 4/2
The following is the CFM configuration for provider bridge C, instance-2 service instance. Provider bridges B and C monitor the S-VLAN between port 4/2 on bridge B and port 9/1 on bridge C:
[local]Redback(config)#ethernet-cfm instance-1 [local]Redback(config-ether-cfm)#level 4 [local]Redback(config-ether-cfm)#domain-name sbc.com [local]Redback(config-ether-cfm)#maintenance-association bayarea [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma)#mep-remotelist 31 [local]Redback(config-ether-cfm-ma)#mep-local 301 9/1 direction up
The following configures port 9/1 on bridge C in the redback.com domain as a MIP in the instance-1 at MD level 4:
[local]Redback(config)#ethernet-cfm instance-2 [local]Redback(config-ether-cfm)#level 5 [local]Redback(config-ether-cfm)#domain-name redback.com [local]Redback(config-ether-cfm)#mip 301 9/1
The following example show how to create an access link group named dslam-face and an aggregated PVC with ID 1 on the link group. The local MEP 101 is one configured on the aggregated 802.1Q PVC:
[local]Redback(config)#link-group dslam-face access [local]Redback(config-link-group)#encapsulation dot1q [local]Redback(config-link-group)#dot1q pvc 1 [local]Redback(config-dot1q-pvc)#bind interface downstream peter ! [local]Redback(config)#ethernet-cfm instance-1 [local]Redback(config-ether-cfm)#maintenance-association R&D [local]Redback(config-ether-cfm-ma)#ccm [local]Redback(config-ether-cfm-ma-ccm)#exit [local]Redback(config-ether-cfm-ma)#mep-local 101 lg dslam-face vlan-id 1 ! [local]Redback(config-ether-cfm-ma)#show configuration link Building configuration... Current configuration: ! link-group dslam-face access encapsulation dot1q dot1q pvc 1 bind interface downstream peter ! ! end ! [local]Redback(config-ether-cfm)#show configuration cfm instance-1 Building configuration... Current configuration: ! !Ethernet connectivity fault management configuration ! ethernet-cfm instance-1 level 0 domain-name instance-1 maintenance-association R&D ccm mep-local 101 lg dslam-face vlan-id 1 ! end
Example 1 Undetailed Linktrace Output of show ethernet-cfm... Command
[local]Redbacj#show ethernet-cfm database down domain ericsson ma devtest mep 201 linktrace SeqNum Ingress Mac Egress Mac Relay Action TTL 6 00:30:88:13:07:8f 00:00:00:00:00:00 RlyFDB 63 6 00:30:88:01:a0:74 00:00:00:00:00:00 RlyFDB 62 6 00:30:88:13:44:ad 00:00:00:00:00:00 RlyHit 61
Example 2 Detailed Linktrace Output of show ethernet-cfm... Command
[local]Redback#show ethernet-cfm database up domain dd ma platform mep 101 linktrace detail ------------------------------------------------------------------- SequenceNumber: 32 ReceiveOrder : 1 ------------------------------------------------------------------- Ttl : 63 Forwarded : No TerminalMep : No Relay Action : RlyMpDB LastEgressId : 00:00:00:30:88:13:07:8f NextEgressId : 00:00:00:00:00:00:00:00 ChassisId Subtype : NetworkAddress ChassisId : 01 0a 0d 0b 1e ManAddressDomain : snmpOther ManAddress : 0 0 0 0 0 IngressMac : 00:30:88:01:a0:74 Ingress Action : IngOk IngressPortIdSubtype : Local IngressPortId : 9/5:1023:63/1/2/18 EgressMac : 00:00:00:00:00:00 Egress Action : IngNoTlv