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 10.100.10.80 /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 10.100.10.2 remote-as 100 *Jul 6 19:55:29.853: %BGP_SESSION-5-ADJCHANGE: neighbor 10.100.10.2 IPv4 Unicast topology base removed from session Neighbor deleted *Jul 6 19:55:29.856: %BGP-5-ADJCHANGE: neighbor 10.100.10.2 Down Neighbor deleted R1(config-router)#neighbor 10.1.1.2 remote-as 100 R2(config)#router bgp 100 R2(config-router)#no neighbor 10.100.10.1 remote-as 100 R2(config-router)#neighbor 10.1.1.1 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:
R1#ping 10.1.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.2, 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 10.1.1.2 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 10.1.1.2 BGP neighbor is 10.1.1.2, remote AS 100, internal link BGP version 4, remote router ID 0.0.0.0 BGP state = Idle Neighbor sessions: 0 active, is not multisession capable (disabled) SNIP 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 10.1.1.1 host 10.1.1.2 R1(config)#access-list 100 permit tcp any host 10.1.1.1 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 10.1.1.2.
*Jul 6 20:07:08.884: IP: s=10.100.10.2 (Ethernet0/0), d=10.1.1.1, 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 10.100.10.2 dst 10.1.1.1
Now in order to solve this, we need to use the update-source bgp command.
R1(config)#router bgp 100 R1(config-router)#neighbor 10.1.1.2 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 10.1.1.2 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 R1(config-if)#shut R2#sh ip bgp sum Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.1.1 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