BGP next-hop behaviour in broadcast network type

[umeshpathrwal10]

Hello  

Please find  topology   below 

(AS100) R1( 10.0.0.1/24)-----Switch1------(10.0.0.2/24) R2( AS 200)

                                                  |

                                                 R3 (10.0.0.3/24) (AS300)

R1 is ebgp neigbhor  with  R2 and R2  is  ebgp  neighbor with R3.

At R1 -- a  network is  advertised in BGP , say (1.1.1.1/32)

on R3 --  1.1.1.1/32 is  received with next- hop  10.0.0.1 . Please  advise why   such  behaviour , in normal  scenerio it should be bgp peer ip .

 configuration ++++

R1

R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.0.1 YES manual up up
FastEthernet1/0 unassigned YES unset administratively down down
FastEthernet1/1 unassigned YES unset administratively down down
FastEthernet2/0 unassigned YES unset administratively down down
FastEthernet2/1 unassigned YES unset administratively down down
Loopback500 1.1.1.1 YES manual up up
R1#sh run | sec bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 10.0.0.2 remote-as 200
no auto-summary
R1#R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.0.1 YES manual up up
FastEthernet1/0 unassigned YES unset administratively down down
FastEthernet1/1 unassigned YES unset administratively down down
FastEthernet2/0 unassigned YES unset administratively down down
FastEthernet2/1 unassigned YES unset administratively down down
Loopback500 1.1.1.1 YES manual up up
R1#sh run | sec bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 10.0.0.2 remote-as 200
no auto-summary
R1#
R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.0.1 YES manual up up
FastEthernet1/0 unassigned YES unset administratively down down
FastEthernet1/1 unassigned YES unset administratively down down
FastEthernet2/0 unassigned YES unset administratively down down
FastEthernet2/1 unassigned YES unset administratively down down
Loopback500 1.1.1.1 YES manual up up
R1#sh run | sec bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 10.0.0.2 remote-as 200
no auto-summary
R1#

R2++++

R2#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.0.2 YES manual up up
FastEthernet1/0 unassigned YES unset administratively down down
FastEthernet1/1 unassigned YES unset administratively down down
FastEthernet2/0 unassigned YES unset administratively down down
FastEthernet2/1 unassigned YES unset administratively down down
R2#sh run | sec bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 100
neighbor 10.0.0.3 remote-as 300
no auto-summary
R2#sh ip bgp summ
BGP router identifier 10.0.0.2, local AS number 200
BGP table version is 6, main routing table version 6
1 network entries using 128 bytes of memory
1 path entries using 52 bytes of memory
1/1 BGP path/bestpath attribute entries using 124 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 328 total bytes of memory
BGP activity 1/0 prefixes, 3/2 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.1 4 100 35 36 6 0 0 00:27:18 1
10.0.0.3 4 300 35 38 6 0 0 00:28:21 0
R2#

R3+++

R3#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.0.3 YES manual up up
FastEthernet1/0 unassigned YES unset administratively down down
FastEthernet1/1 unassigned YES unset administratively down down
FastEthernet2/0 unassigned YES unset administratively down down
FastEthernet2/1 unassigned YES unset administratively down down
R3#sh run | sec bgp
router bgp 300
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.2 remote-as 200
no auto-summary
R3#sh ip bgp summ
BGP router identifier 10.0.0.3, local AS number 300
BGP table version is 6, main routing table version 6
1 network entries using 128 bytes of memory
1 path entries using 52 bytes of memory
1/1 BGP path/bestpath attribute entries using 124 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 328 total bytes of memory
BGP activity 1/0 prefixes, 3/2 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.2 4 200 38 36 6 0 0 00:29:03 1
R3#sh ip bgp
BGP table version is 6, local router ID is 10.0.0.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.0.1 0 200 100 i
R3#

[Harold Ritter]

This behaviour is referred to as third party next hop. It is described in RFC4271 section 5.1.3.

https://tools.ietf.org/html/rfc4271#section-5.1.3

- If the route being announced was learned from an internal
           peer or is locally originated, the BGP speaker can use an
           interface address of the internal peer router (or the
           internal router) through which the announced network is
           reachable for the speaker for the NEXT_HOP attribute,
           provided that peer X shares a common subnet with this
           address.  This is a form of "third party" NEXT_HOP attribute.

Regards, 

[umeshpathrwal10]

Thanks  Harold, 

But  here in this case ,

R1 is  in AS -100

R2 is  in AS -200

R3 is  in AS -300

Forming  ebgp  peer  between R1-R2 and R2-R3,  No  ebgp  peer  between R1 and R3 .

All three  routers  are  connected  by  L2  switch  sharing  same subnet .

Question- Any  network being  advertised via R1 to  R2 and then from R2 to  R3 carries  next-hop address of R1 , why  so ??????? 

[Harold Ritter]

This is exactly the goal of the third party next hop feature. R2 knows the NH for R1 is on the same subnet as NH to R3, so will not change that NH when advertising updates from R1 to R3 or vice versa.

Regards,