Global Unicast Addressing, Routing, and Subnetting India's Best Networking Training Institute in Delhi Gurgaon India

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
 Call: +91-9654672192

The original Internet design called for all organizations to register and be assigned one or
more public IP networks (Class A, B, or C). By registering to use a particular public network
number, the company or organization using that network was assured by the numbering
authorities that no other company or organization in the world would be using the
same addresses. As a result, all hosts in the world would have globally unique IP addresses.
From the perspective of the Internet infrastructure, in particular the goal of keeping Internet
routers’ routing tables from getting too large, assigning an entire network to each organization
helped to some degree. The Internet routers could ignore all subnets as defined
inside an Enterprise, instead having a route for each classful network. For instance, if a
company registered and was assigned Class B network 128.107.0.0/16, the Internet routers
just needed one route for that whole network.
Over time, the Internet grew tremendously. It became clear by the early 1990s that something
had to be done, or the growth of the Internet would grind to a halt when all the
public IP networks were assigned, and no more existed. Additionally, the IP routing tables
in Internet routers were becoming too large for the router technology of that day. So, the
Internet community worked together to come up with both some short-term and longterm
solutions to two problems: the shortage of public addresses and the size of the routing
tables.
The short-term solutions included a much smarter public address assignment policy, in
which public addresses were not assigned as only Class A, B, and C networks, but as
smaller subdivisions (prefixes), reducing waste. Additionally, the growth of the Internet
www.CareerCert.info
534 CCNP ROUTE 642-902 Official Certification Guide
routing tables was reduced by smarter assignment of the actual address ranges based on
geography. For example, assigning the class C networks that begin with 198 to only a particular
ISP in a particular part of the world allowed other ISPs to use one route for
198.0.0.0/8–in other words, all addresses that begin with 198–rather than a route for each
of the 65,536 different Class C networks that begin with 198. Finally, NAT/PAT achieved
amazing results by allowing a typical home or small office to consume only one public
IPv4 address, greatly reducing the need for public IPv4 addresses.
IPv6 provides the long-term solution to both problems (address exhaustion and Internet
routing table size). The sheer size of IPv6 addresses takes care of the address exhaustion
issue. The address assignment policies already used with IPv4 have been refined and applied
to IPv6, with good results for keeping the size of IPv6 routing tables smaller in Internet
routers. This section provides a general discussion of both issues, in particular how
global unicast addresses, along with good administrative choices for how to assign IPv6
address prefixes, aid in routing in the global Internet. This section concludes with a discussion
of subnetting in IPv6.
Global Route Aggregation for Efficient Routing
By the time the Internet community started serious work to find a solution to the growth
problems in the Internet, many people already agreed that a more thoughtful public address
assignment policy for the public IPv4 address space could help keep Internet routing
tables much smaller and more manageable. IPv6 public address assignment follows these
same well-earned lessons.
Note: The descriptions of IPv6 global address assignment in this section provides a general
idea about the process. The process may vary from one RIR to another, and one ISP to
another, based on many other factors.
The address assignment strategy for IPv6 is elegant, but simple, and can be roughly summarized
as follows:
■ Public IPv6 addresses are grouped (numerically) by major geographic region.
■ Inside each region, the address space is further subdivided by ISPs inside that region.
■ Inside each ISP in a region, the address space is further subdivided for each customer.
The same organizations handle this address assignment for IPv6 as for IPv4. The Internet
Corporation for Assigned Network Numbers (ICANN, www.icann.org) owns the process,
with the Internet Assigned Numbers Authority (IANA) managing the process. IANA assigns
one or more IPv6 address ranges to each Regional Internet Registries (RIR), of which
there are five at the time of publication, roughly covering North America, Central/South
America, Europe, Asia/Pacific, and Africa. These RIRs then subdivide their assigned address
space into smaller portions, assigning prefixes to different ISPs and other smaller
registries, with the ISPs then assigning even smaller ranges of addresses to their customers.
www.CareerCert.info
Chapter 16 : IP Version 6 Addressing 535
The IPv6 global address assignment plan results in more efficient routing, as shown in
Figure 16-1. The figure shows a fictitious company (Company1) which has been assigned
an IPv6 prefix by a fictitious ISP, NA-ISP1 (meaning for North American ISP number 1).
The figure lists the American Registry for Internet Numbers (ARIN), which is the RIR for
North America.
As shown in the figure, the routers installed by ISPs in other major geographies of the
world can have a single route that matches all IPv6 addresses in North America. Although
there might be hundreds of ISPs operating in north America, and hundreds of thousands
of Enterprise customers of those ISPs, and tens of millions of individual customers of
those ISPs, all the public IPv6 addresses can be from one (or a few) very large address
blocks–requiring only one (or a few) routes on the Internet routers in other parts of the
world. Similarly, routers inside other ISPs in North America (for example, NA-ISP2, meaning
North American ISP number 2 in the figure), can have one route that matches all address
ranges assigned to NA-ISP2. And the routers inside NA-ISP1 just need to have one
route that matches the entire address range assigned to Company1, rather than needing to
know about all the subnets inside Company1.
Besides keeping the routers’ routing table much smaller, this process also results in fewer
changes to Internet routing tables. For example, if NA-ISP1 signed a service contract with
another Enterprise customer, NA-ISP1 could assign another prefix inside the range of addresses
already assigned to NA-ISP1 by ARIN. The routers outside NA-ISP1’s
Key
Topic
Company 1
NA-ISP2
NA-ISP1
Europe
South America
1 Route for
All Company 1
Addresses
1 Route for All
NA-ISP1 Addresses
1 Route for All North
American IPv6 Addresses
1 Route for All North
American IPv6 Addresses
536 CCNP ROUTE 642-902 Official Certification Guide
Table 16-2 Hexadecimal/Binary Conversion Chart
Hex Binary Hex Binary
0 0000 8 1000
1 0001 9 1001
2 0010 10 1010
3 0011 11 1011
4 0100 12 1100
5 0101 13 1101
6 0110 14 1110
7 0111 15 1111
network–the majority of the Internet–do not need to know any new routes, because their
existing routes already match the address range assigned to the new customer. The NAISP2
routers (another ISP) already have a route that matches the entire address range assigned
to NA-ISP1, so they do not need any more routes. Likewise, the routers in ISPs in
Europe and South America already have a route that works as well.
Conventions for Representing IPv6 Addresses
IPv6 conventions use 32 hexadecimal numbers, organized into 8 quartets of 4 hex digits
separated by a colon, to represent a 128-bit IPv6 address, for example:
2340:1111:AAAA:0001:1234:5678:9ABC
Each hex digit represents 4 bits, so if you want to examine the address in binary, the conversion
is relatively easy if you memorize the values shown in Table 16-2.
Writing or typing 32 hexadecimal digits, although more convenient writing or typing 128
binary digits, can still be a pain. To make things a little easier, two conventions allow you
to shorten what must be typed for an IPv6 address:
■ Omit the leading 0s in any given quartet.
■ Represent one or more consecutive quartets of all hex 0s with “::” but only for one
such occurrence in a given address.
Note: For IPv6, a quartet is one set of 4 hex digits in an IPv6 address. There are 8 quartets
in each IPv6 address.
For example, consider the following address. The bold digits represent digits in which the
address could be abbreviated.
FE00:0000:0000:0001:0000:0000:0000:0056
Key
Topic
www.CareerCert.info
Chapter 16 : IP Version 6 Addressing 537
This address has two different locations in which one or more quartets have 4 hex 0s, so
two main options exist for abbreviating this address–using the :: abbreviation in one or the
other location. The following two options show the two briefest valid abbreviations:
FE00::1:0:0:0:56
FE00:0:0:1::56
In particular, note that the “::” abbreviation, meaning “one or more quartets of all 0s,” cannot
be used twice because that would be ambiguous. So, the abbreviation FE00::1::56
would not be valid.
Conventions for Writing IPv6 Prefixes
IPv6 prefixes represent a range or block of consecutive IPv6 addresses. Just like routers
use IPv4 subnets in IPv4 routing tables to represent ranges of consecutive addresses,
routers use IPv6 prefixes to represent ranges of consecutive IPv6 addresses as well. The
concepts mirror those of IPv4 addressing when using a classless view of the IPv4 address.
Figure 16-2 reviews both the classful and classless view of IPv4 addresses, compared to
the IPv6 view of addressing and prefixes.
First, for perspective, compare the classful and classless view of IPv4 addresses. Classful
IPv4 addressing means that the class rules always identify part of the address as the network
part. For example, the written value 128.107.3.0/24 (or 128.107.3.0 255.255.255.0)
means 16 network bits (because the address is in a class B network), 8 host bits (because
the mask has 8 binary 0s), leaving 8 subnet bits. The same value, interpreted with classless
rules, means prefix 128.107.3.0, prefix length 24. Classless addressing and classful addressing
just give slightly different meaning to the same numbers.
Length of Network + Subnet Parts
Network Subnet Host IPv4 Classful Addressing
Host IPv4 Classless Addressing
Host
(Interface ID)
Prefix
Prefix
Prefix Length
Prefix Length
IPv6 Addressing
Figure 16-2 IPv4 Classless and Classful Addressing, IPv6 Addressing
www.CareerCert.info
538 CCNP ROUTE 642-902 Official Certification Guide
IPv6 uses a classless view of addressing, with no concept of classful addressing. Like IPv4,
IPv6 prefixes list some prefix value, a slash, and then a numeric prefix length. Like IPv4
prefixes, the last part of the number, beyond the length of the prefix, will be represented
by binary 0’s. And finally, IPv6 prefix numbers can be abbreviated with the same rules as
IPv4 addresses.
Note: IPv6 prefixes are often called IPv6 subnets as well. This book uses these terms
interchangeably.
For example, consider the following IPv6 address that is assigned to a host on a LAN:
2000:1234:5678:9ABC:1234:5678:9ABC:1111/64
This value represents the full 128-bit IP address–there are no opportunities to even abbreviate
this address. However, the /64 means that the prefix (subnet) in which this address resides
is the subnet that includes all addresses that begin with the same first 64 bits as the
address. Conceptually, it is the same logic as an IPv4 address, for example, address
128.107.3.1/24 is in the prefix (subnet) whose first 24 bits are the same values as address
128.107.3.1.
As with IPv4, when writing or typing a prefix, the bits past the end of the prefix length are
all binary 0s. In the IPv6 address previously shown, the prefix in which the address resides
would be
2000:1234:5678:9ABC:0000:0000:0000:0000/64
Which, when abbreviated, would be
2000:1234:5678:9ABC::/64
Next, one last fact about the rules for writing prefixes before seeing some examples and
moving on. If the prefix length is not a multiple of 16, then the boundary between the prefix
and the interface ID (host) part of the address is inside a quartet. In such cases, the prefix
value should list all the values in the last octet in the prefix part of the value. For
example, if the address just shown with a /64 prefix length instead had a /56 prefix length,
the prefix would include all of the first 3 quartets (a total of 48 bits), plus the first 8 bits of
the fourth quartet. The next 8 bits (last 2 hex digits) of the fourth octet should now be binary
0s, as part of the host portion of the address. So, by convention, the rest of the
fourth octet should be written, after being set to binary 0s, as follows:
2000:1234:5678:9A00::/56
The following list summarizes some key points about how to write IPv6 prefixes.
■ The prefix has the same value as the IP addresses in the group for the number of bits
in the prefix length.
■ Any bits after the prefix length number of bits are binary 0s.
■ The prefix can be abbreviated with the same rules as IPv6 addresses.
■ If the prefix length is not on a quartet boundary, write down the value for the entire
quartet.
Key
Topic
www.CareerCert.info
Chapter 16 : IP Version 6 Addressing 539
Examples can certainly help in this case. Table 16-3 shows several sample prefixes, their
format, and a brief explanation.
Note which options are not allowed. For example, 2::/3 is not allowed instead of 2000::/3,
because it omits the rest of the octet, and a device could not tell if 2::/3 means “hex 0002”
or “hex 2000”.
Now that you understand a few of the conventions about how to represent IPv6 addresses
and prefixes, a specific example can show how IANA’s IPv6 global unicast IP address assignment
strategy can allow the easy and efficient routing shown in Figure 16-1.
Global Unicast Prefix Assignment Example
IPv6 standards reserve the range of addresses inside the 2000::/3 prefix as global unicast
addresses. This address range includes all IPv6 addresses that begin with binary 001, or as
more easily recognized, all IPv6 addresses that begin with a 2 or 3. IANA assigns global
unicast IPv6 addresses as public and globally unique IPv6 addresses, as discussed using
the example previously shown in Figure 16-1, allowing hosts using those addresses to
communicate through the Internet without the need for NAT. In other words, these addresses
fit the purest design for how to implement IPv6 for the global Internet.
Figure 16-3 shows an example set of prefixes that could result in a company (Company1)
being assigned a prefix of 2340:1111:AAAA::/48.
The process starts with IANA, who owns the entire IPv6 address space and assigns the
rights to registry prefix to one of the RIRs (ARIN in this case, in North America). For the
purposes of this chapter, assume that IANA assigns prefix 2340::/12 to ARIN. This assignment
means that ARIN has the rights to assign any IPv6 addresses that begin with the first
12 bits of hex 2340 (binary value 0010 0011 0100). For perspective, that’s a large group of
addresses: 2116 to be exact.
Next, NA-ISP1 asks ARIN for a prefix assignment. After ARIN ensures that NA-ISP1
meets some requirements, ARIN might assign site prefix 2340:1111::/32 to NA-ISP1. This
too is a large group: 296 addresses to be exact. For perspective, this one address block may
1Although an RIR can assign a prefix to an ISP, an RIR may also assign a prefix to other Internet
registries, which might subdivide and assign additional prefixes, until eventually an ISP and
then their customers are assigned some unique prefix.

IP Version 6 Addressing Network Bulls Best CCNA Course Training Institute in Delhi Gurgaon India

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192


The world has changed tremendously over the last 10–20 years as a result of the growth
and maturation of the Internet and networking technologies in general. As recently as
1990, a majority of the general public did not know about nor use global networks to
communicate, and when businesses needed to communicate, those communications
mostly flowed over private networks. During the 1990s, the public Internet grew to the
point where people in most parts of the world could connect to the Internet; many companies
connected to the Internet for a variety of applications, with the predominate applications
being email and web. During the first decade of the 21st century, the Internet has
grown further to billions of addressable devices with the majority of people on the planet
having some form of Internet access. With that pervasive access came a wide range of applications
and uses, including voice, video, collaboration, and social networking, with a
generation that has grown up with this easily accessed global network.
The eventual migration to IPv6 will likely be driven by the need for more and more IP addresses.
Practically every mobile phone supports Internet traffic, requiring the use of an
IP address. Most new cars have the capability to acquire and use an IP address, along with
wireless communications, allowing the car dealer to contact the customer when the car’s
diagnostics detect a problem with the car. Some manufacturers have embraced the idea
that all their appliances need to be IP-enabled.
Although the two biggest reasons why networks might migrate from IPv4 to IPv6 are the
need for more addresses and mandates from government organizations, at least IPv6 includes
some attractive features and migration tools. Some of those advantages are
■ Address assignment features: IPv6 supports a couple of methods for dynamic address
assignment, including DHCP and Stateless Autoconfiguration.
■ Built-in support for address renumbering: IPv6 supports the ability to change
the public IPv6 prefix used for all addresses in an Enterprise, using the capability to
advertise the current prefix with a short timeout and the new prefix with a longer
lease life.
■ Built-in support for mobility: IPv6 supports mobility such that IPv6 hosts can
move around the Internetwork and retain their IPv6 address without losing current
application sessions.
■ Provider independent and dependent public address space: ISPs can assign
public IPv6 address ranges (dependent), or companies can register their own public
address space (independent).
■ Aggregation: IPv6’s huge address space makes for much easier aggregation of
blocks of addresses in the Internet, making routing in the Internet more efficient.
■ No need for NAT/PAT: The huge public IPv6 address space removes the need for
NAT/PAT, which avoids some NAT-induced application problems and makes for more
efficient routing.
www.CareerCert.info
Chapter 16 : IP Version 6 Addressing 533
■ IPsec: Unlike IPv4, IPv6 requires that every IPv6 implementation support IPsec.
IPv6 does not require that each device use IPsec, but any device that implements IPv6
must also have the ability to implement IPsec.
■ Header improvements: Although it might seem like a small issue, the IPv6 header
actually improves several things compared to IPv4. In particular, routers do not need
to recalculate a header checksum for every packet, reducing per-packet overhead. Additionally,
the header includes a flow label that allows for easy identification of packets
sent over the same single TCP or UDP connection.
■ No broadcasts: IPv6 does not use Layer 3 broadcast addresses, instead relying on
multicasts to reach multiple hosts with a single packet.
■ Transition tools: As covered in Chapter 18, the IPv6 has many rich tools to help
with the transition from IPv4 to IPv6.
This list includes many legitimate advantages of IPv6 over IPv4, but the core difference,
and the main topic of this chapter, is IPv6 addressing. The first two section of this chapter
examine one particular type of IPv6 addresses, global unicast addresses, which have many
similarities to IPv4 addresses–particularly public IPv4 addresses. The third section broadens
the discussion to include all types of IPv6 addresses, and protocols related to IPv6 address
assignment, default router discovery, and neighbor discovery. The final section looks
at the router configuration commands for IPv6 addressing.

Influencing an Enterprise’s Inbound Routes with MED best cisco ccie training center in new delhi

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192


An Enterprise has reasonably good control over its outbound IP routes. The engineers can
configure BGP to set and react to Weight, Local_Pref, and AS_Path length, manipulating
each to choose a different outgoing link or different router through which to forward
packets to the Internet.
An Enterprise has much less control over inbound routes: routes for packets coming back
toward the Enterprise. First, these inbound routes exist on routers that the Enterprise does
not own. Even if an ISP or set of ISPs can be convinced by engineers at the Enterprise to
make their routes toward an Enterprise take a particular path, technical issues may prevent
the design from being implemented. In particular, if the Enterprise’s public IP address
range is summarized, the companies that use addresses in that range may have competing
goals, so no policy can be applied to influence the best route.
However, several tools exist that allow some control over the last ASN hop between an ISP
and their Enterprise customer. This book examines one such tool, called Multi-Exit Discriminator
(MED), originally worked for a dual-homed design–that is, with a single ISP
but with multiple links to that ISP. MED was later expanded to support dual-multihomed
designs (2+ ASNs, 2+ links), relying on the concept that ISPs would work together. This
section examines the dual-homed case, with a single ISP.
MED Concepts
The name Multi Exit Discriminator actually describes its function to a great degree. With
a dual-homed design, at least two links exist between the Enterprise and the ISP. The Enterprise
can announce to the ISP a value (MED) that tells the ISP which path into the Enterprise
is best. As a result, the ISP can discriminate between the multiple exit points from
that ISP to the Enterprise.
Because MED lets the Enterprise ASN tell just the neighboring ASN which link into the
Enterprise to use, engineers typically use MED when advertising an Enterprise’s public IP
address space. Those inbound routes into the Enterprise from the ISP typically consist of
either one, or a few, public IP address ranges.
For example, consider a new network design as shown in Figure 15-10. In this case, the
Enterprise uses the same 128.107.0.0/19 public address range used in Chapters 13 and 14.
The Enterprise connects only to ASN 1 with a total of four physical links and three BGP
neighbors.
Step 5. Origin: Whatever the Origin is (I or ?), it should tie.
Step 6. MED: None of the other steps determined the best route, so now MED
takes effect.
Table 15-7 summarizes the key points about MED.
Key
Topic
Note: For those of you memorizing using the NWLLA OMNI mnemonic, MED is the M
in OMNI.
MED Configuration
MED configuration usually occurs on the routers in the AS that wants to control inbound
routes from the neighboring AS. As such, in the example design shown in Figure 15-10,
Routers E1 and E2 would configure MED. Example 15-9 shows E1’s configuration.
Example 15-9 MED Configuration on Router E1
route-map set-med-to-I1-1 permit 10
match ip address prefix only-public
set metric 10
!
route-map set-med-to-I1-4 permit 10
match ip address prefix only-public
set metric 20
!
ip prefix-list only-public permit 128.107.0.0/19
!
Table 15-7 Key Features of MED
Feature Description
Is it a PA? Yes.
Purpose Allows an AS to tell a neighboring AS the best way to forward packets into
the first AS.
Scope Advertised by one AS into another, propagated inside the AS, but not sent to
any other autonomous systems.
Range 0 through 4,294,967,295 (232 – 1).
Which is
best?
Smaller is better.
Default 0
Configuration Via neighbor route-map out command, using the set metric command inside
the route map.
www.CareerCert.info
522 CCNP ROUTE 642-902 Official Certification Guide
router bgp 11
neighbor 1.1.1.1 route-map set-med-I1-1 out
neighbor 192.168.1.2 route-map set-med-I1-4 out
Both the configuration and the show ip bgp command output refers to MED as metric.
Note that the route map in Example 15-8 uses the set metric command, rather than set
med (which does not exist). And as shown in I1-1’s output for the show ip bgp command
in Example 15-10, the output lists MED under the heading metric. In particular, note that
even the show ip route command lists the MED value in brackets as the metric for the
BGP route.
Example 15-10 BGP Table and IP Routing Table on Router I1-1
I1-1# show ip bgp 128.107.0.0/19
BGP routing table entry for 128.107.0.0/19, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
11, (aggregated by 11 128.107.9.1), (received & used)
11.11.11.11 from 11.11.11.11 (128.107.9.1)
Origin IGP, metric 10, localpref 100, valid, external, atomic-aggregate, best
I1-1# sh ip bgp 128.107.0.0/19 longer-prefixes
BGP table version is 13, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 128.107.0.0/19 11.11.11.11 10 0 11 i
I1-1# show ip route 128.107.0.0 255.255.224.0 longer-prefixes
! Legend omitted for brevity
Gateway of last resort is not set
128.107.0.0/19 is subnetted, 1 subnets
B 128.107.0.0 [20/10] via 11.11.11.11, 00:02:18

Influencing an Enterprise’s Outbound Routes best cisco ccsp training center in new delhi

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

This section examines three different features that can influence the outbound routes
from an Enterprise: Weight, the Local_Pref PA, and AS_Path length. The topics are listed
in the order used by the BGP best path algorithm (Steps 1, 2, and 4). It also introduces the
concept of a Routing Table Manager (RTM) function on a router.
Influencing BGP Weight
A Cisco router can use the BGP Weight, on that single router, to influence that one
router’s choice of outbound route. To do so, when a router receives a BGP Update, that
router can set the Weight either selectively, per route, using a route map, or for all routes
learned from a single neighbor. The router’s best path algorithm then examines the Weight
of competing routes, choosing the route with the bigger Weight.
The Cisco-proprietary Weight settings configured on a single router can influence only
that one router because the Weight cannot be communicated to other neighboring BGP
routers. So, to use the Weight, a router must be configured to examine incoming Updates
to set the Weight. The Weight cannot simply be learned in a received Update because that
Update message does not support a field in which to communicate the Weight setting.
Table 15-4 summarizes some of the key facts about BGP administrative Weight. Following
the table, the text first explains a sample internetwork and its existing configuration, a
configuration that begins with configurations that do not set any values that influence the
choice of best paths. The next section shows how to set the Weight using the neighbor
route-map in command, which allows a router to set different Weights for different routes.
The second example shows how to set the Weight for all routes learned from a neighbor,
using the neighbor weight command.
Key
Topic
Table 15-4 Key Features of Administrative Weight
Feature Description
Is it a PA? No; Cisco proprietary feature
www.CareerCert.info
Chapter 15: BGP Path Control 501
Note: For those of you memorizing using the N WLLA OMNI mnemonic, Weight is the
W in WLLA.
Sample Internetwork Used in the Weight Examples
Figure 15-3 shows a sample Internetwork used to demonstrate setting the Weight. The figure
shows a single Enterprise and a single Enterprise router. The following design requirements
have already been met by the configuration in Router E1 and in the ISP routers:
■ E1 and I1-1 uses loopback IP addresses (11.11.11.11 and 1.1.1.1) for their neighborship.
■ E1 and I3-1 use interface IP addresses for their neighborship.
■ None of the routers have attempted to change any settings that can impact the choice
of best path.
Next, to have some routes to manipulate with the upcoming examples, the ISP routers
each advertise BGP routes for the same five prefixes. Figure 15-4 shows five such prefixes
that both ISPs advertise to E1.
Just to get a little deeper understanding of the best path algorithm before getting into the
Weight configuration, consider the original configuration state of the sample internetwork,
with no attempt to influence E1’s choice of best path. The best path for four of the
five prefixes will be obvious. Prefixes 181.0.0.0/8 and 182.0.0.0/8 have a shorter AS_Path
through ISP1, and 184.0.0.0/8 and 185.0.0.08 have a shorter AS_Path through ISP3. Only
183.0.0.0/8 is in question because its AS_Path length for the competing routes is equal.
Example 15-1 shows the output of the show ip bgp 176.0.0.0/4 longer-prefixes command,
which lists all five of the BGP prefixes listed in Figure 15-4, confirming the results.
(Prefix 176.0.0.0/4 implies a range of values whose first octets are in the range 176 through
191, which includes the routes listed in Example 15-1.)
First, consider the best path algorithm on Router E1 for 181.0.0.0/8. E1 knows two BGP
routes for 181.0.0.0/8, as expected. The one listed as the best path has 1.1.1.1 (I1-1) as
Next_Hop. The following list outlines the best path logic:
Step 0. The Next_Hop of each is reachable. (Otherwise the neighbors would not be up.)
Step 1. The Weight ties (both 0).
Step 2. The Local_Pref ties (unset, so no value is listed; defaults to 100).
Step 3. Neither route is locally injected; both are learned using BGP, so neither is better
at this step.
Step 4. AS_Path length is shorter for the route through I1-1 (1.1.1.1).
Next, consider the example of the route to 183.0.0.0/8. E1 currently lists the path through
I1-1 (1.1.1.1) as best, but the best path decision actually falls all the way to Step 9. For completeness’
sake, E1’s best path logic runs as follows:
Step 0. The Next_Hop of each is reachable (otherwise the neighbors would not be up)
Step 1. The Weight ties (both 0).
Step 2. The Local_Pref ties (unset, defaults to 100).
Step 3. Neither route is locally injected.
Step 4. AS_Path length is 4 in both cases.
Step 5. Both Origin codes are i.
Step 6. MED, listed under the Metric column, ties (0).
Step 7. Neighbor type for each neighbor is eBGP.
Example 15-1 BGP Configuration on E1: Neighborships Configured
www.CareerCert.info
504 CCNP ROUTE 642-902 Official Certification Guide
Step 8. IGP metric does not apply, because neither uses IGP routes. (The routes from
E1 to 1.1.1.1 are static routes.)
Step 9. The route learned from 1.1.1.1 is the oldest route.
Although you may believe the claims at Step 9, the output in Example 15-1 does not explicitly
state that fact. However, when IOS lists output in the variations of the show ip bgp
command, the oldest route for each prefix is listed last, and the newest (most recently
learned) is listed first. Example 15-2 confirms this logic, and confirming how Step 9 works
in this case. Example 15-2 clears peer 1.1.1.1 (I1-1), making E1’s route through 192.168.1.2
(I3-1) become the oldest known route for 183.0.0.0/8:
Example 15-2 Clearing Neighbors to Force a New Route
E1# clear ip bgp 1.1.1.1
E1#
*Aug 24 11:30:41.775: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down User reset
*Aug 24 11:30:43.231: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
E1# show ip bgp 176.0.0.0/4 longer-prefixes
BGP table version is 47, local router ID is 128.107.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 181.0.0.0/8 1.1.1.1 0 0 1 1811 i
* 192.168.1.2 0 0 3 2 50 51 52 1811 i
*> 182.0.0.0/8 1.1.1.1 0 0 1 2 1822 i
* 192.168.1.2 0 0 3 2 50 51 1822 i
* 183.0.0.0/8 1.1.1.1 0 0 1 2 50 1833 i
*> 192.168.1.2 0 0 3 2 50 1833 i
* 184.0.0.0/8 1.1.1.1 0 0 1 2 50 51 1844 i
*> 192.168.1.2 0 0 3 2 1844 i
* 185.0.0.0/8 1.1.1.1 0 0 1 2 50 51 52 1855 i
*> 192.168.1.2 0 0 3 1855 i
After the hard reset of peer 1.1.1.1, E1’s oldest-known route for 183.0.0.0/8 is the route
through 192.168.1.2, listed second (last). That E1 now chooses this route as best is another
confirmation that E1’s best path decision fell to Step 9.
Setting the BGP Administrative Weight Using a Route Map
The neighbor neighbor-ip route-map in BGP subcommand tells a router to apply the
route map to all BGP Updates received from the listed neighbor. Such route maps always
attempt to filter routes. The router allows routes first matched in a permit clause and filters
(discards) routes first matched with a deny clause.
BGP route maps can also be used to change the PAs of routes by using the set command.
For example, a router could use a neighbor 1.1.1.1 route-map fred in command. The route
www.CareerCert.info
Chapter 15: BGP Path Control 505
map could contain permit clauses that cause some routes to not be filtered. In those same
route map clauses, the inclusion of commands such as set weight 100 and set local-preference
200 can be used to set items such as the Weight or Local_Pref of a route. (Although
you can configure a set command in a route map deny clause, the set has no effect
because the deny clause filters the route.)
Example 15-3 shows a sample configuration that sets the Weight for prefix 181.0.0.0/8 as
learned from I3-1 (neighbor ID 192.168.1.2). As shown in Examples 15-1, E1’s original best
route for this prefix is through I1-1 (1.1.1.1), due to the shorter AS_Path length at Step 4 of
the best path algorithm. By setting the Weight higher on the route learned from I3-1, E1
now chooses the route through I3-1.
Example 15-3 Setting the Weight to 50 for 181/8, as Learned from I3-1
E1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
E1(config)# ip prefix-list match-181 permit 181.0.0.0/8
E1(config)# route-map set-weight-50 permit 10
E1(config-route-map)# match ip address prefix-list match-181
E1(config-route-map)# set weight 50
E1(config-route-map)# route-map set-weight-50 permit 20
E1(config-route-map)# router bgp 11
E1(config-router)# neighbor 192.168.1.2 route-map set-weight-50 in
E1(config-router)# ^Z
E1#
E1# clear ip bgp 192.168.1.2 soft
E1# show ip bgp 176.0.0.0/4 longer-prefixes
BGP table version is 48, local router ID is 128.107.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 181.0.0.0/8 1.1.1.1 0 0 1 1811 i
*> 192.168.1.2 0 50 3 2 50 51 52 1811 i
*> 182.0.0.0/8 1.1.1.1 0 0 1 2 1822 i
* 192.168.1.2 0 0 3 2 50 51 1822 i
* 183.0.0.0/8 1.1.1.1 0 0 1 2 50 1833 i
*> 192.168.1.2 0 0 3 2 50 1833 i
* 184.0.0.0/8 1.1.1.1 0 0 1 2 50 51 1844 i
*> 192.168.1.2 0 0 3 2 1844 i
* 185.0.0.0/8 1.1.1.1 0 0 1 2 50 51 52 1855 i
*> 192.168.1.2 0 0 3 1855 i
! The next command lists the pre-route-map received Update
E1# show ip bgp neigh 192.168.1.2 received-routes | include 181
* 181.0.0.0/8 192.168.1.2 0 0 3 2 50 51 52 1811 i
www.CareerCert.info
506 CCNP ROUTE 642-902 Official Certification Guide
! The next command shows the post-route-map received Update
E1# show ip bgp neigh 192.168.1.2 routes | incl 181
*> 181.0.0.0/8 192.168.1.2 0 50 3 2 50 51 52 1811 i
The configuration uses a single-line IP prefix list that matches exactly prefix 181.0.0.0/8,
and a 2-clause route map. The first route-map clause, a permit clause, matches 181.0.0.0/8.
The permit action allows the route through the filter. The set weight 50 command then
sets the weight.
The second route-map clause, also with a permit action, matches the rest of the prefixes
in the Update because there is no match command. The permit action allows these routes
through the filter. Without clause 20, this route map would have matched all other routes
with the route map’s implied deny clause at the end of every route map, filtering all other
routes learned from 192.168.1.2 except 181.0.0.0/8.
The configuration also includes a neighbor 192.168.1.2 route-map set-weight-50 in command
to enable the route map for incoming updates from Router I3-1. The example also
shows that the neighbor must be cleared, in this case with a soft reset of the clear ip bgp
192.168.1.2 soft command because the route map logic takes effect.
Examining the results of this change, note that E1 now thinks the better route is through
I3-1 (192.168.1.2). The output lists the new weight of 50, with the route through I1-1
(1.1.1.1) using the default weight of 0. With weight, bigger is better.
Finally, the last two commands in the example show the pre-route-map received update
(with the received-routes option) and the post-route-map results of the received update
(with the routes option). The received Update does not include Weight because it is
Cisco-proprietary, so E1 initially assigned the Weight to its default value (0). After applying
the route map, E1 now lists a Weight of 50.
Setting Weight Using the neighbor weight Command
Alternatively, the weight can be set for all routes learned from a neighbor using the
neighbor weight command. Example 15-4 shows this configuration added to E1, setting
the Weight for all routes learned from I1-1 (1.1.1.1) to 60. As a result, E1’s route for
181.0.0.0/8 switches back to using the route through 1.1.1.1 (I1-1).
Example 15-4 Setting the Weight to 60 for All Routes Learned from I1-1
E1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
E1(config)# router bgp 11
E1(config-router)# neighbor 1.1.1.1 weight 60
E1(config-router)#^Z
E1# clear ip bgp 1.1.1.1 soft
www.CareerCert.info
Chapter 15: BGP Path Control 507
E1# show ip bgp 176.0.0.0/4 longer-prefixes
BGP table version is 54, local router ID is 128.107.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 181.0.0.0/8 1.1.1.1 0 60 1 1811 i
* 192.168.1.2 0 50 3 2 50 51 52 1811 i
*> 182.0.0.0/8 1.1.1.1 0 60 1 2 1822 i
* 192.168.1.2 0 0 3 2 50 51 1822 i
*> 183.0.0.0/8 1.1.1.1 0 60 1 2 50 1833 i
* 192.168.1.2 0 0 3 2 50 1833 i
*> 184.0.0.0/8 1.1.1.1 0 60 1 2 50 51 1844 i
* 192.168.1.2 0 0 3 2 1844 i
*> 185.0.0.0/8 1.1.1.1 0 60 1 2 50 51 52 1855 i
* 192.168.1.2 0 0 3 1855 i
The neighbor weight command does not use an in or out direction because Weight can
only be set on input. The configuration results in all routes learned from 1.1.1.1 (I1-1) having
a Weight of 60, as noted in the Weight column of the show ip bgp output.
Setting the Local Preference
The BGP Local Preference (Local_Pref) PA gives the routers inside a single AS a value that
they can set per-route, advertise to all iBGP routers inside the AS, so that all routers in the
AS agree about which router is the best exit point for packets destined for that prefix. By
design, the Local_Pref can be set by routers as they receive eBGP routes by using an inbound
route map. The routers then advertise the Local_Pref in iBGP updates. As a result,
all the routers in the same AS can then make the same choice of which route is best, agreeing
as to which router to use to exit the AS for each prefix.
As with the discussion of Weight, this section begins with a description of a sample scenario.
Following that, a sample Local_Pref configuration is shown, using a route-map to
set Local_Pref for routes advertised into an Enterprise. Table 15-5 summarizes some of
the key features of Local_Pref as demonstrated in the upcoming pages.
Table 15-5 Key Features of Local_Pref
Feature Description
PA? Yes
Purpose Identifies the best exit point from the AS to reach a given prefix
Scope Throughout the AS in which it was set; not advertised to eBGP peers
Range 0 through 4,294,967,295 (232 – 1)
Which is best? Higher values are better
Key
Topic
www.CareerCert.info
508 CCNP ROUTE 642-902 Official Certification Guide
Note: For those of you memorizing using the N WLLA OMNI mnemonic, Local_Pref is
the first L in WLLA.
Sample Internetwork Used in the Local_Pref and AS_Path Length Examples
Figure 15-5 shows a sample Internetwork used to demonstrate setting both Local_Pref,
and later, AS_Path Length. The figure shows a single Enterprise with two Internet-connected
routers. A full iBGP mesh exists with these two routers plus two routers internal to
the Enterprise. Two eBGP neighborships exist, one with ISP1, and one with ISP3. (Note in
particular that unlike Figure 15-3, E1 does not have a neighborship with router I3-1 in this
case.) The following design requirements have already been met by the initial configuration
in all routers shown in the figure:
■ E1 and I1-1 uses loopback IP addresses (11.11.11.11 and 1.1.1.1) for their neighborship.
■ E2 and I3-1 use interface IP addresses for their neighborship.
■ None of the routers have attempted to change any settings that can impact the choice
of best path, and Weight settings in the previous examples have been removed.
iBGP
Mesh
ASN 3 ISP3
ASN 1 ISP1
I3-1
E1 I1-1
E2
eBGP
192.168.1.5
Core1
Core2
10.100.1.3
10.100.1.4 10.100.1.2
10.100.1.1
192.168.1.6
11.11.11.11 1.1.1.1
eBGP
Figure 15-5 Sample Internetwork for BGP Local_Pref and AS_Path Length Examples
Default 100
Changing the
default
Using the bgp default local-preference <0-4294967295> BGP subcommand
Configuration Via neighbor route-map command; in option is required for updates
from an eBGP peer
www.CareerCert.info
Chapter 15: BGP Path Control 509
As with the Weight example, both ISPs advertise the same five prefixes, with different
AS_Paths so that the routers have some prefixes to manipulate. Figure 15-6 shows five
such prefixes that both ISPs advertise to E1 and E2. Note that this example network uses
the same five prefixes, prefix lengths, and As_Path values as the previous Weight examples
in this chapter.
Before showing the example of how to set the Local_Pref and how it impacts the routes, it
is helpful to look at the best BGP routes on the Enterprise routers before any PAs have
been changed. Example 15-6 shows the relevant BGP table entries on E1, E2, and Core1
with no attempt to influence E1’s choice of best path. The best path for four of the five
prefixes will be obvious, but the output listed in the commands requires some review. Prefixes
181.0.0.0/8 and 182.0.0.0/8 have a shorter AS_Path through ISP1, so E1 and E2 will
agree that E1’s path, through ISP1, is best. Similarly, 184.0.0.0/8 and 185.0.0.08 have a
shorter AS_Path through ISP3, so both E1 and E2 agree that E2’s path is best for these
prefixes. Again, 183.0.0.0/8 ties on AS_Path length.
Example 15-5 BGP Tables on E1, E2, and Core1, with No Changes to Settings That Affect
Best Path
! First, on router E1
E1# show ip bgp 176.0.0.0/4 longer-prefixes
BGP table version is 15, local router ID is 128.107.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
Best BGP
Routes:
181,182 : I1-1
183 : I1-1
184,185 : E2
Best BGP
Routes:
181,182 : E1
183 : I3-1
184,185 : I3-1
I1-1
510 CCNP ROUTE 642-902 Official Certification Guide
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 181.0.0.0/8 1.1.1.1 0 0 1 1811 i
*> 182.0.0.0/8 1.1.1.1 0 0 1 2 1822 i
* i183.0.0.0/8 10.100.1.2 0 100 0 3 2 50 1833 i
*> 1.1.1.1 0 0 1 2 50 1833 i
*>i184.0.0.0/8 10.100.1.2 0 100 0 3 2 1844 i
* 1.1.1.1 0 0 1 2 50 51 1844 i
*>i185.0.0.0/8 10.100.1.2 0 100 0 3 1855 i
* 1.1.1.1 0 0 1 2 50 51 52 1855 i
! Next, on router E2
E2# show ip bgp 176.0.0.0/4 longer-prefixes
! legend omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*>i181.0.0.0/8 10.100.1.1 0 100 0 1 1811 i
* 192.168.1.6 0 0 3 2 50 51 52 1811 i
*>i182.0.0.0/8 10.100.1.1 0 100 0 1 2 1822 i
* 192.168.1.6 0 0 3 2 50 51 1822 i
* i183.0.0.0/8 10.100.1.1 0 100 0 1 2 50 1833 i
*> 192.168.1.6 0 0 3 2 50 1833 i
*> 184.0.0.0/8 192.168.1.6 0 0 3 2 1844 i
*> 185.0.0.0/8 192.168.1.6 0 0 3 1855 i
! Next, on router Core1
Core1# show ip bgp 176.0.0.0/4 longer-prefixes
! legend omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*>i181.0.0.0/8 10.100.1.1 0 100 0 1 1811 i
*>i182.0.0.0/8 10.100.1.1 0 100 0 1 2 1822 i
*>i183.0.0.0/8 10.100.1.1 0 100 0 1 2 50 1833 i
* i 10.100.1.2 0 100 0 3 2 50 1833 i
*>i184.0.0.0/8 10.100.1.2 0 100 0 3 2 1844 i
*>i185.0.0.0/8 10.100.1.2 0 100 0 3 1855 i
First, pay close attention to the LocPrf column of output in the example. This column lists
the Local_Pref settings of each route. Some list a (default) value of 100, and some list
nothing. As it turns out, because Updates received from eBGP peers do not include the
Local_Pref PA, IOS lists a null value for Local_Pref for eBGP-learned routes by default.
However, Updates from iBGP peers do include the Local_Pref. Because this network does
not have any configuration that attempts to set Local_Pref yet, the routers advertise their
default Local_Pref value of 100 over the iBGP connections.
www.CareerCert.info
Chapter 15: BGP Path Control 511
Also note that when comparing the output on both E1 and E2, the output lists a single
eBGP route, but not the alternative iBGP route through the other Internet-connected
router in the Enterprise. For example, E2 lists a single route for 184.0.0.0/8 and 185.0.0.0/8,
through I3-1 (192.168.1.6). The reason that E2 does not list an alternative route through E1
is that E1’s best route for these prefixes, as seen near the top of the example, is E1’s iBGPlearned
route through E2 (10.100.1.2). BGP does not allow a router to advertise iBGPlearned
routes to iBGP peers, so E1 will not advertise routes for 184.0.0.0/8 or 185.0.0.0/8
to router E2.
Finally, For prefix 183.0.0.0/8, both E1 and E2 tie on the As_Path length. In this case, all
best path choices tie until Step 7, which prefers eBGP routes over iBGP routes. E1 prefers
its eBGP route for 183.0.0.0/8 through ISP1’s Router I1-1, and E2 prefers its eBGP route
through ISP3’s Router I3-1.
Setting the BGP Local_Pref Using a Route Map
To set the Local_Pref, a router can use the neighbor neighbor-ip route-map in BGP subcommand.
Typically, a router uses this command with the inbound direction for routes received
from eBGP peers. Then, with no additional configuration required, the router then
advertises the Local_Pref to any iBGP peers.
To show the Local_Pref configuration and results, start with the sample network shown in
the previous section. The configuration will now be changed to set the Local_Pref for two
different prefixes for Updates received on E1 from I1-1, as shown in Figure 15-7. Note that
the figure reinforces the idea that BGP does not include the Local_Pref PA in eBGP Updates
but will in iBGP Updates.
The figure shows a series of steps, as follows:
Step 1. I1-1 and I3-1 advertise the prefixes into the Enterprise but with no Local_Pref
set because the connections are eBGP peers.
Key
Topic
Set 184.0.0.0/8 Local_Pref = 50
Set 185.0.0.0/8 Local_Pref = 150
E1 I1-1
E2 I3-1
iBGP Updates with
Local_Pref Set
184/8, 185/8
No Local_Pref
184/8, 185/8
No Local_Pref
1
2
3
4
1
184.0.0.0/8: My Local_Pref = 100 is Better
185.0.0.0/8: E1’s Local_Pref = 150 is Better
Figure 15-7 Example Local_Pref Settings for the Upcoming Example
www.CareerCert.info
512 CCNP ROUTE 642-902 Official Certification Guide
Step 2. E1 sets the Local_Pref for routes learned from I1-1: 184.0.0.0/8 (50) and
185.0.0.0/8 (150).
Step 3. E1 includes the Local_Pref settings in its iBGP Updates to Core1, Core2, and E2.
Step 4. E2 realizes that E1’s route for 185.0.0.0/8, Local_Pref 150, is better than E2’s
eBGP route for this prefix, which E2 assigned default Local_Pref 100. Conversely,
E1’s advertised route for 184.0.0.0/8, Local_Pref 50, is worse than E2’s
eBGP route for that same prefix, with assigned default Local_Pref 100.
Example 15-6 shows the configuration on router E1 to assign the Local_Pref values shown
in Figure 15-7. The example also shows the results on E1 and E2. Note that the configuration
differs only slightly as compared with the configuration for administrative Weight as
shown in Example 15-3, the only substantive difference being the set local-preference
route map command rather than the set weight command.
Example 15-6 Configuring Local_Pref on Router E1 (Step 2 per Figure 15-7)
E1# show running-config
! only pertinent portions shown
ip prefix-list match-184 seq 5 permit 184.0.0.0/8
!
ip prefix-list match-185 seq 5 permit 185.0.0.0/8
!
route-map set-LP-150 permit 10
match ip address prefix-list match-185
set local-preference 150
!
route-map set-LP-150 permit 15
match ip address prefix-list match-184
set local-preference 50
!
route-map set-LP-150 permit 20
!
router bgp 11
neighbor 1.1.1.1 route-map set-LP-150 in
! The clearing of BGP neighbor I1-1 is done next, but not shown.
! Next, E1’s Updated BGP Table
E1# show ip bgp 176.0.0.0/4 longer-prefixes
BGP table version is 29, local router ID is 128.107.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 181.0.0.0/8 1.1.1.1 0 0 1 1811 i
*> 182.0.0.0/8 1.1.1.1 0 0 1 2 1822 i
www.CareerCert.info
Chapter 15: BGP Path Control 513
* i183.0.0.0/8 10.100.1.2 0 100 0 3 2 50 1833 i
*> 1.1.1.1 0 0 1 2 50 1833 i
*>i184.0.0.0/8 10.100.1.2 0 100 0 3 2 1844 i
* 1.1.1.1 0 50 0 1 2 50 51 1844 i
*> 185.0.0.0/8 1.1.1.1 0 150 0 1 2 50 51 52 1855 i
E1# show ip bgp 185.0.0.0/8
BGP routing table entry for 185.0.0.0/8, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
1 2 50 51 52 1855, (received & used)
1.1.1.1 from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 150, valid, external, best
! The next output occurs on router E2
E2# show ip bgp 185.0.0.0/8 longer-prefixes
! heading lines omitted
Network Next Hop Metric LocPrf Weight Path
*>i185.0.0.0/8 10.100.1.1 0 150 0 1 2 50 51 52 1855 i
* 192.168.1.6 0 0 3 1855 i
Example 15-6’s output shows E1’s BGP table entries, now with updated Local_Pref values
as compared with Example 15-5. E1 now uses its eBGP route, Next_Hop 1.1.1.1, for prefix
185.0.0.0/8 because of the higher Local_Pref.
The end of the example shows E2 with two possible routes for 185.0.0.0/8. The following
list outlines E2’s BGP best path logic in this case:
Step 0. The two routes both have reachable Next_Hop IP addresses.
Step 1. Both have Weight 0 (tie).
Step 2. The iBGP route through 10.100.1.1 (E1) has a bigger (better) Local_Pref (150
versus 100) that the route through 192.168.1.6 (I3-1), so it is the better route.
Also, note that both the show ip bgp longer-prefixes command’s briefer output, and the
show ip bgp 185.0.0.0/8 commands more verbose output, both identify the Local_Pref
value. However, the longer command output does not list the Weight value.
IP Routes Based on BGP Best Paths
Some of the complexity related to BGP occurs around the BGP functions created by BGP
PAs, including their use by the best path algorithm. When the BGP best path algorithm
has gotten through this complexity and chosen a best route for a prefix, the router then
tries to add that route to the IP routing table. However, rather than add the BGP route to
www.CareerCert.info
514 CCNP ROUTE 642-902 Official Certification Guide
the IP routing table directly, BGP actually gives that best BGP route to another process for
consideration: The IOS Routing Table Manager (RTM).
The IOS RTM chooses the best route among many competing sources. For example,
routes may be learned by an IGP, BGP, or even as connected or static routes. IOS collects
the best such route for each prefix and feeds those into the RTM function. The RTM then
chooses the best route. Figure 15-8 shows the general idea:
Among its tasks, RTM uses the concept of Administrative Distance (AD) to choose the
best route among these different sources. Table 15-6 repeats the list of default AD values
as shown earlier in Table 10-6 from Chapter 10, “Advanced IGP Redistribution,” but with
highlights for the two BGP-related default values:
For the most part, an Enterprise router should not see cases in which a prefix learned with
BGP has also been learned as a connected or IGP-learned route. (Conversely, these issues
Connected
Routes
Routing
Table
Manager
(RTM)
BGP
Routes
IGP
Routes
IP
Routing
Table
Routing
Information
Base
(RIB)
Best
Only
Best
Only
Figure 15-8 Routing Table Manager Concept
Table 15-6 Default Administrative Distances
Route Type Administrative Distance
Connected 0
Static 1
EIGRP summary route 5
eBGP 20
EIGRP (internal) 90
www.CareerCert.info
Chapter 15: BGP Path Control 515
occur more often when implementing MPLS VPNs with BGP/IGP redistribution.) However,
it can happen, and when it does, the show ip bgp rib-failures command can be helpful.
This command lists routes for which BGP has chosen the route as best, but the RTM
function has not placed the route into the Routing Information Base (RIB), which is simply
another name for the IP routing table.
Example of a BGP RIB Failure
To show an example of a RIB failure, imagine that an Enterprise engineer needed to do
some testing, so the engineer just picked an IP address range to use. The engineer tries to
avoid problems by not using network 10.0.0.0, which is used throughout the Enterprise. So
rather than choosing another private network, the engineer then chooses public range
185.0.0.0/8. After changing the lab configuration a few hundred times, a route for
185.0.0.0/8 leaks into the OSPF topology database.
Keep in mind that at the end of the previous example, E1 had chosen its eBGP route for
185.0.0.0/8 as its best route, and E2 had chosen its iBGP route as its best route for
185.0.0.0/8. Example 15-7 shows the results, based on RTM’s comparisons of the AD values.
Example 15-7 Example with the RTM and RIB Failures
! First, E1’s IP Routing table for 185.0.0.0/8
E1# show ip route 185.0.0.0 255.0.0.0 longer-prefixes
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Table 15-6 Default Administrative Distances
Route Type Administrative Distance
IGRP 100
OSPF 110
IS-IS 115
RIP 120
On-Demand Routing (ODR) 160
EIGRP (external) 170
iBGP 200
Unreachable 255
www.CareerCert.info
516 CCNP ROUTE 642-902 Official Certification Guide
Gateway of last resort is 1.1.1.1 to network 0.0.0.0
B 185.0.0.0/8 [20/0] via 1.1.1.1, 00:25:11
! Next, E2’s IP Routing table
E2# show ip route 185.0.0.0 255.0.0.0 longer-prefixes
! Legend omitted for brevity
Gateway of last resort is 192.168.1.6 to network 0.0.0.0
O 185.0.0.0/8 [110/2] via 10.1.1.77, 00:15:44, FastEthernet0/0
E2# show ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
185.0.0.0/8 10.100.1.1 Higher admin distance n/a
The first command shows that E1, with an eBGP route, actually adds its route to the IP
routing table. The route lists a code of B, meaning BGP. The output lists the eBGP default
AD of 20, which is a better default AD than OSPF’s 110. RTM added this BGP route to the
IP routing table on E1 because of eBGP’s better AD.
E2 currently lists its iBGP route through E1 as its current best BGP route for 185.0.0.0/8
because of the higher Local_Pref configured in Example 15-6. However, after giving this
route to the RTM, RTM instead choose the lower-AD OSPF route (AD 110) rather than
the higher-AD iBGP route (AD 200).
Finally, the show ip bgp rib-failure command lists one line for each best BGP route that
the RTM does not place into the IP routing table. In this case, this command on Router E2
lists the route for 185.0.0.0/8, with the reason listed.
BGP and the maximum-paths Command
Like the IGP protocols, BGP supports the maximum-paths number-of-paths subcommand,
but BGP uses significantly different logic than the IGPs. Unlike the IGP routing
protocols, BGP truly needs to pick one route, and only one route, as the best path for a
given prefix/length. In effect, the BGP best path algorithm already breaks the ties for
“best” route for each prefix, so from BGP’s perspective, one route for each prefix is always
best.
BGP does allow multiple BGP routes for a prefix to be considered to tie, at least for the
purpose of adding multiple routes to the IP routing table. The conditions are as follows:
If the BGP best path algorithm does not choose a best path by Step 8 (per the numbering
in this book), the routes which still tie for being best path through Step 8 will
be allowed into the IP routing table, up to the number defined by the BGP
maximum-paths number-of-paths router subcommand.
The section “Overview of the BGP Best Path Algorithm” earlier in this chapter lists the
best path steps, including the tiebreaker steps that allow routes to be considered by the
maximum-paths command.
www.CareerCert.info
Chapter 15: BGP Path Control 517
Increasing the Length of the AS_Path Using AS_Path Prepend
Step 4 of the BGP best path algorithm examines the length of the AS_Path PA. The length
of the AS_Path may appear to be obvious: Just add the number of ASNs listed in the
AS_Path. However, some BGP features outside the scope of this book actually impact the
AS_Path length calculation as well. However, for the purposes of this book, AS_Path
length is simply the number of ASNs listed in the AS_Path.
The AS_Path prepend tool gives engineers a means to increase the length of an AS_Path by
adding ASNs to the AS_Path, while not impacting the loop prevention role of the AS_Path
PA. By increasing the length of an AS_Path, a route is less likely to become the best route.
By adding ASNs that already exist inside a particular route’s AS_Path, the feature does not
inadvertently prevent a route from being ignored due to AS_Path loop prevention.
For example, using the design shown most recently in Figures 15-5, 15-6, and 15-7, imagine
that the Enterprise considers ISP1 to be the better ISP, but they do not want to send all
traffic through ISP1. So, the Enterprise network engineers could make the following type
of implementation choice:
Make the AS_Paths received from ISP3 be 2 ASNs longer.
By making such a choice, when an AS_Path through ISP1 is better, or when it’s a tie on
AS_Path between ISP1 and ISP3, or when the AS_Path through ISP1 is even slightly
longer than through ISP3, the routers can still choose their routes through ISP1. Only
when the AS_Path (before prepending) is at least 2 ASNs shorter through ISP3 can the
ISP3 path be chosen.
Note: For those of you memorizing using the N WLLA OMNI mnemonic, AS_Path
Length is the A in WLLA.
Figure 15-9 shows the mechanics of how an Enterprise route would prepend the AS_Path
for routes received by Router E2 from ISP3, namely Router I3-1. Looking specifically at
the route for 185.0.0.0/8, in this case, I3-1 has not changed the AS_Path and advertised the
route with AS_Path (3, 1855). At Step 2, Router E2 prepends ASN 3–twice–making the
AS_Path length 4. At Step 3, E2 advertises the route to its iBGP peers–peers that may now
prefer to the other route for this prefix through Router E1.
The configuration itself requires only a little additional work compared to the other examples.
As shown in Figure 15-9, Router E1 could use an inbound route map, using the set
as-path prepend 3 3 command to add the two ASNs. (The router sending the Update,
ISP3’s Router I3-1 in this case, could instead use an outbound route map.) Example 15-8
shows the configuration on E2 to add the ASNs at ingress into E2. (Note that all configuration
for changing the Weight and Local_Pref, and the extra OSPF route for 185.0.0.0/8
shown in Example 15-6, have been removed before gathering the output in this example.)

