An airport authority uses route-maps to attach BGP communities that later drive whether traffic exits early (hot-potato) or rides farther (cold-potato). What role do those communities play?
Select an answer to reveal the explanation.
Short Explanation
Communities are colored tags on a suitcase. The airport sticks ‘prefer-exit-west’ on a prefix; downstream policy sees the tag and sets LOCAL_PREF or MED accordingly. The tag itself isn’t the metric—it’s the signal that triggers policy.
Full Explanation
BGP communities are opaque policy markers carried with routes so operators can classify prefixes and apply consistent actions—LOCAL_PREF, MED, filtering, or aggregation behavior—via route-maps. An airport authority attaching communities that later drive whether traffic exits early (hot-potato) or rides farther (cold-potato) is using communities as the signaling layer of routing policy: receiving routers match those communities and apply the intended attributes. That pattern enables scalable hot-potato versus cold-potato designs without per-prefix manual treatment on every router.
Communities do not replace IGP metrics so OSPF no longer needs reference bandwidth. They are not mandatory transitive attributes that every eBGP peer must rewrite to the airport’s ASN. They are not Layer-2 CoS markings copied automatically into MPLS EXP without any routing policy involvement.
Exam caveat: know well-known communities and whether communities are propagated across your eBGP sessions; strip or allow-list carefully at Internet edges to avoid leaking internal policy signals. Operational check: tag prefixes with agreed communities, confirm peers apply the mapped LOCAL_PREF or MED, traceroute to validate hot versus cold potato behavior, and document the community legend for airport NOC staff.