BGP Policies Conflicting with Internal Defaults

Depending on the physical topology of an AS and how policies are set, some odd situations might arise. Traffic following defaults inside the AS toward a border router might end up in a loop, if the border routers have some BGP policies that cause the traffic to be sent back inside the AS. This section discusses situations where loops might occur and experiments with possible solutions for the problem. Two cases will be considered:

---

Troubleshooting:  Ch. 11, pp. 402-418. BGP Policies Conflicting with Internal Defaults

---

•  Defaults inside the AS in conjunction with a Primary/Backup BGP policy

•  Defaults inside the AS in conjunction with other BGP policies

Defaults Inside the AS: Primary/Backup BGP Policy

Consider the routing scenario in figure 7-2; AS1 is connected to the Internet via two connections. RTC in SF is running EBGP with one provider, whereas RTD in NY is running EBGP with another provider. Inside the AS, RTC and RTD are running IBGP, but are not physically connected. Traffic between RTC and RTD has to go via routers RTA and RTB.

Figure 7-2  Following default loop situation.

Assume that RTC and RTD are both receiving full routes from their respective providers. RTC and RTD are also injecting a 0/0 default route inside AS1. Assume also that AS1 wants to run the primary/backup technique to enable the NY T3 link to be the primary. AS1 would set the local preference higher for routes coming from NY, which makes that link primary. The SF link will be used as backup, and hence all outbound traffic that reaches RTC will be directed back toward RTD.

RTA and RTB are interior non-BGP routers and exchange routes via IGP with all other routers in the AS. RTA and RTB do not see any of the exterior routes and follow defaults toward RTC and RTD according to the lower IGP metric. Traffic for outside networks reaching RTA will end up following the default toward RTC, whereas traffic reaching RTB will end up following the default toward RTD.

When RTC receives the traffic, it will divert it toward RTD because of the BGP policy that makes NY the primary link. Because RTC has no direct connection to RTD, it will send the traffic toward RTA. RTA will receive the traffic and send it back toward RTC, and a loop will occur.

Next, multiple scenarios are examined for avoiding the potential looping behavior when using defaults within the AS for primary/backup routing.

Scenario 1: Manipulating the IGP Metric

In this scenario, we want to try to avoid a loop condition by having all traffic for external destinations follow the default toward RTD. This could be done by having RTC inject the 0/0 default inside the IGP with a very high metric to make the 0/0 default for any internal router shorter via RTD. Traffic will never go to RTC unless the NY link goes down.

Scenario 2: IBGP Path Shorter Than IGP Path

The existence of a shorter path between the IBGP routers will make sure that traffic will not go back over the IGP-only routers to reach its destination. This is only required if BGP policies necessitate the redirection of traffic from one BGP router to the other. Such situations occur when an IBGP router does not have an external link to send the traffic, or if it does have an external link, that link is not used as the best path (RTC's situation in figure 7-2).

In the scenario of figure 7-2, a loop can be avoided if the border routers RTC and RTD that run IBGP also share a physical segment such as a serial link. Traffic coming toward RTC from RTA would be redirected over the physical link, which provides a shorter path between RTC and RTD.

Scenario 3: Running BGP on Transit Routers

Running BGP on all transit routers will make sure that once traffic reaches any of these routers, it can be directed outside the AS. In the example of figure 7-2, if RTA and RTB were to run an IBGP full mesh with RTC and RTD, all traffic that reaches RTA or RTB will find its way out. Note that even though AS1 might not be a transit AS, RTA and RTB are still used to carry traffic between border routers. Internal IGP-only routers will use the IBGP cloud to reach the outside word, as already illustrated in figure 7-1.

Scenario 4: Who Generates the Default,
and How Does it Get Generated?

In this scenario, a loop can be avoided if the primary router generates the default into IGP while the secondary router does not. In this example, RTD would inject the 0/0 into the IGP, and RTC would not. All the traffic would follow the default toward RTD.

This solution works only in normal conditions and fails in backup situations. If the NY link fails, the IGP routers would lose the 0/0 default. Because RTC is not generating any default, traffic to outside the AS will fail.

The ideal situation is for RTC to inject a default into the IGP only if the NY link fails. If the NY link goes down, RTD should stop injecting a default into the IGP and RTC should start injecting the default into the IGP. For this mechanism to take place, the routers must engage in the following behaviors:

•  A BGP router should stop injecting default into the IGP if the router's external link fails.

•  A BGP router should inject default into the IGP only if the default it prefers points to the external link.

The first requirement can be easily achieved if the IGP allows redistribution of the external default 0/0 into the IGP. Whenever the external 0/0 ceases to exist, the IGP default disappears with it. The availability and behavior of redistribution depends on what IGP you are running and on the particular vendor implementation. The way Cisco implements redistribution could differ from other vendors.

The second requirement mandates that a router stop generating the default if the default it prefers comes from inside rather than outside the AS. When the secondary router prefers the default from inside the AS, it means that the primary link is still up. When the primary goes down, the secondary will prefer the default from outside the AS and will inject the default into IGP. This situation is easier to explain and understand by example. The next two examples study the difference between a RIP- and OSPF-generated default in a Cisco implementation.