Ports

Nokia routers support port-based network access control for Ethernet ports only. Every Ethernet port can be configured to operate in one of three different operation modes, controlled by the port-control parameter:

• force-auth

  This mode disables 802.1x authentication and causes the port to transition to the authorized state without requiring any authentication exchange. The port transmits and receives normal traffic without requiring 802.1x-based host authentication. This is the default setting.

• force-unauth

  This mode causes the port to remain in the unauthorized state, ignoring all attempts by the hosts to authenticate. The switch cannot provide authentication services to the host through the interface.

• auto

  This mode enables 802.1x authentication. The port starts in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. Both the router and the host can initiate an authentication procedure as described below. The port remains in unauthorized state (no traffic except EAPOL frames is allowed) until the first client is authenticated successfully. After this, traffic is allowed on the port for all connected hosts.

The IEEE 802.1x standard defines three participants in an authentication conversation (see 802.1x architecture that shows an example with the 7450 ESS).

the supplicant

the end-user device that requests access to the network

the authenticator

controls access to the network. Both the supplicant and the authenticator are referred to as Port Authentication Entities (PAEs).

the authentication server

performs the actual processing of the user information

The authentication exchange is carried out between the supplicant and the authentication server, the authenticator acts only as a bridge. The communication between the supplicant and the authenticator is done through the Extended Authentication Protocol (EAP) over LANs (EAPOL). On the back end, the communication between the authenticator and the authentication server is done with the RADIUS protocol. The authenticator is therefore a RADIUS client, and the authentication server a RADIUS server.

The messages involved in the authentication procedure are shown in 802.1x authentication scenario. The router initiates the procedure when the Ethernet port becomes operationally up, by sending a special PDU called EAP-Request/ID to the client. The client can also initiate the exchange by sending an EAPOL-start PDU, if it does not receive the EAP-Request/ID frame during bootup. The client responds on the EAP-Request/ID with a EAP-Response/ID frame, containing its identity (typically username + password).

After receiving the EAP-Response/ID frame, the router encapsulates the identity information into a RADIUS AccessRequest packet, and sends it off to the configured RADIUS server.

The RADIUS server checks the supplied credentials, and if approved returns an Access Accept message to the router. The router notifies the client with an EAP-Success PDU and puts the port in authorized state.

The 802.1x authentication procedure is controlled by a number of configurable timers and scalars. There are two separate sets, one for the EAPOL message exchange and one for the RADIUS message exchange. See 802.1x EAPOL timers (left) and RADIUS timers (right) for an example of the timers on the 7750 SR.

EAPOL timers:

• transmit-period

  This timer indicates how many seconds the Authenticator listens for an EAP-Response/ID frame. If the timer expires, a new EAP-Request/ID frame is sent and the timer restarted. The default value is 60. The range is 1 to 3600 seconds.

• supplicant-timeout

  This timer is started at the beginning of a new authentication procedure (transmission of first EAP-Request/ID frame). If the timer expires before an EAP-Response/ID frame is received, the 802.1x authentication session is considered as having failed. The default value is 30. The range is 1 to 300.

• quiet-period

  This timer indicates number of seconds between authentication sessions. It is started after logout, after sending an EAP-Failure message or after expiry of the supplicant-timeout timer. The default value is 60. The range is 1 to 3600.

RADIUS timer and scalar:

• max-auth-req

  This scalar indicates the maximum number of times that the router sends an authentication request to the RADIUS server before the procedure is considered as having failed. The default value is value 2. The range is 1 to 10.

• server-timeout

  This timer indicates how many seconds the authenticator waits for a RADIUS response message. If the timer expires, the access request message is sent again, up to max-auth-req times. The default value is 60. The range is 1 to 3600 seconds.

The router can also be configured to periodically trigger the authentication procedure automatically. This is controlled by the enable re-authentication and re-auth-period parameters. Reauth-period indicates the period in seconds (since the last time that the authorization state was confirmed) before a new authentication procedure is started. The range of reauth-period is 1 to 9000 seconds (the default is 3600 seconds, one hour). Note that the port stays in an authorized state during the re-authentication procedure.

Tunneling of untagged 802.1x frames received on a port is supported for both Epipe and VPLS service using either null or default SAPs (for example 1/1/1:*) when the config>port>ethernet>dot1x port-control is set to force-auth.

