The Illustrated Network- P42 pdf

CHAPTER
What You Will Learn
In this chapter, you will learn about the BGP and the essential role it plays on the
Internet. With BGP, routing information is circulated outside the AS and to all rout-
ing domains. We’ll see how a simple routing policy change can make a destination
unreachable.
You will learn about the differences between the Internet BGP (IBGP) and the
Exterior Gateway Protocol (EBGP), and why both are needed. We’ll also look at
BGP attributes and message formats.
Border Gateway Protocol
15
The EGP used on the Internet is the Border Gateway Protocol (BGP). IGPs run between
the routers inside a routing domain (single AS). BGP runs between different autono-
mous services (ASs). BGP runs on links between the border routers of these routing
domains and shares information about the routes within the AS or learned by the AS
with the AS on the other side of the “border.”
BGP makes sure that every network and interface in any AS located anywhere on
the Internet is reachable from every other place. BGP does not generate any routing
information on its own, unlike the IGPs, which essentially “bootstrap” themselves into
existence. BGP relies on an underlying IGP (or static routes) as the source of the BGP-
distributed information.
BGP runs on the border routers of Ace ISP’s AS 65459 (routers P9 and P4) and Best
ISP’s AS 65127 (routers P7 and P2). These are highlighted in Figure 15.1. An IGP such as
OSPF or IS–IS runs on the direct links between routers P9 and P4 and routers P7 and P2,
but these are interior links. BGP runs on the other links between the backbone routers.
BGP AS A ROUTING PROTOCOL
There are EGPs defi ned other than BGP. The Inter-Domain Routing Protocol (IDRP)
from ISO is the EGP that was to be used with IS–IS as an IGP. IDRP is also sometimes
promoted as the successor to BGP, or the best way to carry IPv6 routing information
CE0
lo0: 192.168.0.1

fe-1/3/0: 10.10.11.1
MAC: 00:05:85:88:cc:db
(Juniper_88:cc:db)
IPv6: fe80:205:85ff:fe88:ccdb
P9
lo0: 192.168.9.1
PE5
lo0: 192.168.5.1
P4
lo0: 192.168.4.1
so-0/0/1
79.2
so-0/0/1
24.2
so-0/0/0
47.1
so-0/0/2
29.2
so-0/0/3
49.2
so-0/0/3
49.1
so-0/0/0
59.2
so-0/0/2
45.1
so-0/0/2
45.2
so-0/0/0
59.1

ge-0/0/3
50.2
ge-0/0/3
50.1
DSL Link
Ethernet LAN Switch with Twisted-Pair Wiring
bsdclient lnxserver wincli1
em0: 10.10.11.177
MAC: 00:0e:0c:3b:8f:94
(Intel_3b:8f:94)
IPv6: fe80::20e:
cff:fe3b:8f94
eth0: 10.10.11.66
MAC: 00:d0:b7:1f:fe:e6
(Intel_1f:fe:e6)
IPv6: fe80::2d0:
b7ff:fe1f:fee6
LAN2: 10.10.11.51
MAC: 00:0e:0c:3b:88:3c
(Intel_3b:88:3c)
IPv6: fe80::20e:
cff:fe3b:883c
LAN2: 10.10.11.111
MAC: 00:0e:0c:3b:87:36
(Intel_3b:87:36)
IPv6: fe80::20e:
cff:fe3b:8736
winsvr1
LAN1
Los Angeles

Office
Ace ISP
AS 65459
Wireless
in Home
Solid rules
ϭ
SONET/SDH
Dashed rules
ϭ
Gig Ethernet
Note: All links use 10.0.x.y
addressing only the last
two octets are shown.
FIGURE 15.1
BGP on the Illustrated Network.
380 PART III Routing and Routing Protocols
CE6
lo0: 192.168.6.1
fe-1/3/0: 10.10.12.1
MAC: 0:05:85:8b:bc:db
(Juniper_8b:bc:db)
IPv6: fe80:205:85ff:fe8b:bcdb
Ethernet LAN Switch with Twisted-Pair Wiring
bsdserver lnxclient winsvr2 wincli2
eth0: 10.10.12.77
MAC: 00:0e:0c:3b:87:32
(Intel_3b:87:32)
IPv6: fe80::20e:
cff:fe3b:8732

