Short answer: You can influence which of your links a remote AS uses to send traffic toward you, but you cannot dictate its routing policy. AS_PATH prepending, MED, provider communities and selective prefix advertisement are signals; the neighboring network makes the final decision.[1][4]
Inbound traffic engineering: the control boundary
Outbound traffic is chosen by your routers. Inbound traffic is chosen by remote networks. If a customer prefix is reachable through two providers, both providers may advertise it onward, and each upstream applies its own local preference, customer relationships, hot-potato routing and policy. BGP carries path attributes and reachability; it does not provide a mechanism to force a remote AS to use a particular circuit.[1]
Use inbound techniques to express a preference, then measure the result from multiple external vantage points. Design for the path you can guarantee—your own outbound selection and service resilience—not for a remote preference you cannot enforce.
Four practical methods
1. Ask the provider to set a community-based preference
Many providers document communities that request lower or higher local preference, prepend their ASN to selected peers, or suppress advertisements in selected regions. This is often more targeted than adding prepends yourself, but the community values and scope are provider-specific. Obtain the provider's current community guide and confirm whether the action applies to one router, a region, or the provider's entire network.
2. AS_PATH prepending
When announcing a prefix through a less-preferred circuit, append your own ASN one or more times to make that path appear longer to networks that compare AS_PATH length at that stage. A Cisco-style outbound policy conceptually looks like this (syntax and attachment points vary by platform):
ip prefix-list OUR-PREFIX seq 10 permit 203.0.113.0/24
route-map ISP-B-OUT permit 10
match ip address prefix-list OUR-PREFIX
set as-path prepend 65010 65010 65010
route-map ISP-B-OUT permit 100
router bgp 65010
neighbor 192.0.2.2 route-map ISP-B-OUT outReplace documentation-only addresses and ASNs with your assigned values. Apply a narrow prefix match, inspect the advertised route, and confirm your provider permits the policy. Prepending is not a guaranteed steering command: remote local preference commonly wins before AS_PATH length, and some networks normalize or ignore prepends.[1][2]
3. MED
MED can suggest which of multiple entry points a neighboring AS should prefer. Its comparison is commonly scoped to paths received from the same neighboring AS, and remote policy may override it. MED is not a universal Internet-wide ranking value; the behavior depends on the receiving network and configuration.[1][4]
4. Selective advertisement and more-specific prefixes
You can advertise a prefix on one provider only, if that satisfies resilience requirements. A more-specific route may attract traffic because longest-prefix matching is performed, but prefix-length filters and provider policies often limit which more-specifics propagate. Never withdraw the only viable route or announce an unauthorized prefix as an experiment.
Two-ISP example and decision table
Assume ISP-A is the preferred path and ISP-B is backup. Advertise the aggregate through both. Ask ISP-A whether it supports a documented community for normal preference; on ISP-B, consider a modest prepend as a secondary signal. Keep both links able to carry the full critical load during failure.
| Method | What you signal | Scope / limitation |
|---|---|---|
| Provider community | Provider-defined preference or propagation action | Only what that provider documents and honors |
| AS_PATH prepend | Longer path attribute on selected announcements | Remote local policy can outweigh it |
| MED | Suggested entry-point preference | Comparison scope and remote policy vary |
| Selective advertisement | Prefix reachability on chosen links | Reduces redundancy; filters may block specifics |
Verification workflow
- Check the outbound policy is attached to the intended eBGP neighbor and address family.
- Inspect the locally advertised route and confirm the expected AS_PATH, MED or community.
- Use the provider looking glass and at least two independent route collectors to inspect what was received and propagated.
- Test actual inbound paths with traceroute from external probes or controlled remote hosts; route visibility alone does not prove forwarding.
- Repeat after failover and verify return traffic, firewall state, NAT and application health.
Typical commands include show ip bgp neighbors 192.0.2.2 advertised-routes, show ip bgp 203.0.113.0/24 (Cisco-style), show route advertising-protocol bgp 192.0.2.2 203.0.113.0/24 (Junos-style), and the equivalent advertised-routes command on your platform. Exact syntax varies by release.
Troubleshooting checklist
- Is the expected prefix actually exported, or did an outbound filter deny it?
- Does the provider accept the prefix length and your origin ASN?
- Did the intended community survive ingress and egress policy?
- Is the prepend applied only to the backup peer and the intended prefix?
- Does the remote network have higher local preference, a customer route, or another policy that outranks your signal?
- Are you inspecting multiple vantage points and the correct address family?
- Does the data plane follow the observed route, and can the firewall/NAT support asymmetric or changed return paths?
What this cannot control
No attribute lets you command every remote AS. You cannot assume prepending changes traffic when remote local preference is decisive; MED may be ignored or compared differently; a provider community works only within the provider's documented scope. Avoid promising deterministic inbound balancing from BGP attributes alone. For critical services, use resilient capacity, health checks, provider coordination and application-aware failover.
Interview answer
“Inbound BGP traffic engineering is influence, not control. I would first use the provider's documented communities, then consider AS_PATH prepending or MED for the intended scope. I would verify the exported route and observe propagation from several external vantage points, while remembering that remote local preference and policy can override my signals.”
Post a Comment