Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
bgpd: Enforce self-next-hop check in next-hop update.
Problem Description: ===================== +--+ +--+ |R1|-(192.201.202.1)----iBGP----(192.201.202.2)-|R2| +--+ +--+ Routes on R2: ============= S>* 202.202.202.202/32 [1/0] via 192.201.78.1, ens256, 00:40:48 Where, the next-hop network, 192.201.78.0/24, is a directly connected network address. C>* 192.201.78.0/24 is directly connected, ens256, 00:40:48 Configurations on R1: ===================== ! router bgp 201 bgp router-id 192.168.0.1 neighbor 192.201.202.2 remote-as 201 ! Configurations on R2: ===================== ! ip route 202.202.202.202/32 192.201.78.1 ! router bgp 201 bgp router-id 192.168.0.2 neighbor 192.201.202.1 remote-as 201 ! address-family ipv4 unicast redistribute static exit-address-family ! Step-1: ======= R1 receives the route 202.202.202.202/32 from R2. R1 installs the route in its BGP RIB. Step-2: ======= On R1, a connected interface address is added. The address is the same as the next-hop of the BGP route received from R2 (192.201.78.1). Point of Failure: ================= R1 resolves the BGP route even though the route's next-hop is its own connected address. Even though this appears to be a misconfiguration it would still be better to safeguard the code against it. Fix: ==== When BGP receives a connected route from Zebra, it processes the routes for the next-hop update. While doing so, BGP must ignore routes whose next-hop address matches the address of the connected route for which Zebra sent the next-hop update message. Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
- Loading branch information