Problem
Batfish installs routes in the EVPN, BGP, and main RIBs that are not present on the corresponding Junos devices. This affects CE devices receiving leaked EVPN routes, and PE/leaf devices with extra EVPN table entries.
Technical Details
Three categories of extra routes:
-
EVPN RIB extras: Batfish's EVPN RIB includes locally-originated EVPN Type 5 routes (connected subnet redistributions) that do not appear in the device's show route table bgp.evpn.0. It also includes remotely received connected redistribution routes that the device does not display. Example: on node1-1, Batfish has 8 extra EVPN routes for connected subnets (172.16.100.0/24, 172.16.101.0/24, etc.) across multiple RDs from both local and remote PEs.
-
BGP route leak to CE: The CE device (edge1) has no BGP routes for 172.16.100.0/24 and 172.16.200.0/24 in its BGP RIB, but Batfish installs these via the eBGP session with the service PE. These are IRB connected subnets from the EVPN fabric that should not be advertised to the CE.
-
Extra underlay route: Batfish has 172.16.254.2/31 in the BGP and main RIBs of node2-1 and router1 that the devices do not have. This appears to be an underlay connected prefix being incorrectly distributed via iBGP.
Observed In
junos_evpn_type5 lab -- EVPN RIB validation on node1-1, node2-1, router1 (8 extra routes each); BGP RIB on edge1 (2 extra), node2-1 (1 extra), router1 (1 extra); main RIB on edge1 (2 extra), node2-1 (1 extra), router1 (1 extra).
Symptoms
Validation reports "Batfish has extra route" or "No_match_found_on_the_left" for routes that exist in Batfish but not on the device.
Configuration Patterns
Junos EVPN Type 5 topology with:
- Shared services VRF pattern (CE -> service PE -> EVPN fabric)
- IRB interfaces with connected subnets redistributed into EVPN
- Inter-VRF route leaking via vrf-target communities
- eBGP CE peering on service PE
Next Steps
Investigate EVPN Type 5 route export/import filtering to prevent:
- Connected subnet redistribution routes from leaking to CE peers
- Locally-originated EVPN routes appearing in the EVPN RIB
- Underlay prefixes being redistributed into overlay BGP
Problem
Batfish installs routes in the EVPN, BGP, and main RIBs that are not present on the corresponding Junos devices. This affects CE devices receiving leaked EVPN routes, and PE/leaf devices with extra EVPN table entries.
Technical Details
Three categories of extra routes:
EVPN RIB extras: Batfish's EVPN RIB includes locally-originated EVPN Type 5 routes (connected subnet redistributions) that do not appear in the device's
show route table bgp.evpn.0. It also includes remotely received connected redistribution routes that the device does not display. Example: on node1-1, Batfish has 8 extra EVPN routes for connected subnets (172.16.100.0/24, 172.16.101.0/24, etc.) across multiple RDs from both local and remote PEs.BGP route leak to CE: The CE device (edge1) has no BGP routes for 172.16.100.0/24 and 172.16.200.0/24 in its BGP RIB, but Batfish installs these via the eBGP session with the service PE. These are IRB connected subnets from the EVPN fabric that should not be advertised to the CE.
Extra underlay route: Batfish has 172.16.254.2/31 in the BGP and main RIBs of node2-1 and router1 that the devices do not have. This appears to be an underlay connected prefix being incorrectly distributed via iBGP.
Observed In
junos_evpn_type5 lab -- EVPN RIB validation on node1-1, node2-1, router1 (8 extra routes each); BGP RIB on edge1 (2 extra), node2-1 (1 extra), router1 (1 extra); main RIB on edge1 (2 extra), node2-1 (1 extra), router1 (1 extra).
Symptoms
Validation reports "Batfish has extra route" or "No_match_found_on_the_left" for routes that exist in Batfish but not on the device.
Configuration Patterns
Junos EVPN Type 5 topology with:
Next Steps
Investigate EVPN Type 5 route export/import filtering to prevent: