In this article, I would discuss about BGP peering types, BGP Next-Hop Self, BGP Split-Horizon and other fundamental features of the BGP protocol.
It is worth mentioning that just like IP addresses, AS numbers are categorized in public and private AS numbers. Private AS numbers range from 64512 to 65535. They are known to our AS but when these AS routes are advertised to the uplinks, they are stripped off.
BGP uses the AS number for its loop prevention mechanism and ASNs (Autonomous System Numbers) have to be unique on the Internet.
BGP Peering Types:
BGP peering types can be internal (iBGP) or external (eBGP). iBGP is between peers with the same AS number whereas eBGP is neighborship between peers having different AS numbers.
For eBGP neighborships, if eBGP routers are not directly connected, we need to specify the TTL value
greater than 1 (by default). On the other hand, For iBGP neighbors, even if the routers forming adjacency are not directly connected, we can still form the neighborship since the default TTL is 255 for iBGP neighbors.
NOTE: It is recommended to establish BGP neighborship using loopback addresses because if the physical interface goes down for some reason, the logical TCP session still remains intact. So, using loopbacks for BGP peering won’t bring the neighborship down in case of a link failure.
When peering with loopbacks, we also need to tell routers to source their traffic using the loopback addresses or else they will source the traffic using default interface addresses and the neighborship won’t come up!
Next-Hop Self:
When we have an eBGP peer, the next-hop is always changed to our peering IP address. This is because eBGP peers do not have any need to know about all the details inside another ASN. Next hops are measured by an AS Path.
Question: What happens when the link between two eBGP peers (obviously known to the edge router because its connected) is not exchanged via any IGP?
Answer: Suddenly other internal routers learn iBGP routes that appear to be unreachable. They show an
unknown IP as the next hop!
There are two ways to solve the next-hop issue:
- Advertise Next-Hop subnet via IGP
- Use Next-Hop command to modify the next-hop IP
Getting Prefixes into BGP:
Routers cannot advertise a route into BGP unless it is already present somewhere in the routing
infrastructure of the router.
Highlight: Any prefix that a router sources with a next-hop of 0.0.0.0, it means that is the router itself.
RIB (Routing Information Base) Failure: When BGP tries to install the best path prefix into RIB, Routing Information Base (for example, the IP Routing table), the RIB might reject the BGP route due to any of these reasons:
- Route with better administrative distance already present in IGP. For example, if a static route
already exists in IP Routing table. - The number of routes in VPN routing/forwarding (VRF) exceeds the route-limit configured under
the VRF instance. - It indicates memory failure.
In such cases, the prefixes that are rejected for these reasons are identified by r = RIB Failure in the output for show ip bgp command and are not advertised to the peers.
Origin Code:
In the previous article, BGP Fundamentals: Part 1, I mentioned the Origin Code for BGP that is actually responsible for how to get routes into BGP. It is important to note that the order of preference for Origin codes is as follows:
IGP > EGP > incomplete, where IGP = i, EGP = e and incomplete = ?
Aggregate Routes:
Aggregate routes are used when prefixes are advertised to uplinks but note that we should not
summarize for networks we do not own (do not over summarize)!!!
For aggregate routes to be sent to the upstream, the border router can send:
- The summary and some of the detailed routes
- Or the summary and none of the detailed routes
The other way to inject routes into BGP is by BGP inject-map.
So, to summarize there are 4 ways of injecting routes into BGP:
- Via network statement that makes routes show as origin = IGP
- By redistribution of routes (from static, connected or IGP) into BGP that makes them show as Origin = Incomplete
- Use aggregate routes
- BGP inject-map
Question: Why to use iBGP inside an Autonomous System, if IGP protocols fulfill the need for internal
communication?
Answer: iBGP is used within an AS for following reasons:
Scalability: Imagine that you’re receiving 500,000 EBGP routes in more than one location, and you need to influence the per route exit point in your AS. BGP can handle many more routes than IGP protocols. Thus, iBGP is required unless you’re willing to redistribute all the routes you’ve learned via eBGP.
You use BGP because you don’t want to carry your entire internet routing table in your IGP. IGPs are not designed to handle many thousands of routes in internet BGP tables and if you try to use an IGP for this purpose, it will break your network.
Using the example of OSPF, the LSA processing/flooding requirements from 500,000 routes uses too many resources in your routers. Name any other IGP (EIGRP, RIPv1/2, IS-IS, IGRP) and the same story is true!
There have been some notorious instances where a Tier-1 ISP accidentally redistributed their BGP table into their IGP (even when the internet table was a small fraction of its current size) and it caused major outages. Countermeasures have now been implemented in IGP protocols to prevent redistribution from BGP into IGP from causing a major outage.
Enforce Boundaries of Trust: BGP has many more knobs than IGPs for controlling what you
advertise and receive.
Flexible Tools: BGP Attributes, BGP policies, BGP communities and Extended communities make it an attractive way to implement custom routing policies within your own autonomous system
As with everything, (scalability, control and flexibility) you get from iBGP means that it is a slower
converging protocol than IGPs.
BGP Split-Horizon:
The BGP Split-Horizon rule states:
“When a BGP speaker receives an UPDATE message from an internal peer, the receiving BGP speaker
shall not re-distribute the routing information contained in that UPDATE message to other internal
peers.”
This rule is used within an AS to prevent loops. One way to overcome BGP Split Horizon is to configure Full-mesh (iBGP peering sessons) connectivity but for the Full-mesh connectivity, the number of peering sessions increase with the number of BGP running routers.
- The formula for calculating the number of sessions: N x (N – 1) / 2 where N = no. of routers
The other way to combat BGP Split Horizon is that we may configure BGP Route-Reflectors or/and BGP Confederations. However, I am not going to discuss either of these as both of them are beyond the scope of this article.
I will post further about BGP and advanced topics for the protocol in coming days and would like to leave you with this wonderful MicroNugget by Jeremy Cioara on BGP and its working mechanism.
In case of any queries or feedback, please drop a comment below and I would love to respond and help.
Haider Khalid
Latest posts by Haider Khalid (see all)
- From Outdated to Outstanding: Strategies for a Modern Company - August 24, 2024
- Top Challenges in Mobile App Testing and How Automation Addresses Them - August 9, 2024
- Amazon Games – The Future of Gaming Industry - July 16, 2024