Description
When an external peer (ExaBGP) has an AS number equal to the confederation identifier (AS 65000), FRR does not install the route in RIB2 or propagate it to R3. In contrast, both GoBGP and Batfish accept the route and propagate it through the confederation normally.
Version
How to reproduce
The test topology is: ExaBGP (AS 65000) → R2 (Member-AS 65010, Confed ID 65000) → R3 (Member-AS 65011, Confed ID 65000).
ExaBGP config (conf.ini):
process announce-routes {
run python exabgp/example.py;
encoder json;
}
neighbor 6.0.0.2 {
router-id 6.0.0.3;
local-address 6.0.0.3;
local-as 65000;
peer-as 65000;
api {
processes [announce-routes];
}
}
ExaBGP route announcement (example.py):
announce route 100.0.0.0/8 next-hop self
R2 config (frr.conf):
router bgp 65010
no bgp ebgp-requires-policy
bgp confederation identifier 65000
bgp confederation peers 65011
neighbor 6.0.0.3 remote-as 65000
neighbor 8.0.0.3 remote-as 65011
neighbor 8.0.0.3 route-map SET_LOCAL_PREF out
exit
!
route-map SET_LOCAL_PREF permit 10
set local-preference 100
exit
!
R3 config (frr.conf):
router bgp 65011
no bgp ebgp-requires-policy
bgp confederation identifier 65000
bgp confederation peers 65010
neighbor 8.0.0.2 remote-as 65010
exit
!
Expected Behavior
Based on GoBGP and Batfish behavior:
- R2 should accept the route from ExaBGP (100.0.0.0/8) into its RIB (AS_PATH: empty).
- R2 should propagate the route to R3 with AS_CONFED_SEQUENCE prepended: AS_PATH = (65010).
GoBGP result: R2 RIB ✅ (AS_PATH: empty), R3 RIB ✅ (AS_PATH: (65010))
Batfish result: R2 RIB ✅ (AS_PATH: empty), R3 RIB ✅ (AS_PATH: 65010)
Actual Behavior
FRR result: R2 RIB ❌ (no route), R3 RIB ❌ (no route)
FRR does not install the route at R2 at all. The route from ExaBGP (AS 65000) is rejected, likely because FRR sees the peer's AS (65000) matching the confederation identifier (65000) and applies self-AS / loop-detection semantics, preventing the route from being accepted. But both GoBGP and Batfish accept this route in the same configuration.
Additional context
No response
Checklist
Description
When an external peer (ExaBGP) has an AS number equal to the confederation identifier (AS 65000), FRR does not install the route in RIB2 or propagate it to R3. In contrast, both GoBGP and Batfish accept the route and propagate it through the confederation normally.
Version
How to reproduce
The test topology is: ExaBGP (AS 65000) → R2 (Member-AS 65010, Confed ID 65000) → R3 (Member-AS 65011, Confed ID 65000).
ExaBGP config (conf.ini):
ExaBGP route announcement (example.py):
R2 config (frr.conf):
R3 config (frr.conf):
Expected Behavior
Based on GoBGP and Batfish behavior:
GoBGP result: R2 RIB ✅ (AS_PATH: empty), R3 RIB ✅ (AS_PATH: (65010))
Batfish result: R2 RIB ✅ (AS_PATH: empty), R3 RIB ✅ (AS_PATH: 65010)
Actual Behavior
FRR result: R2 RIB ❌ (no route), R3 RIB ❌ (no route)
FRR does not install the route at R2 at all. The route from ExaBGP (AS 65000) is rejected, likely because FRR sees the peer's AS (65000) matching the confederation identifier (65000) and applies self-AS / loop-detection semantics, preventing the route from being accepted. But both GoBGP and Batfish accept this route in the same configuration.
Additional context
No response
Checklist