Networking

Getting autonomous with BGP: How Border Gateway Protocol can help you with routing

BGP is an interautonomous system routing protocol that is heterogeneous and proven. Although routing can sometimes be a rather daunting task, Alexander Prohorenko is here to show you the light with BGP.


... BGP is the primary routing protocol that Internet backbones use to exchange routing information...

Michael Dillon


Okay, let's start from the very beginning. What is BGP? In response to the various faults and limitations of Exterior Gateway Protocol (EGP), the Internet research community developed a new exterior gateway protocol called the Border Gateway Protocol, in short: BGP. In this Daily Drill Down, I’ll show you how BGP can help you with routing.

BGP is an interautonomous system routing protocol designed for TCP/IP networks. The BGP protocol was developed by the IWG/BGP Working Group of the Internet Engineering Task Force. The current version of the BGP protocol is version 4 (BGP-4).

A little background
BGP has been used in the production environment since 1989. The present production environment, where BGP is used as the interautonomous system routing protocol, is highly heterogeneous. In terms of link bandwidth, it varies from 56 Kbps to 45 Mbps. In terms of the actual routes that run BGP, it ranges from relatively slow PCs to the very high-performance RS/6000, and it includes both the special-purpose routers (Cisco) and the general-purpose workstations running UNIX. In terms of the actual topologies, it varies from very sparse (spanning tree or a ring of CA*Net [Canada’s Research and Education Internet] Backbone) to quite dense (T1 or T3 NSFNET [National Science Foundation Network] backbones).

A few words about changes between versions: Version 2 of BGP removed from the protocol the concept of up, down, and horizontal relations between autonomous systems that were present in version 1 and introduced the concept of path attributes. Version 3 of BGP lifted some of the restrictions on the use of the NEXT_HOP path attribute and added the BGP Identifier field to the BGP OPEN message. It also clarified the procedure for distributing BGP routes between the BGP speakers within an autonomous system.

BGP fixes several of EGP's problems and allows the protocol to scale to a much larger network. For example, to fix the problem of processing time for EGP updates, BGP exchanges the full routing table only at initialization; afterwards, it simply exchanges information about what has changed at each update. To fix the problem of IP fragmentation, BGP uses a TCP connection, which guarantees in-order delivery without loss or duplication.

Security
As far as security is concerned, BGP provides a flexible and extensible mechanism for authentication and security. The mechanism allows it to support schemes with various degrees of complexity. As part of the BGP authentication mechanism, the protocol allows BGP to carry an encrypted digital signature in every BGP message. All authentication failures result in the sending of notification messages and immediate termination of the BGP connection. Since BGP runs over TCP and IP, BGP's authentication scheme may be augmented by any authentication or security mechanism provided by either TCP or IP.

Routing
BGP-4 provides a new set of mechanisms for supporting classless interdomain routing, introduces mechanisms that allow the aggregation of routes, including aggregation of AS (autonomous system) paths. BGP-4 runs over a reliable transport protocol. This eliminates the need to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing. BGP-4 uses TCP as its transport protocol. TCP meets BGP's transport requirements and is present in virtually all commercial routers and hosts.

There are several interoperable implementations of BGP currently available from the following companies:
  • Cisco Systems
  • The GateD Consortium
  • 3Com
  • Bay Networks (Wellfleet)
  • Proteon

One more BGP implementation with public domain code (GPL-licensed) for BGP is a young, but very promising one: Zebra.

GNU Zebra is free software (distributed under the GNU General Public License) that manages TCP/IP-based routing protocols. Zebra software offers true modularity, unlike traditional, GateD-based, monolithic architectures, and even the so-called new modular architectures that remove the burden of processing routing functions from the CPU and utilize special ASIC chips instead. Zebra is intended for use as a route server and a route reflector. Currently, Zebra is available on the GNU/Linux platform and almost all branches of FreeBSD, NetBSD, and OpenBSD and is in development for Solaris 7. From the user's standpoint, Zebra looks like Cisco with the same interface and with all the basic commands of Cisco routers. It consists of separate daemons for numerous routing protocols. The main daemon starts on the server and accepts connections to port 2601 (zebra). Once you connect to it, you’ll get an interface very similar to Cisco's. That's why, in the case of a server running Zebra, all you need to do is perform the same operations with it as you do with a Cisco router.

But for the rest of this Daily Drill Down, I'll focus on the most popular implementations of BGP. Cisco’s BGP implementation was wholly developed by Cisco and runs on the proprietary operating system used by the Cisco routers. GateD’s implementation was developed entirely by Jeff Honig and Dennis Ferguson and runs on a variety of operating systems. RFC1226 claims GateD to be the only available public domain code for BGP.

