A city leaf shows BGP Established to a spine but receives zero prefixes from that peer. Where should troubleshooting focus first?
Select an answer to reveal the explanation.
Short Explanation
Established just means the BGP handshake worked—like a phone call that connected while nobody sent the spreadsheet. Dig into families and export/import policy when the prefix count is zero.
Full Explanation
A city leaf that shows BGP Established to a spine yet receives zero prefixes should drive triage into address-family enablement and export/import routing policy on both peers first. Established only means the session handshake succeeded—like a phone call that connected while nobody sent the routing spreadsheet. Mismatched NLRI families or blocking export/import policy are the usual reasons a municipal leaf’s RIB stays empty despite an up session.
Replacing the optical transceiver because Established supposedly proves routing policy cannot be involved reverses cause and effect; an up session with zero prefixes implicates policy or families, not light levels. Disabling the underlay entirely and rebuilding with only static defaults to each spine is a reckless rebuild, not troubleshooting. Lowering CPU threshold alarms so empty RIBs stop generating tickets suppresses symptoms without restoring advertisements.
Exam caveat: Established ≠ exchanging routes; check families and policy before swapping optics when the session is already up.
Operational check: compare configured address families and export/import policies on leaf and spine; inspect advertised versus received prefix counts; correct policy and confirm fabric and VTEP prefixes appear without unnecessary hardware replacement.