When tunneling is enabled on a port (using the command configure port port-id ethernet dot1x tunneling), untagged 802.1x frames are treated like user frames and are switched into Epipe or VPLS services which have a corresponding null SAP or default SAP on that port. In the case of a default SAP, it is possible that other non-default SAPs are also present on the port. Untagged 802.1x frames received on other service types, or on network ports, are dropped.

When tunneling is required, it is expected that it is enabled on all ports into which 802.1x frames are to be received. The configuration of dot1x must be configured consistently across all ports in LAG as this is not enforced by the system.

Note that 802.1x frames are treated like user frames, that is, tunneled, by default when received on a spoke or mesh SDP.

Per-host authentication enables SR OS to authenticate each host individually and allows or disallows the PDUs from this host through the port. Per-host authentication is configurable using the CLI.

When dot1x tunneling is disabled, the port does not allow any PDUs to pass through, with the exception of dot1x packets, which are extracted.

When per-host-authentication is configured on the port for dot1x, each host is authenticated individually according to the RADIUS policy and host traffic is allowed or disallowed through the port. After the first successful host authentication, the behavior is the following:

• On downstream (that is, traffic from the network to the host), the port is authorized and allows all traffic to go through.

• On upstream (that is, traffic from the host to the network), the port is authorized, but allows only traffic from the authenticated hosts. When a host is allowed through the port, all of the PDUs for that host are allowed to pass through the port, including untagged or tagged packets. The traffic from any unauthenticated host is disallowed.

For per-host authentication, EAPOL packets are sent to the RADIUS server using the RADIUS protocol. The calling station identifier is the source MAC address of the host and is usually present in the packet. The identifier is used to allow or disallow the host source MAC address based on the RADIUS success or failure answer.

The hosts are authenticated periodically. If a host is authenticated and placed on the allow list and a subsequent authentication fails, that host is removed from the allow list.

If a host authenticates unsuccessfully multiple times, that host is put on a disallow list for a specific amount of time. That is, enabling per-host authentication provides per-host (source MAC) DoS mitigation.

Duplicate MAC addresses are not allowed on the port.

All logs display per-host authentication.

Configuration of 802.1x network access control on the router consists of two parts:

• generic parameters, which are configured under config>system>security>dot1x

• port-specific parameters, which are configured under config>port>ethernet>dot1x

The following considerations apply:

• If per-host authentication is not configured, the authentication of any host on the port provides access to the port for any device, even if only a single client has been authenticated.
• 802.1x authentication can only be used to gain access to a pre-defined Service Access Point (SAP). It is not possible to dynamically select a service (such as a VPLS service) depending on the 802.1x authentication information.
• If 802.1x access control is enabled and a high rate of 802.1x frames are received on a port, that port is blocked for a period of 5 minutes as a DoS protection mechanism.

The MACsec 802.1AE header includes a security TAG (SecTAG) field that contains the following:

• association number within the channel

• packet number to provide a unique initialization vector for encryption and authentication algorithms as well as protection against replay attack

• optional LAN-Wide secure channel identifier

The security field, which is identified by the MACsec Ethertype, conveys the following information:

• TAG Control Information (TCI)

• Association Number (AN)

• Short Length (SL)

• Packet Number (PN)

• Optionally-encoded Secure Channel Identifier (SCI)

SecTAG format shows the format of the SecTAG.

There are two main modes of encryption in MACsec:

• VLAN in clear text (WAN Mode)

• VLAN encrypted

802.1AE dictates that the 802.1Q VLAN needs to be encrypted. Some vendors give the option of configuring the MACsec on a port with VLAN in clear text.

SR OS supports both modes. On the 7750 SR and 7450 ESS, 1/10 Gig cards support both mode of operation.

802.1 AE LAN and WAN modes and VLAN encrypted/clear shows the VLAN encrypted and VLAN in clear.

There are four main, key management modes in MACsec. MACsec key management modes describes these management modes.

MACsec concepts for static-CAK illustrates some of the main concepts used in MACsec for the static-CAK scenario.

MACsec terms describes the MACsec terminology.

MACsec uses SAs for encryption of packets. SA is a security relationship that provides security guarantees for frames transmitted from one member of a CA to the others. Each SA contains a single secret key (SAK) where the cryptographic operations used to encrypt the datapath PDUs.

SAK is the secret key used by an SA to encrypt the channel.

