iBGP Design: Hidden Routes and an Unintended Exit Point

By default a BGP speaker leaves the NEXT_HOP attribute untouched when advertising to an iBGP peer. BR1 therefore hands IR1 the next hop it learned from ISP-A, which is the address on the BR1-to-ISP-A link. That subnet is not in OSPF - the IGP only carries loopbacks and internal links - so IR1 has no route to the next hop and the prefix is unusable.

The path is still in the table but hidden, which is why the symptom looks like a policy problem and is not one.

Two fixes:

1. next-hop-self on the iBGP sessions on BR1 (and BR2). BR1 rewrites the next hop to its own loopback, which IR1 already reaches via OSPF. This is the standard answer for a mesh where edge routers are the only exit points.
2. Carry the external link subnets in the IGP so the real next hop is reachable. Works, but it puts ISP-facing addresses into your IGP and lets an ISP link failure trigger an IGP event; it also stops working the moment the external link is unnumbered.

Prefer next-hop-self, and verify with show route 203.0.113.0/24 detail on IR1 - the next hop should be BR1's loopback and the route should lose the hidden flag.

Junos BGP selection order is local preference, then AS-path length, then origin, then MED, then eBGP over iBGP, then IGP cost, then router ID.

For the two locally originated defaults, local preference is 100 on both and AS-path length is 1 on both (65100 vs 65200). Nothing in the earlier steps separates them, so the decision falls through to IGP cost to the next hop or, failing that, router ID - effectively an accident of topology. That is exactly why traffic drifts to ISP-B.

The fix is local preference: set 200 on the default (and on the ISP-A-learned routes) as it leaves BR1 toward iBGP peers, or set it on import at IR1. LOCAL_PREF is a discretionary attribute carried inside iBGP, so it propagates across the mesh and is not sent to either ISP.

MED will not work: by default MED is only compared between paths from the same neighbouring AS, and here the two defaults come from different ASes, so the comparison never happens. Prepending toward ISP-B is also wrong here - it would change inbound traffic engineering toward ISP-B, and the AS-path lengths of the two defaults are already equal anyway, so you would be manipulating an attribute that does not decide this outcome.

Two conditions:

1. The paths must be equal at every decision point above multipath: same local preference, same AS-path length, same origin, and the same MED or no MED comparison (different neighbour ASes again). If local preference differs - which is exactly what you just did to force ISP-A - the paths are not equal and no multipath setting will install both.
2. Multipath must be permitted across different neighbour ASes. Junos requires the multipath option on the BGP group, and by default only paths from the same neighbouring AS are eligible; with two different ISPs you also need the multiple-AS form, otherwise only one path is installed.

What breaks it in practice:

• Any per-ISP policy (local preference, MED, prepending) intended to prefer one provider will silently disable load sharing.
• Return traffic is not under your control: you can balance outbound and still get all return traffic on one link, and asymmetric flows can trip stateful devices in the path.
• Per-flow hashing means balance is statistical; with few large flows one ISP can still saturate.

A cleaner alternative is to keep ISP-A preferred for the default and use the second provider only as a backup, accepting that capacity is idle except during failure.