Internet Multihoming and Traffic Engineering
Internet Multihoming and Traffic Engineering
This domain tests how an AS connects to more than one upstream and uses BGP attributes - not IGP metrics - to steer traffic in each direction.
Inbound versus outbound
Outbound traffic (you sending) follows your own best-path selection, so LOCAL_PREF and local policy decide it. Inbound traffic (others sending to you) is chosen by your neighbors, so you only influence it with AS_PATH prepending, MED, or ISP-supplied communities. You never control inbound directly.
Common designs: single-homed, dual-homed to one ISP, multihomed with provider-aggregatable (PA) space, and multihomed with provider-independent (PI) space and your own ASN. Only PI space plus your own ASN gives stable inbound policy across providers, because with PA space the covering aggregate is announced by one provider and inbound naturally follows that announcement.
Worked example
Two ISPs, A and B, both announcing your /24. To make inbound prefer A, apply an export policy on the eBGP sessions toward B that prepends your AS three times (as-path-prepend "65000 65000 65000") and leave A untouched. Outbound, set local-preference 200 on routes learned from A so your own traffic also leaves via A. If A fails, B still has a path - longer, but present. For finer inbound control, ask ISP A for the customer community that sets local-pref 200 inside its network.
Traps
Using MED for inbound across two different ISPs - MED is not comparable across ASes and is often stripped. Prepending on the wrong session: prepending toward B affects what B and its customers choose, not what A does. Assuming prepending is precise; it is blunt and can divert traffic to an unintended third path. Announcing more-specifics that conflict with provider filters and create leaks.