When enabled, MACsec uses a static CAK security mode. Two security keys, a connectivity association key (CAK) that secures control plane traffic and a randomly-generated secure association key (SAK) that secures data plane traffic are used to secure the point-to-point or point-to-multipoint Ethernet link. Both keys are regularly exchanged between both devices on each end of the Ethernet link to ensure link security.

MACsec generating the CAK illustrates MACsec generating the CAK.

The node initially needs to secure the control plane communication to distribute the SAKs between two or more members of a CA domain.

The securing of control plane is done via CAK. To generate the CAK, there are two main methods:

• EAPoL (SR OS does not support EAPoL)

• pre shared key (CAK and CKN values are configured manually via CLI). The following CAK and CKN rules apply.

  • CAK is a 32 hexadecimal characters for 128-bit key and 64 hexadecimal characters for 256-bit key depending on which algorithm is used for control plane encryption (for example, aes-128-cmac or aes-256-cmac).

  • CKN is a 32 octets char (64 hex) and it is the connectivity association key name which identifies the CAK. This allows each of the MKA participants to select which CAK to use to process a received MKPDU. MKA places no restriction on the format of the CKN, except that it must comprise an integral number of octets, between 1 and 32 (inclusive), and that all potential members of the CA use the same CKN.

  • CKN and CAK must match on peers to create a MACsec Secure CA.

MACsec control plane and encryption illustrates the MACsec control plane authentication and encryption.

After the CAK is generated, it can obtain two other keys. These keys are:

Key Encryption Key (KEK)

used to wrap and encrypt the SAKs

Integrity Connection Value (ICV) Key (ICK)

used for an integrity check of each MKPDU sent between two CAs

The key server then creates a SAK, that is shared with the CAs of the security domain, and that SAK secures all data traffic traversing the link. The key server continues to periodically create and share a randomly-created SAK over the point-to-point link for as long as MACsec is enabled.

The SAK is encrypted via the AES-CMAC, the KEK as encryption key, and ICK as integration key.

SR OS regenerates the SAK after the following events:

• when a new host has joined the CA domain and MKA hellos are received from this host

• when the sliding window is reaching the end of its 32-bit or 64-bit length

• when a new PSK is configured and a rollover of PSK has been executed

Each MACsec peer operates the MACsec Key Agreement Protocol (MKA). Each node can operate multiple MKAs based on the number of CA to which the node belongs. Each MKA instance is protected by a distinct secure connectivity Association key (CAK), that allows each PAE to ensure that information for a specific MKA instance is only accepted from other peer that also possess that CAK, and therefore identifying the peers as members or potential members of the same CA. See MACsec static CAK for information about the CAK identification process done via CKN.

A peer may support the use of one or more pre-shared keys (PSKs). An instance of MKA operates for each PSK that is administratively configured as active.

A pre-shared key may be created by NSP, or entered in CLI manually.

Each PSK is configured with two fields. The two fields are:

• CKN (connectivity association name)

• CAK value

The CAK name (CKN) is required to be unique per port among the configured sub-ports, and can be used to identify the key in subsequent management operations.

Each static CAK configuration can have two pre-shared key entries for rollover. The active PSK index dictates the CAK that is used for encrypting the MKA PDUs.

NSP has additional functionality to roll over and configure the PSK. The rollover via NSP can be based on a configured timer.

MKA uses a member identifier (MI) to identify each node in the CA domain.

A participant proves liveness to each of its peers by including their MI, together with an acceptably-recent message number (MN), in an MKPDU.

To avoid a new participant having to respond to each MKPDU from each partner as it is received, or trying to delay its reply until it is likely that MI MN tuples have been received from all potential partners, each participant maintains and advertises both of the following:

• live peers list

  This list includes all the peers that have included the participant's MI and a recent MN in a recent MKPDU.

• potential peers list

  This list includes all the other peers that have transmitted an MKPDU that has been directly received by the participant or that were included in the Live Peers List of a MKPDU transmitted by a peer that has proved liveness.

Peers are removed from each list when an interval of between MKA Life Time and MKA Life Time plus MKA Hello Time has elapsed since the participant's recent MN was transmitted. This time is sufficient to ensure that two or more MKPDUs are lost or delayed before the incorrect removal of a live peer.

MKA participant timer values describes the MKA participant timer values used on SR OS.

802.1x-2010 had identified two fields in the MKA PDU. Those fields are:

• MACsec Capability

• Desire

