cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3470
Views
10
Helpful
6
Replies

BGP Update-source

Mahesh Gohil
Level 7
Level 7

Hello Experts,

I am confused as what is the use of update-source with ebgp and ibgp.

I have performed some test in lab with

> configured bgp session between directly connected link ..peering is loopback to loopback..not configured any update-source at either end but still bgp is up

====A-End======

interface Loopback99
ip address 10.0.0.81 255.255.255.255
end

router bgp 1234
neighbor 10.100.66.2 remote-as 4567
neighbor 10.100.66.2 ebgp-multihop 3
!
address-family ipv4
  neighbor 10.100.66.2 activate
exit-address-family


====B-End======

interface Loopback99
ip address 10.100.66.2 255.255.255.255
end

interface Loopback1978
ip address 95.95.95.1 255.255.255.255
no ip directed-broadcast
end

router bgp 4567
neighbor 10.0.0.81 remote-as 1234
neighbor 10.0.0.81 ebgp-multihop 3
!
address-family ipv4
neighbor 10.0.0.81 activate
exit-address-family

> Also I have shutdown the directly connected link and route traffic to some other link but still bgp is up even though update-source is not configured.

> Same behavior observed when I configured IBGP session between two routers...bgp is up

Any idea as what exactly use of update-source

Regards

Mahesh

 

1 Accepted Solution

Accepted Solutions

Hello Mahesh,

It seems that for some reason, your routers were using the Loopback interfaces. This is from your output:

Router A:

Local host: 10.0.0.81, Local port: 30492
Foreign host: 10.100.66.2, Foreign port: 179

Router B:

Local host: 10.100.66.2, Local port: 179
Foreign host: 10.0.0.81, Foreign port: 30492

I guess that if you just removed the update-source command after the BGP peering was already established, it did not cause the session to reset, so it simply continued working. I guess that is logical... when you create a socket in an operating system, you can assign it a local address (using the bind() call). After that, when you establish the connection, the local socket address is maintained even if the next socket would be assigned a different address. Perhaps if you totally cleared the BGP process, or deconfigured the neighbor entirely and then put it back without the update-source command, the adjacency would not go up until you used the update-source again.

That's my guess about it right now.

Best regards,

Peter

View solution in original post

6 Replies 6

Peter Paluch
Cisco Employee
Cisco Employee

Hi Mahesh,

Your issue is very interesting. I was not actually able to replicate your behavior. If I peered two routers in an IBGP by referencing their loopback addresses but not using the update-source on either side, the BGP adjacency did not go up as expected. I needed to use the update-source on at least one router of the two to actually get it going. Please see the attached PCAP file using Wireshark to see what I saw - the two peering routers are 10.255.255.1 (R1 Loopback0) and 10.255.255.3 (R3 Loopback0), and their Serial interface addresses are 10.0.12.1 (R1) and 10.0.23.3 (R3); there was an intermediate router R2 between the two.

I suspect some gotcha in the way you built your experiment but I cannot see anything explanatory yet.

Can you perhaps post the full output of the show ip bgp neighbor X.X.X.X from one of your routers?

Best regards,

Peter

Hello Peter,

I was expecting your reply.

I am attaching output from both the end..This output is taken when two peer was directly connected. If you want I can route it to some other path

and provide output.(will have output when ebgp peer is not directly connected) I have also captured TCP interaction debug output from one of the router.

One more query :As you told update-source is required atleast on one router...can ou explain in detail please

NOTE: AS number is changed in my first post. Output attached contains actual AS number.

Regards

mahesh

Hello Mahesh,

Nice to talk to you again! I will need some more time going over the output you have provided - sorry about the delay but there's some work around right now I need to do.

Just a few words about your question with the update-source being configured on at least one side: Consider this config:

Router R1:

router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 10.255.255.3 remote-as 1
neighbor 10.255.255.3 update-source Loopback0
no auto-summary

Router R3:

router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 10.255.255.1 remote-as 1
no auto-summary

A key thing to remember here is that both R1 and R3 will at some points in time try to actively establish a TCP connection to each other.

When R3 tries to establish the TCP connection with R1, it sends its packets to the destination 10.255.255.1 but the source IP will be the address of the outgoing interface, in my case, 10.0.23.3. The R1 will not recognize the sender, and as a result, it will respond with TCP RST segment. However, when R1 tries to establish the TCP connection with R3, it will source its packets from 10.255.255.1 (its Lo0) and send it towards 10.255.255.3. The R3 will recognize such BGP peer, and just like every well-behaved TCP/IP stack implementation, if R3 has been contacted on its address 10.255.255.3, it will respond using this very address so the replies will be recognized by R1 and the BGP adjacency will fire up.

So this configuration is actually workable but the problem is that the TCP session can be successfully established only by R1 sending TCP SYNs to R3, not vice versa.

Best regards,

Peter

Hello Peter,

Thanks for the wonderful explanation. The original issue was update-source at one end not at other end which is there in my production network

with IBGP.  But while performing test in lab I have tried by putting not update-source at both end (one side:GSR other side:7600) bgp came up

but now I am testing with some 3660 at both end and BGP is not coming up.

But anway I will await for the reply.

Regards

Mahesh

Hello Mahesh,

It seems that for some reason, your routers were using the Loopback interfaces. This is from your output:

Router A:

Local host: 10.0.0.81, Local port: 30492
Foreign host: 10.100.66.2, Foreign port: 179

Router B:

Local host: 10.100.66.2, Local port: 179
Foreign host: 10.0.0.81, Foreign port: 30492

I guess that if you just removed the update-source command after the BGP peering was already established, it did not cause the session to reset, so it simply continued working. I guess that is logical... when you create a socket in an operating system, you can assign it a local address (using the bind() call). After that, when you establish the connection, the local socket address is maintained even if the next socket would be assigned a different address. Perhaps if you totally cleared the BGP process, or deconfigured the neighbor entirely and then put it back without the update-source command, the adjacency would not go up until you used the update-source again.

That's my guess about it right now.

Best regards,

Peter

Hello Peter,

Thanks for reply.

I have removed all bgp config with no luck. Even I reloaded router at both end but bgp came up with source/destination as loopback

Local host: 10.0.0.81, Local port: 179
Foreign host: 10.100.66.2, Foreign port: 11012

Local host: 10.100.66.2, Local port: 11012
Foreign host: 10.0.0.81, Foreign port: 179

Any insight ?

Regards

Mahesh

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: