Route Reflectors, Equal Local Preference, and a 70/30 Egress Split

What is happening. With local preference equal and BR-1's AS path shorter (4 vs 5), standard best-path selection keeps only BR-1's route. A 70/30 split therefore means two routes are installed in the forwarding table, which only happens when multipath is enabled with a relaxed AS-path-length check (the Junos equivalent of multipath multiple-as). The 70/30 ratio is not a policy outcome; it is the flow-hashing distribution of two installed next hops. Nothing in BGP chose 70/30.

Minimum change. Decide first whether you want load sharing or primary/backup.

For primary/backup:

1. Raise local preference on BR-1's received eBGP routes for the affected prefixes via an inbound policy on the provider session. Local preference must be set on the route as received at BR-1; setting it anywhere else does not change egress selection.
2. Remove multipath for that prefix set (or drop the relaxed AS-path option), so only the preferred next hop is installed.
3. Let the new local preference propagate to the PEs through the reflector; verify with show route <prefix> detail on an eastern PE.

For load sharing by design: keep multipath but accept that the ratio is hash-driven and unstable, and set it with local preference and per-prefix policy rather than expecting BGP to produce a ratio.

Use a community as the signalling mechanism so the prefix list lives in one place and operators do not have to keep two border policies in sync.

1. Tag at the source. On the CE-facing or customer-facing sessions (or in the redistribution policy), attach a standard community such as 65010:200 to the 40 prefixes:

set policy-options policy-statement cust-in term mark from prefix-list-list COMMERCIALS
set policy-options policy-statement cust-in term mark then community add NO-EXIT-BR2
set policy-options policy-statement cust-in term mark then accept

2. Act at BR-2. Inbound from the reflectors/iBGP, match the community and set local preference low (for example 50) so the route is retained as a backup but never preferred:

set policy-options policy-statement from-ibgp term no-br2 from community NO-EXIT-BR2
set policy-options policy-statement from-ibgp term no-br2 then local-preference 50

3. Act at BR-1. Match the same community and set local preference high (200) so it is unambiguously primary.

Points of care.

• Standard communities are transitive over iBGP, so they reach both borders from any PE; do not strip them on the reflectors.
• If the tag is to cross an eBGP boundary you must add send-community; for the stated requirement it must not leak to providers, so do not send it.
• Verify with show route <prefix> community 65010:200 on both borders and confirm the two local preferences differ.
• Because BR-2 keeps the route at low preference, traffic still has a path if BR-1 fails, which is usually what is actually wanted.

Use remote-triggered blackhole with an explicit no-export guard.

1. Trigger. A control host announces the victim /32 to both borders with a blackhole community, for example 65010:666.

2. Action at each border. Match the community on the inbound policy and set the next hop to a discard address:

set policy-options policy-statement rtbh term bh from community BLACKHOLE
set policy-options policy-statement rtbh term bh then next-hop 192.0.2.1
set policy-options policy-statement rtbh term bh then tag 666
set policy-options policy-statement rtbh term bh then accept

On the interface side, 192.0.2.1 is a discard route (set routing-options static route 192.0.2.1 discard), so matched traffic is dropped at ingress to the AS rather than being carried across the core.

3. Containment. Attach no-export (or no-advertise between the borders if you do not want the trigger visible internally) to the blackholed prefix. This is the piece people forget: without it, the /32 is a more specific route and will be advertised to both providers, and you have effectively blackholed the victim from the whole internet rather than from your own edge.

4. Filter check. The /32 must survive the outbound prefix filters on the provider sessions in the direction you need it to; normally you want it blocked outbound. Confirm the outbound policy denies anything tagged 666 before the general permit term. Also confirm the blackhole is not redistributed into the IGP, where a discard next hop would attract traffic from every router in the AS.

5. Verify. show route <victim>/32 on both borders shows the discard next hop, and show route advertising-protocol bgp <provider peer> shows nothing for the /32.