12-22-2013 12:52 AM - edited 03-04-2019 09:55 PM
Hi,
I just started learning BGP protocol today, i have some confusion, when we using loopback interface to connect other ebgp using different AS, we have to mention three commands to get neighbor up using non-directly connected interface, the two which i highlighted below is mandatory, i try remvoe this cmd no neighbor 2.2.2.2 update-source lo 0, but the neighbor won't down, its still show BGP state = Established
. (R1 and R2 already advertise loop interface via RIP v2), please explain why and how this neighbor up and even i remove no update source cmd.
R1<---->R2
S111#sh run | sec bgp
router bgp 111
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 222
neighbor 2.2.2.2 ebgp-multihop 2
no auto-summary
AS222#sh run | sec bgp
router bgp 222
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 111
neighbor 1.1.1.1 ebgp-multihop 2
no auto-summary
AS111#sh ip bgp summ
BGP router identifier 192.168.2.1, local AS number 111
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 222 32 33 1 0 0 00:30:15 0
AS111#sh ip bgp neighbors
BGP neighbor is 2.2.2.2, remote AS 222, external link
BGP version 4, remote router ID 192.168.1.2
BGP state = Established, up for 00:30:24
Last read 00:00:12, last write 00:00:11, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
New ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Solved! Go to Solution.
12-23-2013 08:20 PM
Hi Feroz,
Just as Jon mentioned, when BGP was established, you have update-source command in you config, hence the TCP session between both the host was established ( BGP relies on underlying TCP for session establishment). Once the session is built, even though you remove update-source command, it will not affect the existing TCP session, as no new TCP is getting built between the two, the TCP three-way handshake process is already completed and now it is only keepalive which would be sent periodically to keep session up. One can argue that if keepalive are sent to and from loopback ip's why session is not torn, reason is that you already have route to loopback ip's in routing table and since for BGP TCP session is already established, it will continue to send keepalives.
Also, as you noticed that when you clear the BGP session, it went to active state as it was then when TCP was trying to establish session with its peer with mentioned IP in the configs, though those IP's were reachable, BGP by default when forming eBGP session sets the TTL to 1.
One way to circumvent is as you know ebgp multihop.
Another way to do the same thing is to disable connect check for that neighbour.
Regards,
Smitesh
PS: Please rate helpful posts.
12-22-2013 02:21 AM
So you didn't have update source set on either side? How long did you wait to see if it went down? Default timers for BGP is 60 seconds keepalive and 180 seconds hold time.
Daniel Dib
CCIE #37149
12-22-2013 02:27 AM
till now it's up,
AS111#sh ip bgp neighbors
BGP neighbor is 2.2.2.2, remote AS 222, external link
BGP version 4, remote router ID 192.168.1.2
BGP state = Established, up for 02:05:08
Last read 00:00:17, last write 00:00:16, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
New ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 0 0
Keepalives: 126 125
Route Refresh: 0 0
Total: 127 126
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 1/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Address tracking is enabled, the RIB does have a route to 2.2.2.2
AS111#sh run | sec bgp
router bgp 111
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 222
neighbor 2.2.2.2 ebgp-multihop 2
no auto-summary
AS111#
AS222#sh run | sec bgp
router bgp 222
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 111
neighbor 1.1.1.1 ebgp-multihop 2
no auto-summary
AS222#
12-22-2013 02:55 AM
i try clear ip bgp * now it's went to Active state
AS222#sh ip bgp summary
BGP router identifier 2.2.2.2, local AS number 222
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 111 151 150 0 0 0 00:02:50 Active
AS222#sh ip bgp neighbors
BGP neighbor is 1.1.1.1, remote AS 111, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:03:01, last write 00:03:01, hold time is 180, keepalive interval is 60 seconds
Message statistics:
12-23-2013 01:35 AM
It is Active now because you have removed the command and now a new session cannot be formed.
I can't test it but i assume that when you removed the command initially the BGP session was already up and running so it just continued to use the loopback address in it's updates.
This is a common case with BGP, where you need to reset the session before your new configuration is used.
Jon
12-23-2013 08:20 PM
Hi Feroz,
Just as Jon mentioned, when BGP was established, you have update-source command in you config, hence the TCP session between both the host was established ( BGP relies on underlying TCP for session establishment). Once the session is built, even though you remove update-source command, it will not affect the existing TCP session, as no new TCP is getting built between the two, the TCP three-way handshake process is already completed and now it is only keepalive which would be sent periodically to keep session up. One can argue that if keepalive are sent to and from loopback ip's why session is not torn, reason is that you already have route to loopback ip's in routing table and since for BGP TCP session is already established, it will continue to send keepalives.
Also, as you noticed that when you clear the BGP session, it went to active state as it was then when TCP was trying to establish session with its peer with mentioned IP in the configs, though those IP's were reachable, BGP by default when forming eBGP session sets the TTL to 1.
One way to circumvent is as you know ebgp multihop.
Another way to do the same thing is to disable connect check for that neighbour.
Regards,
Smitesh
PS: Please rate helpful posts.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide