Information About Fibre Channel Interfaces
Virtual Fibre Channel Interfaces
Fibre Channel over Ethernet (FCoE) encapsulation allows a physical Ethernet cable to simultaneously carry Fibre Channel and Ethernet traffic. In Cisco Nexus devices, an FCoE-capable physical Ethernet interface can carry traffic for one virtual Fibre Channel (vFC) interface.
Like any interface in Cisco NX-OS, vFC interfaces are manipulable objects with properties such as configuration and state. Native Fibre Channel and vFC interfaces are configured using the same CLI commands.
The following capabilities are not supported for virtual Fibre Channel interfaces:
-
SAN port channels.
-
The SPAN destination cannot be a vFC interface.
-
Buffer-to-buffer credits.
-
Exchange link parameters (ELP).
-
Configuration of physical attributes (speed, rate, mode, transmitter information, MTU size).
-
Port tracking.
VF Port
vFC interfaces always operate in trunk mode; vFC interfaces do not operate in any other mode. You can configure allowed VSANs on a vFC by using the switchport trunk allowed vsan command under the vfc interface (which is similar to FC TF and TE ports). For vFC interfaces that are connected to hosts, port VSAN is the only VSAN that supports logins (FLOGI). We recommend that you restrict the allowed VSANs for such vFC interfaces to the port VSAN by using the switchport trunk allowed vsan command in the interface mode to configure a VF port.
Includes support for 160 vFC interfaces.
The vFC VSAN assignment and the global VLAN-to-VSAN mapping table enables the Cisco Nexus device to choose the appropriate VLAN for a VF port.
VE Ports
A virtual E port (VE port) is a port that emulates an E port over a non-Fibre Channel link. VE port connectivity between Fibre Channel Forwarders (FCFs) is supported over point-to-point links. These links can be individual Ethernet interfaces or members of an Ethernet port-channel interface. For each of the FCF connected Ethernet interfaces, you must create and bind an vFC interface to the Ethernet interface. Configure vFC interfaces as VE ports by using the switchport mode E command in interface mode.
VE ports have the following guidelines:
-
Auto mode on the vFC is not supported.
-
VE Port trunking is supported over FCoE-enabled VLANs.
-
VE Port interface binding to MAC addresses is not supported.
-
By default the VE Port is enabled for trunk mode.
You can configure multiple VSANs on the VE port. You must configure the FCoE VLANs that correspond to the VE port’s VSANs on the bound Ethernet interface.
-
The Spanning Tree Protocol is disabled on the FCoE VLANs on any interface that a vFC interface is bound to, which includes the interfaces that the VE ports are bound to.
The number of VE port pairs that can be supported between a given FCF and a peer FCF depends on the FCF-MAC advertising capability of the peer FCF:
-
If a peer FCF advertises the same FCF-MAC address over all its interfaces, the FCF can connect to it over one VE port. In such a topology, we recommended that you use one port-channel interface for redundancy.
-
If a peer FCF advertises multiple FCF-MAC addresses, the limits in the VE Port Configuration Limits table are applicable.
VE Ports in a vPC Topology
VE ports in a vPC topology have the following guidelines:
-
Dedicated links are required for FCoE VLANs between FCFs connected over a vPC for LAN traffic.
-
FCoE VLANs must not be configured on the inter-switch vPC interfaces.
-
VE port can get flapped during congestion if FCoE payload size is larger than 2112.
FSPF Parameters
FSPF operates on a per-VSAN basis over a VE port once it is brought up on the VSAN. The default FSPF cost (metric) of the vFC interface is as per 10-Gbps bandwidth. For VE ports that are bound to Ethernet port channels, the cost is adjusted based on the number of operational member ports.
VE Port Configuration Limits
Interface Type | Platform | ||||
---|---|---|---|---|---|
N9K-C9336C-FX2-E | N9K-C93360YC-FX2 | N9K-C93180YC-FX | FEX | ||
vFC (VE and VF) Port that is bound to an Ethernet Port-Channel Interface |
8 (max limit) |
8 (max limit) |
8 (max limit) |
Not supported |
Interface Modes
Each physical Fibre Channel interface in a switch may operate in one of several port modes: E mode, TE mode, F mode, and TF mode. A physical Fibre Channel interface can be configured as an E port or an F port, an F port, or an SD port. Interfaces may also be configured in Auto mode; the port type is determined during interface initialization.
Fibre Channel interfaces may operate in E mode or an F mode.
Virtual Fibre Channel interfaces can be configured in E mode or F mode.
Interfaces are automatically assigned VSAN 1 by default.
Each interface has an associated administrative configuration and an operational status:
-
The administrative configuration does not change unless you modify it. This configuration has various attributes that you can configure in administrative mode.
-
The operational status represents the current status of a specified attribute such as the interface speed. This status cannot be changed and is read-only. Some values may not be valid when the interface is down (for example, the operational speed).
E Port
In expansion port (E port) mode, an interface functions as a fabric expansion port. This port may be connected to another E port to create an Inter-Switch Link (ISL) between two switches. E ports carry frames between switches for configuration and fabric management. They serve as a conduit between switches for frames destined to remote N ports. E ports support class 3 and class F service.
An E port connected to another switch may also be configured to form a SAN port channel.
F Port
In fabric port (F port) mode, an interface functions as a fabric port. This port may be connected to a peripheral device (host or disk) operating as a node port (N port). An F port can be attached to only one N port. F ports support class 3 service.
TE Port
In trunking E port (TE port) mode, an interface functions as a trunking expansion port. It may be connected to another TE port to create an extended ISL (EISL) between two switches. TE ports connect to another Cisco Nexus device or a Cisco MDS 9000 Family switch. They expand the functionality of E ports to support the following:
-
VSAN trunking
-
Fibre Channel trace (fctrace) feature
In TE port mode, all frames are transmitted in EISL frame format, which contains VSAN information. Interconnected switches use the VSAN ID to multiplex traffic from one or more VSANs across the same physical link. This feature is referred to as VSAN trunking in the Cisco Nexus device. TE ports support class 3 and class F service.
TF Port
When the switch is operating in NPV mode, the interfaces that connect the switch to the core network switch are configured as NP ports. NP ports operate like N ports that function as proxies for multiple physical N ports.
In trunking F port (TF port) mode, an interface functions as a trunking expansion port. It may be connected to another trunked N port (TN port) or trunked NP port (TNP port) to create a link between a core switch and an NPV switch or an HBA to carry tagged frames. TF ports expand the functionality of F ports to support VSAN trunking.
In TF port mode, all frames are transmitted in an EISL frame format, which contains VSAN information. Interconnected switches use the VSAN ID to multiplex traffic from one or more VSANs across the same physical link. This feature is referred to as VSAN trunking in Cisco Nexus devices. TF ports support class 3 and class F service.
Auto Mode
Interfaces configured in auto mode can operate in one of the following modes: E, F, TE, and TF. The port mode is determined during interface initialization. For example, if the interface is connected to a node (host or disk), it operates in F port mode. If the interface is attached to a third-party switch, it operates in E port mode. If the interface is attached to another switch in the Cisco Nexus device or Cisco MDS 9000 Family, it may become operational in TE port mode.
Interface States
The interface state depends on the administrative configuration of the interface and the dynamic state of the physical link.
Administrative States
The administrative state refers to the administrative configuration of the interface. The table below describes the administrative states.
Administrative State |
Description |
---|---|
Up |
Interface is enabled. |
Down |
Interface is disabled. If you administratively disable an interface by shutting down that interface, the physical link layer state change is ignored. |
Operational States
The operational state indicates the current operational state of the interface. The table below describes the operational states.
Operational State |
Description |
---|---|
Up |
Interface is transmitting or receiving traffic as desired. To be in this state, an interface must be administratively up, the interface link layer state must be up, and the interface initialization must be completed. |
Down |
Interface cannot transmit or receive (data) traffic. |
Trunking |
Interface is operational in TE or TF mode. |
Reason Codes
Reason codes are dependent on the operational state of the interface. The following table describes the reason codes for operational states.
Administrative Configuration |
Operational Status |
Reason Code |
---|---|---|
Up |
Up |
None. |
Down |
Down |
Administratively down. If you administratively configure an interface as down, you disable the interface. No traffic is received or transmitted. |
Up |
Down |
See the table below. |
If the administrative state is up and the operational state is down, the reason code differs based on the nonoperational reason code. The table below describes the reason codes for nonoperational states.
Note |
Only some of the reason codes are listed in the table. |
Reason Code (long version) |
Description |
Applicable Modes |
---|---|---|
Link failure or not connected |
The physical layer link is not operational. |
All |
SFP not present |
The small form-factor pluggable (SFP) hardware is not plugged in. |
All |
Initializing |
The physical layer link is operational and the protocol initialization is in progress. |
All |
Reconfigure fabric in progress |
The fabric is currently being reconfigured. |
|
Offline |
The switch software waits for the specified R_A_TOV time before retrying initialization. |
|
Inactive |
The interface VSAN is deleted or is in a suspended state. To make the interface operational, assign that port to a configured and active VSAN. |
|
Hardware failure |
A hardware failure is detected. |
|
Error disabled |
Error conditions require administrative attention. Interfaces may be error-disabled for various reasons. For example:
To make the interface operational, you must first fix the error conditions causing this state and then administratively shut down andor enable the interface. |
|
Isolation because limit of active port channels is exceeded. |
The interface is isolated because the switch is already configured with the maximum number of active SAN port channels. |
|
Isolation due to ELP failure |
The port negotiation failed. |
Only E ports and TE ports |
Isolation due to ESC failure |
The port negotiation failed. |
|
Isolation due to domain overlap |
The Fibre Channel domains (fcdomain) overlap. |
|
Isolation due to domain ID assignment failure |
The assigned domain ID is not valid. |
|
Isolation due to the other side of the link E port isolated |
The E port at the other end of the link is isolated. |
|
Isolation due to invalid fabric reconfiguration |
The port is isolated due to fabric reconfiguration. |
|
Isolation due to domain manager disabled |
The fcdomain feature is disabled. |
|
Isolation due to zone merge failure |
The zone merge operation failed. |
|
Isolation due to VSAN mismatch |
The VSANs at both ends of an ISL are different. |
|
port channel administratively down |
The interfaces belonging to the SAN port channel are down. |
Only SAN port channel interfaces |
Suspended due to incompatible speed |
The interfaces belonging to the SAN port channel have incompatible speeds. |
|
Suspended due to incompatible mode |
The interfaces belonging to the SAN port channel have incompatible modes. |
|
Suspended due to incompatible remote switch WWN |
An improper connection is detected. All interfaces in a SAN port channel must be connected to the same switch.pair of switches. |
|
Bound physical interface down |
The Ethernet interface bound to a virtual Fibre Channel interface is not operational. |
Only virtual Fibre Channel interfaces |
STP not forwarding in FCoE mapped VLAN |
The Ethernet interface bound to a virtual Fibre Channel interface is not in an STP forwarding state for the VLAN associated with the virtual Fibre Channel interface |
Only virtual Fibre Channel interfaces |
Buffer-to-Buffer Credits
Buffer-to-buffer credits (BB_credits) are a flow-control mechanism to ensure that Fibre Channel interfaces do not drop frames. BB_credits are negotiated on a per-hop basis.
The BB_credit mechanism is used on Fibre Channel interfaces but not on virtual Fibre Channel interfaces. The receive BB_credit determines the receive buffering capability on the receive side without having to acknowledge the peer. This is important for links with large bandwidth-delays (long links with large latency) to be able to sustain line-rate traffic with increased latency.
For virtual Fibre Channel interfaces, BB_credits are not used. Virtual Fibre Channel interfaces provide flow control based on a class based pause mechanism named Priority Flow Control.Priority-Flow_control.
Note |
|
Note |
The receive BB_credit value is 64 in N9K-C93180YC-FX and 32 in N9K-C93360YC-FX2 and N9K-C9336C-FX2-E. This is applicable for all port modes (F,E) in both platforms and cannot be changed. |
Licensing Requirements for Fibre Channel
Ensure that you have the correct license installed before using Fibre Channel interfaces and capabilities. For more information on licensing, see Enabling FC/FCoE chapter in this guide.
Enabling the Fibre Channel Port License
This section explains how to enable the licensing for SAN Switching.
Before you begin
To enable the port license, you must shut down the fibre channel (FC) ports.
Note |
For information about converting to FC ports, see Configuring Unified Ports. |
SUMMARY STEPS
- Enable the port license.
DETAILED STEPS
Enable the port license. Example:
|
Configuring QoS for no-drop Support
A qos ingress policy is used to mark ingress FC/FCoE frames. The qos ingress policy must be applied to the interfaces that handle FC/FCoE traffic (such as, all ethernet/port-channel interfaces bound to vFCs).
Note |
Check to ensure that the port qos region has hardware TCAM space reserved. Whenever an ingress PACL TCAM threshold is seen in the syslog, increase the TCAM size and reload the switch. This step is mandatory for FC/FCoE to work.
Example:
|
Configuring QoS Policies for FC/FCoE
-
There are four types of FC/FCoE default policies: network-qos, output queuing, input queuing, and input qos.
-
To use a different queue or cos value for FC/FCoE traffic, create user-defined policies.
-
You can configure a QoS policy by following one of these methods:
-
Predefined policies—You can apply a predefined QoS policy: default-fcoe-in-policy .
Note
-
No policy will be applied by default for FCoE.
-
We recommend to apply no-stats to QoS policy.
-
-
User-defined policy—You can create a QoS policy that conforms to one of the system-defined policies.
-
Configuring System-wide QoS Policy
Note |
The network-qos policy and output/input queuing policies should be applied at the system level and the qos policy should be applied at the interface level, for every interface that carries the FC/FCoE traffic. |
switch(config)# system qos
switch(config-sys-qos)# service-policy type queuing input default-fcoe-in-que-policy
switch(config-sys-qos)# service-policy type queuing output { default-fcoe-8q-out-policy | default-fcoe-out-policy }
switch(config-sys-qos)# service-policy type network-qos { default-fcoe-8q-nq-policy | default-fcoe-nq-policy }
Configuration Example for user-defined policies
switch(config)# policy-map type network-qos fcoe_nq
switch(config-pmap-nqos)# class type network-qos c-nq1
switch(config-pmap-nqos-c)# pause pfc-cos 3
switch(config-pmap-nqos-c)# mtu 9216
switch(config-pmap-nqos-c)# class type network-qos c-nq2
switch(config-pmap-nqos-c)# mtu 1500
switch(config-pmap-nqos-c)# class type network-qos c-nq3
switch(config-pmap-nqos-c)# mtu 1500
switch(config-pmap-nqos-c)# class type network-qos c-nq-default
switch(config-pmap-nqos-c)# mtu 1500
switch(config-pmap-nqos-c)# exit
switch(config-pmap-nqos)# exit
switch(config)#
switch(config)# policy-map type queuing fcoe-in-policy
switch(config-pmap-que)# class type queuing c-in-q1
switch(config-pmap-c-que)# bandwidth percent 50
switch(config-pmap-c-que)# class type queuing c-in-q-default
switch(config-pmap-c-que)# bandwidth percent 50
switch(config-pmap-c-que)# exit
switch(config)
switch(config)# policy-map type queuing fcoe-out-policy
switch(config-pmap-que)# class type queuing c-out-q3
switch(config-pmap-c-que)# priority level 1
switch(config-pmap-c-que)# class type queuing c-out-q-default
switch(config-pmap-c-que)# bandwidth remaining percent 50
switch(config-pmap-c-que)# class type queuing c-out-q1
switch(config-pmap-c-que)# bandwidth remaining percent 50
switch(config-pmap-c-que)# class type queuing c-out-q2
switch(config-pmap-c-que)# bandwidth remaining percent 0
switch(config-pmap-c-que)# exit
switch(config)#
switch(config)# class-map type qos match-any fcoe
switch(config-cmap-qos)# match protocol fcoe
switch(config-cmap-qos)# match cos 3
switch(config-cmap-qos)# exit
switch(config)#
switch(config)# policy-map type qos fcoe_qos_policy
switch(config-pmap-qos)# class fcoe
switch(config-pmap-c-qos)# set cos 3
switch(config-pmap-c-qos)# set qos-group 1
switch(config-pmap-c-qos)# exit
switch(config-pmap-qos)# exit
switch(config)#
switch(config)# system qos
switch(config-sys-qos)# service-policy type queuing input fcoe-in-policy
switch(config-sys-qos)# service-policy type queuing output fcoe-out-policy
switch(config-sys-qos)# service-policy type network-qos fcoe_nq
Note |
The set cos 3 command under the QOS policy is mandatory only when there are native fiber channel ports and the command is applicable only for N9K-C93180YC-FX platform , N9K-C93360YC-FX2 platforms . For all the other Cisco Nexus 9000 Platform switches, this step is optional. |
Applying the ingress QoS policy to each Ethernet/port-channel interface that is bound to vFC interface for FC/FCoE.
switch(config)# interface ethernet 2/1
switch(config-if)# switchport mode trunk
switch(config-if)# mtu 9216 /* Or maximum allowed value */
switch(config-if)# service-policy type qos input { default-fcoe-in-policy | fcoe_qos_policy ) no-stats
switch(config-if)# exit
switch(config)#
-
Configuring FC/FCoE QoS policies
-
There are four types of FC/FCoE default policies: network QoS, output queuing, input queuing, and QoS.
-
To use a different queue or cos value for FC/FCoE traffic, create user-defined policies.
-
-
Configuring Network QoS Policies for FC/FCoE
-
You can configure a network QoS policy by following one of these methods:
-
Predefined policies—You can apply a predefined network QoS policy that fits your requirement. You have the option to choose either default-fcoe-8q-nq-policy or default-fcoe-nq-policy .
Note
No policy will be applied by default for FC/FCoE.
-
User-defined policy—You can create a network QoS policy that conforms to one of the system-defined policies.
-
-
-
Configuring Output Queuing Policies for FC/FCoE
-
You can configure an output queuing policy by following one of these methods:
-
Predefined policies—You can apply a predefined output queuing policy that fits your requirement. You have the option to choose either default-fcoe-8q-out-policy or default-fcoe-out-policy .
Note
No policy will be applied by default for FC/FCoE.
-
User-defined policy—You can create a output queuing policy that conforms to one of the system-defined policies.
-
-
-
Configuring Input Queuing Policies for FC/FCoE
-
You can configure an input queuing policy by following one of these methods:
-
Predefined policies—You can apply a predefined input queuing policy: default-fcoe-in-que-policy .
Note
No policy will be applied by default for FCoE.
-
User-defined policy—You can create a input queuing policy that conforms to one of the system-defined policies.
-
-
Note |
Whenever you see label allocation failure in the syslog, there is a possibility of FC/FCoE ACL not getting applied on interfaces. You must then check whether the QoS policy is applied with no-stats on the interfaces. |
Physical Fibre Channel Interfaces
Cisco Nexus C93180YC-FX and C93360YC-FX2 switches support up to 48 and 96 physical fibre channel (FC) interfaces respectively as either uplinks connected to SAN network or as downlinks (connected to server or target). Cisco Nexus N9K-C9336C-FX2-E switches can have up to 112 physical fibre channel (FC) breakout interfaces as either uplinks connected to SAN network or as downlinks (connected to server or target). Only ports from 9 to 36 can be converted in FC breakout.
Each Fibre Channel port can be used as a downlink (connected to a server) or as an uplink (connected to the data center SAN network). The Fibre Channel interfaces support the following modes: E, F, SD, TE, and TF.
Long-Distance ISLs
Beginning with Cisco NX-OS Release 10.2(1)F, the Cisco Nexus N9K-C93180YC-FX and N9K-C93360YC-FX2 switches support long distance on 32-Gbps Fibre Channel Inter-Switch Link (ISL).
The formula for computing long-distance ISL BB_credits assumes a typical Fibre Channel frame of 2 KB and factors in the interface speed. With fixed (64) buffer-to-buffer credits, the new switch now provide support for 32-Gbps Fibre Channel ISLs across distances of up to 3 kilometers.
Speed |
Distance |
---|---|
32G |
3 KM |
16G |
5 KM |
8G |
10 KM |