Internal BGP (Border Gateway Protocol) explained

Hello NetworkLessons Crew and Readers,

Two things Rene:

  • First wanted to point out, as a friend, you have a grammatical error in this lesson in this sentence,

Are we done now? Almost…there’s one more thing I want to learn you about the IBGP neighbor adjacencies…

  • Second thing is, when R1 is trying to reply to the 192.168.23.0 subnet, you advertise 192.168.45.0 on R5 as the fix for the failed pings from R3. Why did you do it this way and how does it work?

Thanks,
Austin

1 Like

Hello Austin

Thanks for pointing out the typo, I’ll let Rene know and he’ll have that fixed. It’s always helpful when users point these out so we can provide the best quality material for everyone. Thanks for helping out!!

As for your second question, the original connectivity test that was made was a ping from R5 to 1.1.1.1 on R1. This is the communication that initially failed. So in order to troubleshoot this, Rene went to R3, and R2 to determine if from those routers, 1.1.1.1 is accessible. The original test is not connectivity from R1 to the 192.168.23.0 subnet.

Now 1.1.1.1 was “pingable” from R2 but not from R3. What was the reason? It was determined that R1 did not know how to reach the 192.168.23.0/24 subnet. So the ping reached R1, but R1 didn’t know how to reply to that destination of 192.168.23.3.

Now we don’t need R1 to be able to know how to get to 192.168.23.0/24, but this gives us a clue as to why the ping from R5 didn’t work. The reason the ping from R5 didn’t work was because R1 didn’t know how to reach the 192.168.45.0/24 subnet which contains the source IP address of the ping. So for pings from R5 to 1.1.1.1, they reached R1 but didn’t know how to get back to 192.168.45.5.

The solution was to have R5 advertise this network using BGP. Via BGP, R1 learns this subnet, and can now respond to the ping.

I hope this has been helpful!

Laz

1 Like

Thanks Austin, just fixed this!

Rene

Dear Rene,

Thanks for your explanation,
I just wanted to know why we did not add the “network 192.168.12.0 mask 255.255.255.0” in router 1?
if we do not need it, why we added “network 192.168.45.0 mask 255.255.255.0” in Router 5.
I am still confused.
Thanks in advance.

Hello Wisam

BGP is used to share particular destination networks between BGP routers. In this lesson, the goal is to allow R5 to reach the loopback interface of R1. This is why The 192.168.12.0/24 subnet is not a destination that needs to be advertised to the rest of the network. Note that the 1.1.1.0/24 network is the only network being advertised by BGP.

This is an area where BGP differs from IGPs. For IGPs, it is conventional to include all directly connected networks on a router in the routing protocol operation in order to allow connectivity between routers. BGP however is only interested in the destination networks that user traffic will want to go to. All of the inter-router routing is taken care of by conventional IGPs such as OSPF in this case.

I hope this has been helpful!

Laz

1 Like

Hi,

When I connect R4 with the AS 2 with R5 with the AS 3 and vice versa I got a error message saying

Feb 25 09:33:43.659: %BGP-3-NOTIFICATION: received from neighbor 192.168.45.4 active 2/2 (peer in wrong AS) 2 bytes 0005

What did I do wrong??

Hello Mohamud

Remember that between R4 and R5, you are configuring eBGP. This means that the two routers must be in different AS’es as you mention in your post. The configuration of BGP for these two routers should be:

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

Notice the AS numbers in all commands. The AS in which R4 has been configured must match the AS of the neighbor command in the other router. The same is true about the AS in which R5 has been configured, as it should be the same AS as the neighbor command configured in R4.

If these AS numbers don’t match, you get the error message stated in your post. Take a look at your configs to verify this and let us know.

I hope this has been helpful!

Laz

1 Like

I know what the problem is, I used the router number for each bgp for example:
Router1: router bgp 1
Router 2: router bgp 2
router 3: router bgp 3
Router 4: router bgp 4
Router 5: router bgp 5

I did’t know that the IBGP routers needed to use the same bgp ID

1 Like

Hello Rene,

I have a question. So R5 needs to ping Loopback of R1. Now R1 does advertise it’s Loopback IP in EBGP to R2. But R2 never advertises the scope 1.1.1.0/24 IP in neither IBGP nor OSPF. So how does R4 learn route to 1.1.1.0/24 and how does it advertise it to R5?

Thanks.

Hello Kunj

From the moment that R1 is a BGP neighbor of R2 using eBGP, and from the moment that R1 is configured to share the 1.1.1.0/24 network with R2, this prefix has entered into the BGP table of R2. The following commands achieve the neighbor relationship as well as the advertising of the 1.1.1.0/24 network:

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

This results in the particular prefix showing up in the BGP table of R2:

R2#show ip bgp
BGP table version is 2, local router ID is 2.2.2.2
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       192.168.12.1             0             0 1 i

From the moment it enters the BGP table of R2, it can then be advertised using iBGP to the rest of the iBGP peers in AS2.

I hope this has been helpful!

Laz

1 Like

Hi, in the last step of the lesson when R5 advertises its network to R1. How does R1 know that the next hop is R2 and not R5 since BGP doesnt change the next hop?