MACsec Capability signals weather MACsec is capable of integrity and confidentiality. MACsec basic settings describes the four basic settings for MACsec Capability.

An encryption offset of 0, 30, or 50 starts from the byte after the SecTAG (802.1ae header). Ideally, the encryption offset should be configured for IPv4 (offset 30) and IPv6 (offset 50) to leave the IP header in the clear text. This allows routers and switches to use the IP header for LAG or ECMP hashing.

The participants, in an MKA instance agree on a Key Server, are responsible for the following:

• deciding on the use of MACsec

• cipher suite selection

• SAK generation and distribution

• SA assignment

• identifying the CA when two or more CAs merge

Each participant in an MKA instance uses the Key Server priority (an 8-bit integer) encoded in each MKPDU to agree on the Key Server. Each participant selects the live participant advertising the highest priority as its Key Server whenever the Live Peers List changes, provided that highest priority participant has not selected another as its Key Server or is unwilling to act as the Key Server. If a Key Server cannot be selected, SAKs are not distributed. In the event of a tie for highest priority Key Server, the member with the highest priority SCI is chosen. For consistency with other uses of the SCI's MAC address component as a priority, numerically lower values of the Key Server Priority and SCI are accorded the highest priority.

Each MACsec device supports 64 TX-SAs and 64 RX-SAs. An SA (Security Association) is the key to encrypt or decrypt the data.

In accordance with the IEEE 802.1AE standard, each SecY contains a SC. An SC is a unidirectional concept; for example, Rx-SC or Tx-SC. Each SC contains at least one SA for encryption on Tx-SC and decryption on Rx-SC. Also, for extra security, each SC should be able to roll over the SA. Nokia recommends that each SC should have two SAs for rollover purposes.

Each MACsec phy, referred to as a MACsec security zone, supports 64Tx-SAs and 64 RX-SAs. Assuming two SAs per SC for SA rollover, then each security zone supports 32 RX-SC and 32 TX-SC.

Port mapping to security zone describes the port mapping to security zones.

In a point-to-point topology, each router needs a single security zone and single Tx-SC for encryption and a single Rx-SC for decryption. Each SC has two SAs. In total for point-to-point topology, four SAs are needed, two RxSA for RxSC1 and two TXSA for TxSC1. See Switch point to switch point topology.

In a multipoint topology with N nodes, each node needs a single TxSC and N RxSC, one for each one of the peers. As such, 64 max RX-SA per security zone translates to 32 Rx-SCs, which breaks down to only 32 peers (for example, only 33 nodes in the multipoint topology per security zone, from each node perspective there is one TxSC and 32 RxSC).

In Switch multi-point to switch multi-point topology, when the 34rd node joins the multi-point topology, all other 33 nodes that are already part of this domain do not have any SAs to create an RxSC for this 34th node. However, the 34th node has a TxSC and accepts 32 peers. The 34th node starts to transmit and encrypt the PDUs based on its TxSC. However, because all other nodes do not have a SC for this SAI, they drop all Rx PDUs.

It is recommended to ensure that a multicast domain, for a single security zone, does not exceed 32 peers or the summation of all the nodes, in a security zone's CA domain, do not exceed 33. This is the same is if a security zone has four CAs, the summation of all nodes in the four CAs should be 33 or less.

In SA limits and network design, it was described that a security zone has 64 RxSAs and 64 TxSAs. Two RxSAs are used for each RxSC for rollover purposes and two TxSAs are used for TxSC for rollover purposes. This translates to 32 peers per security zone.

Under each port, a max-peer parameter can be configured. This parameter assigns the number of peers allowed on that port.

In most Layer 2 networks, MAC forwarding is done via destination MAC address. The 802.1AE standard dictates that any field after source and destination MAC address and after the SecTAG is required to be encrypted. This includes the 802.1Q tags. In some VLAN switching networks, it may be needed to leave the 802.1Q tag in clear text.

SR OS supports the configuration of 802.1Q tag, in clear text, by placing the 802.1Q tag before the SecTAG or encrypted, by placing it after the SecTAG.

MACsec encryption of 802.1Q tags with clear-tag configured lists the MACsec encryption of 802.1Q tags when the clear-tag is configured on SR OS.

MACsec is an Ethernet packet and, as with any other Ethernet packet, can be forwarded through multiple switches via Layer 2 forwarding. The encryption and decryption of the packets is performed via the 802.1x (MKA) capable ports.

