Internal BGP (Border Gateway Protocol) explained

In this lesson, we’ll take a look at IBGP (Internal BGP). Students new to BGP often wonder why we have “external” and “internal” BGP. I’m not going to show you just a couple of quick commands but we’ll take a close look at IBGP and its configuration.

Let’s start with an example topology, and I’ll explain a couple of things:

Above, you see three autonomous systems and five routers. When AS1 wants to reach AS3, we have to cross AS2. This makes AS2 our transit AS. This is a typical scenario where AS1 and AS3 are customers and AS2 is the ISP.

In our scenario, AS1 has a loopback interface with network 1.1.1.0 /24, and AS3 wants to reach this network. This means we’ll have to advertise this network through BGP. Here’s what it looks like:

 

So what is going on here? Let me explain it step-by-step:

1. We need EBGP between AS1 and AS2 because these are two different autonomous systems. This allows us to advertise a prefix on R1 in BGP so that AS2 can learn it.
2. We also need EBGP between AS2 and AS3 so R5 can learn prefixes through BGP.
3. We need to get the prefix that R2 learned from R1 somehow to R5. We do this by configuring IBGP between R2 and R4, this allows R4 to advertise it to R5.

So that’s the first reason we need IBGP…so you can advertise a prefix from one autonomous system to another. You might have a few questions after reading this:

1. Why don’t we use OSPF (or EIGRP) on AS2 instead and redistribute the prefix on R2 from BGP into OSPF and on R4 from OSPF back into BGP?
2. Doesn’t IBGP have to be directly connected?
3. How are R2 and R4 able to reach each other through IBGP if we don’t have any routing protocol within AS2?
4. What about R3? do we need IBGP?

These are some of the questions I get all the time from students who are learning BGP. Here are the answers:

1. Technically this is possible…we can run OSPF (or EIGRP) within AS2 and use redistribution between BGP and OSPF. In my example, R1 will only have a single prefix, so it’s no problem, but what if R1 had a full internet routing table? (over 900,000 prefixes since 2023). IGPs like OSPF or EIGRP are not able to handle that many prefixes so you’ll need BGP for this.
2. IBGP does not have to be directly connected, this might be a little confusing when you only know about OSPF or EIGRP since they always form adjacencies on directly connected links.
3. They are not! This is why we need an IGP within the AS. Since R2 and R4 are not directly connected, we’ll configure an IGP so that they can reach each other.
4. I’ll give you the answer to this question in a bit…I want to show you what will go wrong if we don’t configure R3 🙂

Enough reading for now. Let’s get our hands dirty with some configuration. We’ll start with BGP between R1/R2, R2/R4, and R4/5 as I just described.

Configuration

First, we’ll configure R1 and R2. I am also advertising a prefix (on a loopback interface) in BGP:

R1(config)#interface loopback 0
R1(config-if)#ip address 1.1.1.1 255.255.255.0

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 remote-as 2
R1(config-router)#network 1.1.1.0 mask 255.255.255.0

R2(config-router)#neighbor 192.168.12.1 remote-as 1

That’s easy enough, just a few commands. Our next step will be to configure IBGP between R2 and R4…what IP addresses are we going to use for this? Let’s look at our options:

R2#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.12.2    YES NVRAM  up                    up
FastEthernet1/0            192.168.23.2    YES NVRAM  up                    up

R4#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.34.4    YES NVRAM  up                    up
FastEthernet1/0            192.168.45.4    YES NVRAM  up                    up

I can use any of these IP addresses, but we need connectivity. That’s why we need an IGP like we talked about earlier. So, which IP addresses will we select? In this particular scenario, it really doesn’t matter since there is only 1 path between R2 and R4. What if we had multiple paths between R2 and R4?

When there are multiple paths, it’s better to use a loopback interface with an IP address and to advertise that into your IGP. We will use the loopback interface as the source for our BGP session. Why?

A physical interface can go down, which means the IP address on the interface is no longer reachable. A loopback interface will never go down unless the router crashes or when you “shut” it. This is why it’s best practice to use loopback interfaces when configuring IBGP.

I’ll add a loopback interface on R2 and R4 and use these for IBGP, we’ll have to configure an IGP (I’ll use OSPF) to advertise them:

R2(config)#interface loopback 0
R2(config-if)#ip address 2.2.2.2 255.255.255.0

R4(config)#interface loopback 0
R4(config-if)#ip address 4.4.4.4 255.255.255.0

That takes care of the loopback interfaces. Now we can enable OSPF:

R2(config)#router ospf 1
R2(config-router)#network 192.168.23.0 0.0.0.255 area 0
R2(config-router)#network 2.2.2.0 0.0.0.255 area 0

R3(config)#router ospf 1
R3(config-router)#network 192.168.23.0 0.0.0.255 area 0
R3(config-router)#network 192.168.34.0 0.0.0.255 area 0

R4(config)#router ospf 1
R4(config-router)#network 192.168.34.0 0.0.0.255 area 0
R4(config-router)#network 4.4.4.0 0.0.0.255 area 0

Excellent, R2 and R4 will now be able to reach each other’s loopback interfaces. It’s not a bad idea to test this though:

R2#ping 4.4.4.4 source 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/52/60 ms

Alright we are now prepared for IBGP between R2 and R4. Here’s what it looks like:

R2(config)#router bgp 2
R2(config-router)#neighbor 4.4.4.4 remote-as 2
R2(config-router)#neighbor 4.4.4.4 update-source loopback 0

R4(config)#router bgp 2
R4(config-router)#neighbor 2.2.2.2 remote-as 2
R4(config-router)#neighbor 2.2.2.2 update-source loopback 0

This takes care of our IBGP session. Note that we have to use the update-source command to specify that we will use the loopback interfaces as the source for the IBGP session.

Last but not least, let’s configure EBGP between R4 and R5:

R4(config)#router bgp 2
R4(config-router)#neighbor 192.168.45.5 remote-as 3

R5(config)#router bgp 3
R5(config-router)#neighbor 192.168.45.4 remote-as 2

Great, that takes care of that. Whenever you configure BGP, you will see a message on the console that shows you that the neighbor adjacency has been established. You can also check it with the show ip bgp summary command.

Verification

If everything went OK, all routers should have learned about the 1.1.1.0 /24 prefix that I advertised on R1. Let’s see if that is true:

First, we’ll check R1:

R1#show ip bgp
BGP table version is 2, 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
*> 1.1.1.0/24       0.0.0.0                  0         32768 i

You can see that it is in the BGP table. This means that I successfully used the network command to advertise into BGP. The next hop is 0.0.0.0 since it originated on this router. If you don’t see anything here, then normally there are two reasons for this: