A rural cooperative peers separately with Transit-A and Transit-B. Engineers are concerned that if a term is missing, the co-op's router could start forwarding traffic between the two transit providers, effectively becoming unpaid transit itself. Which policy design correctly prevents this?
Select an answer to reveal the explanation.
Short Explanation
Becoming accidental transit happens when a co-op re-advertises one upstream's routes to the other, so the fix lives on export: explicitly reject routes learned from Transit-A when exporting to Transit-B, and vice versa, so only the co-op's own subscriber and aggregate routes ever go out to either one. Import policy alone can't prevent this, since the problem is what gets sent, not what gets received. Preference and OSPF cost tuning don't touch advertisement at all.
Full Explanation
Preventing accidental transit requires controlling what gets exported to each transit provider, so the correct design places an export policy on the session toward Transit-A that rejects any route learned from Transit-B, and a matching export policy toward Transit-B that rejects any route learned from Transit-A, ensuring the only routes advertised to either upstream are the co-op's own subscriber and aggregate prefixes. This is a routine safeguard for any multihomed ISP, since without it, a route learned from one transit provider could be re-advertised to the other, making the cooperative's router an unintended, unpaid path between two much larger networks. Relying only on an import policy is insufficient because import governs what gets installed into the local routing table, not what subsequently gets advertised outward, so Transit-B's routes could still be learned, installed, and exported right back toward Transit-A unless export is separately controlled. OSPF cost has no bearing here, since cost only influences interior path selection and has no effect on whether BGP advertises a route externally. Raising local preference equally on both sessions changes nothing about export behavior either, since local preference only governs which route the co-op itself prefers internally, not what it tells either provider. A caveat: the reject match must key on the learned-from neighbor or an as-path condition, not protocol alone, or it could also catch legitimate customer routes. A concrete check is show route advertising-protocol bgp <Transit-A>, confirming none of Transit-B's routes appear in what is sent to Transit-A.