A regional planning commission merged township networks that used private ASNs and now advertises to the public Internet from a public ASN. What must happen to those private ASNs before updates leave the public edge?
Select an answer to reveal the explanation.
Short Explanation
Private ASNs are like internal extension numbers—fine inside the merged townships, wrong on letterhead to the Internet. At the public edge, peel those private hops off so the world only sees your public ASN path.
Full Explanation
Private AS numbers (for example 64512–65534 historically, plus the four-octet private range) must not remain in AS paths advertised to the global Internet. A regional planning commission that merged township networks using private ASNs and now advertises to the public Internet from a public ASN must strip private ASNs from the AS path on advertisements toward eBGP ISPs so global tables do not retain private AS hops. Edge remove-private-as style policy is the hygiene step after mergers that introduced private ASNs inside the civic network.
Prepending private ASNs repeatedly so upstreams treat the path as more specific is the opposite of cleanup and pollutes global tables with non-unique AS hops. Translating every private ASN into AS 23456 without removing private hops does not by itself satisfy private-AS hygiene toward the public Internet. Disabling BGP synchronization does not make private ASNs globally unique automatically.
Exam caveat: platform remove-private-as behaviors vary, including cases with confederations or when private ASNs appear in the middle of paths—verify documentation for your code train. Operational check: before and after enabling private-AS removal, inspect AS paths advertised to the ISP, confirm no private ASN remains, and validate that inbound traffic engineering still works as designed.