-
Cisco Nexus 9332C, 9364C, and 9300-EX/FX/FXP/FX2/FX3/GX/GX2 platform switches support vPC Fabric Peering. Cisco Nexus 9200 and 9500 platform switches do not support vPC Fabric Peering.
Note
|
For Cisco Nexus 9300-EX switches, mixed-mode multicast and ingress replication are not supported. VNIs must be configured
with either multicast or IR underlay, but not both.
|
-
Beginning with Cisco NX-OS Release 10.2(3)F, vPC Fabric Peering is supported on Cisco Nexus C36180YC-R and N3K-C3636C-R platforms.
You need to enable TCAM carving in these R-series modules for the vPC Fabric Peering to work.
-
The following guidelines and limitations are applicable only to Cisco Nexus C36180YC-R and N3K-C3636C-R platforms:
-
With vPC Fabric Peering enabled, ingress PACL MAC feature is not supported.
-
With vPC Fabric Peering enabled, Layer 2 SPAN based on Layer 2 filters using MAC and CoS values are not supported. Other filters
for Layer 2 SPAN are supported.
-
With vPC Fabric Peering enabled, Uni-dimensional scale of Layer 3 host/adjacency will come down to half.
-
On the steady state with all vPC PO's up, BUM traffic from core are received on both the vPC peers. For all flows vPC primary
will forward the traffic to vPC PO's.
-
Layer 3 Tenant Routed Multicast (TRM) is not supported.
-
BGP peering behind vPC PO is not supported.
-
IGMP snooping is not supported with vPC Fabric peering
-
DHCP relay agent is not supported.
-
vPC Fabric Peering is not supported on hand off node.
-
vPC Fabric Peering requires TCAM carving of region ing-flow-redirect. TCAM carving requires saving the configuration and reloading
the switch prior to using the feature.
-
Prior to reconfiguring the vPC Fabric Peering source and destination IP, the vPC domain must be shut down. Once the vPC Fabric
Peering source and destination IP have been adjusted, the vPC domain can be enabled (no shutdown ).
-
The source and destination IP supported in virtual peer-link destination command are class A, B, and C. Class D and E are not supported for vPC Fabric Peering.
-
The vPC Fabric Peering peer-link is established over the transport network (the spine layer of the fabric). As communication
between vPC peers occurs in this manner, control plane information CFS messages used to synchronize port state information,
VLAN information, VLAN-to-VNI mapping, host MAC addresses are transmitted over the fabric. CFS messages are marked with the
appropriate DSCP value, which should be protected in the transport network. The following example shows a sample QoS configuration
on the spine layer of Cisco Nexus 9000 Series switches.
Classify traffic by matching the DSCP value (DSCP 56 is the default value):
class-map type qos match-all CFS
match dscp 56
Set traffic to the qos-group that corresponds with the strict priority queue for the appropriate spine switch. In this example,
the switch sends traffic to qos-group 7, which corresponds to the strict priority queue (Queue 7). Note that different Cisco
Nexus platforms might have a different queuing structure.
policy-map type qos CFS
class CFS
Set qos-group 7
Assign a classification service policy to all interfaces toward the VTEP (the leaf layer of the network):
interface Ethernet 1/1
service-policy type qos input CFS
-
Beginning with Cisco NX-OS Release 10.1(1), FEX Support is provided with vMCT for IPv4 underlay on Cisco Nexus 9300-EX/FX/FX2/FX3
platform switches.
-
Beginning with Cisco NX-OS Release 10.1(1), vPC Fabric Peering supports FEX in Straight Through and Active-Active (dual home)
modes in N9K-C9336C-FX2-E, N9K-C93108TC-EX, N9K-C93108TC-FX,N9K-C93180YC-EX, N9K-C93180YC-FX, N9K-C93216TC-FX2, N9K-C93240YC-FX2,
N9K-C93360YC-FX2, N9K-C9336C-FX2, N9K-C93180YC-FX3, N9K-C93180YC-FX3S platform switches.
Refer to Cisco Nexus 2000 Series NX-OS Fabric Extender Configuration Guide for Cisco Nexus 9000 Series Switches for details on FEX (Straight Through and Active-Active modes).
-
The vPC Fabric Peering domain is not supported in the role of a Multi-Site vPC BGW.
-
Enhance forwarding to orphan hosts by extending the VIP/PIP feature to Type-2 routes.
-
Layer 3 Tenant Routed Multicast (TRM) is supported. Layer 2/Layer 3 TRM (Mixed Mode) is not supported.
-
If Type-5 routes are used with this feature, the
advertise-pip
command is a mandatory configuration.
-
VTEPs behind vPC ports are not supported. This means that virtual peer-link peers cannot act as a transit node for the VTEPs
behind the vPC ports.
-
SVI and sub-interface uplinks are not supported.
-
An orphan Type-2 host is advertised using PIP. A vPC Type-2 host is advertised using VIP. This is the default behavior for
a Type-2 host.
To advertise an orphan Type-5 route using PIP, you need to advertise PIP under BGP.
-
Traffic from remote VTEP to orphan hosts would land on the actual node which has the orphans. Bouncing of the traffic is avoided.
Note
|
When the vPC leg is down, vPC hosts are still advertised with the VIP IP.
|
-
When converting vPC fabric peering to a physical peer link, make sure to reload the switch.
Feedback