BGP Neighbor/Advising Routes with loopback interfaces

Creating BGP neighbors with physical interfaces can become troublesome when that interface is changed or is flapping, best practice is to create neighbors with loopback interfaces that are always up if the router is. Additional commands are needed to create a neighbor with loopback interfaces and an extra command is needed for EBGP peers.

The update source command is needed to change the interface from a physical interface to a loopback. The ebgp multihop command is required to tell BGP how many hops away the loopback interface is.

R1(config)#router bgp 100
R1(config-router)#neighbor 3.3.3.3 remote-as 200

R1(config-router)#neighbor 3.3.3.3 update-source loopback 0

R1(config-router)#neighbor 3.3.3.3 ebgp-multihop 2

R3(config)#router bgp 200

R3(config-router)#neighbor 1.1.1.1 remote-as 100        

R3(config-router)#neighbor 1.1.1.1 update-source loopback 0

R3(config-router)#neighbor 1.1.1.1 ebgp-multihop 2

The neighborship between R1 and R3 still won't happen unless they know how to reach each others loopback addresses. A static route can accomplish this.

R1(config)#ip route 3.3.3.3 255.255.255.255 172.12.123.3
R3(config)#ip route 1.1.1.1 255.255.255.255 172.12.123.1

With routes to each others loopbacks the adjacency comes up.

R3(config)#
*Mar  1 00:39:47.866: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

Verifying the BGP adjacency with the show ip bgp summary command.

R1#show ip bgp sum
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
3.3.3.3         4   200       4       4        1    0    0 00:00:32        0

Below I create adjacencies between R1 and R2, no ebgp multi-hop command is needed because these are internal BGP peers, both in AS 100.

R1(config)#router bgp 100

R1(config-router)#neighbor 2.2.2.2 remote-as 100

R1(config-router)#neighbor 2.2.2.2 update-source loopback 0

R2(config)#router bgp 100

R2(config-router)#neighbor 1.1.1.1 remote-as 100

R2(config-router)#neighbor 1.1.1.1 update-source loopback 0

R2(config-router)#       

*Mar  1 00:44:01.574: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up 

R1 now has adjacencies with both R2 and R3.

R1#show ip bgp sum

BGP router identifier 1.1.1.1, local AS number 100

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

2.2.2.2         4   100       4       4        1    0    0 00:00:42        0

3.3.3.3         4   200       8       8        1    0    0 00:04:55        0

Similar to OSPF, to advise a route into BGP we use the network command along with the actual mask not the inverse mask. The mask isn't required but can cause problems when classful boundaries are overlapping. 

R3(config)#router bgp 200

R3(config-router)#network 3.3.3.3 mask 255.255.255.255

R3(config-router)#network 33.33.33.33 mask 255.255.255.255     

The show ip bgp command will show the routes learned by BGP. Both routes are valid and best. BGP has many attributes that decide which route is valid and best when multiple routes to a destination are known.

R1#show ip bgp   

BGP table version is 4, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 3.3.3.3/32       3.3.3.3                  0             0 200 i

*> 33.33.33.33/32   3.3.3.3                  0             0 200 i