Traffic Shifts to the Backup Transit After a Policy Change

Outbound path selection is decided by the local router, so the only thing that matters is what the router installed after applying its own import policy. On the ISP-B session, an import policy sets local-preference 250, which beats ISP-A's default 100 on the same prefix length. Best-path selection stops at step: highest local preference wins before AS path length, origin, MED, or router ID are even considered. So every prefix both ISPs advertise (including the default) is installed via ISP-B.

Evidence to collect:

1. show route 0.0.0.0/0 detail - compare the two paths: the ISP-B path shows Localpref 250 and is marked >, the ISP-A path shows 100.
2. show route receive-protocol bgp 198.51.100.1 detail - this shows the routes after import policy, which separates 'what the ISP sent' from 'what we changed'.
3. show configuration policy-options policy-statement <name> | display set - show the then local-preference 250 term and the fact that it has no from clause restricting it.
4. show bgp neighbor 198.51.100.1 | match Import - confirm which policy is bound to the session.

This is entirely independent of the prepend; the prepend only explains the inbound direction.

Inbound traffic is controlled by what other networks learn from us. A policy exported toward ISP-A changes what ISP-A hears, and therefore changes the AS path length that the rest of the Internet sees for AS 65001 through ISP-A.

Prepending 65001 three times on the ISP-A export makes the path '65001 65001 65001 65001' as seen via ISP-A, while the ISP-B export is unchanged at '65200 65001'. Every other network now sees a shorter AS path through ISP-B and prefers it for our prefixes, so inbound traffic arrives via ISP-B - the opposite of the intended outcome. The engineer applied the prepend to the wrong session.

Confirm with:

• show route advertising-protocol bgp 192.0.2.1 - shows the prepended AS path we send to ISP-A.
• show route advertising-protocol bgp 198.51.100.1 - shows the clean path we send to ISP-B.
• A looking glass in a third AS to see the path as the Internet chooses it.

Rule to state explicitly: inbound traffic control is done by modifying the export policy on the backup ISP (prepend there), never by prepending on the primary.

The two faults are independent and must be fixed in the right order, because fixing one exposes the other.

1. Remove the temporary local-preference 250 from the ISP-B import policy (or delete the policy binding from the ISP-B session). This restores outbound traffic to ISP-A immediately; without it, egress stays on the metered 1 Gbps circuit and keeps dropping.
2. Remove the AS-path prepend from the ISP-A export policy. Inbound returns to ISP-A because the path we advertise to ISP-A is now the same length as the ISP-B path, and the shorter/lower-router-ID path wins for the Internet.
3. If inbound balancing is genuinely required later, prepend only on the ISP-B export, only for selected prefixes, and only after confirming the ISP-B circuit has capacity for the inbound traffic it will attract. A three-hop prepend on ISP-B for all prefixes would be far too coarse for a 10:1 capacity ratio.

Guardrails:

• Use commit confirmed 5 for each step so a mistake auto-reverts.
• Confirm each step with show route 0.0.0.0/0 detail and show route receive-protocol bgp before moving to the next.
• Watch the ISP-B interface for egress rate and drops for 15 minutes after step 1.
• Do not remove both policies in one commit; separate commits tell you which change moved the traffic, which matters when the change record is reviewed.