BGP Path Attributes and Best Path Algorithm best cisco ccnp training center in new delhi

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

BGP supports a wide variety of Path Attributes. Some of the PAs exist solely to be used as
part of the litany of options in the BGP best path algorithm, some have nothing to do
with the BGP best path algorithm, and some impact the best path algorithm as well as being
used for other purposes. For example, the Local Preference PA exists to give control to
a single AS regarding their outbound routes from an AS-wide perspective. Conversely, the
BGP Next_Hop PA provides BGP a place to list the next-hop IP address for a path, but it
does not provide a useful means for engineers to set different values for the purpose of influencing
the best path choice.
The term BGP best path algorithm refers to the process by which BGP on a single router
examines the competing BGP paths (routes) in its BGP table, for a single prefix, choosing
one route as the best route. The best path algorithm has many steps, but it eventually results
in the choice of a single route for each prefix as that router’s best BGP path.
The initial major section of this chapter examines the BGP PAs used by the BGP best path
algorithm, the BGP best path algorithm itself, and some related topics.
BGP Path Attributes
BGP Path Attributes define facts about a particular route or path through a network. Each
PA defines something different about the path, so to truly understand BGP PAs, you need
to examine each PA. This section begins by reviewing a few PAs that should now be familiar
to you if you have read the preceding BGP chapters, and then this section introduces a
few new PAs.
BGP uses the Autonomous System Path (AS_Path) PA for several purposes, as already
seen in Chapters 12, 13, and 14. This particular PA lists the ASNs in the end-to-end path.
BGP uses the AS_Path PA as its primary loop-prevention tool: When an eBGP peer receives
an Update, if its own ASN is already in the received AS_Path, then that route has already
been advertised into the local ASN and should be ignored. In addition to loop
prevention, the BGP best path algorithm uses the AS_Path PA to calculate the AS_Path
length, which the algorithm considers as one of its many steps.
BGP also defines the next-hop IP address (Next_Hop) of a route as a PA. BGP may advertise
one of several different IP addresses as a route’s Next_Hop, depending on several factors.
To support such features, BGP needs to list the Next_Hop IP address for each path
(route), and BGP defines this concept in the Next_Hop PA. The best path algorithm includes
a check related to the Next_Hop IP address of the route.
Table 15-2 lists these two PAs, plus a few more PAs, and a related BGP feature (Weight) that
is not a PA but is used by Cisco BGP best path implementation. The table lists the PAs in
the same order that they will be considered by the BGP best path algorithm. The table also
describes each feature listed in the table, relative to whether it is most useful to influence
outbound routes (away from the Enterprise) and inbound routes (toward the Enterprise).
www.CareerCert.info
Chapter 15: BGP Path Control 495
Key
Topic
Table 15-2 BGP Path Attributes That Affect the BGP Best Path Algorithm
PA Description Enterprise Route
Direction (Typical)
NEXT_HOP Lists the next-hop IP address used to reach a
prefix.
N/A
Weight1 A numeric value, range 0 through 216 – 1, set
by a router when receiving Updates, influencing
that one router’s route for a prefix. Not
advertised to any BGP peers.
Outbound
Local Preference (LOCAL_
PREF)
A numeric value, range 0 through 232 – 1, set
and communicated throughout a single AS
for the purpose of influencing the choice of
best route for all routers in that AS.
Outbound
AS_PATH (length) The number of ASNs in the AS_Path PA. Outbound, Inbound
ORIGIN Value implying the route was injected into
BGP; I (IGP), E (EGP), or ? (incomplete information).
Outbound
Multi Exit Discriminator
(MED)
Set and advertised by routers in one AS, impacting
the BGP decision of routers in the
other AS. Smaller is better.
Inbound
1Weight is not a BGP PA; it is a Cisco-proprietary feature that acts somewhat like a PA.
The short descriptions in the table can be helpful for review when doing your final preparation
study, but the table does not hold enough information to truly appreciate how an
engineer might use these PAs effectively. The second and third major sections of this
chapter examine most of these PAs and how to influence the best path choice with each.
To find the current settings of the features in Table 15-2, you can use commands like
show ip bgp and show ip bgp prefix/length. However, picking the values out of the
clutter in the output of the show ip bgp command can be a challenge. Figure 15-1 shows
a sample of this command’s output and some notations on where to find the various PA
settings.
The examples throughout this chapter include examples of these commands, along with
the PA settings as changed by various route maps.
Overview of the BGP Best Path Algorithm
The BGP best path algorithm follows the steps shown in shorthand form in Table 15-3.
The table lists steps 0 through 8, a short descriptive phrase, and a notation about the
criteria for one value to be better than another.
www.CareerCert.info
496 CCNP ROUTE 642-902 Official Certification Guide
Table 15-3 BGP Decision Process Plus Mnemonic: N WLLA OMNI
Step Mnemonic
Letter
Short Phrase Which Is Better?
0 N Next hop: reachable?
If no route to reach Next_Hop, router cannot
use this route.
1 W Weight Bigger.
2 L LOCAL_PREF Bigger.
3 L Locally injected
routes
Locally injected is better than iBGP/eBGP
learned.
4 A AS_PATH length Smaller.
5 O ORIGIN Prefer I over E.
Prefer E over ?
6 M MED Smaller.
7 N Neighbor Type Prefer eBGP over iBGP.
8 I IGP metric to
Next_Hop
Smaller.
R3 #show ip bgp
BGP table version is 12, local router ID is 3.3.3.3
r RIB-failure, S stale
Network Next Hop Metric
0
000000000
65000 1 33333 10 200 44 i
5 1 33333 10 200 44 i
(111)4 1 33333 10 200 44 i
4 1 33333 10 200 44 i
65000 1 33333 10 200 44 i
5 1 33333 10 200 44 i
(111) 4 1 33333 10 200 44 i
4 1 33333 10 200 44 i
(111) 4 {1, 404, 303, 202} i
0
0
100
100
100
LocPrf Weight Path
NEXT_HOP
MED Weight
LOCAL_PREF
AS_Path Origin
10.1.36.6
10.1.35.5
10.1.14.4
10.1.34.4
10.1.36.6
10.1.35.5
10.1.14.4
10.1.34.4
10.1.14.4
Neighbor
Type
11.0.0.0
12.0.0.0
>
>
i
i
i
*********
16.0.0.0/4
Comments: To Discover Other Details…
Neighbor Type: No Letter Means “EBGP”
IGP Metric: show ip route next-hop-address
RID: show ip bgp n/ri
Origin codes: i - IGP, e - EGP, ? - incomplete
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
Figure 15-1 Finding PA Settings in the Output of the show ip bgp Command
Note: The step numbering of the BGP best path steps does not exist in the BGP RFCs.
The steps are numbered in this book for easier reference. Because the RFCs do not dictate
Key
Topic
Key
Topic
www.CareerCert.info
Chapter 15: BGP Path Control 497
a particular step numbering, other references likely use different step numbers; do not be
concerned about memorizing the step numbers.
Starting with a Step 0 may seem odd, but it helps make an important point about the logic
listed at this step. Some BGP best path references include the logic in this step as a best
path step, and some just list this same information as a side note. Regardless, the step 0
concept is important. For step 0, a router looks at the BGP route and compares the
Next_Hop IP address to the IP routing table.
If that router does not have a matching IP route for the BGP route’s Next_Hop IP address,
then that router will not know how to forward packets for that particular prefix, using that
particular route. To avoid using such a route, at Step 0, the BGP best path algorithm removes
such routes from consideration.BGP then uses the following eight steps, in order,
until one best route is chosen for a given prefix.
If a router still did not determine a best route when finishing Step 8, the router takes several
other small steps to break the tie. At this point, the competing routes are considered
to be just as good as each other. However, unlike IGPs, BGP needs to choose one and only
one route as best, in part because BGP advertises only the best routes to its neighbors. In
such cases, BGP breaks the tie with these additional steps, which would be considered
Steps 9-11:
Step 9. Oldest (longest-known) eBGP route
Step 10. Lowest neighbor BGP RID
Step 11. Lowest neighbor IP address
Taking a more detailed view of the entire best path algorithm, BGP begins by choosing
the oldest known route for a given prefix as the best route. It then takes the next longestknown
route for that same prefix and compares the two routes using the best path algorithm.
The router eventually chooses one of the two BGP routes as the best path (route). If
another route exists for the same prefix, the router repeats the process, using the winner
of the previous comparisons and the new route, choosing one of those as the better route.
The process continues until all routes have been considered, with one route being listed as
best in the BGP table.
For example, if Router R1 were considering two routes for prefix 181.0.0.0/8, it would first
make sure that both routes had reachable Next_Hop IP addresses. The router would then
compare the weight settings, choosing the route with the bigger weight. If they tied on
weight, the router would prefer the route with a bigger Local_Pref. If again a tie, the router
would prefer the one route that was injected into BGP locally (using the network command
or using route redistribution). If neither or both routes were locally injected, the
router moves on to AS_Path length, and so on, until the router chooses one of the two as
the better route.
As soon as one of the steps determines a best route, the comparison of those two
routes stops.
www.CareerCert.info
498 CCNP ROUTE 642-902 Official Certification Guide
Key
Topic
Perspectives on the Core 8 Best Path Steps
Some of the BGP best path steps purposefully give the engineer a tool for influencing the
choice of best path, whereas other steps have a different purpose, often simply being a
side effect of some BGP feature. So, when an engineer starts building a BGP implementation
plan, only a subset of the core 8 BGP best path steps need be considered, as follows:
■ Weight (Step 1)
■ Local_Pref (Step 2)
■ AS_Path Length (Step 4)
■ MED (often called metric) (Step 6)
Because the ROUTE exam focuses on the more practical aspects of BGP for Enterprises,
it gives much more attention to these four features and less attention to the other BGP
best path steps. This chapter describes each of these four features to some depth in the
context of best path selection. However, before focusing on these four items, it can be
helpful to see a small glimpse into the meaning of the other steps, which can be helpful as
you work to memorize the steps in the BGP best path algorithm.
Step 3 compares the source from which the routes were added to the BGP table. When the
BGP best path algorithm compares two routes at this step, if one were injected into BGP
locally, and the other were not (it was learned from a BGP peer), the router chooses the
route that was injected locally. Chapter 13, “External BGP,” section “Injecting Routes into
BGP for Advertisement to the ISPs,” describes the two ways to locally inject these routes,
the network command and redistribution from an IGP.
Step 5 refers to the BGP Origin PA. The Origin PA attempts to identify the source from
outside BGP from which the route was injected into BGP. The three Origin code values
are
■ I: Injected from an IGP (for example, redistribution from EIGRP)
■ E: Injected from Exterior Gateway Protocol (EGP)
■ ?: Undetermined
Although the original intent of the Origin PA is to identify the source from which BGP
learned the route, routers can also set the Origin PA as part of a strategy to influence the
BGP best path.
Step 7 refers to the Neighbor type: iBGP or eBGP. Remembering that BGP compares two
routes at a time, if one is learned with eBGP, and the other with iBGP, the router chooses
the eBGP route as best. Using this feature to influence the best path choice would be difficult,
because the ASN in which a router resides is fixed by the BGP design.
Finally, Step 8 refers to the IGP metric to the Next_Hop address. At this step, the router
compares the metrics of the IP routes for each Next_Hop IP address and chooses the BGP
route with the lower IGP metric to its Next_Hop. (If an IGP-learned route is not used, for
example, if both use connected routes, BGP considers the metrics to tie.) It is conceivable
that an engineer might tune the IGP to manipulate BGP’s best path choice, but this step is
so far into the algorithm that the earlier and more flexible settings would be much better
options.
www.CareerCert.info
Chapter 15: BGP Path Control 499
Memorization Tips for BGP Best Path
This short section suggests a mnemonic tool to help you memorize Steps 0 through 8 of
the BGP best path algorithm. Feel free to skim this section for now, or ignore it
entirely–there is no requirement that you memorize the best path algorithm using the
mnemonics in this section. (However, you may want to at least review upcoming Figure
15-2, which gives a good visual reference for some of the information summarized in Table
15-3.) But you should plan on memorizing the list at some point before the exam, even if
you ignore the mnemonic device.
First, if you refer back to the BGP best path algorithm as listed in table 15-3, you see that
the second column lists a single-letter mnemonic letter. These letters match the first letter
of the description in the third column of that table. Then, take these initial letters and
group them as follows:
■ N
■ WLLA
■ OMNI
The N is listed separately because it represents the “is the next-hop reachable” logic of
Step 0 and is somewhat separate from the other steps.
The mnemonic groups the eight main steps as two sets of four letters for a couple of reasons.
Both sets can be pronounced, even if they don’t spell words. It should be easier to
memorize as two sets of four. And maybe most important, the first set of four letters, representing
Steps 1 through 4, include all the features that engineers typically use to influence
outbound routes from the Enterprise:
■ WLLA: Refers to the three steps that an engineer might use to influence outbound
routes: Weight, Local_Pref, and AS_Path length. (Additionally, the second L, in
WLLA for Step 3, represents the “Locally injected routes” choice.)
W L L A O M N I
Popular to
Influence
Outbound
Routes
Popular to
Influence
Inbound
Routes
N
Figure 15-2 BGP Best Path Mnemonics
www.CareerCert.info
500 CCNP ROUTE 642-902 Official Certification Guide
■ OMNI: As listed in Table 15-3, the letters represent Origin (I or ?), MED, neighbor
type (eBGP over iBGP), and IGP metric to Next-hop.
So, if you can memorize N WLLA OMNI, by the time you’ve read this chapter you can
probably pick out which of those correlate to the four bigger topics later in this chapter:
Weight, Local_Pref, AS_Path length, and MED. Hopefully with a little more study, you
can memorize the rest of the list.
Figure 15-2 shows the mnemonic letters in graphical form just as another aid in memorizing
the steps. It also shows a reminder of which features are most likely to be used to influence
outbound routes from the Enterprise, and the one setting (MED) most likely to be
used to influence inbound routes into the Enterprise.
The rest of this chapter focuses on a deeper explanation of the four best path steps that
engineers typically use to influence the choice of best path.

