CNC Logo

BGP Part II

Peter J. Welcher

Introduction

Last month we started to look at BGP. See http://www.netcraftsmen.net/welcher/papers/bgp1.htm . Recall that an IGP is an Internal Gateway Protocol: whatever your routers speak "at home" -- probably RIP, IGRP, EIGRP, or OSPF.

We saw that one of the usual reasons people have for wanting to run BGP is being multi-homed, either to one or two ISP's. We examined the various "degrees of BGP" that you might wish to use, matching what you do to your needs and your skills. I hope that left you with the idea that there are some finer gradations in between "no BGP" and "full Internet routing with BGP", sort of a 1-10 scale of increasingly difficult things to attempt.

And don't assume that high-quality Internet connectivity, with redundancy, requires BGP. BGP just buys you the capability of doing more complex things, more optimal routing. Rarely do we want or need "perfect" routing (in the sense of the absolute best path). We trade off optimality for smaller routing tables, stability, and ease of troubleshooting.

Default routing is the usual answer to not doing BGP. See http://www.netcraftsmen.net/welcher/papers/default.htm for some thoughts on default routing.

We also saw that redistributing, either into or out of BGP, is rarely necessary or appropriate.

After such a big introduction, I feel compelled to warn the reader: there's a lot to say about BGP, and we're not going to say it here. The ultimate reference on BGP is the book Internet Routing Architectures, Bassam Halabi, Cisco Press, 1997. For more ideas (and configurations) relating to the discussions in last months' article, read the fine book!

To aid in categorizing the various levels of complexity one might tackle with BGP, I introduced some diagrams like the following. We then discussed them, with some caveats as to what they don't show.

Designs

Diagram 1: one connection to ISP: use default routing!

Diagram 2: one corporate gateway router, two connections to ISP (possibly geographically diverse).

Configuration for Diagram 1

A configuration for Diagram 1 might look something like the following: I've assumed the ISP has issued 200.30.50.0 /24 for local use, and that they're taking care of routing traffic to you (possibly via static routing). The example uses a static default route, redistributed, with a distribute list to make sure we don't accidentally redistribute any other static routes that get added later. This is a bit unnatural for EIGRP, which understands " ip default-network" better. That's perfectly workable, but you need a good choice of default network (preferably one of your ISP's Class B's, or MAE-East or some large aggregate that isn't too likely to go away). You also need to already have an EIGRP route to it, possibly a redistributed static route -- so why not use a static to 0.0.0.0 /0?

For reference; "ip default-gateway" only applies when your router isn't a router. (That's a riddle: when is a router not a router?) Answer: when you configure "no ip routing" or when you boot in RXBOOT mode.

Configuration for Diagram 2

Suppose your provider wants to hear about your availability via BGP. Suppose furthermore that you have unequal speed links,
with the bottom link in the diagram being a T1 and the top link being a lower speed backup. Then your configuration might look something like the following:  This causes outbound traffic to prefer the link to 200.30.40.1, because of the static default route. We advertise our prefix to the ISP (so the ISP can track link availability dynamically). We tell the ISP via the lower metric (MED: Multiple Exit Discriminator) to use the link from 200.30.40.1 for return traffic, unless it is down. The route map NOROUTES keeps us from learning routes from our ISP: we don't need to know any.

The static routes to 0.0.0.0 /0 take care of default. We of course redistribute these into our internal protocol, not shown in this example (probably something like in the first example). The floating static route (ending in 70) only applies if and when the other static route fails, i.e. when 200.30.40.1 is unreachable.

There are other possibilities for Diagram 2, such as load balancing across equal speed links. Since space is short, let's move on and look at a more complicated scenario. (Those who are paying close attention will note that we've omitted our prior Diagram 3, for space reasons).

Diagram 4: two corporate gateway routers, geographically diverse on both ends.

Configuration for Diagram 4

I've drawn the picture with a serial link between Router A and Router B. This makes iBGP simpler, and means that we don't have to worry about IGP synchronization, possible routing loops, etc. along a multi-router path between A and B.

Routing policy:

Our corporate network, AS 1000, will only learn routes to destinations in the ISP, AS 1, or its customers. (In our sample configuration, I've used 145.1.0.0 /16 for the ISP's network). We'll assume for simplicity that the ISP is stripping any AS paths for its customers, so that we'll only see such AS paths advertised as "1". This might well be the case if the ISP customers are using private AS numbers. Our AS 1000 is to use the 200.30.40.0 (bottom) link, via Router B, for outbound traffic to AS 1. Remaining outbound traffic is to normally use the other (top) link, via Router A. Inbound traffic should use whichever link is closest, since the ISP only sees a summary route. This is for stability, they and the Internet don't need to hear about our internal links going up or down.

Note also that this shuffles traffic between A and B somewhat, depending on connectivity to the rest of our network (not shown). Traffic for 145.1.0.0 /16 that arrives at A gets sent to B. Other traffic (following the default route) that arrives at B gets sent to A. Balancing could be done by "tuning" to allow information about additional AS's in via B.

Question: do we summarize 145.1 /16?

Another approach is to reason that you only care to take "the best exit" to destinations in AS 1 (or customer AS's). The idea would be to redistribute information about the ISP network 145.1.0.0 /16 carefully at A and B, into our IGP. The question there is, since we redistribute with a default metric, we really are only picking the closer exit point, which we could do much more simply with default routing. If we want the redistributed routes to contain more information, we need to fiddle with route maps to influence the metrics.

As part of this alternative strategy, both A and B could then also advertise default into the IGP. This allows traffic to fail over to the other link in case of a failure.

However, this alternative isn't what I've built and tested.

By the way, I've also used the Serial 0 addresses on routers A and B for iBGP neighbors, for simplicity, whereas loopback addresses might be somewhat preferable. You'll also notice I tried this on 2500's, not on 7x00's (didn't happen to have any with me this week). Just imagine that "Serial 0" is "Serial 0/0", and "Serial 1" is "Serial 1/0". Since back-to-back serial links were used, the configurations also show "clock rate" commands for the DCE-cabled serial port. And I realize I've never really written about route maps -- but space is tight, so that will have to wait for another article (sometime).

Configurations:

RouterA

 RouterB

(The on-line version of this article at http://www.netcraftsmen.net/welcher/papers/bgp2.htm will have all eight (8) configurations and routing and BGP tables from the routers I experimented with).

RouterC

RouterD

RouterG

RouterH

RouterE

RouterF

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net . 


5/98
Copyright 1998, Peter J. Welcher