A number of multichassis aggregation technologies are deployed
in the data center today, for example, Cisco’s Multichassis EtherChannel (MEC)
on catalyst 6500 VSS, and Virtual Port Channel (vPC) on Nexus platforms.
Inter-chassis aggregation greatly increases link utilization, while simplifying
design by eliminating topology dependence on spanning tree protocol. STP
becomes passive as most links are forwarding, and most failure scenarios no
longer require STP re-convergence, thus minimizing disruptions. Furthermore, a
more elegant data center design can be achieved, with lower operational
complexity, and higher return on investment.
System MAC address exists on individual devices, often used for
device level negotiation, for example, bridge ID field in STP BPDU, or as part
of LACP LAGID.
When multiple chassis operate in unison, software simulates
the behavior of a common logical system, with the use of common virtual identifiers.
Differentiating and sorting out the use of virtual system identifier and
various MAC addresses is helpful for understanding, designing and deploying such
systems.
It can be illustrated with a simple topology such as the one
shown in the diagram, in which a pair of Nexus (in VPC domain 100) is connected
to another pair (in VPC domain 101) on back to back VPCs.
The following display shows that each physical device has a system
MAC address, and each pair of pairing devices also has a common VPC system MAC
address.
N7k pair: VPC domain 100
Nexus7k-1
|
Nexus7k-2
|
Nexus7k-1# sh vpc role
vPC Role status
----------------------------------------------------
vPC role : primary
Dual Active Detection
Status : 0
vPC system-mac : 00:23:04:ee:be:64
vPC system-priority : 32667
vPC local system-mac : 00:26:98:08:7a:c2
vPC local role-priority : 100
|
Nexus7k-2# sh vpc role
vPC Role status
----------------------------------------------------
vPC role : secondary
Dual Active Detection
Status : 0
vPC system-mac : 00:23:04:ee:be:64
vPC system-priority : 32667
vPC local system-mac : 00:26:98:08:7c:c2
vPC local role-priority : 110
|
Nexus7k-1# sh lacp system-identifier
32768,0-26-98-8-7a-c2
|
Nexus7k-2# sh lacp
system-identifier
32768,0-26-98-8-7c-c2
|
N5k pair: VPC domain 101
Nexus5k-1
|
Nexus5k-2
|
Nexus5k-1sh vpc role
vPC Role status
----------------------------------------------------
vPC role : primary
Dual Active Detection
Status : 0
vPC system-mac : 00:23:04:ee:be:65
vPC system-priority : 32667
vPC local system-mac : 00:05:9b:75:08:3c
vPC local role-priority : 100
|
Nexus5k-2# sh vpc role
vPC Role status
----------------------------------------------------
vPC role : secondary
Dual Active Detection
Status : 0
vPC system-mac : 00:23:04:ee:be:65
vPC system-priority : 32667
vPC local system-mac : 00:05:9b:76:08:fc
vPC local role-priority : 110
|
Nexus5k-1# sh lacp
system-identifier
32768,0-5-9b-75-8-3c
|
Nexus5k-2# sh lacp
system-identifier
32768,0-5-9b-76-8-fc
|
Note the “common” system MAC address is generated from a
pre-defined set of MACs, with its last octet derived from the VPC domain ID.
For the pair of 7k shown, domain 100 is 64 in hex. For the pair of 5k shown,
domain 101 is 65 in hex. If both pairs happen to be using the same leading
octets, then the last octet will ensure the uniqueness of VPC MAC. This is an
example of why domain ID needs to be unique to each pair in the topology.
Visually, they look like this (shown for pair of 7k):
Note Local system MAC is used for communication among the
pair:
Nexus7k-1# sh lacp
port-channel
port-channel1
System Mac=0-26-98-8-7a-c2
Local System Identifier=0x8000,0-26-98-8-7a-c2
Admin key=0x9
Operational key=0x9
Partner System Identifier=0x8000,0-26-98-8-7c-c2
Operational key=0x9
Max delay=0
Aggregate or individual=1
Member Port List=1,17
port-channel5
System Mac=0-26-98-8-7a-c2
Local System Identifier=0x8000,0-26-98-8-7a-c2
Admin key=0x31
Operational key=0x31
Partner System Identifier=0x8000,0-26-98-8-7c-c2
Operational key=0x31
Max delay=0
Aggregate or individual=1
Member Port List=10,18
VPC system MAC is used for communication over VPC, for
example, in this case LACP negotiation between pair of 7k and pair of 5k.
LACP uses its local system MAC for a local port channel
(normal behavior); but in order for VPC to work, it must use “common” system
MAC for VPC negotiation. The following command can be misleading as it only
shows the local system MAC.
Nexus7k-1# sh lacp system-identifier
32768,0-26-98-8-7a-c2
It is more evident when looking from the remote side, that common
MAC is used as LACP identifier on VPC, instead of local system MAC.
Nexus7k-1# sh lacp
port-channel
port-channel101
System Mac=0-26-98-8-7a-c2
Local System
Identifier=0x8000,0-26-98-8-7a-c2
Admin key=0x8065
Operational key=0x8065
Partner System Identifier=0x7f9b,0-23-4-ee-be-65
Operational key=0x8065
Max delay=0
Aggregate or individual=1
Member Port List=17
Nexus5k-1# sh lacp nei int
po101
Flags: S - Device is sending Slow LACPDUs F - Device
is sending Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
port-channel101 neighbors
Partner's information
Partner Partner Partner
Port System ID Port Number Age
Flags
Eth1/3 32667,0-23-4-ee-be-64 0x311 10761537 SA
LACP Partner Partner Partner
Port Priority Oper Key Port State
32768 0x8065 0x3d
Note common system MAC only identifies the VPC system formed
by the pair, not individual port channel or interfaces. For tracing and
troubleshooting, they are not to be confused with MAC address on port channels
and physical interfaces.
No comments:
Post a Comment