This table describes the default interface configuration parameters that are present when an interface is enabled on a 100-Gigabit Ethernet line card.

Note

You must use the shutdown command to bring an interface administratively down. The interface default is no shutdown . When a line card is first inserted into the router, if there is no established preconfiguration for it, the configuration manager adds a shutdown item to its configuration. This shutdown can be removed only be entering the no shutdown command.

1Gig interfaces connected through copper or fiber cable can have interface speed of either 100 Mbps or 1000 Mbps. This is applicable on 1Gig interface with a 1000Base-T module (GLC-TE). By default 1G interface has following capabilities:

• Speed—1000 Mbps for fiber cable and autonegotiate for copper cable

• Duplex—Full

• Pause—Receive Part (RX) and Transmit Part (TX)

The copper and fiber cables have same default values as mentioned above but autonegotiation is default for copper cable.

The speed can either configured or set to autonegotiate with remote end interface. When in autonegotiation mode, an interface is capable of negotiating the speed of 100 Mbps or 1000 Mbps depending on the speed at the remote end interface; and other parameters such as full duplex and pause are also autonegotiated.

Autonegotiation is an optional function of the Fast Ethernet standard that enables devices to automatically exchange information over a link about speed and duplex abilities. Autonegotiation is very useful for ports where devices with different capabilities are connected and disconnected on a regular basis.

Note	Autonegotiation is disabled by default, but it's mandatory on QSFP-100G-CUxM link. You must enable autonegotiation manually when you use 100GBASE-CR4 DAC cable.

You can configure the network interface speed by using on of the following methods:

• Using the speed command

• Using the negotiation auto command

• Using both speed and negotiation auto command

Note	It is mandatory to configure network interface speed using the speed command.

The Ethernet maximum transmission unit (MTU) is the size of the largest frame, minus the 4-byte frame check sequence (FCS), that can be transmitted on the Ethernet network. Every physical network along the destination of a packet can have a different MTU.

Cisco IOS XR software supports two types of frame forwarding processes:

• Fragmentation for IPV4 packets–In this process, IPv4 packets are fragmented as necessary to fit within the MTU of the next-hop physical network.

  Note	IPv6 does not support fragmentation.

• MTU discovery process determines largest packet size–This process is available for all IPV6 devices, and for originating IPv4 devices. In this process, the originating IP device determines the size of the largest IPv6 or IPV4 packet that can be sent without being fragmented. The largest packet is equal to the smallest MTU of any network between the IP source and the IP destination devices. If a packet is larger than the smallest MTU of all the networks in its path, that packet will be fragmented as necessary. This process ensures that the originating device does not send an IP packet that is too large.

Note	To enable hashing for L3 header only when the majority of traffic is fragmented, use the hw-module profile load-balance algorithm L3-Only command.

Jumbo frame support is automatically enable for frames that exceed the standard frame size. The default value is 1514 for standard frames and 1518 for 802.1Q tagged frames. These numbers exclude the 4-byte frame check sequence (FCS).

Following are the supported MTU properties on devices containing NC55 first generation line cards, NCS 5501, NCS5501-SE cards:

• Each physical port can have a different MTU.

• Main interface of each bundle can have one MTU value.

• L3 sub-interface (bundle or physical) shares MTU profiles and can have a maximum of 3 unique configured MTUs per NPU.

  Note	L2 sub-interface MTU is not supported.

For more information about the architecture, refer to the NCS 5500 and NCS 5700 Fixed Platform Architecture white paper.

It is possible to override the system default values for some of the mandatory LLDP Type-Length-Values (TLVs) that are advertised by routers to their directly connected neighboring devices. While advertising their identity and capabilities, routers can assign user-defined meaningful names instead of autogenerated values. Using the following CLIs you can specify these user-defined values:

• Router(config)#lldp tlv-select: Choose the wire-power management (Cisco 4-wire Power via MDI TLV or IEEE 802.3 DTE Power)

• Router(config)#lldp system-name system-name

• Router(config)#lldp system-description system-description

• Router(config)#lldp chassis-id-type chassis-type

• Router(config)#lldp chassis-id local-chassis-id

  Note	The chassis-id value is configurable only when the chassis-id-type is set as Local . If there is a mismatch, you encounter a configuration failed error message.

