Configuring Peering for Neighbor Autonomous Systems

So far in this series we've looked at a number of basic concepts about BGP, covering both who would want to use it and why. In particular we've learned that speaking or advertising BGP to your service providers and/or peers lets you do two things:

  • Make semi-intelligent routing decisions concerning the best path for a particular route to take outbound from your network (otherwise you would simply set a default route from your border routers into your service providers).
  • Advertise your routes to those providers, for them to advertise in turn to others (for transit connectivity) or just use internally (in the case of peers).

We also pointed out some of the negative consequences that can result from careless BGP configuration. In this post, we'll delve deeper into the mechanics of BGP by looking at how you actually configure BGP on routers.

Autonomous Systems and ASNs

As discussed in Part 1, the term Autonomous System (AS) is a way of referring to a network such as a private enterprise network or a service provider network. Each AS is administered independently and may also be referred to as a domain. Each AS is assigned at least one Autonomous System Number (ASN), which identifies the network to the world. Most networks use (or at least show to the world) only one ASN. Each ASN is drawn from a 16-bit number field (allowing for 65,536 possible ASNs):

  • ASNs 0 and 65,535 are reserved values
  • The block of ASNs from 64,512 through 65,534 is designated for private use
  • The remainder of possible ASN values available for Internet routing range from 1 through to 64,511 (except 23,456).

eBGP vs. iBGP

One more clarification before we start configuring: BGP can be used internally (iBGP) within an AS to manage routes, and externally (eBGP) to route between ASes, which is what makes possible the Internet itself. In this article when we say BGP we're talking about eBGP, not iBGP. eBGP and iBGP share the same low-level protocol for exchanging routes, and also share some algorithms. But eBGP is used to exchange routes between different ASes, while iBGP is used to exchange routes within the same AS. In fact, iBGP is one of the "interior routing protocols" that you can use to do "active routing" inside your network/domain.

The major difference between eBGP and iBGP is that eBGP tries like crazy to advertise every BGP route it knows to everyone, and you have to put "filters" in place to stop it from doing so. iBGP, on the other hand, tries like crazy not to reconfigure routes. In fact, iBGP can actually be a challenge to get working because to make it work you have to peer all of the iBGP-"speakers" inside your network with all of the other iBGP speakers. This is called a "routing mesh" and, as you can imagine, it can get to be quite a mess when you have 20 routers that each have to peer with every other router. The solution to this is "BGP confederations," a topic we'll cover in a subsequent tutorial.

Peering Sessions

So now let's look at the actual configuration. BGP-speaking routers exchange routes with other BGP-speaking routers via peering sessions using ASN identification. At a technical level, this is what it means for one network or organization to peer with another. Here's a simplified Cisco code snippet of a router BGP clause:

router bgp 64512

<omitted lines…>

neighbor remote-as 701

The clause starts out by saying “router bgp 64512.” This means that what follows is a list of commands that describe how to speak BGP on behalf of ASN 64512. (We're using 64512 in our examples because it's not a live ASN, so if anyone uses a configuration straight from this column and uses this made up ASN, automated route-examination programs will detect it.)

All that's required to bring up a peering session is that one neighbor line under the router bgp clause. In this example, this line specifies as the remote IP address (with respect to the customer's route) of a router in the AS with ASN 701.

The purpose of neighbor commands is to initiate peering sessions with neighbors. It's possible to have BGP peering sessions that go over multiple hops, but eBGP multi-hop is a more advanced topic and has many potential pitfalls. So for now, let's assume that all neighbors must be on a LAN interface (Ethernet, Fast Ethernet, FDDI). In practice, you nearly always use more than one line to specify how to exchange routes with a given neighbor in a given peering session. So a typical neighbor command sequence would look more like this:

router bgp 64512

<omitted lines…>

neighbor remote-as 4969

neighbor next-hop-self

neighbor send-communities

neighbor route-map prepend-once out

neighbor filter-list 2 in

<omitted lines…>

Every time a neighbor session comes up, each router will evaluate every BGP route it has by running it through any filters you specify in the BGP neighbor command. Any routes that pass the filter are sent to the remote end. This filtering is a critical process. The most dangerous element of BGP is the risk that your filtering will go awry and you'll announce routes that you shouldn't to your upstream providers.

Seeing routes

While the session is up, BGP updates will be sent from one router to the other each time one of the routers knows about a new BGP route or needs to withdraw a previous route announcement. To see a list of all current peering sessions you can use the Cisco “sho ip bgp sum” command line: sho ip bgp summ

The command typically returns results like the following, which is a session summary from a core router at an ISP. The 6451x Autonomous Systems are BGP sessions to other routers at the same ISP whose ASNs are not shown to the world. The session is a session that is down, and the sessions where the remote Autonomous Systems are 4231, 3564, and 6078 are external peering sessions with routers from another ISP.

BGP table version is 1159873, main routing table version 1159873
44796 network entries (98292/144814 paths) using 9596344 bytes of memory
16308 BGP path attribute entries using 2075736 bytes of memory
12967 BGP route-map cache entries using 207472 bytes of memory
16200 BGP filter-list cache entries using 259200 bytes of memory
Neighbor   V   AS   MsgRcvd   MsgSent   TblVer   InQ   OutQ   Up/Down   State   4   6313   0   0   0   0   0   never   Active   4   64514   1145670   237369   1159873   0   0   4d03h   4   64515   6078   5960   1159869   0   0   4d03h   4   64512   6128   6782   1159870   0   0   4d03h   4   64512   5962   6894   1159870   0   0   10:08:46   4   4231   161072   276660   1159870   0   0   2d05h   4   3564   6109   310292   1159867   0   0   22:40:50   4   64513   164708   724571   1159866   0   0   3d23h   4   3564   6086   274182   1159853   0   0   4d03h   4   6078   5793   310011   1159869   0   0   2d03h     

Most of the above table is fairly self-explanatory:

  • The neighbor column gives the IP address of the neighbor with which the router is peered.
  • The V column is the BGP version number. If it is not 4, something is very wrong! BGP version 3 doesn't understand about Classless (CIDR) routing and is thus dangerous.
  • The AS column is the remote ASN.
  • InQ is the number of routes left to be sent to us.
  • OutQ is the number of routes left to be sent to the other side.
  • The Up/Down column is the time that the session has been up (if the State field is empty) or down (if State field is not empty).
  • Anything in a State field indicates that the session for that row is not up. In just one of the nomenclature flaws of BGP, a state of Active actually indicates that the session is inactive.

Coming Next

In our next installment we'll be looking at what to keep in mind when configuring BGP, as well as topics such as route withdrawal, route flaps, route selection, load balancing, and BGP metrics.