bgpd: Force 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>

0 files changed, 0 insertions, 0 deletions