BGP Routing Tutorial Series: Part 3
Summary
In this post we continue our look at BGP — the protocol used to route traffic across the interconnected Autonomous Systems (AS) that make up the Internet — by clarifying the difference between eBGP and iBGP and then starting to dig into the basics of actual BGP configuration. We’ll see how to establish peering connections with neighbors and to return a list of current sessions with useful information about each.
For an updated version of all four parts of this series in a single article, see “BGP Routing: A Tutorial” or download our Ultimate Guide to BGP Routing.
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 207.106.127.122 remote-as 701The 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 207.106.127.122 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 207.106.127.122 remote-as 4969
neighbor 207.106.127.122 next-hop-self
neighbor 207.106.127.122 send-communities
neighbor 207.106.127.122 route-map prepend-once out
neighbor 207.106.127.122 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:
brain.companyx.com# 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 205.160.5.1 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
205.160.5.1 4 6313 0 0 0 0 0 never Active
207.106.90.1 4 64514 1145670 237369 1159873 0 0 4d03h
207.106.91.5 4 64515 6078 5960 1159869 0 0 4d03h
207.106.92.16 4 64512 6128 6782 1159870 0 0 4d03h
207.106.92.17 4 64512 5962 6894 1159870 0 0 10:08:46
206.245.159.17 4 4231 161072 276660 1159870 0 0 2d05h
207.44.7.25 4 3564 6109 310292 1159867 0 0 22:40:50
207.106.33.3 4 64513 164708 724571 1159866 0 0 3d23h
207.106.33.4 4 3564 6086 274182 1159853 0 0 4d03h
207.106.127.6 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.
