Categories R&S

BGP – implement and troubleshoot Peerings – Update Source Modification

To improve a BGP network redundancy, we might want to establish a peering over two different links.
Update Source Modification can be used in this case.



BGP peering doesn’t require a direct connection between two neighbors.
But the IP source used to establish the peering is the IP address of the outgoing interface.



Change the peering between R1 and R2 so that if the ethernet connection goes down, the peering is still establish over the serial link.



We just had a new serial connection between R1 and R2.

A new loopback is also created on both of them.



Configuration and verification:

The network /28 is part of OSPF area 0.

The loopbacks 1 on R1 and R2 are also in OSPF area 0.


Now let’s change the peering between R1 and R2 and use their loopback 1 address for the neighbor command.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router bgp 100
R1(config-router)#no neighbor remote-as 100
*Jul  6 19:55:29.853: %BGP_SESSION-5-ADJCHANGE: neighbor IPv4 Unicast topology base removed from session  Neighbor deleted
*Jul  6 19:55:29.856: %BGP-5-ADJCHANGE: neighbor Down Neighbor deleted
R1(config-router)#neighbor remote-as 100

R2(config)#router bgp 100
R2(config-router)#no neighbor remote-as 100
R2(config-router)#neighbor remote-as 100


Well doesn’t seems to work as I didn’t received the info in the log…


Let’s troubleshoot this.

I can ping R2’s loopack1 from R1:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms


BGP summary says the session is idle:

R1#sh ip bgp sum
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd        4          100       0       0        1    0    0 never    Idle


BGP neigh command says the state is idle, no so much more information except at the bottom where it says “No active TCP connection”:

R1#sh ip bgp neigh
BGP neighbor is,  remote AS 100, internal link
  BGP version 4, remote router ID
  BGP state = Idle
  Neighbor sessions:
    0 active, is not multisession capable (disabled)
  No active TCP connection


Let’s try to catch some debug output by creating an access-list and turning on debug ip packet.

R1(config)#access-list 100 permit tcp host host
R1(config)#access-list 100 permit tcp any host
R1# R1#debug ip packet 100 detail
IP packet debugging is on (detailed) for access list 100


As you can see the packet is sent with source ip address of R2 Ethernet0/0, R1 is awaiting a TCP session to be establish with the source of

*Jul  6 20:07:08.884: IP: s= (Ethernet0/0), d=, len 44, input feature
*Jul  6 20:07:08.884:     TCP src=39925, dst=179, seq=1502406074, ack=0, win=16384 SYN, MCI Check(99), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FA
*Jul  6 20:07:08.884: FIBipv4-packet-proc: route packet from Ethernet0/0 src dst


Now in order to solve this, we need to use the update-source bgp command.

R1(config)#router bgp 100
R1(config-router)#neighbor update-source lo1


And then the session is establish:

R1(config-router)#                 do sh ip bgp sum
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd        4          100       7       7       11    0    0 00:00:19        1


Now, if we bring down the ethernet link between R1 and R2, the BGP session is still establish.

R1(config)#int Ethernet0/0

R2#sh ip bgp sum
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd        4          100      44      43       11    0    0 00:33:03        1



Using the loopback interface for iBGP peering is a good idea when you have different path to reach a neighbor.



Thank you for reading.



BGP – implement and troubleshoot Peerings – Update Source Modification