The interview question is simple: what does a vPC peer-link carry, and how is it different from peer-keepalive? The useful answer separates synchronization, forwarding and failure handling rather than calling both connections a heartbeat.
Short answer: the peer-link is a Layer 2 port-channel between Nexus peers, carrying coordination and selected data traffic; peer-keepalive is a separate IP liveness path, not a data backup.[1]
What crosses the peer-link?
A vPC presents links from two switches as one port-channel to a downstream device.[1]
- Synchronization: Cisco Fabric Services over Ethernet (CFSoE) exchanges coordination information and synchronizes MAC learning for shared VLANs.[1]
- Flooded traffic: broadcast, unknown unicast and multicast can traverse the peer-link; multicast forwarding state is synchronized.[1]
- Selected unicast: normal known-unicast forwarding prefers a usable local member, but remote-only destinations and failure conditions can require the peer-link.[1]
It does not copy the entire running configuration: relevant settings still need matching configuration on both peers.[1]
Packet flow: why traffic does not always cross it
Consider this fictional same-VLAN exercise, not a tested switch lab. Server S is dual-attached through a vPC; host H has one ordinary access connection to switch B. Both peers carry the example VLAN.
independent peer-keepalive path
A ----------------------------- B
A ===== L2 peer-link ========== B ---- H
\ /
\---- S: one port-channel -/
Ask these questions before drawing any arrows:
- Which switch receives this particular frame from S?
- Is H's destination MAC already known?
- Which interface is the eligible egress on that receiving switch?
- Does the packet need routing, or is this strictly same-VLAN switching?
Applying the documented model: B forwards directly to H; A needs the peer-link to reach H on B.[1]
Loop avoidance: the important restriction
A frame received across the peer-link generally cannot exit a vPC member if the corresponding member is operational on the other peer. This prevents duplicate forwarding; it is not a blanket prohibition on every peer-link-to-access-port path.[3]
The restriction also matters when routing: a packet addressed to the other peer's physical router MAC may cross the peer-link, be routed there, and then hit the vPC egress restriction.[3]
The peer-gateway enhancement permits local routing on behalf of the other peer's router MAC, avoiding that unnecessary crossing. It is not another name for the peer-link or the peer-switch feature.[3]
Do not enable it blindly as a generic repair: routing adjacencies over vPC can require the separate layer3 peer-router capability, with platform and release restrictions.[3]
What happens if the peer-link fails?
With the peer-link down but keepalive confirming the other switch is alive, the secondary suspends its vPC member ports; traffic uses the surviving side.[1]
For an interview, state that condition explicitly. “The secondary shuts everything down” is too broad: distinguish vPC members, SVIs and single-homed orphan ports, then consult the relevant platform behavior instead of promising universal failover.
For a proposed maintenance test, record the roles and application baseline first. Test one failure at a time in an isolated lab or approved window. Keep console access and an agreed stop condition. Do not infer application recovery from a green link indicator alone.
Read-only troubleshooting checklist
The following commands are illustrative NX-OS checks, not output collected from a real switch. Cisco documents these command families for vPC diagnosis.[2]
show vpc
show vpc peer-keepalive
show running-config vpc
show port-channel summary
show vpc consistency-parameters global
show vpc consistency-parameters interface port-channel 10
Replace port-channel 10 with the affected downstream bundle. Capture both peers, not just the one receiving the alert.
| Observation | Next check |
|---|---|
| Keepalive unreachable | Source/destination reachability in the configured VRF.[2] |
| Physical members up, vPC unhealthy | Peer adjacency, peer-link state and consistency results.[2] |
| Type-1 mismatch | Compare reported local and peer values; these mismatches can suspend the vPC.[2] |
| Only selected VLANs suspended | Verify those VLANs are permitted on the peer-link too.[2] |
| Same-VLAN access works, routed access fails | Inspect gateway MAC use and the loop-avoidance path before changing routing.[2][3] |
Suggested incident worksheet: affected VLAN, ingress peer, destination MAC, expected egress, local/remote member state, first failing probe, and timestamp. Keep one worksheet per failed flow rather than mixing unrelated symptoms.
Common interview pitfalls
- Treating keepalive as a replacement data path for the peer-link.[1]
- Treating a physical link-up result as proof of a healthy vPC; consistency and VLAN eligibility also matter.[2]
- Confusing peer-gateway's local routing behavior with peer-switch's STP behavior.[3]
- Claiming to have tested failover when only configuration or documentation was reviewed.
A concise interview answer
“The peer-link carries synchronization and selected data traffic; keepalive checks peer liveness separately. If the peer-link fails while the peer is alive, the secondary suspends its vPC members.[1] I check both peers' status, consistency, VLANs and port-channel membership before changing configuration.”[2]
Practice saying that answer, then draw the same-VLAN example without assuming every frame crosses between switches.
Related reading
- LACP EtherChannel: active/passive modes and bundle behavior
- vPC orphan-port troubleshooting and maintenance
- Data Center Networking hub
Preparing for a network engineering interview? Draw the topology from memory, explain one healthy flow and one failure, then name the evidence you would collect. A precise conditional answer beats a memorized command list.
Post a Comment