The configured values, such as the system name, system description, chassis-id, chassis-type become part of the TLV in the LLDP packets that are sent to its neighbors. Values are transmitted only to LLDP enabled interfaces to which the router is connected.

You can assign any of the following values for the chassis-id-type . The chassis-id-types are objects that are part of the management information base (MIB). Depending on the selected chassis-id-type, values are assigned to these objects, and they are advertised by the router to its neighboring devices.

Tip	You can programmatically modify default values of LLDP TLVs by using the openconfig-lldp OpenConfig data model. To get started with using data models, see the Programmability Configuration Guide for Cisco NCS 5500 Series Routers.

Router(config)#lldp system-name cisco-xr
Router(config)#lldp system-description cisco-xr-edge-device
Router(config)#lldp chassis-id-type local
Router(config)#lldp chassis-id ce-device9

Router#show lldp
Tue Sep 13 16:03:44.550 +0530
Global LLDP information:
Status: ACTIVE
LLDP Chassis ID: ce-device9  
LLDP Chassis ID Subtype: Locally Assigned Chassis Subtype 
LLDP System Name: cisco-xr 
LLDP advertisements are sent every 30 seconds
LLDP hold time advertised is 120 seconds
LLDP interface reinitialisation delay is 2 seconds

When you enable LLDP globally, all interfaces that support LLDP are automatically enabled for both transmit and receive operations. However, if you want to enable LLDP per interface, perform the following configuration steps:

1. RP/0/RSP0/CPU0:router(config)# int gigabitEthernet 0/2/0/0

2. RP/0/RSP0/CPU0:router(config-if)# no sh

3. RP/0/RSP0/CPU0:router(config-if)#commit

4. RP/0/RSP0/CPU0:router(config-if)#lldp ?

5. RP/0/RSP0/CPU0:router(config-if)#lldp enable

6. RP/0/RSP0/CPU0:router(config-if)#commit

Running configuration

RP/0/RSP0/CPU0:router#sh running-config  
Wed Jun 27 12:40:21.274 IST
Building configuration...
!! IOS XR Configuration 0.0.0
!! Last configuration change at Wed Jun 27 00:59:29 2018 by UNKNOWN
!
interface GigabitEthernet0/1/0/0
 shutdown
!
interface GigabitEthernet0/1/0/1
 shutdown
!
interface GigabitEthernet0/1/0/2
 shutdown
!
interface GigabitEthernet0/2/0/0
 Shutdown
!
interface GigabitEthernet0/2/0/1
 shutdown
!
interface GigabitEthernet0/2/0/2
 shutdown
!
end

Verification

Verifying the config
==================
RP/0/RSP0/CPU0:router#sh lldp interface <===== LLDP enabled only on GigEth0/2/0/0
Wed Jun 27 12:43:26.252 IST


GigabitEthernet0/2/0/0:
        Tx: enabled
        Rx: enabled
        Tx state: IDLE
        Rx state: WAIT FOR FRAME
RP/0/RSP0/CPU0:router# 

