Junos EVPN Type 5: eBGP-learned routes not re-advertised to other eBGP peers

[dhalperi]

Problem

Batfish does not re-advertise eBGP-learned underlay routes to other eBGP peers on Junos devices. This results in missing multipath routes in the BGP RIB.

Technical Details

In a Clos-like topology where each leaf has eBGP sessions to two spines, remote link prefixes should be reachable via both spines:

• Path 1: direct eBGP advertisement from the spine that owns the link
• Path 2: re-advertisement through the other spine, which learned it via eBGP from the remote leaf

Batfish only installs Path 1. Path 2 never appears in the BGP RIB, not even as a backup — the re-advertisement from the second spine simply doesn't happen.

Example on node1-1 for 172.16.254.4/31 (the link between node2-1 and node1-2):

Device (show route protocol bgp):

• * AS 65011, NH 172.16.254.1 (direct from node2-1, which owns the link)
• * AS 65012 65002, NH 172.16.254.3 (via node2-2, which learned it from node1-2)

Batfish (routes(rib="bgp")):

• BEST AS 65011, NH 172.16.254.1 (only entry)

The route via node2-2 is completely absent. node2-2 has the route in its main RIB (via BGP from node1-2), its export policy (export-underlay) permits protocol bgp + route-filter 172.16.254.0/24 orlonger, and the import policy on node1-1 also permits it. The eBGP session between node2-2 and node1-1 is established. Yet the re-advertisement doesn't happen.

This affects all 4 remote link prefixes on every leaf — each only has 1 of the expected 2 ECMP paths.

Since multipath multiple-as is configured, both paths should be installed as ECMP. The missing re-advertisement means BGP multipath has no second path to install.

Because Batfish processes VRs in random order (toListInRandomOrder), which single path it picks as BEST can vary between runs, causing flaky lab validation results.

Observed In

junos_evpn_type5

Symptoms

• test_bgp_rib_routes flaky XPASS/xfail — AS path mismatches when Batfish's single route happens to differ from the device's first entry
• Only 1 BGP route per remote prefix instead of 2 ECMP paths
• Consistent across all nodes in the topology

Configuration Patterns

Junos eBGP underlay with export-underlay policy accepting protocol bgp, where spines re-advertise leaf-learned routes to other leaves.

Next Steps

Investigate why Batfish doesn't generate eBGP re-advertisements for routes learned from other eBGP peers on Junos. The export policy matches and the route is in the main RIB — the advertisement should be generated.