Yes, but only when the BGP session is initiated by the router w/ the proper "update-source" configured. When the router w/out "update-source" tries to initiate, it will source its IP packets from the pTp interface closest to the remote router. Since the remote router is configured to peer w/ the loopback, and not the pTp interface, it will disregard the packets that it receives from this unconfigured neighbor.
this is right:
this output from the router (w/out update-source command)
*Mar 1 00:23:43.535: TCP: sending SYN, seq 730879118, ack 0
*Mar 1 00:23:43.539: TCP0: Connection to 18.104.22.168:179, advertising MSS 536
*Mar 1 00:23:43.539: TCP0: state was CLOSED -> SYNSENT [11003 -> 22.214.171.124(179)]
*Mar 1 00:23:43.587: TCP0: state was SYNSENT -> CLOSED [11003 -> 126.96.36.199(179)]
*Mar 1 00:23:43.587: TCP0: bad seg from 188.8.131.52 -- closing connection: port 11003 seq 0 ack 730879119 rcvnxt 0 rcvwnd 0 len 0
*Mar 1 00:23:43.591: TCP0: connection closed - remote sent RST
*Mar 1 00:23:43.591: TCB 0x64E1D324 destroyed
*Mar 1 00:24:14.067: TCB64E1D324 created
*Mar 1 00:24:14.067: TCP0: state was LISTEN -> SYNRCVD [179 -> 184.108.40.206(11005)]
*Mar 1 00:24:14.071: TCP0: Connection to 220.127.116.11:11005, received MSS 536, MSS is 516
*Mar 1 00:24:14.071: TCP: sending SYN, seq 4173950892, ack 838907728
*Mar 1 00:24:14.071: TCP0: Connection to 18.104.22.168:11005, advertising MSS 536
*Mar 1 00:24:14.135: TCP0: state was SYNRCVD -> ESTAB [179 -> 22.214.171.124(11005)]
*Mar 1 00:24:14.135: TCB64E13804 callback, connection queue = 1
*Mar 1 00:24:14.139: TCB64E13804 accepting 64E1D324 from 126.96.36.199.11005
*Mar 1 00:24:14.215: %BGP-5-ADJCHANGE: neighbor 188.8.131.52 Up
when the router initiated the TCP session, it didn't work and the session was closed and when the other router (update-source command configured)
initiated the TCP session, it worked.
this is fine but do they need to confirm the update source each time they send updates?, or only while TCP sesseion?
Thank you all for your replies
The "neighbor" command does not control which routes are advertised.
The "update-source" command only sets the source IP address of the IP packets which carry BGP control messages. It does not set the BGP next-hop field in BGP UPDATE messages. Setting next-hop is a function of whether the session is iBGP or eBGP - if you configure update-source on an iBGP session, you'll see that the next-hop on eBGP-learned routes is unchanged when readvertising to iBGP neighbors.
If you want to change the next-hop when readvertising, you have to configure "next-hop-self". Be careful w/ that one; it will cause routing loops if you do it in the wrong place in a network.
Actually I didn't mean to underestimate you at all, I may mean something differes from you are talking about as follows:
Neighbor x.x.x.x command by directly connected interface:
R1 R2 router bgp 100 router bgp 200 no synchronization no synchronization bgp log-neighbor-changes bgp log-neighbor-changes network 184.108.40.206 neighbor 10.1.1.1 remote-as 100 neighbor 10.1.1.2 remote-as 200 no auto-summary no auto-summary
R2#sh ip bgp
BGP table version is 2, local router ID is 220.127.116.11
Network Next Hop Metric LocPrf Weight Path
*> 18.104.22.168 10.1.1.1 0 0 100 i
Neighbor x.x.x.x command by Loopback interface:
R1#sh running-config | sec bgp R2#sh run | sec bgp router bgp 100 router bgp 200 no synchronization no synchronization bgp log-neighbor-changes bgp log-neighbor-changes network 22.214.171.124 neighbor 126.96.36.199 remote-as 100 neighbor 188.8.131.52 remote-as 200 neighbor 184.108.40.206 ebgp-multihop 2 neighbor 220.127.116.11 ebgp-multihop 2 neighbor 18.104.22.168 update-source Loopback2 neighbor 22.214.171.124 update-source Loopback1 no auto-summary no auto-summary
R2#sh ip bgp
BGP table version is 4, local router ID is 126.96.36.199
Network Next Hop Metric LocPrf Weight Path
*> 188.8.131.52 184.108.40.206 0 0 100 i
so what I meant, according to the neighborship command, the nexthop will be the same.
my question is regardless eBGP or iBGP, what fills the nexthop in the update message?(neighbor IP address or the update-source of the remote nerighbor) and is the update message cosidered a control message or not?
Thank you all for your care.
Next-hop behavior is built into the BGP protocol (http://tools.ietf.org/html/rfc4271#section-5.1.3). For most cases when readvertising a route to an eBGP neighbor, by default the next-hop is set to the local IP address that terminates the BGP session. When readvertising to iBGP neighbor, by default the next-hop is unchanged.
You posit that update-source sets next-hop, but your session is eBGP. It's the fact that the session is eBGP which causes a router to rewrite the next-hop to the local IP address it used for establishing the session. I think a testbed like this one would be more helpful to you:
R1 --eBGP-- R2 --iBGP-- R3
Configure the R2--R3 iBGP session w/ update-source Loopback<N>. Have R1 advertise some routes to R2. R2 will readvertise those routes to R3. On R3, do "show ip bgp", and look at the next-hops of the routes learned from R2. You should see that the next-hop is R1 (and not R2, despite it having update-source configured toward R3).
Edit: I've attached a GNS3 lab topo+config's.
BGP-update-source.zip 2.8 K
I thought of another way to prove that update-source doesn't set next-hop. When you have update-source only on one side of an eBGP session, after the session establishes and routes are exchanged, you will see that the router which is missing "update-source Loopback<n>" still sets the next-hop to its loopback as it advertises to the other router.