To ensure that MKA is not terminated on any intermediate switch or router, the user can enable 802.1x tunneling on the corresponding port.

An example check to see if tunneling is enabled, is provided below.

*A:SwSim28>config>port>ethernet>dot1x# info 
----------------------------------------------
      tunneling

By enabling tunneling, the 802.1X MKA packets transit the port, without being terminated, therefore MKA negotiation does not occur on a port that has 802.1X tunneling enabled.

The MKA packets are transported over EAPoL with a multicast destination MAC address. At some point, it may be needed to have the MKA have a point-to-point connection to a peer node over a Layer 2 multihop cloud. In this case, the EAPoL destination MAC address can be set to the peer MAC address. This forces the MKA to traverse multiple nodes and establish an MKA session with the specific peer.

Mirroring is performed before the MACsec encryption engine. Therefore, if a port is MACsec-enabled and also, that port is mirrored, all the mirrored packets are in cleartext.

APS can operate in a single chassis configuration (SC-APS) or in a multi-chassis configuration (MC-APS).

An SC-APS group can span multiple ports, MDAs or IOMs within a single node whereas as MC-APS can span two separate nodes as shown in SC-APS versus MC-APS protection.

The support of SC-APS and MC-APS depends on switching modes, MDAs, port types and encaps. For a definitive description of the MDAs, port types, switching modes, bundles and encapsulations supported with APS, see APS applicability, restrictions, and interactions.

APS behavior and operation differs based on the switching mode configured for the APS group as shown in APS switching modes. Several switching modes are supported in the router.

The switching mode affects how the two directions of a link behave during failure scenarios and how APS tx operates.

Unidirectional / Bidirectional configuration must be the same at both sides of the APS group. The APS protocol (K byte messages) exchange switching mode information to ensure that both nodes can detect a configuration mismatch.

• If one end of an APS group is configured in a Unidirectional mode (Uni 1+1 Sig APS or Uni 1+1 Sig+Data APS) then the other end must also be configured in a Unidirectional mode (Uni 1+1 Sig+Data APS).

• If one end of an APS group is configured in a Bidirectional mode then the other end must also be configured in Bidirectional mode.

  Table 12. APS switching modes

  	Bidirectional 1+1 signaling APS	Unidirectional 1+1 signaling APS	Unidirectional 1+1 signaling and datapath APS
  Short form name	Bidir 1+1 Sig APS	Uni 1+1 Sig APS	Uni 1+1 Sig+Data APS
  CLI	bidirectional	unidirectional	uni-1plus1
  Interworks with a standards compliant APS implementation	Yes	Yes	Yes
  Full 1+1 APS standards-based signaling	Yes	Yes	Yes
  Data is transmitted simultaneously on both links/circuits (1+1 Data)	No	No	Yes

The support of switching modes depends on SC-APS/MC-APS, MDAs, port types and encaps. For a definitive description of the MDAs, port types, switching modes, bundles and encapsulations supported with APS, see APS applicability, restrictions, and interactions.

The APS channel (bytes K1 and K2 in the SONET header) exchanges APS protocol messages for all APS modes.

The APS implementation also provides the revertive and non-revertive modes with non-revertive switching as the default option. In revertive switching, the activity is switched back to the working port after the working line has recovered from a failure (or the manual switch is cleared). In non-revertive switching, a switch to the protection line is maintained even after the working line has recovered from a failure (or if the manual switch is cleared).

A revert-time is defined for revertive switching so frequent automatic switches as a result of intermittent failures are prevented. A change in this value takes effect upon the next initiation of the wait to restore (WTR) timer. It does not modify the length of a WTR timer that has already been started. The WTR timer of a non-revertive switch can be assumed to be infinite.

In case of failure on both working and the protection line, the line that has less severe errors on the line is active at any point in time. If there is signal degrade on both ports, the active port that failed last stays active. When there is signal failure on both ports, the working port is always active. The reason is that the signal failure on the protection line is of a higher priority than on the working line.

Actions for the bidirectional protection switching process describes the steps that a bidirectional protection switching process goes through during a typical automatic switchover.

Operation and behavior conferment with Annex B of ITU.T G.841 can be configured for an APS group. Characteristics of this mode include are the following:

• Annex B operates in non-revertive bidirectional switching mode only as defined in G.841.

• Annex B operates with 1+1 signaling, but 1:1 datapath whereby data is transmitted on the active link only.