Hello Alexis

You’re absolutely right, that BGP doesn’t change the next hop IP address by default. However, in the lesson, because we saw that this presented a problem when R4 couldn’t find the next hop IP, the next-hop-self command was implemented on R2 and R4. So when the 192.168.45.0 network is advertised by R5 via BGP, it reaches R2, and R2 in turn advertises it to R1.

But R2 has the next-hop-self command implemented, so the route it shares with R1 will have 192.168.12.2 as the next hop, as can be seen from the output of the show ip bgp command on R1:

R1#show ip bgp
BGP table version is 3, 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
*> 192.168.45.0     192.168.12.2                           0 2 3 i

Notice the next hop IP address for the 192.168.45.0 network is that of R2.

I hope this has been helpful!

Laz

1 Like

Dear Rene,
I tried to use packet tracer but it doesn’t support for IBGP configuration any other other do you recommend?

Thanks

I cannot use packet tracer for IBGP confgiuration do we have alternative

Hello Dinesh

It is true that Packet Tracer does not support iBGP. However, you can use several other options. Some of the most popular are GNS3, which is free, or VIRL, which is Cisco’s emulator, which has a subscription cost. You can find out more about these at the following lesson:

Note that the content says that GNS3 doesn’t support switching, but this has since changed. But for iBGP, you’re all set with

I hope this has been helpful!

Laz

1 Like

Hi Rene

A quick question…Let us assume R1 and R25 are two routers within an AS trying to establish iBGP via their loopbacks, they already have connectivity via IGP and next-hop-self, update-source is configured as well. If the TTL value of BGP packet is 1, How do those routers become peers when they are multiple hops away? Is it because the BGP packet is encapsulated into underlying OSPF/MPLS protocol header?

Thank you
Sai

Hello Sai

iBGP peers don’t have a limitation as to the number of hops they are away from each other. The TTL for BGP packets sent between iBGP peers is always set to the maximum, just like any other IP packets. The only prerequisite for iBGP peering is that there is a routable path between BGP peers.

This limitation however does exist for eBGP. If you have two eBGP routers and you want to have them peer using a loopback as the update-source, then peering will not occur unless the eBGP multihop feature is used. You can find out more information about this at the eBGP multihop lesson.

I hope this has been helpful!

Laz

2 Likes

Hi Rene,

I have a question. Why actually we need OSPF here and why alone iBGP is not enough. We are already configuring IBGP between all 3 routers in the same AS. So not able to understand the role of OSPF here? Is it only because R2 and R4 not connected. If yes, why? Whether OSPF would be required if there is direct connection between R2 and R4?

Hello Maruti

This is a good question, and is important in order to understand the relationship between IGPs and BGP. Think about it this way. BGP is used to route traffic between AS’es while IGPs are used to route traffic within AS’es.

Now the next question that usually comes up is “since we’re using iBGP within an AS, why configure OSPF as well?”. Actually, iBGP within an AS is not used to route the traffic within the AS, but is used to share internal routes with the BGP routers on the edge of the AS so that they can advertise them with other BGP routers in other AS’es via eBGP.

So in order for iBGP to share these routes with all iBGP routers within an AS, routing capabilities between all BGP enabled routers within the AS via an IGP must be established.

Remember that an IGP is always better to use within an AS rather than BGP. You can find out more about why at the following post:

I hope this has been helpful!

Laz

2 Likes

Hi Rene / Laz and Team,

I am trying to recreate this in GNS3 LAB and came with an issue. While creating the IBGP between R2 and R4, please explain why we need update-source command. Because without it I am unable to make the neighborship.

In my lab, i cannot make the IBGP peer without the update-source command. Here is my config:

adding the diagram and

R2#ping 4.4.4.4       
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R2#show ip bgp summar
BGP router identifier 192.168.23.2, local AS number 1
BGP table version is 4, main routing table version 4
1 network entries using 140 bytes of memory
1 path entries using 76 bytes of memory
1/1 BGP path/bestpath attribute entries using 136 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 376 total bytes of memory
BGP activity 2/1 prefixes, 2/1 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
4.4.4.4         4            1       0       0        1    0    0 00:11:26 Idle
192.168.12.1    4            2      30      29        4    0    0 00:22:56        1
R2#show runn | sec bgp
ipv6 multicast rpf use-bgp
router bgp 1
 bgp log-neighbor-changes
 neighbor 4.4.4.4 remote-as 1
 neighbor 192.168.12.1 remote-as 2

R4:

R4#show ip bgp summar
BGP router identifier 4.4.4.4, local AS number 1
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            1       0       0        1    0    0 00:12:57 Idle
192.168.45.5    4            3      18      17        1    0    0 00:12:57        0
R4#show runn | sec bgp
ipv6 multicast rpf use-bgp
router bgp 1
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 1
 neighbor 192.168.45.5 remote-as 3
R4#show ip int brief | i up
Ethernet0/0            192.168.45.4    YES manual up                    up      
Ethernet0/2            192.168.34.4    YES manual up                    up      
Loopback0              4.4.4.4         YES manual up                    up

BGP_IBGP