A regional headquarters multihomes to two ISPs with its own public ASN, needing primary outbound use of ISP-A and inbound preference for critical application prefixes via ISP-A while keeping ISP-B as backup without causing transit between providers. Which BGP path control design balances inbound and outbound traffic?
Select an answer to reveal the explanation.
Short Explanation
You can steer traffic in both directions by using local preference for your outbound choice and AS-path prepending plus provider communities for inbound preference. Keep ISP-B as backup without advertising routes that would make you transit between providers.
Full Explanation
Local preference is the standard outbound control: you assign a higher value to routes learned from ISP-A, and that preference is shared across your AS but never advertised to eBGP peers. For inbound preference, AS-path prepending toward ISP-B makes paths through that provider look longer to remote networks, while provider communities can request ISP-A preference where the providers support them. This matches the design that combines outbound local preference with inbound prepending and provider communities. Using MED for outbound control and local preference for inbound control reverses their roles: MED is an external hint about how a neighboring AS should enter your network, while local preference stays within your AS. Weight applies only on one router, so it cannot steer the whole AS; advertising all prefixes to both ISPs can make you transit between them. Origin code is a weak late-stage tiebreaker, and stripping communities removes a provider signaling mechanism, so neither reliably prefers ISP-A for all traffic. A caveat is that MED is normally compared only between paths learned from the same neighboring AS, so it may not determine a choice between two different ISPs. In practice, inspect your BGP table to verify outbound selection and use provider looking-glass views to check how external networks see your advertised paths.