I am curious about the advertisement process. When R3 at the stage only runs OSPF, R4 already learned the advertised route 22.214.171.124/24 via ibgp neighbor R2. So how does R2 deliver this advertised route to R4 via R3, especially how does R3 process this advertised route when it only runs OSPF?
In the specific scenario, R3 does not participate in BGP. It does, however, participate in OSPF. This means that it is only via R3 that R2 and R4 can communicate with each other. This connectivity is achieved via OSPF. So, when R2 sends a BGP update to R4, the next hop IP of the message is that of R4. R3 will simply forward that packet like it would any other packet on the network.
So to answer your question, R3 doesn’t process the advertised route at all! Indeed, R3 knows nothing about the routes found behind R1 in AS1 and behind R5 in AS5.
I’m seeing some unexpected behavior with regard to peering using loopbacks.
From the labs I’ve been doing it seems that you can still establish an adjacency using loopbacks even if only one side has update-source loopback configured. For example:
If you have R1 configured to use a Lo0 as the update source but not on R2, but you are trying to peer using loopbacks, the following seems to happen (on packet captures):
R2 tries to peer with R1 using Gi0/1 as its source IP and R1’s Lo0 as its destination, the result is a TCP RST back from R1 - which makes sense, because it does have R2’s Gi0/1 IP configured as a neighbor.
However, when R1 tries to peer with R2 - and uses its Lo0 as its source and R2’s Lo0 as the destination - R2 replies (instead of also sending an RST) with Lo0 and not Gi0/1, and an adjacency continues to form.
I’m using OSPF for loopback reachability.
So it seems that BGP port 179 is listening on all IP addresses on the router, not just the update source. Is that correct?
It’s an interesting situation! The truth is that a BGP session takes place in both directions. If the configuration is correct for one direction to be established, as is the case for your R1, you will see from R1’s perspective that the session is established. From R2’s perspective, it is not.
Yes, that is correct. Update source will tell a router from which interface it should send BGP messages, it does not affect which interfaces a BGP router will accept BGP messages.
BGP in general should be deployed only for large-scale networks, where it makes sense to separate the network into autonomous systems. Typically you will find that ISPs deploy BGP to route within their networks, and to route traffic between their networks and neighboring ISP networks. You may also deploy BGP on the edge of your network if you are advertising public IP addresses to allow users on the Internet to have access to your internal services (like web servers, email servers or others…) More about this can be found at the following lesson.
eBGP is used by BGP routers that exchange routes between ASes, while iBGP is used to exchange routes within ASes. The protocol is the same, but the “i” and the “e” are simply used to denote that the exchange of routes is taking place between BGP routers within the same AS or between different ASes respectively.
So if the edge network of your company uses BGP with an AS of 100, and it peers with the ISP’s BGP router in AS 200, then eBGP will be used to exchange that information. Now the ISP’s BGP router in turn will share its routes with other BGP peers within AS 200. So yes, in this case, it would use iBGP to further advertise the company’s BGP routes on the Internet. When those routes are advertised beyond the AS of the ISP with other ASes, then eBGP will be used. Does that make sense?
It makes perfect sense, thank you. I have one more question. In the iBGP section, it was mentioned that we use IBGP on our routers in our transit AS. Question is, if we are already running iBGP, why should we also run an IGP like OSPF?
I understand that this would be to provide connectivity between the routers within the AS, but couldn’t we use just purely iBGP for that?
Can you use only BGP within an AS for routing? Yes you can, however, it is less than ideal. This is because of BGP is not well suited for such implementations due to its slower convergence times. IGPs are designed to be used within ASes and that’s why it’s recommended. Does that make sense?
About this sh ip bgp output on this lesson:
I’ve marked in bold both “i” codes, one after the best path symbol “>” and the other in the Path column. What’s the difference between them ? there are 2 codes, one internal uses the same letter “i” and the other is the origin code it uses the letter “i” too . I also know “internal” means that the route is learned via iBGP and igp is for routes locally originated.
R4#show ip bgp
BGP table version is 2, local router ID is 126.96.36.199
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
*>i188.8.131.52/24 184.108.40.206 0 100 0 1 i
This weekend i’ve tried this topology but i made a little changes. R2-R3-R4 (ASN2) IGP configuration using OSPF but R2 is Area 1 Stub , R3 is the ABR (lo0 220.127.116.11 in Area 0) link 192.168.23.0/24 in Area 1 stub , link 192.168.34.0/24 in Area 2 Stub, and R4 Area 2 stub :
R4 installed the 18.104.22.168/32 (announced via eBGP from R1 to R2) with next-hop 192.168.12.1 but R4 hasn’t specific route (for example the 192.168.12.0/24 subnet) for 192.168.12.1
I’ve always tought BGP Speaker while doing the recursive lookup to the BGP next-hop must has specific route into the RiB for that BGP next-hop .
I was wrong : R4 installed that route due the default route injected by R3 (OSPF ABR), so then i issued no area 1 stub (on R1 & R3) and no area 2 stub (on R3 & R4) therefore using normal OSPF areas and the ABR no longer inject the default route , now the 22.214.171.124/32 isn’t installed into the RiB because its no longer has any entry into the RiB (specific nor default route) for the BGP next-hop
The BGP table can be confusing, especially when they use the same letter “i” for multiple indicators!
So the leftmost “i” that appears before the prefix destination is the Status Code. This indicates that the route was learned via iBGP.
The rightmost “i” at the end of the entry is what is known as the Origin code. This is useful when we look at the Origin Code Attribute of BGP. The following two NetworkLessons notes clarify these indicators and how they appear in the BGP table:
Thanks for sharing your experience with your topologies! This is useful information. Let me go over some of the mechanisms that are being applied here to get the results you see.
Actually, BGP will check the routing table to see if there is a valid route to the next hop. A default route is still considered a valid route to the next hop. When you had stub areas configured, R4 had a default route automatically added to the routing table. However, when you removed this configuration, that default route was also removed, thus BGP no longer has a valid route to the next hop address.
Now in your scenario, the next hop for the 126.96.36.199/32 network from R4 was 192.168.12.1, which is R1. Even though there was a default route, I believe that this address would still not have been reachable, since the 192.168.12.0/24 network is not advertised using BGP, correct? Or OSPF for that matter. So connectivity would still fail. Keep in mind that the point of this lab is to see how prefixes are installed in the routing and BGP tables, and not necessarily how traffic is successfully routed… Does that make sense?
This is an excellent question. The truth is that we can use BGP to route traffic within an AS. However, BGP is not designed to be as fast in converging as IGPs. Its timers can be adjusted, but even so, its convergence time would be on the order of several seconds compared to milliseconds that are achievable with IGPs. So in general, it would be too slow to respond to the needs of routing internally in an AS.
For this reason, it is best practice to employ an IGP within an AS and BGP between ASes. Take a look at these NetworkLessons notes on the topic for more information:
The possibility of routing loops occurs because of the fundamental differences in how iBGP and IGPs like OSPF handle routing information.
In iBGP, routes learned from one iBGP neighbor are not advertised to another iBGP neighbor. This is known as the iBGP split-horizon rule. The purpose of this rule is to prevent routing loops within the AS.
On the other hand, IGPs like OSPF do not have this rule. They advertise all learned routes to all neighbors. So, if you redistribute an iBGP-learned route into OSPF, OSPF would then advertise this route to all its neighbors, including the iBGP router that originally advertised the route. This could potentially create a loop.
Let’s take an example: Router A learns a route from iBGP peer Router B. Router A then redistributes this route into OSPF. Router C, an OSPF neighbor of Router A, learns this route and advertises it to its iBGP peer, Router B. Now, Router B has a looped route.
The more logical solution, as the ENARSI OCG book suggests, is to advertise the network directly into the IGP and not redistribute. This means that instead of redistributing specific routes from iBGP into OSPF, you directly advertise the network that these routes belong to. This way, all routers in the OSPF domain will have a route to the network, and you avoid the potential for routing loops.
This brings into light the design principles of the operation of BGP and how it relates to IGPs.
IGPs are typically used to route traffic within an AS while BGP is used to route traffic between ASes. The role of iBGP is simply to learn about the routes in the local AS and inform the eBGP routers on the edge of the AS of those routes, so those routes can be advertised to external ASes. iBGP typically plays no role in the routing mechanisms within an AS.
Great lesson as always. This one took me a few tries to lab up and understand. As for iBGP, not sure why iBGP designers couldn’t just create another attribute to use during config to prevent loops. Also , other then the full mesh config, is the difference between BGP and iBGP, syntactically, just using the same AS number for iBGP?
The loop prevention mechanisms for iBGP involve either the creation of a full mesh, the use of route reflectors, or the use of confederations. These in conjunction with the iBGP split horizon rule ensure that within an AS, iBGP does not create loops.
The reason iBGP designers didn’t just create another attribute to prevent loops is because BGP was designed to be a path vector protocol, which means it needs a way to prevent loops at the AS level. The loop prevention mechanisms in iBGP are different from eBGP because iBGP assumes that it’s running within a single AS.
Yes, that is correct. Syntactically, iBGP is by definition operating between BGP peers in the same AS, while eBGP is operating between BGP peers in different ASes. It’s the same protocol, but they behave a little differently when the peering is with a router in the same AS or a different AS.