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 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.
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.
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.
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:
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 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
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?
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:
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.
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?
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.
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
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?
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 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?
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 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