RP/0/RSP0/CPU0:router# show lldp neighbors 
Wed Jun 27 12:44:38.977 IST
Capability codes:
        (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
        (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID       Local Intf          Hold-time  Capability     Port ID
ios             Gi0/2/0/0           120        R               Gi0/2/0/0       <====== LLDP enabled only on GigEth0/2/0/0 and neighborship seen for the same.

Total entries displayed: 1

RP/0/RSP0/CPU0:router#

You can now transmit VLAN-tagged LLDP packets on the subinterfaces. When VLAN-tagged LLDP transmission is enabled either globally or at subinterface level, VLAN information is added to the Ethernet header of the constructed LLDP packet. For VLAN tagging, LLDP packet includes a TLV called the "Port VLAN ID TLV" to convey VLAN information. This TLV contains the VLAN ID associated with the port or interface of the sending device. It provides the receiving device with information about the VLAN membership of the transmitting port. With this, the devices can exchange VLAN information during LLDP discovery and facilitate the configuration and management of VLANs across the network.

The following usage guidelines and restrictions are applicable for setting the carrier delay on physical interfaces:

• You can configure carrier-delay for only link-up, only link-down, or both link-up and link-down notifications.

• If the carrier-delay down milliseconds command is configured on a physical link that fails and cannot be recovered, link down detection time increases, and it may take longer for the routing protocols to reroute the traffic around the failed link.

• If not configured, the carrier-delay up parameter defaults to 200 ms and the carrier-delay down parameter to 0 ms. When carrier-delay down is not configured, the higher-layer protocols are notified immediately when a physical link state changes.

• The carrier-delay command overwrites the previous configuration every time you execute the command. If any of the optional keywords is not explicitly configured, its default value is considered.

  For example, you already configured 500 ms for up timer and 300 ms for down timer. Later, if you want to change the up timer to 600 ms, you need to run carrier-delay up 600 down 300 command. If down keyword is not mentioned, the default value of down timer, 0 ms, would replace the previous configuration of 300 ms.

• Loss of Signal (LOS) is not supported on carrier delay.

PFC has the following restrictions:

• PFC for transmit is not supported for internal traffic (recycle / loopback) and non-unicast traffic (broadcast / multicast).

• PFC for receive impacts all traffic meant to go out of the port. This may cause unintended drops to both unicast and non-unicast traffic because non-unicast traffic may consume buffer descriptors, thus starving unicast traffic. Hence, PFC is incompatible with sustained high rate non-unicast traffic in the system.

• PFC configuration will enable or disable both PFC transmit and receive functionalities. There is no support to enable only transmit or receive functions.

• PFC is only supported in the non-HQoS profile. For more details on this QoS prerequisite and configuration examples, please refer to Modular QoS Configuration Guide for Cisco NCS 5500 Series Routers.

• Link level flow control and PFC are not supported on the same interface simultaneously.

• PFC is only qualified on 40G and 100G physical interface types. PFC is not supported on breakout ports for these interface types and is not qualified on other interface types.

• Being an Ethernet feature, PFC has to be individually configured on the member interfaces of a bundle instead of the bundle interface. The user is expected to either enable or disable PFC on all members of the bundle, as a mix isn’t supported.

• Pause frames are not counted in the interface's statistical information, and the show interfaces command displays this counter as 0. Use the show controllers Ethernet-interface-type interface-path-id command to retrieve the PFC statistics.

Use the following steps to configure Priority Flow Control:

Configuration:

RP/0/RP0/CPU0:router# configure
RP/0/RP0/CPU0:router(configure)#interface HundredGigE0/0/0/0
RP/0/RP0/CPU0:router(config)# priority-flow-control mode on

Running configuration:

*Interface Level*
interface HundredGigE0/0/0/0
priority-flow-control mode on

Verification:

Sample output for show controllers hundredGigE 0/0/0/0 priority-flow-control command is:

RP/0/RP1/CPU0:router#show controllers hundredGigE 0/0/0/0 priority-flow-control 
Mon Oct 12 12:20:53.520 UTC
 
Priority flow control information for interface HundredGigE0/0/0/0:
 
Priority Flow Control:
    Total Rx PFC Frames: 0
    Total Tx PFC Frames: 1764273
    Rx Data Frames Dropped: 0
    CoS  Status  Rx Frames   Tx Frames
    ---  ------  ----------  ----------
      0  off              0           0
      1  off              0           0
      2  off              0           0
      3  on               0      882032
      4  on               0      882241
      5  off              0           0
      6  off              0           0
      7  off              0           0
 
 
Priority flow control watchdog configuration:
(D) : Default value
U : Unconfigured
--------------------------------------------------------------------------------
       Configuration Item           Global  Interface Effective
--------------------------------------------------------------------------------
    PFC watchdog state           :        U        U  Enabled(D)
    Poll interval                :        U        U      100(D)
    Shutdown multiplier          :        U        U        1(D)
    Auto-restore multiplier      :        U        U       10(D)
 
 
Priority flow control watchdog statistics:
SAR: Auto restore and shutdown
-------------------------------------------------------------------------------------------------
Traffic Class            :       0        1        2        3        4        5        6        7 
-------------------------------------------------------------------------------------------------
Watchdog Events          :       0        0        0        0        0        0        0        0 
Shutdown Events          :       0        0        0        0        0        0        0        0 
Auto Restore Events      :       0        0        0        0        0        0        0        0 
SAR Events               :       0        0        0        0        0        0        0        0 
SAR Instantaneous Events :       0        0        0        0        0        0        0        0 
Total Dropped Packets    :       0        0        0        0        0        0        0        0 
Dropped Packets          :       0        0        0        0        0        0        0        0 
 
 
Priority flow control watchdog state machine state:
D - Disabled
M - Monitoring
S - Waiting For Shutdown
R - Waiting to Restore
--------------------------------------------------------------
PFC Watchdog      : Enabled
Watchdog SM state :  Traffic Class
                    7 6 5 4 3 2 1 0
                    - - - D D - - -
RP/0/RP1/CPU0:router#

Sample output for show controllers hundredGigE 0/0/0/0 priority-flow-control statistics command is:

RP/0/RP1/CPU0:router#show controllers hundredGigE 0/0/0/0 priority-flow-control statistics                
Mon Oct 12 12:22:39.362 UTC
 
Priority flow control information for interface HundredGigE0/0/0/0:
 
Priority Flow Control:
    Total Rx PFC Frames: 0
    Total Tx PFC Frames: 1764273
    Rx Data Frames Dropped: 0
    CoS  Status  Rx Frames   Tx Frames
    ---  ------  ----------  ----------
      0  off              0           0
      1  off              0           0
      2  off              0           0
      3  on               0      882032
      4  on               0      882241
      5  off              0           0
      6  off              0           0
      7  off              0           0

Sample output for clear controller hundredGigE 0/0/0/0 priority-flow-control statistics [traffic-class <0-7>] is:

RP/0/RP1/CPU0:router#clear controller hundredGigE 0/0/0/0 priority-flow-control statistics traffic-class 3
Mon Oct 12 12:22:48.778 UTC
RP/0/RP1/CPU0:router#show controllers hundredGigE 0/0/0/0  priority-flow-control statistics               
Mon Oct 12 12:22:51.097 UTC
 
Priority flow control information for interface HundredGigE0/0/0/0:
 
Priority Flow Control:
    Total Rx PFC Frames: 0
    Total Tx PFC Frames: 882241
    Rx Data Frames Dropped: 0
    CoS  Status  Rx Frames   Tx Frames
    ---  ------  ----------  ----------
      0  off              0           0
      1  off              0           0
      2  off              0           0
      3  on               0           0
      4  on               0      882241
      5  off              0           0
      6  off              0           0
      7  off              0           0
RP/0/RP1/CPU0:router#

The following are some of the important guidelines and restrictions related to OTN:

• OTN is only supported on the NC55-MPA-12T-S line card.

• NC55-MPA-12T-S is supported on the following 2RU Cisco NCS 5500 Series Routers:

  • NCS-55A2-MOD-S

  • NCS-55A2-MOD-SE-S

  • NCS-55A2-MOD-HX-S

  • NCS-55A2-MOD-SE-H-S

  • NCS-55A2-MOD-HD-S

• NC55-MPA-12T-S is supported in the following Modular Line cards:

  • NC55-MOD-A-S

  • NC55-MOD-A-SE-S

• OTN isn't supported on SF_BER and SD_BER.

• OTN converts 10GE LAN PHY signal (host side) into OTU1e/OTU2e signal (line side).

• Supports 10G mapping modes

• OTU2e signal operates at 11.096 Gbps, which carries 10GE LAN PHY signal. Also known as the BMP mapping

• OTU1e signal operates at 11.049 Gbps, which carries 10GE LAN PHY signal. Also known as the BMP mapping

• Supports FEC functionality in the following modes:

  • GFEC = ITU-T G.709 / G.975, OH 7%

  • EFEC = ITU-T G.975.1 (1.4), OH 7%

  • UFEC = ITU-T G.975.1 (1.7), OH 7%

• FEC EC/UNC alarms aren't reported on NC55-MPA-12T-S.

The router supports transmission of traffic in the breakout mode. The breakout mode enables a 40GbE, 100GbE, or 400GbE port to be split into multiple GbE ports.

Breakout Mode options:

• 4x10GbE

• 4x25GbE

• 2x50GbE

• 8x50GbE

• 4x100GbE

• 3x100GbE

• 2x100GbE

• 1x100GbE

Note	The supported breakout mode is dependent on the port and optic transceiver. A configuration inconsistency alarm may occur during router reload when breakout interfaces are created with ETM mode. The system automatically clears this alarm by retrying the configuration.