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
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 now has adjacencies with both R2 and R3.
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 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
