Bgp Update source

[mrityunjay singh]

Hello Folk,

I have connected two router point to point and using BGP to check the update source behavior.

R1--------------R2

R1:
Lo1 10.10.10.10
f0/0 10.10.10.1

R2
Lo1 11.11.11.11
f0/0 10.10.10.2

Configuration

R1:

router bgp 10
neighbor 10.10.10.2 remote-as 20

R2:

router bgp 20
neighbor 10.10.10.10 remote-as 10
neighbor 10.10.10.10 update sou lo1
neighbor 10.10.10.10 ebgp-multi 2

ip route 10.10.10.10 255.255.255.255 10.10.10.1

As per my understanding when we define update source then TCP packet sent from the interface defined as update source to the destination configured as neighbor under BGP.
At other end when peer reply on TCP 179 it reply from the physical interface as source to the destination address under BGP neighbor , if no update source configured.

R2 to R1 communication
Here when R2 should send update to R1 from 11.11.11.11 to address 10.10.10.10. When R1 see the packet it should check the source i.e 11.11.11.11 which is not configured as neighbor at R1.

R1 to R2 communication

When R1 send update to R2 source address will be 10.10.10.1 and destination will be neighbor 10.10.10.2 ,
once the packet arrived at R2 it will check the source address ( 10.10.10.1) that should be configured as neighbor at R2 ,So R2 should reject the packet.

If a router recieves a TCP connection request( to BGP port 179) from a source IP address that is not configured as BGP neibor , router rejects the request.

In my case BGP is established.Upon further check-up in Wireshark I see R2 is not using Lo1 as source address for sending TCP packet instead it using its physical address 10.10.10.2.

Not getting why the packet is not being send by Lo1 from R2.

[paul driver]

Hello

Are you sure the bgp peering is established as it doesn't seem viable to establish a peering like you have posted?

Also does R1 know how to get to the lo1 of R2 so R2 cannot source from it

res
Paul

[Masoud Pourshabanian]

Hello,

when R1 starts to communicate with R2, it uses the souce of 10.10.10.1 and destination of 10.10.10.2. This is TCP connection. The response of TCP is exchanging the source and destination. In this case R2 does not use its loopback as its source since it is responding(it can not use loopback because using loopback means a new session). They use both 10.10.10.1 and 10.10.10.2 for some messagess and then after that R2 reset the TCP connection.

When R2 starts the communication, it uses the source of 11.11.11.11. In this case, R1 resets the connection right away since it is waiting for 10.10.10.2.

If you wait a little longer, you see this behaviour.

Masoud

[Kevin Rivest · Accepted solution]

It matters on the order of configuration. Was the neighbor 10.10.10.10 update sou lo1 the last command you configured on R2?

If it was, the reason for what you are seeing is as follows.

When you configured R1, it sent a BGP open message with source 10.10.10.1 and destination 10.10.10.2. When R2 received this message it checked the source address with configured neighbors and when it did not match it rejected it.

When you configured the interfaces, static route, and initial BGP configuration on R2, R2 sent an open message sourced from 10.10.10.2 (the outgoing interface to 10.10.10.10) with a destination of 10.10.10.10. When R1 received this message it accepted it as the neighbor command matched the source. R1 then sent its own open message in response to R2 with a source address of 10.10.10.10 (as this was the destination of the message it is replying to) and a destination of 10.10.10.2 (as this was the source). R2 receives this message and finds the source address matches the neighbor command and accepts the message and the connection is established.

Once the TCP connection is established it will not be torn down without manual intervention, unless the TCP connection becomes stale due to inactivity.

When you then configured the update source on R2, it had no effect as the TCP connection was already established using the original addresses.

If you do a hard clearing of the BGP neighbor on R1 or R2 with clear ip bgp *, or if you clear the TCP connection on R1 or R2 with clear tcp tcb 0x0 (0x0 being whatever your TCB address is), it will reset the TCP connection. The BGP peer should now not come up as R2 will source its BGP open message with 11.11.11.11, which R1 will reject because it does not match the neighbor command.

Hope this is correct and answers your question. 

[mrityunjay singh]

Hi Kevin,

Many thanks for explaining this.

I think I faced this issue because tcp connection was already formed and then i was using updated source.

When I torn down the neighborship from R2 it working as expected.

Once again thank you all for replying.