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:
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.
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):
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.
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 188.8.131.52 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 184.108.40.206 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 220.127.116.11 remote-as 4969 neighbor 18.104.22.168 next-hop-self neighbor 22.214.171.124 send-communities neighbor 126.96.36.199 route-map prepend-once out neighbor 188.8.131.52 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.
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 184.108.40.206 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 220.127.116.11 4 6313 0 0 0 0 0 never Active 18.104.22.168 4 64514 1145670 237369 1159873 0 0 4d03h 22.214.171.124 4 64515 6078 5960 1159869 0 0 4d03h 126.96.36.199 4 64512 6128 6782 1159870 0 0 4d03h 188.8.131.52 4 64512 5962 6894 1159870 0 0 10:08:46 184.108.40.206 4 4231 161072 276660 1159870 0 0 2d05h 220.127.116.11 4 3564 6109 310292 1159867 0 0 22:40:50 18.104.22.168 4 64513 164708 724571 1159866 0 0 3d23h 22.214.171.124 4 3564 6086 274182 1159853 0 0 4d03h 126.96.36.199 4 6078 5793 310011 1159869 0 0 2d03h
Most of the above table is fairly self-explanatory:
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.