eth0: 10.10.12.166
MAC: 00:b0:d0:45:34:64
(Dell_45:34:64)
IPv6: fe80::2b0:
d0ff:fe45:3464
LAN2: 10.10.12.52
MAC: 00:0e:0c:3b:88:56
(Intel_3b:88:56)
IPv6: fe80::20e:
cff:fe3b:8856
LAN2: 10.10.12.222
MAC: 00:02:b3:27:fa:8c
IPv6: fe80::202:
b3ff:fe27:fa8c
LAN2
New York
Office
P7
lo0: 192.168.7.1
PE1
lo0: 192.168.1.1
P2
lo0: 192.168.2.1
so-0/0/1
79.1
so-0/0/1
24.1
so-0/0/0
47.2
so-0/0/2

29.1
so-0/0/3
27.2
so-0/0/3
27.1
so-0/0/2
17.2
so-0/0/2
17.1
so-0/0/0
12.2
so-0/0/0
12.1
ge-0/0/3
16.2
ge-0/0/3
16.1
Best ISP
AS 65127
Global Public
Internet
CHAPTER 15 Border Gateway Protocol 381
between ISP ASs. However, when it comes to the Internet today, the only EGP worth
considering is BGP.
In a very real sense, BGP is not a routing protocol at all. BGP does not really
carry routing information from AS to AS, but information about routes from AS to AS.
Generally, a route that passes through fewer ASs (ISPs) than another is considered more
attractive, although there are many other factors (BGP attributes) to consider. BGP is a
routing protocol without real routes or metrics, and both of those derive from the IGP.
BGP is not a link-state protocol, because the state of links in many AS clouds would be

diffi cult to convey and maintain across the entire network (and links would tend to
“average out” to a sort of least common denominator anyway). But it’s not a distance-
vector protocol either, because more attributes than just AS path length determine
active routes. BGP is called a “path-vector” protocol (a vector has a direction as well as
value), but mainly because a new term was needed to describe its operation.
BGP information is not even described as a “route.” BGP carries network layer
reachability information (NLRI). BGP “routes” do not have metrics, like IGP routes, but
attributes. Together, the BGP NLRI and their attributes allow other ASs to make deci-
sions about the best way to reach a route (network) in another AS. Once a packet is
routed to the correct AS through BGP information, the packet is delivered locally using
the IGP information.
The differences between BGP and IGPs should always be remembered. Some new
to BGP struggle with BGP terminology and concepts because they attempt to interpret
BGP features in terms of more familiar IGP features. BGP does not work like an IGP
because BGP is not an IGP and should not work like an IGP. When BGP passes informa-
tion from one AS border router to another AS border router inside an AS, a form known
as interior BGP (IBGP) is used. When BGP passes information from one AS to another
AS, the form of BGP used is called exterior BGP (EBGP).
This chapter does not deal much with routing policies for BGP based on multiple
attributes, which determine how the routers use BGP to route packets. Complex rout-
ing policies are beyond the scope of this book.
Confi guring BGP
It’s important to keep in mind exactly what is meant by a routing domain and routing
policy. For example, is CE0 part of AS 65459 or not? This is not as simple a question as
it sounds, because there might be a dozen routers behind CE0 that the Ace ISP knows
nothing about. But the interface to PE5 is fi rmly under the control of Ace, and generally
all customer site routers are considered part of the ISP’s routing domain in the sense
that a routing policy on PE5 can always control the routing behavior of CE0.
This does not mean something like preventing the users on LAN1 from running
Internet Chat or something. This type of application-level detailing is not what a rout-