• K bytes are transmitted on both circuits.

Because the request/reverse-request nature of an Annex B switchover, the data outage is longer than a typical (non Annex B single chassis) APS switchover. Nokia recommends using maintenance commands under the tools>perform>aps context for planned switchovers (not MDA or IOM shutdown) to minimize the outage.

APS prevents upper layer protocols and services from being affected by the failure of the active circuit.

The following example with figures and description illustrate how services are protected during a single-chassis APS switchover.

APS working and protection circuit example shows an example in which the APS working circuit is connected to IOM-1/MDA-1 and the protection circuit is connected to IOM-2/MDA-1. In this example, assume that the working circuit is currently used to transmit and receive data.

The following subsections describe APS user-initiated requests.

SNMP Management of APS uses the APS-MIB (from rfc3498) and the TIMETRA-APS-MIB.

Switching mode to MIB mapping shows the mapping between APS switching modes and MIB objects.

apsConfigMode in the APS-MIB is set to onePlusOneOptimized for Annex B operation.

Supported APS mode combinations shows the supported APS mode combinations.

The following subsections provide APS application examples.

LLDP is a unidirectional protocol that uses the MAC layer to transmit specific information related to the capabilities and status of the local device. Separately from the transmit direction, the LLDP agent can also receive the same kind of information for a remote device which is stored in the related MIBs.

LLDP itself does not contain a mechanism for soliciting specific information from other LLDP agents, nor does it provide a specific means of confirming the receipt of information. LLDP allows the transmitter and the receiver to be separately enabled, making it possible to configure an implementation so the local LLDP agent can either transmit only or receive only, or can transmit and receive LLDP information.

The information fields in each LLDP frame are contained in an LLDP Data Unit (LLDPDU) as a sequence of variable length information elements, that each include type, length, and value fields (known as TLVs), where:

• Type identifies what kind of information is being sent.

• Length indicates the length of the information string in octets.

• Value is the actual information that needs to be sent (for example, a binary bit map or an alphanumeric string that can contain one or more fields).

Each LLDPDU contains four mandatory TLVs and can contain optional TLVs as selected by network management:

• Chassis ID TLV

• Port ID TLV

• Time To Live TLV

• Zero or more optional TLVs, as allowed by the maximum size of the LLDPDU

• End Of LLDPDU TLV

The chassis ID and the port ID values are concatenated to form a logical identifier that is used by the recipient to identify the sending LLDP agent/port. Both the chassis ID and port ID values can be defined in a number of convenient forms. After selected however, the chassis ID/port ID value combination remains the same as long as the particular port remains operable.

A non-zero value in the TTL field of the Time To Live TLV tells the receiving LLDP agent how long all information pertaining to this LLDPDU’s identifier is valid so that all the associated information can later be automatically discarded by the receiving LLDP agent if the sender fails to update it in a timely manner. A zero value indicates that any information pertaining to this LLDPDU’s identifier is to be discarded immediately.

A TTL value of zero can be used, for example, to signal that the sending port has initiated a port shutdown procedure. The End Of LLDPDU TLV marks the end of the LLDPDU.

The implementation defaults to setting the port-id field in the LLDP OAMPDU to tx-local. This encodes the port-id field as ifIndex (sub-type 7) of the associated port. Some network management systems use the ifIndex value to properly build the Layer Two Topology Network Map. However, this numerical value is difficult to interpret or readily identify the LLDP peer. Configuration options are available to control the encoding of the port-id information and the associated subtype using the port-id-subtype option. Three options are supported for the port-id-subtype:

tx-if-alias

transmits the ifAlias String (subtype 1) that describes the port as stored in the IF-MIB, either user configured description or the default entry (10/100/Gig Ethernet SFP)

tx-if-name

transmits the ifName string (subtype 5) that describes the port as stored in the IF-MIB, ifName info

tx-local

the interface ifIndex value (subtype 7)

IPv6 (address subtype 2) and IPv4 (address subtype 1) LLDP System Management addresses are supported. The IP addresses can be selected from the system IP addressing, the out-of-band management address (BOF), or both.

If the port-desc TLV is enabled it has a maximum of 255 byte limit. However, truncation of the port description information occurs if the combination of the port-id and the ifDesc (for example 1/1/c1/2, 10-Gig Ethernet) exceeds the 255 byte maximum. The truncation of the port description information is equal to the number of bytes required to include the ifDesc.