RIP-Generated Default

In the example in figure 7-3, RTC and RTD can learn a 0/0 default or statically configure a 0/0 default toward their respective providers. In normal conditions, RTD will automatically (or via controlled redistribution) inject the 0/0 into RIP. RTC will detect the presence of a default coming from RTD and will stop generating a default. All traffic will be directed toward RTD.

Figure 7-3  Injecting 0/0 default into RIP.

In case of a failure in the NY link, RTD will stop generating the default into RIP. RTC will detect the loss of 0/0 via RIP and will inject its own default.

Note that RTC is receiving the 0/0 default via EBGP, RIP, and possibly IBGP if RTD is passing the 0/0 in the IBGP session. Because of the higher local preference via RTD, RTC would prefer the 0/0 via IBGP. Because the IBGP distance is 200, higher than the RIP distance of 120 (see table 5-1), the 0/0 default via RIP is preferred.

OSPF-Generated Default

OSPF behaves differently from RIP. The BGP 0/0 cannot be passed into OSPF via redistribution. OSPF has different hooks that enable the protocol to generate the 0/0 into the OSPF at any time, or even better, if the presence of a 0/0 is detected in the IP routing table. Now apply this behavior to the example in figure 7-4.

7-4  Injecting O/O default into OSPF.

RTD and RTC will receive the 0/0 via EBGP or point a static default toward their respective providers. If RTD and RTC are configured such that the 0/0 is injected into OSPF as long as they themselves have a 0/0 in their IP routing table, the primary/backup model will fail. It fails because both RTD and RTC are receiving the 0/0 via IBGP. RTC will always inject the 0/0 into OSPF whether the NY link is up or down. Also, unlike the RIP scenario, RTC will ignore the OSPF default coming from RTD because RTC is also configured to generate a default.

To remedy this situation, further configuration is needed to instruct the routers RTC and RTD to generate the 0/0 into OSPF only if their own default points to their respective providers.

In essence, if RTD chooses, from all defaults, the default that points to its provider, RTD will inject the 0/0 into OSPF. In the same manner, if RTC prefers the default that points to its provider, RTC will inject the 0/0 into OSPF.

With this new model, this is what will happen: in normal operation, the NY link is up. RTD will prefer the external default over any other default. RTD will inject the 0/0 into OSPF. RTC will receive the 0/0 via EBGP, IBGP, and OSPF. RTC will ignore the OSPF default, as mentioned earlier. RTC would prefer the 0/0 coming from RTD via IBGP because of the higher local preference. Because the 0/0 is not learned via RTC's provider, RTC will not inject any default into OSPF.

If the NY link goes down, RTD will lose the 0/0 from its provider. RTD will still receive a 0/0 via IBGP and would not generate a 0/0 into OSPF because the 0/0 was not learned via RTD's provider. RTC will stop receiving the 0/0 via IBGP and will prefer the 0/0 via its provider. RTC will then start injecting the 0/0 into OSPF.

---

Troubleshooting:  Ch. 11, pp. 405-418. Using OSPF as IGP

---

Defaults Inside the AS: Other BGP Policies

As you have already seen, loop situations can occur any time if the IGP defaults conflict with the BGP policies. In the primary/backup scenarios, you were able to control which border router should generate the default because you decided in advance which should be the primary router for all traffic external to the AS. In some situtions, routing policies might be imposed on your AS by outside factors. In other cases, normal IBGP/EBGP routing will make the exit point from your ASs unspecified, which would conflict with your own defaults.

Consider figure 7-5. AS1 is connected to its provider AS2 in two locations, SF and NY. AS1 is injecting defaults from both its SF router RTC and its NY router RTD in such a way that internal locations will exit from the closest exit point.

Figure 7-5  Policies inflicted from outside sources.

Assume also that AS1 is very careful about injecting defaults. The SF router will never inject a default if the SF link is down, and the NY router will never inject a default if the NY link is down. All is well and working great until one day provider AS2 starts advertising metrics (MED) toward AS1.

Assume in figure 7-5 that AS2 is sending its updates toward AS1 with the internal IGP metrics as MED. AS1 will receive the same networks on both the SF and NY links with different MED values. For each network, BGP will follow the path with the lowest metric. If, for example, RTC receives network 192.213.16.0/24 with MED 50 on the SF link and MED 20 on the NY link, RTC will prefer the NY link. This would mean that to reach 192.213.16.0/24, RTA might follow the interior default toward RTC and then be instructed to go toward RTD. Similarly, RTB might follow a default toward RTD and then be directed toward RTC. In both cases, a loop will occur.

As you can see, the exit point for all networks cannot be predetermined as in the primary/backup case. To deal with this situation, you have the following options:

•  Ignore the MED and base the routing on a primary/backup scenario.

•  Have a shorter path connection between RTC and RTD so that traffic redirected between exit points follows the shortest path between the IBGP routers.

•  Run an IBGP mesh between, RTA, RTB, RTC, and RTD.

Other normal situations can also cause loops. You could end up in a looping situation whenever you have multiple links and you are running defaults inside the AS. If you are connected to two providers, you might prefer some destinations via one provider and others via the second provider. If your IGP is following defaults, you might end up at the wrong exit point with no way to go back.

As you can see by now, the solution to solve looping problems is to either have the BGP and your IGP be more deterministic about where to exit the AS or prevent traffic between IBGP routers from going back over IGP-only routers. The more you are aware of your traffic behavior, the better you can avoid loop situations.