ing policy is for. Corporate policies of this type (application policing) are best han-
dled by an appliance on site. ISP routing policies determine things like where the
382 PART III Routing and Routing Protocols
10.10.11.0/24 route to LAN1 is advertised or held back, and which routes are accepted
from other sources.
Let’s see how easy it is to confi gure BGP on the border routers. Each of them is
essentially identical in basic confi guration, so let’s use P9 as an example.
set protocols bgp group ebgp-to-as65127 type external;
set protocols bgp group ebgp-to-as65127 peer-as 65127;
set protocols bgp group ebgp-to-as65127 neighbor 10.0.79.1;
set protocols bgp group ebgp-to-as65127 neighbor 10.0.29.1;
set protocols bgp group ibgp-mesh type internal;
set protocols bgp group ibgp-mesh local-address 192.168.9.1;
set protocols bgp group ibgp-mesh neighbor 192.168.4.1;
set protocols bgp group ibgp-mesh neighbor 192.168.5.1;
BGP confi gurations are organized into groups that have user-defi ned names
(ebgp-to-as65127 and ibgp-mesh) Note that there are two types of BGP running on
the border routers: EBGP and IBGP. EBGP must know the other AS number and IBGP
must know the local address to use as a source address (routers typically have many
IP addresses). Note that EBGP uses link addresses and IBGP uses the router’s “loopback”
address, in this case the address assigned to the routing engine. We’ll see why this is
usually done when we discuss EBGP and IBGP later in this chapter.
We showed at the end of the previous chapter that we could ping IPv6 addresses
from the Windows XP client on LAN1 to the Windows XP client on LAN2. Let’s see
if the same works for the IPv4 addresses on the Unix hosts. All is well between
bsdclient and bsdserver.
bsdclient# ping 10.10.12.77
PING 10.10.12.1 (10.10.12.77): 56 data bytes
64 bytes from 10.10.12.77: icmp_seq=0 ttl=255 time=0.600 ms
64 bytes from 10.10.12.77: icmp_seq=1 ttl=255 time=0.477 ms

64 bytes from 10.10.12.77: icmp_seq=2 ttl=255 time=0.441 ms
64 bytes from 10.10.12.77: icmp_seq=3 ttl=255 time=0.409 ms
^C
10.10.12.77 ping statistics
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.409/0.482/0.600/0.072 ms
The default behavior for BGP is to advertise all active routes that it learns by its
own operation, so no special advertising policies are needed on the backbone rout-
ers. Because there are direct links in place between the two ISPs to connect the Los
Angeles offi ce (LAN1) with the New York offi ce (LAN2), each ISP relies on the routing
protocol metrics to make sure traffi c fl owing between LAN1 (10.10.11/24) and LAN2
(10.10.12/24) is not forwarded onto the Internet. That is, the cost of forwarding a
LAN1-LAN2 packet between the provider backbone routers will always be less than
using the Internet at large.
CHAPTER 15 Border Gateway Protocol 383
However, one day the users on LAN1 and LAN2 discover a curious thing: no one can
reach servers on the other LAN. Pings to the local router work fi ne, but pings to remote
hosts on the other LAN produce no results at all.
bsdserver# ping 10.10.12.1
PING 10.10.12.1 (10.10.12.1): 56 data bytes
64 bytes from 10.10.12.1: icmp_seq=0 ttl=255 time=0.599 ms
64 bytes from 10.10.12.1: icmp_seq=1 ttl=255 time=0.476 ms
64 bytes from 10.10.12.1: icmp_seq=2 ttl=255 time=0.401 ms
64 bytes from 10.10.12.1: icmp_seq=3 ttl=255 time=0.443 ms
^C
10.10.12.1 ping statistics
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.401/0.480/0.599/0.071 ms
bsdserver# ping 10.10.11.177
PING 10.10.11.177 (10.10.11.177): 56 data bytes

