Hi everybody,
As I had difficulties in finding all processes about BGP loop prevention, my intention with this post is to show in a just document all BGP loop prevention mechanisms. I will introduce resources and processes about it. I hope it could make it easy and help better you understand. However, if someone finds some mistakes and has new information, please share it with us.
EBGP loop protection
Mechanism-based on AS-PATH attribute
After receiving the eBGP route, the device checks the AS-Path attribute and discards any route update information that contains the AS number received from the eBGP peer.
When an ISP origin or advertises a network to the Internet, its as-number is inserted in the as-path. In some situations, it happens that one of its peers or a customer advertises to him this same network originated from its AS. Therefore, he can receive a prefix in which his as-number is present in the as-path. In this case, the prefix and the BGP update are silently ignored.
This situation is common when customers and their upstream providers are linked in a way that the global connectivity is fully meshed, closing the loop.
AS-PATH Attribute
The AS_Path attribute has four types:
AS_Sequence: records in reverse order all the ASs through which a route passes from the local device to the destination.
AS_Set: records without an order all the ASs through which a route passes from the local device to the destination. The AS_Set attribute is used in route summarization scenarios. After route summarization, the device records the unsequenced AS numbers because it cannot sequence the numbers of ASs through which specific routes pass. No matter how many AS numbers an AS_Set contains, BGP regards the AS_Set as one AS number when calculating routes.
AS_Confed_Set: records without an order all the sub-ASs within a BGP confederation through which a route passes from the local device to the destination. The AS_Confed_Set attribute is used in route summarization scenarios in a confederation.
AS_Confed_Sequence: records in reverse order all the sub-ASs within a BGP confederation through which a route passes from the local device to the destination.
The AS_Confed_Sequence and AS_Confed_Set attributes are used to prevent routing loops and to select routes among the various sub-ASs in a confederation
IBGP loop protection
According to the BGP route advertisement rule, the IBGP peer does not advertise any route update information to the IBGP peer.
The IBGP split-horizon function is used to prevent loops in an AS, and the RR breaks the split horizon.
Is possible to prevent this behavior in two ways:
Create full mesh bgp neighborship between nodes
However full bgp mesh is quite annoying to do there is another way called route reflectors.
Route Reflector
To ensure connectivity between IBGP peers, you need to establish full-mesh connections between IBGP peers. If there are n devices in an AS, n(n-1)/2 IBGP connections need to be established. When there are a large number of devices, many network resources and CPU resources are consumed. A route reflector (RR) can be used between IBGP peers to solve this problem.
In an AS, one router functions as a Route Reflector (RR) and the other routers as clients. The clients establish IBGP connections with the RR. The RR and its clients form a cluster. The RR reflects routes among clients, and BGP connections do not need to be established between the clients.
RR loop prevention
With the introduction of an RR, there is a possibility that a route selection loop occurs in an AS. A route update packet that leaves a group may attempt to return to the group.
The traditional AS path method cannot detect the internal loop of the AS because the route update packet has not left the AS.
When configuring an RR, BGP provides the following measures to prevent loops in the AS.
CLUSTER_LIST attribute
Cluster_List is an optional and non-excessive attribute. The attribute type is 10, which records the list of all Cluster_ids that the route passes through and adds the latest Cluster_id to the front of the Cluster_list.
An RR and its clients form a cluster, which is identified by a unique cluster-ID in an AS. To prevent routing loops between clusters, an RR uses the Cluster_List attribute to record the cluster IDs of all the clusters that a route passes through
When multiple RRs provide redundancy for clients, routing updates between RRs may cause loops. To prevent loops, the cluster is introduced.
When a route is reflected by an RR for the first time, the RR adds the local cluster-ID to the top of the cluster list. If there is no cluster list, the RR creates a Cluster_List attribute.
When receiving an updated route, the RR checks the cluster list of the route. If the cluster list contains the local cluster-ID, the RR discards the route. If the cluster list does not contain the local cluster-ID, the RR adds the local cluster-ID to the cluster list and then reflects the route.
ORIGINATOR_ID attribute
Originator_id is also used for RR ring protection. It is an optional non-excessive attribute and its attribute type is 9. Originator_id is created by the first reflector and is not changed by the subsequent reflector. It works as a report and should be received only from IBGP. If the route is originated from the local AS: Originator_id is the Router_id of the sender, and the route is originated from the non-local AS. Originator_id is the Router_id of the border router of the local AS. The reflector discards the route update whose Originator_id is the same as that of Router_id.
The originator ID identifies the originator of a route and is generated by an RR to prevent routing loops in a cluster. Its value is the same as the router ID.
When a route is reflected by an RR for the first time, the RR adds the Originator_ID attribute to this route. The Originator_ID attribute identifies the originator of the route. If the route contains the Originator_ID attribute, the RR retains this Originator_ID attribute.
When a device receives a route, the device compares the originator ID of the route with the local router ID. If they are the same, the device discards the route.
Backup RR
To ensure network reliability and prevent single points of failure, redundant RRs are required in a cluster. An RR allows a BGP device to advertise the routes received from an IBGP peer to other IBGP peers. Therefore, routing loops may occur between RRs in the same cluster. To solve this problem, all the RRs in the cluster must use the same cluster-ID.
BGP confederation
BGP Confederations is another mechanism to avoid iBGP Full Mesh topology like Route Reflectors
BGP confederations allow us to divide a single AS into one or more ASs and assign the whole group to a single AS. In other words, in this BGP mechanism, there are Sub Autonomous Systems inside the iBGP Topology. Each smaller AS will need to have a full mesh inside its own AS. Even though these ASs will have EBGP peers to ASs within the confederation, they exchange routing as if they were using IBGP; next hop, metric and local preference information is preserved. The top Autonomous System is still exists and the new Sub ASs have connected to this AS and formed BGP Confederation.
BGP Confederation Attributes
Next_Hop attribute of confederation external routes remains unchanged when the routes are advertised within the confederation.
MED attribute of the routes advertised to a confederation remains unchanged when the routes are advertised within the confederation.
Local_Pref attribute of routes remains unchanged when the routes are advertised within the confederation
In standard BGP, the AS_PATH attribute contains two parameters:
AS_SET: the unordered set of ASs that a route has traversed
AS_SEQUENCE: ordered set of ASs that a route has traversed
In the case of a confederation, two additional parameters are introduced:
AS_CONFED_SET: the unordered set of sub-ASs that a route has traversed in confederation
AS_CONFED_SEQUENCE: ordered set of sub-ASs that a route has traversed in confederation
AS_SEQ and AS_SET components help prevent loops between autonomous systems, AS_CONFED_SEQ and AS_CONFED_SET help prevent loops within confederation autonomous systems.
Before confederation eBGP peers can advertise an iBGP route into another sub-AS, the router must make sure that the destination sub-AS is not already in the AS_PATH AS_CONFED_SEQ segment.
When a route is advertised across a confederation member AS, the confederation member AS number is added to the AS_Path of the route, but the confederation member AS number is not advertised outside of the confederation. An eBGP connection between sub-ASs also serves as kind of a loop-avoidance mechanism.
By the end of these steps, all the routers inside ASN 100 have learned of the 59.1.1.0/24 prefix. Also, ASN 300 learned of a route for that same prefix. In fact, from ASN 300’s perspective, it sees a route that appears to be through ASNs 100 and 300.
References:
https://support.huawei.com/enterprise/en/doc/EDOC1100055468/587f795f/bgp-fundamentals
https://forum.huawei.com/enterprise/en/bgp-fundamentals-24-bgp-confederation/thread/561999-863
https://forum.huawei.com/enterprise/en/forum.php?mod=viewthread&tid=529741
https://tutorzine.com/bgp-confederations-route-reflectors/
https://netquarks.wordpress.com/2016/04/08/bgp-as_path-part-ii/
https://ipcisco.com/lesson/bgp-confederation/