Route Filtering and Clearing BGP Peers best cisco ccna training center in new delhi

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

BGP allows the filtering of BGP Update messages on any BGP router. The router can filter
updates per neighbor for both inbound and outbound Updates on any BGP router.
After adding a new BGP filter to a router’s configuration, the BGP neighbor relationships
must be reset or cleared to cause the filter to take effect. The IOS BGP clear command
tells the router specifically how to reset the neighborship. This section also examines the
variations on the BGP clear command, including the more disruptive hard reset options
and the less disruptive soft reset options.
BGP Filtering Overview
BGP filtering works generally like IGP filtering, particularly like EIGRP. Similar to EIGRP,
BGP Updates can be filtered on any router, without the restrictions that exist for OSPF
with various area design issues. The filtering can examine the prefix information about
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 477
each router and both the prefix and prefix length information, in either direction (in or
out), on any BGP router.
The biggest conceptual differences between BGP and IGP filtering relate to what BGP can
match about a prefix to make a choice of whether to filter the route. EIGRP focuses on
matching the prefix/length. BGP can also match the prefix/length but can also match the
large set of BGP Path Attributes (PA). For example, a filter could compare a BGP route’s
AS_Path PA and check to see if the first ASN is 4, that at least three ASNs exist, and that
the AS_Path does not end with 567. The matching of routes based on their PA settings has
no equivalent with any of the IGPs.
The biggest configuration difference between BGP and IGP filtering, beside the details of
matching BGP PAs, has to do with the fact that the filters must apply to specific neighbors
with BGP. With EIGRP, the filters can be applied to all outbound updates from
EIGRP, or all inbound updates into EIGRP, using a single EIGRP distribute-list command.
BGP configuration does not allow filtering of all inbound or outbound updates. Instead,
the BGP filtering configuration enables filters per neighbor (using a neighbor command),
referencing the type of BGP filter, the filter number or name, and the direction (in or out).
So, a router could literally use the same filter for all BGP Updates sent by a router, but the
configuration would require a neighbor command for each neighbor that enabled the
same filter.
The ROUTE course and exam focus on Enterprise routing topics, whereas BGP filtering—
especially the more detailed filtering with BGP PAs—is used most frequently by ISP network
engineers. As a result, CCNP ROUTE appears to cover BGP filtering very lightly, at
least compared to IGP filtering.
This section does briefly describe the BGP filtering commands, showing a few samples
just for perspective. Table 14-2 summarizes the BGP filtering options and commands,
along with the fields in the BGP Update message that can be matched with each type. Following
the table, the text shows an example of how an Enterprise might apply an outbound
and inbound filter based on prefix/length.
Table 14-2 BGP Filtering Tools
BGP
Subcommand
Commands
Referenced by
neighbor Command
What Can Be Matched
neighbor distribute-
list (standard
ACL)
access-list, ip access-list Prefix, with WC mask
neighbor distribute-
list (extended
ACL)
access-list, ip access-list Prefix and prefix length, with WC mask for
each
neighbor prefixlist
ip prefix-list Exact or “first N” bits of prefix, plus range
of prefix lengths
www.CareerCert.info
478 CCNP ROUTE 642-902 Official Certification Guide
neighbor filter-list ip as-path access-list AS_PATH contents; all NLRI whose
AS_PATHs are matched considered to be a
match
neighbor routemap
route-map Prefix, prefix length, AS_PATH, and/or any
other PA matchable within a BGP route map
Inbound and Outbound BGP Filtering on Prefix/Length
Enterprises that choose to use BGP benefit from both learning routes from the connected
ISPs and advertising the Enterprise’s public prefix to the same ISPs. However, when the
eBGP connections to the various ISPs come up, the Enterprise BGP routers advertise all
the best routes in each router’s BGP table over the eBGP connection. As a result, the ISPs
could learn a best route that causes one ISP to send packets to the Enterprise, with the Enterprise
then forwarding the packet out to another ISP. In such a case, the Enterprise AS
would be acting as a transit AS; in other words, an AS through which packets go through,
rather than being the destination or source of the packet.
The Enterprise engineers can, and probably should, make an effort to filter inappropriate
routes sent to the ISP over the eBGP peer connections with the goal of preventing the Enterprise
AS from becoming a transit AS. Additionally, the Enterprise can filter all private
IP address ranges, in case any such address ranges get into the Enterprise BGP router’s
BGP table.
As an example, consider Figure 14-7, with the now-familiar prefix 192.135.250.0/28. As
seen in earlier examples, both E1 and E2 learn this prefix, and both agree that the best
route from ASN 11 (the Enterprise) toward this prefix is through E2. The figure shows the
BGP routing updates as dashed lines.
E1’s best route for 192.135.250.0/28 lists E2 as the next-hop router, so without any filtering
in place, E1 then advertises prefix 192.135.250.0/28 to Router I1-1 in ISP1. I1-1 may be
configured to filter this prefix. (In the examples throughout Chapters 13 and 14, router I1-
1 was indeed configured to filter such prefixes.) However, if the Enterprise did not filter
this prefix when advertising to ISP1, and ISP1 did not filter it, then ISP1 might choose the
route through ASN 11 as its best route, making ASN 11 a transit AS for this prefix and
consuming the Enterprise’s Internet bandwidth.
Typically, an Enterprise would use outbound filtering on its eBGP neighborships, filtering
all routes except for the known public prefixes that need to be advertised into the Internet.
Example 14-10 shows just such a case, using the neighbor prefix-list command. The
example also highlights a particularly useful command, show ip bgp neighbor neighborid
advertised-routes, which shows the post-filter BGP update sent to the listed neighbor.
The example shows the BGP Update before adding the filter, after adding the filter, and
then after clearing the peer connection to router I1-1.
E1(config-router)#neighbor 1.1.1.1 prefix-list only-public out
E1(config-router)#^Z
E1#
! Next, the Update sent to I1-1 is displayed.
E1# show ip bgp neighbor 1.1.1.1 advertised-routes
BGP table version is 16, local router ID is 128.107.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 128.107.0.0/19 0.0.0.0 32768 i
*>i192.135.250.0/28 10.100.1.2 0 100 0 3 4 i
Total number of prefixes 2
! Next, the peer connection is cleared, causing the filter to take effect.
E1# clear ip bgp 1.1.1.1
E1#
*Aug 17 20:19:51.763: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down User reset
*Aug 17 20:19:52.763: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
! Finally, the Update is displayed with the filter now working.
E1# show ip bgp neighbor 1.1.1.1 advertised-routes
BGP table version is 31, local router ID is 128.107.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 128.107.0.0/19 0.0.0.0 32768 i
Total number of prefixes 1
Example 14-10 shows an interesting progression if you just read through the example start
to finish. To begin, the show ip bgp 1.1.1.1 advertised-routes command lists the routes
that E1 has advertised to neighbor 1.1.1.1 (Router I1-1) in the past. Then, the configuration
shows a prefix-list that matches only 128.107.0.0/19, with a permit action; all other prefixes
will be denied by the implied deny all at the end of each prefix list. Then, the neighbor
1.1.1.1 prefix-list only-public out BGP subcommand tells BGP to apply the prefix list to
filter outbound routes sent to I1-1.
The second part of the output shows an example of how BGP operates on a Cisco router,
particularly how BGP requires that the neighbor be cleared before the newly configured
filter takes effect. Router E1 has already advertised two prefixes to this neighbor:
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 481
128.107.0.0/19 and 192.135.250.0/28, as seen at the beginning of the example. To make the
filtering action take effect, the router must be told to clear the neighborship with router
I1-1. The clear ip bgp 1.1.1.1 command tells E1 to perform a hard reset of that neighbor
connection, which brings down the TCP connection, and removes all BGP table entries associated
with that neighbor. The neighbor (I1-1, using address 1.1.1.1) also removes its BGP
table entries associated with Router E1. After the neighborship recovers, E1 resends its
BGP Update to Router I1-1–but this time with one less prefix, as noted at the end of the
example with the output of the show ip bgp neighbor 1.1.1.1 advertised-routes command.
This same filtering action could have been performed with several other configuration options:
using the neighbor distribute-list or neighbor route-map commands. The neighbor
distribute-list command refers to an IP ACL, which tells IOS to filter routes based on
matching the prefix (standard ACL) or prefix/length (extended ACL). The neighbor routemap
command refers to a route-map that can use several matching options to filter routes,
keeping routes matched with a route-map permit clause and filtering routes matched with a
route-map deny clause. Example 14-11 shows two such options just for comparison’s sake.
Example 14-11 Alternatives to the Configuration in Example 14-10
! First option – ACL 101 as a distribute-list
access-list 101 permit ip host 128.107.0.0 host 255.255.224.0
router bgp 11
neighbor 1.1.1.1 distribute-list 101 out
! Second option: Same prefix list as Example 12-10, referenced by a route map
ip prefix-list only-public seq 5 permit 128.107.0.0/19
!
route-map only-public-rmap permit 10
match ip address prefix-list only-public
!
router bgp 11
neighbor 1.1.1.1 route-map only-public-rmap out
Clearing BGP Neighbors
As noted in Example 14-10 and the related explanations, IOS does not cause a newly configured
BGP filter to take effect until the neighbor relationship is cleared. The neighborship
can be cleared in several ways, including reloading the router and by administratively
disabling and re-enabling the BGP neighborship using the neighbor shutdown and no
neighbor shutdown configuration commands. However, IOS supports several options on
the clear ip bgp exec command for the specific purpose of resetting BGP connections.
This section examines the differences in these options.
Each variation on the clear ip bgp... command either performs a hard reset or soft reset of
one or more BGP neighborships. When a hard reset occurs, the local router brings down
the neighborship, brings down the underlying TCP connection, and removes all BGP table
entries learned from that neighbor. Both the local and neighboring router reacts just like it
www.CareerCert.info
482 CCNP ROUTE 642-902 Official Certification Guide
Table 14-3 BGP clear Command Options
Command Hard or
Soft
One or All
Neighbors
Direction (in or
out)
clear ip bgp * Hard all both
clear ip bgp neighbor-id Hard one both
clear ip bgp neighbor-id out Soft one out
clear ip bgp neighbor-id soft
out
Soft one out
clear ip bgp neighbor-id in Soft one in
clear ip bgp neighbor-id soft in Soft one in
clear ip bgp * soft Soft all both
clear ip bgp neighbor-id soft Soft one both
does for any failed BGP neighborship by removing its BGP table entries learned over that
neighborship. With a soft reset, the router does not bring down the BGP neighborship or
the underlying TCP connection. However, the local router re-sends outgoing Updates, adjusted
per the outbound filter and reprocesses incoming Updates per the inbound filter,
which adjusts the BGP tables based on the then-current configuration.
Table 14-3 lists many of the variations on the clear ip bgp command, with a reference as
to whether it uses hard or soft reset.
The commands listed in the table should be considered as pairs. In the first pair, both commands
perform a hard reset. The first command uses a * instead of the neighbor IP address,
causing a hard reset of all BGP neighbors, while the second command resets that
particular neighbor.
The second pair of commands performs soft resets for a particular neighbor but only for
outgoing updates, making these commands useful when a router changes its outbound
BGP filters. Both commands do the same function; two such commands exist in part because
of the history of the BGP implementation in the IOS. When issued, these two commands
cause the router to reevaluate its existing BGP table and create a new BGP Update
for that neighbor. The router builds that new Update based on the existing configuration,
so any new or changed outbound filters affect the contents of the Update. The router
sends the new BGP Update, and the neighboring router receives the new Update and adjusts
its BGP table as a result.
The third pair of commands performs soft resets for a particular neighbor, but only for incoming
updates, making these commands useful when a router changes its inbound BGP
filters. However, unlike the two previous commands in the table, these two commands do
have slightly different behavior and need a little more description.
Key
Topic
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 483
The clear ip bgp neighbor-id soft in command, the older command of the two, works
only if the configuration includes the neighbor neighbor-id soft-reconfiguration inbound
BGP configuration command for this same neighbor. This configuration command
causes the router to retain the received BGP Updates from that neighbor. This consumes
extra memory on the router, but it gives the router a copy of the original pre-filter Update
received from that neighbor. Using that information, the clear ip bgp neighbor-id soft in
tells IOS to reapply the inbound filter to the cached received Update, updating the local
router’s BGP table.
The newer version of the clear ip bgp command, namely the clear ip bgp neighbor-id in
command (without the soft keyword), removes the requirement for the neighbor
neighbor-id soft-reconfiguration inbound configuration command. Instead, the router
uses a newer BGP feature, the route refresh feature, which essentially allows a BGP router
to ask its neighbor to re-send its full BGP Update. The clear ip bgp neighbor-id in command
tells the local router to use route refresh feature to ask the neighbor to re-send its
BGP Update, and then the local router can apply its current inbound BGP filters, updating
its BGP table.
Example 14-12 shows a sample of how to confirm whether a router has the route refresh
capability. In this case, both the local router (E1 from Figure 14-5) and the neighbor (I1-1
from Figure 14-5) have route refresh capability. As a result, E1 can perform a soft reset inbound
without the need to consume the extra memory with the neighbor soft-reconfiguration
inbound configuration command.
Example 14-12 Alternatives to the Configuration in Example 14-10
E1# show ip bgp neighbor 1.1.1.1
BGP neighbor is 1.1.1.1, remote AS 1, external link
BGP version 4, remote router ID 1.1.1.1
BGP state = Established, up for 00:04:21
Last read 00:00:20, last write 00:00:48, hold time is 180, keepalive interval
is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
! Lines omitted for brevity
The last pair of commands in Table 14-3 do a soft reset both inbound and outbound at the
same time, either for all neighbors (the * option) or for the single neighbor listed in the
clear command.
Displaying the Results of BGP Filtering
To verify and troubleshoot filtering configurations, you need to see both the before and
after results of the filter. IOS provides several show commands that allow you to do exactly
that. For instance, Example 14-10 shows several cases of the show ip bgp neighbor
advertised-routes command that shows the post-filter BGP Updates sent by a router.
Figure 14-8 summarizes these commands, showing how they can be used to display the
pre- and post-filter BGP table contents. The figure shows Router E1, with inbound filtering
www.CareerCert.info
484 CCNP ROUTE 642-902 Official Certification Guide
Key
Topic
I1-1
Router E1
I3-1
BGP Table
BGP Table
Subset
Learned from
I3-1
show ip bgp neighbors I3-1 routes
Outbound
Filter
Inbound
Filter
Sent
Update
Received
Update
show ip bgp neighbors I3-1 received-routes
show ip bgp
show ip bgp neighbors I1-1 advertised-routes
“Best”
Routes
Figure 14-8 show Commands Related to BGP Filtering
for Updates received from Router I3-1 and outbound filtering of BGP Updates sent to
Router I1-1.
The commands for displaying inbound updates, at the bottom of the figure, display output
in the same format as the show ip bgp command. These commands restrict the contents
to either exactly what has been received from that one neighbor (the show ip bgp
neighbor received-routes command) or what has been received and passed through any
inbound filter (the show ip bgp neighbor routes command).
One of the two commands helpful for the inbound direction, namely the show ip bgp
neighbor received-routes command, requires the configuration of the BGP subcommand
neighbor soft-reconfiguration inbound. As a result, to see the pre-filter BGP Update received
from a neighbor, a router must configure this extra command, which causes the
router to use more memory to store the inbound Update. (A router cannot use the BGP
route refresh option just to get another copy of the incoming Update to list in this command.)
However, when learning in a lab, the extra memory should not pose a problem.
Of the two commands for outbound filtering, the post-filter command is somewhat obvious,
but there is no command to specifically display a pre-filter view of the BGP Update
sent to a neighbor. However, BGP advertises the best route for each prefix in the BGP
table, within certain restrictions. Those restrictions include that BGP will not advertise
iBGP-learned routes to an iBGP peer, and a router will not advertise the best route back to
the same neighbor that advertised that route. So, to see the pre-filter BGP table entries,
use the show ip bgp command, look for all the best routes, and then consider the additional
rules. Use the show ip bgp neighbor advertised-routes to display the post-filter
BGP Update for a given neighbor.
Example 14-13 shows the output of these commands on E1. In this case, E1 has been already
been configured with an inbound filter that filters inbound prefixes 184.0.0.0/8 and
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 485
185.0.0.0/8. (The filter configuration is not shown.) As a result, the post-filter output lists
five prefixes, and the pre-filter output lists seven prefixes. The example also shows the error
message when soft-reconfiguration is not configured.
Example 14-13 Displaying the BGP Table Pre- and Post-Inbound Filter
E1# show ip bgp neighbors 1.1.1.1 routes
BGP table version is 78, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 1.1.1.1 0 0 1 i
*> 181.0.0.0/8 1.1.1.1 0 1 2 111 111 i
*> 182.0.0.0/8 1.1.1.1 0 1 2 222 i
*> 183.0.0.0/8 1.1.1.1 0 1 2 i
* 192.135.250.0/28 1.1.1.1 0 1 2 3 4 i
Total number of prefixes 5
E1# show ip bgp neighbors 1.1.1.1 received-routes
% Inbound soft reconfiguration not enabled on 1.1.1.1
E1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
E1(config)#router bgp 11
E1(config-router)#neighbor 1.1.1.1 soft-reconfiguration inbound
E1(config-router)#^Z
E1#
E1# show ip bgp neighbors 1.1.1.1 received-routes
BGP table version is 78, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 1.1.1.1 0 0 1 i
*> 181.0.0.0/8 1.1.1.1 0 1 2 111 111 i
*> 182.0.0.0/8 1.1.1.1 0 1 2 222 i
*> 183.0.0.0/8 1.1.1.1 0 1 2 i
*> 184.0.0.0/8 1.1.1.1 0 1 2 i
*> 185.0.0.0/8 1.1.1.1 0 1 2 i
* 192.135.250.0/28 1.1.1.1 0 1 2 3 4 i
Total number of prefixes 7