^C
10.10.11.177 ping statistics
5 packets transmitted, 0 packets received, 100% packet loss
The remote router cannot be pinged either (presumably, no security prevents them
from pinging to another site router’s port).
bsdserver# ping 10.10.11.1
PING 10.10.11.1 (10.10.11.1): 56 data bytes
^C
10.10.11.1 ping statistics
7 packets transmitted, 0 packets received, 100% packet loss
The Power of Routing Policy
There are many things that could be wrong in this situation. In this case, the cause of
the problem is ultimately determined to be a feud between the Ace ISP and Best ISPs
running the service provider routers. The issue (greatly exaggerated here) is a server
located on LAN2 in New York. This essential server provides full-motion video, huge
database fi les, and all types of other information to the clients in Los Angeles on LAN1.
Naturally, a lot more packets fl ow from Best ISP’s AS to Ace ISP’s AS than the other way
around. So, the Ace ISP (AS 65459) controlling border routers P9 and P4 decided that
Best ISP (AS 65127) should pay for all these “extra” packets they were delivering from
the New York server. Shortly before the LANs stopped communicating, they sent a bill
to Best ISP—turning AS 65127 from a peer into a customer.
Naturally, Best ISP was not happy about this new arrangement and refused to pay.
So, Ace ISP decided to do a simple thing: they applied a routing policy and did not send
any information about the LAN1 network (10.10.11/24) to AS 65127’s border routers
(P7 and P2). If the border routers don’t know how to send packets back to LAN1
from the servers on LAN2, Ace ISP will be getting what they paid Best ISP for—which
is nothing. (In the real world, the customer paying for LAN1 and LAN2 connectivity
would be asked to pay for the asymmetrical traffi c load.)
384 PART III Routing and Routing Protocols
Without the correct routing information available on the routers on both ASs, no