Autonomous systems
The BGP routing protocol employs the concept of the autonomous system (AS). The definition of AS has been unclear and ambiguous for some time. Nowadays BGP-4 states, “The classic definition of an autonomous system is a set of routers under a single technical administration, using an Interior Gateway Protocol (IGP) and common metrics to route packets within the AS and using an Exterior Gateway Protocol (EGP) to route packets to other ASs.” Since this classic definition was developed, it has become common for a single AS to use several IGPs and sometimes several sets of metrics within an AS.

The use of the term autonomous system stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASs to have a single coherent interior routing plan and presents a consistent picture of which networks are reachable through it. (To rephrase succinctly: An AS is a connected group of one or more IP prefixes run by one or more network operators that has a single and clearly defined routing policy.) Typically, the AS would be the networks of a single organization, but it might be a group of cooperating organizations, such as a subsidiary. Because a router must be able to determine which AS it is in, as well as the ASs of its neighbors, each AS is assigned a globally unique 16-bit number (sometimes referred to as an ASN, or autonomous system number). This number is used both in the exchange of exterior routing information (between neighboring ASs) and as an identifier of the AS itself. The same central authority that assigns IP network addresses assigns these ASNs. Also, according to RFC1930, the Internet Assigned Numbers Authority (IANA) has reserved the block of AS numbers from 64512 through 65535 for private use (not to be advertised on the global Internet).

Let's get to work!
Now that you have a little overview of what BGP is, let’s start working with it. As I mentioned, BGP is much more flexible than EGP. Unfortunately, when a protocol becomes more flexible, at the same time it becomes more complex. I’ll present a sample BGP configuration scheme because a full discussion of all that’s possible could fill a book or even more.

Basic configuration—Cisco
This is the basic BGP configuration for a Cisco router (IP address 192.168.169.37) with a few local networks (192.168.134.0/23, 192.168.169.200/29, and 192.168.133.0) and one neighbor (192.168.169.33). I'll use ASN 65533 from the private block, which is not being distributed to the outside world. If your network isn't big enough, or if you just don’t want to get an ASN, feel free to use this one (for internal use only, of course). Our neighbor is another router from our network, so the remote ASN is the same.
! our ASN is 65533
router bgp 65533
bgp router-id 192.168.169.37
network 192.168.134.0 mask 255.255.254.0
network 192.168.169.200 mask 255.255.255.248
network 192.168.133.0
neighbor internal peer-group
neighbor 192.168.169.33 remote-as 65533
neighbor 192.168.169.33 peer-group internal
default-metric 1


This configuration isn't much more complex than the basic IGP configuration. A router statement starts a BGP process. Following the router statement is one or more network statements. These statements specify networks that BGP considers local to the AS and that BGP will originate to its partners in the BGP exchange. Next, I'll tell the BGP process who its neighbors are, using a neighbor statement with the autonomous systems to which each neighbor belongs.

I've already noticed that BGP-4 can handle classless network routes. In the case of the 192.168.133.0 network block, where I did not specify a mask on the network statement, the IOS assumes that I meant the natural mask for the old-style classified networks. For classless networks, which 192.168.134.0/23 and 192.168.169.200/29 are, I've appended the mask to the network statements.

Less-basic configuration
The network 192.168.134.0 mask 255.255.254.0 statement specifies the 192.168.134.0/23 network to be included in BGP updates, but this doesn't mean that BGP will automatically aggregate the two networks 192.168.134.0/24 and 192.168.135.0/24. It only means that if your IGP carries the network route, BGP will send it out, too. To get automatic summarization, you must use a more complex configuration, like the one below:
! our ASN is 65533
router bgp 65533
bgp router-id 192.168.169.37
aggregate-address 192.168.134.0 255.255.254.0 summary-only
network 192.168.169.200 mask 255.255.255.248
network 192.168.133.0
neighbor internal peer-group
neighbor 192.168.169.33 remote-as 65533
neighbor 192.168.169.33 peer-group internal
default-metric 1
redistribute rip route-map aggregate


Also, we have to add these blocks to our configuration:
! setting the origin of route matching access list 41 to IGP
route-map aggregate
match ip address 41
set origin igp

! select the component routes of 192.168.134.0/23 for aggregation
access-list 41 permit 192.168.134.0 0.0.1.255


A bit more complex
When either 192.168.134.0/24 or 192.168.135.0/24 (or both) appears in the router's table, BGP includes an advertisement for the CIDR (classless interdomain routing, RFC1519) aggregate 192.168.134.0/23 and suppresses the advertisement of the two more specific routes. The redistribute, route-map, and access-list statements are used to get routes for the two networks redistributed from our IGP to BGP. (I'm using RIP in this example.)

