There are two types of loops that exist in routed networks. These loops are applicable to both IGPs and BGP. Given that IGP loop prevention mechanisms are described in detail in previous chapters, this chapter focuses exclusively on BGP loop prevention. The two types of loops are:
- Routing Information Loops
- Routing Loops
Routing information loops are loops that occur when routing information is both received and accepted by the router that advertised it. Figure 6-20 illustrates a routing information loop:
Fig.6-20. Routing Information Loops
Referencing Figure 6-20, R2 is peered to both R1 and R3. R2 advertises the 150.0.0.0/24 prefix to R1 which in turn advertises the same prefix to R3. R3 turn around and re-advertises the same prefix back to R2. The same would be applicable to the route advertised to R3 which would turn around and advertise it to R1 which is re-advertise it back to R2.
If R2 accepts these routes, a routing information loop will occur. The different routing protocols we learned about in the previous chapters have different means or methods for ensuring that routing information loops do not occur. For example, if this was an EIGRP network, the routes that R2 received from R1 and R3 would not meet the feasibility condition and would therefore not be placed into the EIGRP Topology Table and ultimately the RIB. This prevents the routing information loop from forming in the EIGRP domain.
A routing loop occurs when packets are sent back and forth between two or more routers as was illustrated in the IGP Route Filtering and Route Redistribution chapter. In this case, the packets loop back and forth between the devices until the IP TTL value reaches 0, after which they are discarded. In this section, we are going to learn about both routing information and routing loops as they pertain to BGP.
Preventing Routing Information Loops in BGP Implementations
Fortunately, like most routing protocols, BGP includes built-in mechanisms that are used to avoid routing information from being received and accepted by the router that originated it. With BGP, however, it is important to understand that different mechanisms are used for external BGP (eBGP) and internal BGP (iBGP) implementations. The following mechanisms are used to prevent routing information loops for eBGP:
- The AS_PATH attribute
The following mechanisms are used to prevent routing information loops for iBGP:
- Preventing iBGP speakers from advertising iBGP routes to iBGP peers
- The ORIGINATOR_ID attribute
- The CLUSTER_LIST attribute
The AS_PATH attribute
The AS_PATH attribute is used to prevent routing information loops in inter-AS BGP, i.e. eBGP, implementations. The AS_PATH attribute contains a reverse order sequenced list of autonomous system numbers that represent the domains the prefix has transited. This attribute is changed only when an UPDATE is sent to an eBGP neighbor, but not when sent to an iBGP peer; hence the reason that this attribute is applicable only for external BGP implementations.
When an eBGP speaker receives UPDATE messages, it looks at the AS_PATH list to determine the best (shortest) path to the destination prefix. However, if the eBGP speaker notices its autonomous system number in the AS_PATH list, it ignores this UPDATE and does not take it into consideration in the path selection process. This prevents the router from receiving and accepting information that it originated, or was originated within its own autonomous system.
To further clarify this point, consider the topology illustrated in Figure 6-21 as an example:
Fig.6-21. Using the AS_PATH to Prevent Loops
Figure 6-21 shows a basic network comprised of three routers in three different ASes. All three routers are peered with each other and R2 is advertising the 150.0.0.0/24 prefix to R1 and R3. When R1 receives this UPDATE, it includes its AS and advertises the prefix to R3. R3 also does the same and advertises the prefix received from R2 to R1.
R1 and R3 now have two paths for the same destination: the path via R2, which contains only a single AS and the path via each other, which contains two AS numbers. By default, the path with the shortest AS_PATH list will be selected and both R1 and R3 forward packets destined to the 150.0.0.0/24 prefix directly to R2. In addition to this, both R1 and R3 advertise the paths that they also received from each other to R2 after they have included their AS.
When R2 receives these UPDATE messages, it notices that its own AS is included. Because AS 2 is included in the AS_PATH list, R2 ignores these paths and they are not placed into either the BGP Table or the IP routing table. This default behavior prevents a routing information loop from being formed when prefixes are re-advertised back to the originating autonomous system.
Preventing iBGP speakers from advertising iBGP routes to iBGP peers
With iBGP implementations, the AS_PATH attribute cannot be used because the AS_PATH list is not updated when an UPDATE is sent from one iBGP speaker to another iBGP speaker as stated earlier in this chapter. This means that iBGP implementations cannot use the AS_PATH attribute to prevent routing information loops because this attribute is preserved within the same autonomous system. This means that iBGP implementations must use other techniques to prevent routing information loops within the domain.
To prevent routing information loops in an iBGP network, when iBGP speakers reside within an autonomous system that is not fully meshed or is using Route Reflectors or confederations any prefix learned from an iBGP speaker will not be advertised to another iBGP peer. These prefixes will only be advertised to eBGP peers. This concept is illustrated in Figure 6-22:
Fig.6-22. iBGP Routing Information Loop Prevention
Referencing the topology illustrated in Figure 6-22, R1, R2, and R3 reside within AS 2. R1 has an eBGP neighbor relationship with R4 and an iBGP neighbor relationship with R2. R2 has an iBGP neighbor relationship with R3 and an eBGP neighbor relationship with R6. R3 only has an iBGP neighbor relationship with R2.
R4, in AS 4, advertises the 150.254.0.0/16 prefix to R1. R1, in turn, advertises the same prefix to its iBGP neighbor, R2. When R2 receives this UPDATE, it advertises the prefix to R6 because this is an eBGP neighbor; however, it will not advertise a prefix received from another iBGP peer to another iBGP speaker. R2 therefore does not advertise the prefix to R3. The end result is that all routers illustrated in this topology, except for R3, have a valid routing entry for the 150.254.0.0/16 prefix. Therefore, while this default behavior does prevent routing information loops in iBGP networks, not all routers in the domain have routing information. This can be addressed using one of three methods:
- Implement a full iBGP mesh
- Use Route Reflectors
- Implement Confederations
The first method is the most simple. Using this method, R1 and R3 can be configured as iBGP peers. Because BGP does not require that neighbors be directly connected to establish a neighbor relationship, as will be illustrated later in this chapter, this would be as simple as configuring R1 and R3 with neighbor commands for each other.
While this solution is easy to implement, it is not scalable. For example, if there were 10 iBGP speakers in the domain, N(N-1) neighbor statements would need to be configured in order to create a fully meshed iBGP network. This would result in a total of 90 adjacencies, with each iBGP speaker having 9 neighbor statements. This scalability limitation can be lifted by implementing the second and third solutions, which are more complex than the first solution.
NOTE: Route Reflectors and Confederations are described in detail in the following chapter. The emphasis in this section should be placed on remembering the methods used to prevent routing information loops in iBGP implementations.
The ORIGINATOR_ID attribute
The ORIGINATOR_ID attribute is used in iBGP implementations that use Route Reflectors. This attribute is used to prevent routing information loops within the iBGP network. The RR set the BGP Identifier of the client router that originated the route as the ORIGINATOR_ID. Therefore, when a client receives an UPDATE from the RR and it recognizes the ORIGINATOR_ID as its BGP Identifier will ignore it. This prevents the iBGP speaker from both receiving and accepting routes that it originated or injected into BGP.
The CLUSTER_LIST attribute
The CLUSTER_LIST attribute is used in iBGP implementations that are using Route Reflectors. When the Route Reflector reflects a prefix, it must prepend the CLUSTER_ID to the CLUSTER_LIST. Using this attribute an RR can identify if the routing information has looped back to the same cluster. If the local CLUSTER_ID is found in the CLUSTER_LIST, the received advertisement is ignored. This prevents the RR from accepting information that it advertised.
Preventing Routing Loops in BGP Implementations
Now that we are familiar with the mechanisms employed by both eBGP and iBGP speakers to prevent routing information loops, the following section focuses on the prevention of traditional routing loops when implementing BGP. As you will recall, earlier in this chapter when we learned about the different types of connectivity options to ISPs, we learned that if there are any Layer devices that will be providing transit service between the two edge routers, the enterprise should implement an iBGP mesh between these devices and the edge routers.
This ensures that all intermediate devices have routing information for the BGP networks being advertised between the edge routers, while negating the need to redistribute BGP routes into the IGP. It also prevents the black-holing of network traffic. To expand on this concept, consider the topology illustrated in Figure 6-23:
Fig. 6-23. Preventing Routing Loops in BGP Implementations
Figure 6-23 illustrates a basic network. Routers R1, R2, R3, and R4 reside within AS 2. Only R3 and R4 are BGP speakers. These two routers have an iBGP neighbor relationship between themselves and an eBGP neighbor relationship to the ISP in AS 1234. EIGRP has been enabled within AS 2 allowing for IP connectivity between all routers. However, BGP is not being redistributed into EIGRP. Instead, for simplicity’s sake, let us assume that theip summary-address eigrp 2 0.0.0.0 0.0.0.0 command has been configured on the ASBR interfaces connected to the interior routers. Based on this configuration, interior routers R1 and R2 prefer the default received from their upstream ASBRs.
Assume that the link between R3 and the ISP fails. Despite this failure, R3 is still able to receive Internet routes from iBGP peer R4. However, the problem arises when R1 sends an Internet-bound packet to the 200.1.1.1 address to R3 – its preferred default gateway. The routing loop is established based on the following sequence of events:
- R1 forwards the packet to the 200.1.1.1 address to R3, its preferred Autonomous System Border Router (ASBR) based on the IGP configuration
- R3 has received routing information for this destination from R4, via iBGP, and so R3 performs a recursive lookup for the NEXT_HOP address in this UPDATE. The NEXT_HOP address could either be the address of R4 or that of the ISP edge router. In this case, assume it is the address of R4. R3 then sends the packet to the next hop address of the NEXT_HOP, which is R1
- R1 receives a packet destined to 200.1.1.1 from R3. Since this router does not know how to reach this destination, it forwards the packet using its default route – which points back to R3. A routing loop has formed. This is illustrated in Figure 6-24:
Fig. 6-24. Understanding Routing Loops in BGP Implementations
To resolve this issue, one of two solutions must be implemented. These solutions are:
- Enabling BGP on all transit or intermediate devices between the edge routers
- Redistributing BGP into EIGRP, or any other IGP that may be running
The first solution is the recommended solution. With this option, an iBGP mesh is implemented within AS 2 and all routers are configured to peer with each other. This ensures that all routers have routing knowledge of all external destinations and prevents the formation of routing loops on transit devices that do not have BGP enabled.
The second solution is valid but is dangerous and is not recommended. A full Internet routing table contains upwards of 100,000 prefixes. While BGP was designed to carry a large number of prefixes, IGPs were not. This solution could cause serious issues within the network. While route filtering during redistribution could be used to reduce the number of prefixes injected into the IGP, determining which prefixes to import is a headache within itself. This solution should be avoided whenever possible.