In peer-Switch mode bridge-ID comes from system-mac (vPC) as opposed to local mac in normal mode
Peer-Link STP inconsistencies on Secondary Switch
When a peer link STP inconsistency is dedicated on secondary switch the peer-link will be put in a "inconsistent" STP state (blocking)
All VLAN's of MST instances are also blocked on all vPC's
The above behavior will depend on STP Bridge Assurance on peer-link (default) as a way to signal the secondary switch peer about
With out BA on the peer-link any inconsistency on the Primary will lead to a Peer-Link FLAP (big NO NO)
PES/SPS and BG redirection
Primary vPC peer control the port states on the secondary peer by the mans of SPS (set-port-state) messages
Changes in STP information are synchronized between the peers using PES (port-event-sync) messages
Can see with "sh spanning-tree internal info vPC , these counters should be stable unless a reconvergence event keeps happening
BPDU's are sent to vPC's out of the primary switch. If vPC leg connected to the primary is down, BPDU's are sent over peer-link and sent by secondary
Can use the "sh system internal frame traffic" to see the counter for the internal STP traffic
"sh spanning-tree vlan 4 you will see two root ports
"debug spanning-tree bpud_tx tree 101
"used debut logfile <file>
Can also sho the history
BA is default enabled on Peer-Link, not recommended for vPC unless Peer-Switch feature is also operational
Dispute is default enabled (for both RSTP and MST on vPC)
UDLD (normal mode) is recommended to take out bad links from channels (otherwise LACP takes 100SEC vs 20SEC with UDLD)
Preferred BA+ UDLD+ Dispute on all inter switch links when using Peer-Switch of course all switches have to support this
Without Peer-Switch BA should be kept only on a Peer-Link (no BA our LoopGuard on vPC's use UDLD+Dispute
Used Loop Guard + UDLD on all non all Nexus (CATALYST) switch links
Could use UDLD aggressive much more prone to false positives
Important to remember that when PC A is sent primary (let) it will flood, but Frames received on the Peer-Link will not be flooded out of vPC's
This is called vPC check stands for al L2,L3,unicast, multicast, broadcast and flooded traffic.
IF the frame comes in on the left switch it will stay on the left switch unless the upstream port-channel link is down (orphaned link)
This is not supported, must add a routed cross-link.
MAC address learning
The MAC is not flooded over the peer-link but via CFS message it is synced with the right switch which updates it MAC addr. table
Always learn on lower vPC
"sh hardware internal errors all"
Number 1 command to look for hardware packet drops.
Run several times to see if any counters increase
To clear module counters "clear statistics module-all device all"
1st hop redundancy
Will forward on both peers via virtual mac
sh hsrp brief
sh mac address-table address
Install MAC address of Left and Right switches on each other so the can respond to quarries sent to either
What happens when you need to just talk to the left router, have to use separate routed interface
Can use "peer-gateway exclude vlan" to turn off on certain vlans
vPC multicast considerations
Goal is to allow the peer receiving the source traffic to forward it to receivers behind vPC without crossing the peer-link
(vPC will drop such traffic otherwise)
What if the source is behind the vPC
Uses Proxy DR and will send the request to the same switch
When vPC is configured on a N7K-F248XP-25 (F2) there is no proxy-DR function due to hardware limitations. Packets will be bridged to DR over peer-link (vPC check is modified accordingly for L3 multicast packets on F2 linecards)
Peers do metrics exchange over CFS for each new source
Peer that has better metric to source or primary will be forwarder
"sh ip pim internal vPC rpf"
For sources behind the vPC both peers will forward as they have to control on which one will get the traffic
"sh ip pim internal vPC rpf"