Okay, now let's test:
kitty>sh ip pro
Routing Protocol is "bgp 65533"
Sending updates every 60 seconds, next due in 0 seconds
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is enabled
Automatic route summarization is enabled
Default redistribution metric is 1
Neighbor(s):
 Address   FiltIn FiltOut DistIn DistOut Weight RouteMap
 192.168.169.33
Routing for Networks:
 192.168.134.0/23
 192.168.169.200/29
 192.168.133.0
Routing Information Sources:
 Gateway   Distance  Last Update
 192.168.169.33  200  1w0d
Distance: external 20 internal 200 local 200


Well, our configuration looks fine. We're starting to announce routing from 192.168.169.33 for our networks, which are 192.168.134.0/23, 192.168.169.200/29, and 192.168.133.0.

As you can see, BGP configurations can be very simple, but they can also quickly become extremely complex. A good way to solve your own specific configuration problem is to look at other configurations. There are many of them on the Net. Cisco specialists like to share their experience with the world and often put configurations of their routers on their home pages.

Basic configuration—GateD
Okay, now let's jump to our UNIX-router, which is running GateD, and learn a bit from its configuration.

Our UNIX router is a FreeBSD-powered PC system, which is running FreeBSD 3.4-STABLE and the GateD routing daemon, the most popular one that handles multiple routing protocols and replaces routed and egpup. Since GateD is very popular in the UNIX world, many UNIX distributions already include it in the binary package. FreeBSD includes it in a package distribution as well as in ports.

This router's IP is 192.168.169.33, and it has one network and one neighbor peer.

GateD’s configuration file is named gated.conf and is placed in the /etc directory. It looks like this:
interfaces {
  interface all passive;
};

autonomoussystem 65533;
routerid 192.168.169.33;

bgp yes {
  preference 20;
  traceoptions none;
  group type internal peeras 65533 {
 peer 192.168.169.37;
  };
};
 
rip no;
static {
  default gateway 192.168.169.36 preference 220;
  192.168.169.200 masklen 29 gateway 192.168.169.37 retain;
};
 
import proto bgp as 65533 {
  default preference 222;
  all
};


This configuration is a bit more complex than Cisco's, but not by too much.

Better security
Let’s spend some time looking at ways to provide better security for your routers. It goes without saying that one of the first things you should do is filter some routes that your router learns from one or more of our BGP neighbors. Let's look at the updated configuration:
! our ASN is 65533
router bgp 65533
bgp router-id 192.168.169.37
network 192.168.134.0 mask 255.255.254.0
network 192.168.169.200 mask 255.255.255.248
network 192.168.133.0
neighbor internal peer-group
neighbor 192.168.169.33 remote-as 65533
neighbor 192.168.169.33 filter-list 61 in
neighbor 192.168.169.33 peer-group internal
default-metric 1

! define an AS path access list that will block routes announced from AS 65500
ip as-path access-list 61 deny ^65500$
ip as-path access-list permit .*


Applied AS path access list 61 blocks any routes from uplinking with an AS path that contains AS 65500. As you can see, Cisco's IOS AS path syntax is a bit strange. This is a pattern-matching syntax based on UNIX regular expressions. First, a “$” symbol matches the end of the path, and a “^” symbol matches the beginning of the path. Since the AS path describes the path from your network to a destination network, your ASN (or your uplink's number) will normally be at the start of any path you see, and the destination ASN will be at the end. Second, a "." sign matches anything, and an "*" means zero or more occurrences of a thing. This means that the two-character sequence ".*" matches anything, or nothing, as appropriate. Finally, an "_" symbol matches any break between two ASNs or between an ASN and the beginning or end of the path.

Experiment, experiment!
As you can easily see, the options that can be used for a BGP configuration are endless. Each BGP configuration for each router is unique in some way, and there really is no typical BGP configuration. The best way to figure out how to achieve a goal is to look through several configurations and to experiment.

Conclusion
From a network administrator's viewpoint, BGP has proven to be very effective for big networks. Experience with implementing BGP shows that the protocol is relatively simple to implement. On the average, a BGP implementation takes about one man/month of effort. That's not much, which makes BGP very popular. It's not a panacea, however, and sometimes it's much better to use RIP than BGP (or even an OSPF scheme). In this Daily Drill Down, I showed you how BGP can help you with routing.

Whether you’re connecting to the Internet or to your company’s intranet, and whether you’re dealing with a permanent connection or an on-demand one, any connection to the world outside your network should be very carefully thought out, planned, and implemented. After all, if the network is a living organism (and it is!), then the impact of an external link should be given at least as much consideration as a new internal link. This is especially true for security, the most important factor of any network connection. You should never take security risks!
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox