- play_arrow Basic CoS Configuration
- play_arrow CoS Overview
- play_arrow CoS on Interfaces
- play_arrow CoS Code-Point Aliases
- play_arrow CoS Classifiers
- Understanding CoS Classifiers
- Defining CoS BA Classifiers (DSCP, DSCP IPv6, IEEE 802.1p)
- Example: Configuring Classifiers
- Example: Configuring Unicast Classifiers
- Example: Configuring Multidestination (Multicast, Broadcast, DLF) Classifiers
- Understanding Host Inbound Traffic Classification
- Configuring a Global MPLS EXP Classifier
- Monitoring CoS Classifiers
- play_arrow CoS Rewrite Rules
- Understanding CoS Rewrite Rules
- Defining CoS Rewrite Rules
- Understanding Applying CoS Classifiers and Rewrite Rules to Interfaces
- Troubleshooting an Unexpected Rewrite Value
- Understanding CoS MPLS EXP Classifiers and Rewrite Rules
- Configuring Rewrite Rules for MPLS EXP Classifiers
- Monitoring CoS Rewrite Rules
- play_arrow CoS Forwarding Classes and Forwarding Class Sets
- Understanding CoS Forwarding Classes
- Defining CoS Forwarding Classes
- Forwarding Policy Options Overview
- Configuring CoS-Based Forwarding
- Example: Configuring CoS-Based Forwarding
- Example: Configuring Forwarding Classes
- Understanding CoS Forwarding Class Sets (Priority Groups)
- Defining CoS Forwarding Class Sets
- Example: Configuring Forwarding Class Sets
- Monitoring CoS Forwarding Classes
- play_arrow Lossless Traffic Flows, Ethernet PAUSE Flow Control, and PFC
- Understanding CoS IEEE 802.1p Priorities for Lossless Traffic Flows
- Configuring CoS PFC (Congestion Notification Profiles)
- Understanding CoS Flow Control (Ethernet PAUSE and PFC)
- Enabling and Disabling CoS Symmetric Ethernet PAUSE Flow Control
- Configuring CoS Asymmetric Ethernet PAUSE Flow Control
- Understanding PFC Functionality Across Layer 3 Interfaces
- Example: Configuring PFC Across Layer 3 Interfaces
- Understanding PFC Using DSCP at Layer 3 for Untagged Traffic
- Configuring DSCP-based PFC for Layer 3 Untagged Traffic
- play_arrow CoS and Host Outbound Traffic
-
- play_arrow Weighted Random Early Detection (WRED) and Explicit Congestion Notification (ECN)
- play_arrow WRED and Drop Profiles
- play_arrow Explicit Congestion Notification (ECN)
-
- play_arrow CoS Queue Schedulers, Traffic Control Profiles, and Hierarchical Port Scheduling (ETS)
- play_arrow Queue Schedulers and Scheduling Priority
- Understanding Default CoS Scheduling and Classification
- Understanding CoS Scheduling Behavior and Configuration Considerations
- Understanding CoS Output Queue Schedulers
- Defining CoS Queue Schedulers
- Example: Configuring Queue Schedulers
- Defining CoS Queue Scheduling Priority
- Example: Configuring Queue Scheduling Priority
- Monitoring CoS Scheduler Maps
- play_arrow Port Scheduling and Shaping
- play_arrow Troubleshooting Egress Bandwidth Issues
- play_arrow Traffic Control Profiles and Priority Group Scheduling
- Understanding CoS Traffic Control Profiles
- Understanding CoS Priority Group Scheduling
- Understanding CoS Virtual Output Queues (VOQs)
- Defining CoS Traffic Control Profiles (Priority Group Scheduling)
- Example: Configuring Traffic Control Profiles (Priority Group Scheduling)
- Understanding CoS Priority Group and Queue Guaranteed Minimum Bandwidth
- Example: Configuring Minimum Guaranteed Output Bandwidth
- Understanding CoS Priority Group Shaping and Queue Shaping (Maximum Bandwidth)
- Example: Configuring Maximum Output Bandwidth
- play_arrow Hierarchical Port Scheduling (ETS)
-
- play_arrow CoS Buffers and the Shared Buffer Pool
- play_arrow CoS Buffers Overview
- play_arrow Shared Buffer Pool Examples
- Example: Recommended Configuration of the Shared Buffer Pool for Networks with Mostly Best-Effort Unicast Traffic
- Example: Recommended Configuration of the Shared Buffer Pool for Networks with Mostly Best-Effort Traffic on Links with Ethernet PAUSE Enabled
- Example: Recommended Configuration of the Shared Buffer Pool for Networks with Mostly Multicast Traffic
- Example: Recommended Configuration of the Shared Buffer Pool for Networks with Mostly Lossless Traffic
-
- play_arrow CoS on EVPN VXLANs
- play_arrow Configuration Statements and Operational Commands
Configuring DCBX Autonegotiation
Data Center Bridging Capability Exchange protocol (DCBX) discovers the data center bridging (DCB) capabilities of peers by exchanging feature configuration information. DCBX also detects feature misconfiguration and mismatches, and can configure DCB on peers. DCBX is an extension of the Link Layer Discovery Protocol (LLDP), and LLDP must remain enabled on every interface for which you want to use DCBX. If you attempt to enable DCBX on an interface on which LLDP is disabled, the configuration commit operation fails.
LLDP and DCBX are enabled by default on all interfaces.
The switch supports DCBX autonegotiation for:
Priority-based flow control (PFC) configuration
Layer 2 and Layer 4 applications such as Fibre Channel over Ethernet (FCoE) and Internet Small Computer System Interface (iSCSI)
Enhanced transmission selection (ETS) advertisement
DCBX autonegotiation is configured on a per-interface basis for each supported feature or application. The PFC and application DCBX exchanges use autonegotiation by default. The default autonegotiation behavior is:
DCBX is enabled on the interface if the connected peer device also supports DCBX.
DCBX is disabled on the interface if the connected peer device does not support DCBX.
You can override the default behavior for each feature by turning off autonegotiation to force an interface to enable or disable the feature.
Autonegotiation of ETS means that when ETS is enabled on an interface (priority groups are configured), the interface advertises its ETS configuration to the peer device. In this case, priorities (forwarding classes) that are not part of a priority group (forwarding class set) receive no bandwidth and are advertised in an automatically generated default forwarding class. If ETS is not enabled on an interface (no priority groups are configured), all of the priorities are advertised in one automatically generated default priority group that receives 100 percent of the port bandwidth.
Disabling ETS autonegotiation prevents the interface from sending the Recommendation TLV or the Configuration TLV to the connected peer.
On interfaces that use IEEE DCBX mode to exchange DCBX parameters, you can disable autonegotiation of the ETS Recommendation TLV to the peer if you want an asymmetric ETS configuration between the peers. DCBX still exchanges the ETS Configuration TLV if you disable the ETS Recommendation TLV.
Autonegotiation of PFC means that when PFC is enabled on an interface, if the peer device connected to the interface supports PFC and is provisioned compatibly with the switch, DCBX sets the PFC operational state to enabled. If the peer device connected to the interface does not support PFC or is not provisioned compatibly with the switch, DCBX sets the operational state to disabled.
In addition, if the peer advertises that it is “willing” to learn its PFC configuration from the switch, DCBX pushes the switch’s PFC configuration to the peer and does not check the peer’s administrative state. The switch does not learn PFC configuration from peers (the switch does not advertise its state as “willing”).
Disabling PFC autonegotiation prevents the interface from exchanging PFC configuration information with the peer. It forces the interface to enable PFC if PFC is configured on the interface or to disable PFC if PFC is not configured on the interface. If you disable PFC autonegotiation, the assumption is that the peer is also configured manually.
Autonegotiation of applications depends on whether or not you apply an application map to an interface. If you apply an application map to an interface, the interface autonegotiates DCBX for each application in the application map. PFC must be enabled on the FCoE priority (the FCoE IEEE 802.1p code point) for the interface to advertise the FCoE application. The interface only advertises applications that are included in the application map.
For example, if you apply an application map to an interface and the application map does not include the FCoE application, then that interface does not perform DCBX advertisement of FCoE.
If you do not apply an application map to an interface, DCBX does not advertise applications on that interface, with the exception of FCoE, which is handled differently than other applications.
If you do not apply an application map to an interface, the interface performs autonegotiation of FCoE if the interface carries traffic in the FCoE forwarding class and also has PFC enabled on the FCoE priority. On such interfaces, if DCBX detects that the peer device connected to the interface supports FCoE, the switch advertises its FCoE capability and IEEE 802.1p code point on that interface. If DCBX detects that the peer device connected to the interface does not support FCoE, DCBX marks that interface as “FCoE down” and disables FCoE on the interface.
When DCBX marks an interface as “FCoE down,” the behavior of the switch depends on how you use it in the network:
When the switch acts as an FCoE transit switch, the interface drops all of the FIP packets it receives. In addition, FIP packets received from an FCoE forwarder (FCF) are not forwarded to interfaces marked as “FCoE down.”
When the switch acts as an FCoE-FC gateway (only switches that support native Fibre Channel interfaces), it does not send or receive FCoE Initialization Protocol (FIP) packets.
Disabling autonegotiation prevents the interface from exchanging application information with the peer. In this case, the assumption is that the peer is also configured manually.
To disable DCBX autonegotiation of PFC, applications (including FCoE), and ETS using the CLI:
To disable autonegotiation of the ETS Recommendation TLV so that DCBX exchanges only the ETS Configuration TLV:
- content_copy zoom_out_map
[edit protocols dcbx interface interface-name] user@switch# set enhanced-transmission-selection no-recommendation-tlv
