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 22.214.171.124
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
*>i126.96.36.199/24 188.8.131.52 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 184.108.40.206 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 220.127.116.11/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 18.104.22.168/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 22.214.171.124/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.