A huge part of your CCNP certification study is all about BGP, and BGP is a highly complex protocol - and as you'll learn from future studies, it seems that the more you learn about it, the more complex it becomes!
Never fear! As with any protocol, most problems are caused by basic misconfiguration. BGP is no exception, because the #1 issue with most BGP configurations happens during configuration, and it all boils down to one question -
"Why aren't my neighbors forming an adjacency?"
Sure, you're going to have more-complex issues than this (and we'll look at a few of them later in this section), but let's face it - before we can start worrying about route advertisement, AS_PATHs, and the rest, we've got to have our BGP adjacencies in place. After all, if two routers cannot form an adjacency, we're going to have a real problem advertising routes between the two of them!
There's going to be a great deal of redundancy in a typical BGP deployment, and that's great - we always want to avoid that single point of failure, especially with BGP. For that reason, many BGP deployments use loopback addresses to form adjacencies and use as the source of BGP updates. In the following network, if the 172.12.123.0 segment goes down, the BGP adjacency will be lost if the neighbor commands are using the 172.12.123.0 /24 IP addresses to form the adjacency. But if they use the loopback interfaces instead, the secondary path will be used as long as the involved routers still have a route to each other's loopbacks.
We'll now configure a BGP adjacency using the loopback addresses of each router. As you're about to see, the router will also tell you if you get a bit confused and try to form a neighbor relationship with yourself!
R1(config)#router bgp 100
R1(config-router)#neighbor 3.3.3.3 remote-as 300
R1(config-router)#no synch
R1(config-router)#neighbor 3.3.3.3 update-source loopback0
R3(config-if)#router bgp 300
R3(config-router)#no synch
R3(config-router)#neighbor 3.3.3.3 remote-as 100
% Cannot configure the local system as neighbor
R3(config-router)#neighbor 1.1.1.1 remote-as 100
R3(config-router)#neighbor 1.1.1.1 update-sour loopback0
We have the AS numbers right, and the update-source command is in place, so we've avoided two common errors already. Let's check the adjacency tables.
The status is Idle and the up/down value shows as "never", so we've got a fundamental problem here. One concern when using loopbacks to form BGP adjacencies is that the routers must have an IGP route to the loopback - in other words, R3's got to know where 1.1.1.1 is or no adjacency is going to take place! We'll use RIPv2 on both routers to advertise the respective loopbacks.
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto
R1(config-router)#network 172.12.0.0
R1(config-router)#network 1.0.0.0
R3(config)#router rip
R3(config-router)#version 2
R3(config-router)#no auto
R3(config-router)#network 172.12.0.0
R3(config-router)#network 3.0.0.0
Let's look at the RIP table on R1, try to ping R3's loopback from there, and look at the state of the BGP adjacency.
R1 has the route to R3's loopback, can ping R3's loopback.... and still cannot form a BGP adjacency with that loopback. What's the issue?
It's rare that you'll see this one, but it does happen. These two routers are in different autonomous systems, making them potential eBGP neighbors. BGP assumes that potential eBGP neighbors are directly connected, resulting in the ebgp-multihop default being 1. That's not the case here, as R1 is not directly connected to R3's loopback. Therefore, we've got to change the ebgp-multihop default.
R3(config-router)#router bgp 300
R3(config-router)#neighbor 1.1.1.1 ebgp-multihop ?
<1-255> maximum hop count
<cr>
R3(config-router)#neighbor 1.1.1.1 ebgp-multihop 2
R1(config)#router bgp 100
R1(config-router)#neighbor 3.3.3.3 ebgp-multihop 2
About 30 seconds after adding this configuration, the BGP state goes to Active. Shortly after that, the adjacency reaches Established state and the adjacency is up.
Just in case, always check the adjacency from the other side as well.
To test the redundancy, we'll shut down the 172.12.123.0 /24 network.
The BGP adjacency remains Established thanks to the redundant connection over the 172.12.13.0/24 network - and that we used loopbacks to establish the adjacency instead of the IP addresses from the 172.12.123.0/24 network.
There's quite a bit that can go wrong with a BGP adjacency! Watch the details, take the eBGP / iBGP configuration into account, and you'll be troubleshooting configurations like this in no time - not to mention earning your CCNP certification and paving the way for your CCIE studies!
To your success,
Chris Bryant
CCIE #12933