Because BGP peerings use TCP for transport, it is not a requirement that neighbors be directly connected. When neighbors are not directly connected, the choice of IP addresses used in peering can greatly affect the redundancy design of a BGP network. In the previous case, the peering between R4 and R5 was configured using their connected DMVPN Tunnel interface IP addresses. This implies that if the DMVPN link were to go down, the BGP peering would also go down, even if alternate routes still existed between the two devices. To fix this redundancy issue, the update-source for a BGP peering session can be changed on a per-neighbor basis.
Normally the IP source address used in a BGP packet is the IP address of the outgoing interface in the routing table. For example, before the above modifications, R5 used the address 177.1.0.4 to reach R4 for the BGP peering
R5#show ip route 177.1.0.4
Routing entry for 177.1.0.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via eigrp 100 Routing Descriptor Blocks: * directly connected, via Tunnel0 Route metric is 0, traffic share count is 1
R5#show ip interface brief | include Tunnel0
Tunnel0 177.1.0.5 YES NVRAM up up
Based on the fact that R5 routes out Tunnel0 to reach 177.1.0.4, the source address in the IP packet is 177.1.0.5. Observe what occurs with the BGP session when this interface is down
R5
interface Tunnel0 shutdown
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 177.1.0.2 (Tunnel0) is down: interface down %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 177.1.0.4 (Tunnel0) is down: interface down %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=169.254.100.5, prot=50, spi=0x2E21953F(773952831), srcaddr=169.254.100.4, input interface=GigabitEthernet0/0
R5#show ip route 177.1.0.4
Routing entry for 177.1.0.0/24 Known via "eigrp 100", distance 90, metric 26880256, type internal Redistributing via eigrp 100 Last update from 177.1.45.4 on GigabitEthernet0/1, 00:00:49 ago Routing Descriptor Blocks: * 177.1.45.4, from 177.1.45.4, 00:00:49 ago, via GigabitEthernet0/1 Route metric is 26880256, traffic share count is 1 Total delay is 50010 microseconds, minimum bandwidth is 100 Kbit Reliability 255/255, minimum MTU 1400 bytes Loading 1/255, Hops 1
With a route to 177.1.0.4 pointing out of the GigabitEthernet0/1 interface, the BGP session is lost, even though the GigabitEthernet0/1 link could have been used for rerouting. The session is torn down because R4 is still using its DMVPN Tunnel interface and sourcing packets from 177.1.0.4 to get to R5 (177.1.0.5). However, R5 is using its GigabitEthernet0/1 interface and sourcing packets from 177.1.45.5 to get to R4 (177.1.0.4):
configure terminal access-list 100 permit tcp host 177.1.45.5 host 177.1.0.4 access-list 100 permit tcp any host 177.1.45.5 debug ip packet detail 100 debug ip bgp
BGP: 177.1.0.5 active went from Idle to Active BGP: 177.1.0.5 open active, local address 177.1.0.4 IP: s=177.1.45.5 (GigabitEthernet0/1), d=177.1.0.4, len 44, input feature TCP src=15097, dst=179, seq=1989083684, ack=0, win=16384 SYN, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 177.1.45.5 dst 177.1.0.4 FIBfwd-proc: Default:177.1.0.4/32 receive entry FIBipv4-packet-proc: packet routing failed IP: tableid=0, s=177.1.45.5 (GigabitEthernet0/1), d=177.1.0.4 (Tunnel0), routed via RIB IP: s=177.1.45.5 (GigabitEthernet0/1), d=177.1.0.4, len 44, rcvd 4 TCP src=15097, dst=179, seq=1989083684, ack=0, win=16384 SYN IP: s=177.1.45.5 (GigabitEthernet0/1), d=177.1.0.4, len 44, stop process pak for forus packet TCP src=15097, dst=179, seq=1989083684, ack=0, win=16384 SYN IP: s=177.1.45.5 (GigabitEthernet0/1), d=177.1.0.4, len 44, enqueue feature TCP src=15097, dst=179, seq=1989083684, ack=0, win=16384 SYN, TCP Adjust MSS(5), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE FIBipv4-packet-proc: route packet from (local) src 177.1.0.4 dst 177.1.45.5 FIBfwd-proc: packet routed by adj to GigabitEthernet0/1 177.1.45.5 FIBipv4-packet-proc: packet routing succeeded IP: s=177.1.0.4 (local), d=177.1.45.5 R4# (GigabitEthernet0/1), len 40, sending TCP src=179, dst=15097, seq=0, ack=1989083685, win=0 ACK RST IP: s=177.1.0.4 (local), d=177.1.45.5 (GigabitEthernet0/1), len 40, sending full packet TCP src=179, dst=15097, seq=0, ack=1989083685, win=0 ACK RST
Based on the debug, we can see that the session attempts establishment, but R4 replies with ACK RST, refusing and closing the session. This is because R5’s route to 170.1.4.4 is out the GigabitEthernet0/1 link, causing the source IP address to be 177.1.45.5. R4 has its neighbor statement pointing at 177.1.0.5, not 177.1.45.5, so the connection is refused. The important thing to remember here is that the TCP server of the BGP session must approve where the session is coming from. If the SYN packet arrives from an address that is not specified in a neighbor statement, the connection is refused. To remedy this, the neighbor statement on R4 can be changed to point to 177.1.45.5 instead of 177.1.0.5
R4
configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
router bgp 100 no neighbor 177.1.0.5 neighbor 177.1.45.5 remote-as 100
R4#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100 R4# BGP: 177.1.67.7 Active open failed - no route to peer, open active delayed 14336ms (35000ms max, 60% jitter) R4# BGP: 177.1.146.6 Active open failed - no route to peer, open active delayed 6144ms (35000ms max, 60% jitter) R4# BGP: 177.1.0.3 open failed: Connection timed out; remote host not responding BGP: 177.1.0.3 Active open failed - tcb is not available, open active delayed 8192ms (35000ms max, 60% jitter) BGP: ses global 177.1.0.3 (0x121680A8:0) act Reset (Active open failed). BGP: 177.1.0.3 active went from Active to Idle BGP: nbr global 177.1.0.3 Active open failed - open timer running BGP: nbr global 177.1.0.3 Active open failed - open timer running R4# BGP: 177.1.146.6 Active open failed - no route to peer, open active delayed 11264ms (35000ms max, 60% jitter) R4# FIBipv4-packet-proc: route packet from (local) src 177.1.0.4 dst 177.1.45.5 FIBfwd-proc: packet routed by adj to GigabitEthernet0/1 177.1.45.5 FIBipv4-packet-proc: packet routing succeeded IP: s=177.1.0.4 (local), d=177.1.45.5 (GigabitEthernet0/1), len 59, sending TCP src=179, dst=61306, seq=835527728, ack=992200671, win=16183 ACK PSH IP: s=177.1.0.4 (local), d=177.1.45.5 (GigabitEthernet0/1), len 59, sending full packet TCP src=179, dst=61306, seq=835527728, ack=992200671, win=16183 ACK PSH IP: s=177.1.45.5 (GigabitEthernet0/1), d=177.1.0.4, len 40, input feature TCP src=61306, dst=179, seq=992200671, ack=835527747, win=16145 ACK, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 177.1.45.5 dst 177.1.0.4 FIBfwd-proc: Default:177.1.0.4/32 receive entry
Now R5 sends a SYN to 177.1.0.4 (R4’s Tunnel 0 address), sourced from 177.1.45.5 (R5’s GigabitEthernet0/1). Because R4 already has a neighbor statement for 177.1.45.5, SYN ACK is returned and the session opens:
BGP: 177.1.67.7 Active open failed - no route to peer, open active delayed 6144ms (35000ms max, 60% jitter)
If the peering between physical interfaces is reverted and R4 and R5 are configured via their Loopback0 addresses, this problem can be avoided. If one of the links between the neighbors goes down, the peering is simply rerouted based on the convergence of IGP:
Routing entry for 170.1.4.4/32 Known via "eigrp 100", distance 90, metric 130816, type internal Redistributing via eigrp 100 Last update from 177.1.45.4 on GigabitEthernet0/1, 00:00:17 ago Routing Descriptor Blocks: * 177.1.45.4, from 177.1.45.4, 00:00:17 ago, via GigabitEthernet0/1 Route metric is 130816, traffic share count is 1 Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
R5#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
interface GigabitEthernet0/1 shutdown
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 177.1.45.4 (GigabitEthernet0/1) is down: interface down R5(config-if)# %LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state to administratively down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
R5#show ip route 170.1.4.4
Routing entry for 170.1.4.4/32 Known via "eigrp 100", distance 90, metric 25984000, type internal Redistributing via eigrp 100 Last update from 177.1.0.4 on Tunnel0, 00:00:39 ago Routing Descriptor Blocks: * 177.1.0.4, from 177.1.0.4, 00:00:39 ago, via Tunnel0 Route metric is 25984000, traffic share count is 1 Total delay is 15000 microseconds, minimum bandwidth is 100 Kbit Reliability 255/255, minimum MTU 1400 bytes Loading 2/255, Hops 1
In this scenario, R5 prefers to route over the GigabitEthernet0/1 interface to reach Loopback0 of R4 because of the EIGRP composite metric. The cost to reach R4's Loopback0 via R5's Tunnel interface is much higher. However, as soon as the GigabitEthernet0/1 interface of R5 is disabled, EIGRP convergence reroutes traffic via the next-best path toward R4. Observe that the BGP session does not go down.
Note that technically, only one neighbor needs to add the update-source command, as long as both agree on the destination of the peering. If R4 sets the update source to Loopback 0, but R5 does not, this ensures that R4 is always the TCP client and R5 is always the TCP server. In most designs, the update sources are modified on both sides for clarity.