one on LAN2 can fi nd a route to LAN1. Even if there were still some connectivity
between the sites through Ace and Best ISPs’ links to the Internet, this means that the
symptom would show up as a sharply increased network delay (and related application
timeouts), as packets now wander through many more hops than before. Something
would still clearly be wrong.
This large effect comes from a very simple cause. Let’s look at the routing tables and
policies on P2 and P7 (and P9 and P4) and see what has happened. Best ISP has applied
a very specifi c routing policy to their external BGP session with Ace ISP’s border rout-
ers. Here’s what it looks like on P7.
set policy-statement no-10-10-11 term1 from route-filter 10.10.11.0/24 exact;
set policy-statement no-10-10-11 term1 then reject;
This basically says, “Out of all the routing protocol information, fi nd (fi lter) the infor-
mation matching the network 10.10.11.0/24 exactly and nothing else; then discard
(reject) this information and do not use it in the routing or forwarding tables.”
This import policy on P7 and P2 (Best ISP’s routers) is applied on links from neigh-
bor border routers P4 and P9 (Ace ISP’s routers). The effect is to block BGP in AS 65127
from learning anything at all about network 10.10.11/24 from P4 and P9. Normally, Best
ISP’s backbone routers would pass the information about the route to LAN1 through
P7 and P2 to all other routers in the AS, including CE6 (LAN2’s site router). Without this
information, no forwarding table can be built on CE6 to allow packets to reach LAN1.
Problem solved: no packets for LAN1 can fl ow through Best ISP’s router network.
Note that Best ISP (AS 65127) still advertises its own LAN2 network (10.10.12/24)
to Ace ISP, and Ace ISP’s routers accept and distribute the information. So, on LAN1 the
site router CE0 still knows about both LANs.
admin@CE0# show route 10.10/16
inet.0: 38 destinations, 38 routes (38 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.11.0/24 *[Direct/0] 00:03:31
> via fe-1/3/0.0
10.10.11.1/32 *[Local/0] 00:03:31

Local via fe-1/3/0.0
10.10.12.0/24 *[BGP/170] 00:00:09
> via ge-0/0/3.0
But this makes no difference: Packets can get to LAN2 through CE6 (and from any-
where else in Best ISP’s AS), but they have no way to get back if they have a source
address of 10.10.12.x. Let’s verify this on CE6.
admin@CE6# show route 10.10/16
inet.0: 38 destinations, 38 routes (37 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
CHAPTER 15 Border Gateway Protocol 385
10.10.12.0/24 *[Direct/0] 00:25:42
> via fe-1/3/0.0
10.10.12.1/32 *[Local/0] 00:25:42
Local via fe-1/3/0.0
How are packets to get back to 10.10.11/24? They can’t. ( The former route to
LAN1 is now hidden because the network is no longer reachable.) This simple exam-
ple shows the incredible power of BGP and routing policies on the Internet.
BGP AND THE INTERNET
BGP is the glue of the Internet. Generally, an ISP cannot link to another ISP unless both
run BGP. Contrary to some claims, customer networks (even large customer networks
with many routers and multiple ASs) do not have to run BGP between their own net-
works and to their ISP (or ISPs). Smaller customers especially can defi ne a limited num-
ber of static routes provided by the ISP, and larger customers might be able run IGP
passively (no adjacency formed) on the border router’s ISP interface. It depends on the
complexity of the customer and ISP network. A customer with only one link to a single
ISP generally does not need BGP at all. But if a routing protocol is needed, it will be BGP.
When a customer network links to two ISPs and runs BGP, routing policies are
immediately needed to prevent the large ISPs from seeing the smaller network as a
transit AS to each other. This actually happened a number of times in the early days of
BGP, when small corporate networks new to BGP suddenly found themselves passing

traffi c between two huge national ISPs whose links to each other had failed. Why pass
traffi c through two or three other ISPs when “Small Company, Inc.” has a BGP path
a single AS long? BGP routing policies are immediately put in place to not advertise
routes learned for one national ISP to the other. As long as “you can’t get there from
here,” all will be fi ne at the little network in the middle.
BGP summarizes all that is known about the IP address space inside the local AS
and advertises this information to other ASs. The other ASs pass this information along,
until all ASs running BGP know exactly what is where on the Internet. Without BGP,
a single default route must handle all destinations outside the AS. This is okay when a
single router leads to the Internet, but inadequate for networks with numerous connec-
tions to other ASs and ISPs.
BGP was not the original EGP used on the Internet. The fi rst exterior gateway pro-
tocol was Exterior Gateway Protocol (EGP). EGP is still around, but only on isolated
portions of the original Internet—such as for the U.S. military. An appreciation of EGP’s
limitations helps to understand why BGP works the way it does.
EGP and the Early Internet
In the early 1980s, the Internet had grown to include almost 1000 computers. Several
noted that distance-vector routing protocols such as the original Gateway-to-Gateway
Protocol (GGP), an IGP, would not scale to a large network environment. If every router
386 PART III Routing and Routing Protocols
needed to know everything about every route, convergence times when links failed
would be very high. GGP routing changes had to happen globally and in a coordinated
fashion. But the Internet, even in the 1980s, was a huge network with many different
types of computers and routers run by many different organizations.
The answer divided the emerging Internet into independent but interconnected ASs.
As seen in Chapter 14, the AS is identifi ed by a 4-byte (32-bit) number assigned by the
same authorities that assign IP addresses. We’ll use a shorthand such as
65127 instead
of the full (and proper) 0.65127 to indicate legacy 2-byte AS numbers. The AS range
64512 through 65535 is reserved for private AS numbers. Inside the AS, the network

was assumed to be under the control of a single network administrator. Within the AS,
local network matters (addressing, links, new routers, and so on) could be addressed
locally with GGP. But GGP ran only within the AS. Between ASs, some way had to be
found to communicate what networks were reachable within and through one AS to
the other AS.
EGP was the solution. EGP ran on the border routers (gateways), with links to other
ASs. EGP routers just sent a list of other routers and the classful major networks that
the router could reach. This cut down on the amount of information that needed to
be sent between ASs. Today, aggregation should be used as often as possible with BGP
instead of classful major network routes, but the intent and result are the same. So,
if a BGP router knows about networks 10.10.1.0/24 through 10.10.127.0/24 it can
aggregate the route as 10.10.0.0/17 and advertise that one route ( NRLI ) instead of
128 separate routing updates. Even if a network such as 10.10.11.0/24 is not included
in the range, the more specifi c advertisement of 10.10.11.0/24 and the longest match
rule will make sure traffi c fi nds its way to the right place—as long as the route is adver-
tised properly. Nevertheless, there are many reasons people do not aggregate as much
as they should, and many of their reasons are fl awed. For example, trying to protect a
network against “prefi x hijacking” is a bad reason not to aggregate.
There is no need for an EGP to reproduce the features of an IGP. An IGP needs to
tell every router in the AS which router has which interfaces and what IP addresses are
attached to these interfaces or reachable through that router (such as static routes). All
that other ASs need to know is which IP addresses are reachable in a particular AS and
how to get to a border router on, or nearer to, the target AS.
The Birth of BGP
EGP suffered from a number of limitations, too technical to recount. After some ini-
tial attempts to upgrade EGP, it was decided to create a better EGP (as a class of
routing protocol, contrasted with IGPs) than EGP: BGP. BGP was defi ned in 1989
with RFC 1105 (BGP1 or BGP-1 or BGPv1), revised in 1990 as RFC 1163 (BGP2), and
revised again in 1991 as RFC 1267 (BGP3). The version of BGP used today on the
Internet, BGP4, emerged in 1994 as RFC 1654 and was extended for classless opera-

tion in 1995 as RFC 1771. The baseline BGP specifi cation today is RFC 4271. This
chapter describes BGP4.
CHAPTER 15 Border Gateway Protocol 387
BGP has been extended for new roles on the Internet. BGP extended communities
are used with virtual private networks (VPNs). Communities are simply labeled that
so they can be used to associate NLRIs that do not share other traits. For example, a
community value can be assigned to small customers and another community value
used to identify a small customer with multiple sites. There are few limits to the com-
munity “tags’” usage. And BGP routes are often the only ones that can use multiprotocol
label switching (MPLS) label-switched paths (LSPs). BGP is as easily extensible as IS–IS
and OSPF to support new functions and add routing information that needs to be cir-
culated between ASs.
Many organizations fi nd themselves suddenly forced to adapt BGP in a hurry, for
instance, when they have to multihome their networks. Also, when they deploy VPNs
or MPLS or any one of the many newer technologies used to potentially span ISPs and
ASs, BGP is needed. The problem with IGPs is that they cannot easily share information
across routing domain boundaries.
BGP AS A PATH-VECTOR PROTOCOL
One of the problems with EGP was that the metrics looked very much like RIP hop
counts. Simple distance vectors were not helpful at the AS level, because hop counts
did not distinguish the fast links that began appearing in major ISP network backbones.
Destinations that were “close” over two or three 56- or 64-kbps links actually took
much longer to reach than through four or fi ve hops over 45-Mbps links, and distance
vectors had no protection against routing loops.
Link-state protocols could have dealt with the problem by implementing some of
the alternate TOS metrics described for OPSF and IS–IS. However, these would rely not
only on consistent implementation among all ISPs but the proper setting of bits in IP
packets. In the world of independent highly competitive ISPs, this consistency was
next to impossible. So, BGP was developed as a path-vector protocol. This means that
one of the most important attributes BGP uses to choose the active route is the length

of the AS path reported in the NLRI.
To create this AS list, BGP routing updates carry a complete list of transit networks
(ASs) that must be traversed between the AS receiving the update and the AS that can
deliver the packet using its IGP. A loop occurs when an AS path list contains the same
AS that is receiving the update, so this update is rejected and loops are prevented. If
the update is accepted, that AS will add its own AS to the list when advertising the
routing update to other ASs. This lets an AS apply routing policies to the updates and
avoid using routes that lead through an AS that is not the preferred way to reach a
destination.
Path vectors do not mean that all ASs are created equal. Numerous small ASs might
get traffi c through faster than one huge AS. But more aspects of a route are described in
BGP than just the length of the AS path to the destination. The system allows each AS
to represent the route with a different metric that means something to the AS originat-
ing the route.
388 PART III Routing and Routing Protocols