Nokia Border Gateway Protocol SG v3.1.1

Module 0 | 1
Border Gateway Protocol v3.1.1

© 2016 Nokia
This Nokia Border Gateway Protocol v3.1.1 is for the exclusive use of Dandan HUA - ALCATEL-LUCENT
This course is part of the Nokia Service Routing Certification (SRC) Program. For more information on the SRC
program, see https://networks.nokia.com/src
To locate additional information relating to the topics presented in this manual, refer to the following:
 Technical Practices for the specific products referenced in this course
 Internet Standards documentation such as protocol standards bodies, RFCs, and IETF drafts
 Technical support pages of the Nokia website located at: https://networks.nokia.com/support
Module 0 | 2 Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 0 | 3
© 2016 Nokia
Module 0 | 4
© 2016 Nokia
Module 0 | 5
© 2016 Nokia
Module 0 | 6
© 2016 Nokia
Module 0 | 7
© 2016 Nokia
Module 0 | 8
© 2016 Nokia
Module 0 | 9
© 2016 Nokia
Module 0 | 10
© 2016 Nokia
Module 0 | 11
© 2016 Nokia
Module 0 | 12
© 2016 Nokia
Module 0 | 13
© 2016 Nokia
Module 0 | 14
© 2016 Nokia
Module 0 | 15
© 2016 Nokia
Module 0 | 16
© 2016 Nokia
Module 1 – 1
Nokia Border Gateway Protocol v3.1.1
© 2016 Nokia
Module 1 – 2
© 2016 Nokia
Module 1 – 3
© 2016 Nokia
Module 1 – 4
© 2016 Nokia
Module 1 – 5
© 2016 Nokia
Module 1 – 6
© 2016 Nokia
Nokia Border Gateway Protocol
This course is part of the Nokia Service Routing Certification (SRC) Program. See www.networks.nokia.com/src for
more information on the SRC program.
 Technical Practices for the specific product
 Technical support pages of the Nokia website located at: http://www.networks.nokia.com/support
Module 1 – 7 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 8
© 2016 Nokia
Module 1 – 9
© 2016 Nokia
The Internet is a distributed, open and global network of networks that rely heavily on the interconnections provided by Tier1
providers, Content Providers and regional Internet exchange points. The Internet can also be described as a continuous
and interconnected set of all of the public IP (v4 or v6) networks, advertised and shared across the globe. It is an
inter-connected network of networks that allows every Internet Service Provider (ISP) to reach every other ISP in
the world.
An Internet exchange point (IX or IXP) is a physical infrastructure through which Internet service providers (ISPs)
exchange internet traffic between their networks.
Internet exchanges form key interconnection points that allow ISPs to form relationships with each other in a
neutral, low cost setting. Internet exchanges serve, not just ISPs, but also several different types of content
providers that want to get their services closer to end users.

Popular opinion argues that there are 14 Tier 1 providers. Tier 1’s are typified by the fact that they can reach
every network on the global Internet, without paying any transit charges to any other provider. This is often a very
contentious topic because it is difficult to verify that any given provider does not use the services of another
provider in order to provide end to end connectivity across the entire Internet.
The 14 Tier 1 ISPs are identified as (again, subject to debate):
AT&T (AS 7018)

Century Link (formerly Qwest and Sawis) (AS 209/3561)
Deutsche Telekom AG (AS 3320)
XO Communications (AS 2828)
Telecom Italia Sparkle (AS 6762)
Inteliquent (formerly Tinet) (AS 3257)
Level 3 Communications (formerly Level 3 and Global Crossing) (AS 3356/3549)
TeliaSonera International Carrier (AS 1299)
NTT Communications (AS 2914)
Sprint (AS 1239)
Tata Communications (AS 6453)
Verizon Business (AS 701)
Telefonica (AS 12956)
Zayo Group (AS 6461)
Tier2 providers serve large regional areas of a country or continent but may not have as extensive a global reach
as Tier1 providers and probably pay Tier1 providers to transit their networks.
Although, geographically speaking, Tier 1 networks span very large portions of the Internet and peer at every
major exchange point, many Tier 2’s are actually larger in terms of the number of nodes served and number of
customers served. Tier 2’s are also typically closer to the end system, or customer, or content provider. For
example, the top AS’s, in terms of number of prefixes originated, are mostly not Tier 1’s.
Increasingly, in terms of traffic volumes, Internet traffic originates from very large web hosting sites, which
consolidate traffic from thousands of individual Enterprises to much fewer shared facilities. Most Internet traffic
now originates directly from content providers, such as Google and Yahoo, and content delivery networks, such as
Akamai and LimeLight.

The Internet comprises a global set of unique routing domain interconnections, known as Autonomous Systems
(AS). These AS’s represent actual BGP networks that advertise their respective prefixes or routes, and the prefixes
of their customers to other AS’s in their local area, region, or even on a global basis, on their own global network.
The descriptive terms Downstream and Upstream are references to where a specific customer, network, person,
or node sits, in relation to the overall Internet architecture.
Downstream indicates that, in that direction, network devices are closer to the edge of the Internet, where access
networks actually connect individuals, homes, and enterprise to the Internet. There are, of course, exceptions to
this; many Enterprises and Content Providers will actually locate their routers in carrier hotels and colo facilities to
be as close as possible to as many ISPs, and therefore their customers, as possible.
Upstream indicates that, in that direction, network devices are moving closer to the core of the Internet. If you are
client of a Tier 2 network, upstream would be towards the Tier 1 networks that your Tier 2 provider either peers
with or buys transit services from.
Internet Exchanges are physical locations that bring ISPs, Publishers, Hosting sites, Social Networking, Government,
and other types of BGP speakers that will peer with one another for mutual benefit, together. Exchanges were
once the domain of ISPs alone, but as more content providers began sending more data, it became increasingly
beneficial for ISPs to also peer with other types of Internet experiencial organizations. There are now hundreds of
exchanges worldwide that offer peering services at the local, regional, and continental levels.
A key consideration is that, architecturally speaking, the Internet does not impose any set architecture or set of
required devices to access it, apart from the standards published by the IETF and other Standards Development
Organizations (SDO, such as the ITU and IEEE. The aforementioned ICANN, its member organizations, IETF,
exchange points, and ISPs will, however, insist that you follow some key best practices. Addressing and naming are
two of the most important of these, and the idea of peering is another major consideration.

Peering loosely describes the conditions under which an Autonomous System (AS) announces certain prefixes to
another AS. Typically, if those conditions are met, neither AS will expect fees or tariffs from the other. In addition
to their own networks, AS’s can announce networks from their customers as well as from other Autonomous
Systems.
If fees or tariffs are charged, the relationship between the two AS’s changes; it becomes a transit relationship,
where one AS charges the other to transit traffic across its backbone. This is typical for Tier 1 providers, which
charge lower tier providers for access to their global backbone.

How or where neighbor establishments (either transit or peering) are actually made is very important. In the diagram
above, the arrows indicate traffic flow. In peering arrangements (for ISPs), traffic flow is typically equal; that is, each
peer sends and receives approximately the same amount from the other peer. In transit situations, the flow of traffic
can be unequal in terms of receiving vs. sending traffic, because the client network pays for the access and,
therefore, can send or receive as much traffic as it likes. The point where AS’s interconnect is also where each AS
applies its respective routing policies, regardless of whether the relationship is for peering or is transit.
Peering allows two networks to form a BGP neighbor relationship to their mutual benefit (SAVING MONEY). For this to
successfully result, some, or all, of the following policies may need to be met, depending on the size of AS that you
are attempting to peer with (this list is not exhaustive but illustrates typical types of policy agreements used on the
Internet):
1. Cost to peer (BGP session) is zero; cost to operate peer network is non-zero
Access to the exchange point is the responsibility of the AS itself and the cost is not zero. Other operational
costs are typical for peering arrangements too. Peers will insist on 24/7 tech support capability.
2. Public vs. Private Peering

Private peering is performed when 2 or more networks want to have their own private BGP session. There are
hundreds of private facilities worldwide. Private peering arrangements are typical for larger providers, such as
Tier 1 ISPs. Public peering describes when many AS’s buy access to an Internet exchange point that provides an
open and public interconnection point for any AS’s that wish to peer with one another. One of the largest
public peering exchanges is the Amsterdam Internet Exchange, which interconnects over 300 peers at close to
Terabit rates daily. Exchanges like AMSIX form the interconnection part of the Internet for a lot of Tier 1 and
Tier 2 providers, content providers, and other types of organizations.
3. Traffic Policies
These allow ISPs to push traffic from valuable sources, which could be publishers, government organizations,
and so on. First, a peer may insist on a certain sized backbone, in terms of the minimum bandwidth of core
links, so that there is sufficient capacity for the peering arrangement to work. Pushing traffic means that the AS
has something (apart from prefixes) to offer other AS’s that their customers will value. If the ratio between pull
and push becomes too high, it can mean that, as a peer, the AS is not pushing enough for the arrangement to
remain mutually beneficial. The sending peer is acting more as a transit provider rather than a peer.

4. Geographic Policy (Internet Exchanges mostly)
Some peers will insist that you have a minimum global or regional footprint. The AS must have a minimum
presence at certain exchanges (there are hundreds worldwide).
5. Transit AS Policy / Origin of routes (perhaps the most important part)

Some peers will insist that you advertise a minimum number transit AS networks; that is, the AS in question
must have a minimum number of transit customers that run BGP themselves. An extreme example is
Verizon Business (Tier 1, AS 701, formerly UUnet), which publishes its minimum number of US-based transit
AS networks at 1500. Essentially this says that, if the AS that wishes to be a peer of Verizon’s is in the US, it
will have to be either a Tier 1 or a very large Tier 2 provider (and even then very few Tier 2’s actually
originate 1500 transit AS’s). On the other end are peers that want no transit customer traffic and only want
the routes that originated directly from the AS in question.
Peering Do’s and Don’ts

 Send only the routes the peer wants
 Do not send a full Internet Table
 Do not send a default route
 Do not announce upstream or another peers routes
In summary, peering is an extremely efficient way for similar sized/scoped networks to exchange prefixes and to
create value for their customers by getting closer to the sources of content on the Internet.

TRANSIT (sometimes referred to as Paid Peering)
With a transit service (pay for a BGP neighbor in an upstream network), the conditions are quite simple:
 The Transit provider will provide a layer 1 or 2 circuit, or a mutually agreed upon exchange point location.
The connection will be a certain size - GigE, TenGigE, and so on.
 The Transit provider will provide up to a full Internet table to the transit customer’s AS using BGP, thereby
giving the customer full access to any network on the Internet.
 The Transit provider will advertise the client’s prefixes (and those of its customers, including transit AS’s) to
the rest of the Internet.
 The customer will follow the Transit provider’s Acceptable Use policy.
 Optionally, the transit provider will provide the means for a transit customer to influence incoming and
outgoing BGP path selections (the labs in this course show examples of how to do this).
 The customer is free to pull or push as much traffic as it can (extra charges may apply). Typically, the transit
customer will pull more traffic than it sends.

From the ICANN About page: “To reach another person on the Internet you have to type an address into your
computer - a name or a number. That address has to be unique so computers know where to find each other.
ICANN coordinates these unique identifiers across the world. Without that coordination we wouldn't have one
global Internet” . The Internet Assigned Numbers Authority (IANA) is operated by the ICANN.
The ICANN/IANA governs the global allocation of all possible address space used in the Internet to the 5 regional
registries. Each Regional Internet Registry (RIR) assigns chunks of address space to end users (mostly ISP’s), based
on their specific regional policies. The five regional registries are African Network Information Center (AfriNIC),
Asia Pacific Network Information Centre (APNIC), American Registry for Internet Numbers (ARIN), Latin America
and Caribbean Network Information Centre (LACNIC), and Réseaux IP Européens Network Coordination
Centre (RIPE NCC).
ICANN also manages the top level domain for generic domains (gTLD) and country code domains (ccTLD), and now
enables International domain names (IDN) that allow for URLs to use international character sets (for example,
Chinese or Arabic).
The IANA function within ICANN tracks and manages all IP protocol related numbers, including AS numbers, BGP
well known communities, PDU’s, Wireless, MPLS and related protocol numbers. The IANA website is a useful
resource to help you to determine whether a protocol works properly, or that certain protocol parameters have
been set correctly.
Apart from the two major governance aspects of name space and address space, the rest of the technologies,
implementation, and methods of access are the responsibility of individual Autonomous Systems, which,
interconnected, form the Internet backbone.

Module 1 – 18
© 2016 Nokia
Module 1 – 19
© 2016 Nokia
Module 1 – 20
© 2016 Nokia
An AS, or Autonomous System, is a set of routers under a single technical administration that uses an interior
gateway protocol and common metrics to route packets within the AS, and an exterior gateway protocol to route
packets to other AS’s. Since this definition was developed, it has become common for a single AS to use several
interior gateway protocols, and sometimes several sets of metrics. The use of the term AS here stresses that,
even when multiple IGPs and metrics are used, the administration of an AS appears to have a single coherent
interior routing plan, and presents a consistent picture of which destinations are reachable through it, to other
AS’s.
BGPv4, defined in RFC 4271, provides reachability information to external networks (those outside the AS) by
enabling the exchange of routing information between AS’s to allow data flow between them.
Once an exchange has been enabled, the application of administrative policy onto the traffic flows becomes of
equal or greater concern. Policy implementation is a key strength of BGP as it allows the administration to
manipulate traffic, based on virtually any policy.
BGP also has proven scalability. Most implementations, including the Nokia Service Router (SR) product line, scale
to millions of routes and hold multiple Internet tables (each as large as at least 300K). Therefore, BGP is the
fundamental building block of the Internet and is used by every ISP in the world for ISP interoperability.
BGP is the most feature-rich and scalable routing protocol in use today. It supports the current requirements of
the Internet, and with extended capabilities, such as multiple protocol families and extended AS numbers, is well-
positioned for the future.

An AS is a group of networks and network equipment under a common administration, identified by either a 16-
bit or 32-bit number.
IGP protocols, such as OSPF and IS-IS, run inside of an AS and are used to route traffic between internal BGP
speakers and related next-hops.
BGP is used to connect external BGP speakers in other AS’s.

RFC 1930 describes when you should register for a public AS number, the qualification criteria, and the guidelines
associated with this process.

According to “Autonomous System (AS) Reservation for Private Use draft-ietf-idr-as-private-reservation-05”,
the 32-bit AS number ranging from 4200000000-4294967294 will be reserved for private use.

To convert an ASPLAIN 4 byte AS to ASDOT:
1. Take the ASPLAIN number and divide by 65536 (2 to the power of 16). The whole number result is the
high order number.
For example, AS 135000  135000 / 65536 = 2.0599365… ASDOT is 2.x (notice this is from APNIC
space)
2. Multiply whole number in step 1 by 65536 and subtract this from the original ASPLAIN number.
For example, 65536 x 2 = 131072  135000 -131072 = 3928
Alternatively, you can arrive at this number by calculating 135000 mod 65536 = 3928 (modulo)
3. Therefore AS 135000 (ASPLAIN) is 2.3928 in ASDOT notation.

For example, check: (65536 x 2) + 3928 = 135000
Almost no implementations support ASDOT+, where the 16-bit ASN is converted to 0:<16bit ASN>, most
existing peering policies would be completely broken by doing this

• The use of public, private, or reserved AS and/or Network numbers in your real networks (experimental or
not), need to adhere to the acceptable use policies of your organizations, or those of your providers and
peers. You are free to use some of the example configurations discussed in the course and labs, but you
must ensure that you modify them to fit your specific organization’s safe use policies.
• Recall that, as an Open entity, everything you do on the Internet can be inspected and studied by the rest of
the Internet community, so govern yourself accordingly. For example, do not use the public or private AS’s
shown in example configurations in your own networks. Mistakes can - and do – happen, but remember that
they happen publicly.
• Use of Private or Documentation AS ranges does not protect you from the consequences of bad or
unwanted routing policy in your organization’s networks. Typically, most BGP implementations (SR OS
included) will not prevent an AS from being advertised by default.
• There have been many security incidents involving the Internet's core routing protocol, the Border Gateway
Protocol. Some of these incidents were attacks; others were accidental misconfigurations. But all of them
disrupted traffic to Web sites or entire networks because of incorrect routing messages being propagated
across the Internet through BGP.
• Among the biggest security incidents were: Pakistan Telecom blocks YouTube in Feb 2008, Malaysian ISP
blocks Yahoo in 2004, Turkish ISP takes over the Internet in 2004, and Brazilian carrier leaks BGP table in
2004.

Single-homed AS:
• Also known as a stub or leaf AS.
• Has a single connection to 1 AS (ISP); all traffic flows over this link.
• Addressing is usually part of the ISP assigned address space.
• Uses either the ISP or a private AS number.
• Internally sourced traffic is forwarded via the default route.
• Policy is simple.
• Usually small enterprises.
Multi-Homed AS:
• Has multiple connections to 1 or more AS’s.
• Should use its own AS number and IP addressing.
• May also employ default routing.
• More complex policy is required.
• Usually medium-to-large enterprises or ISPs.
• A common requirement to run BGP with an ISP is that the AS be multi-homed.
• Can be either transit or non-transit.
Interior routing policies and protocols must be established within each AS, enabling it to route packets internally.
A Stub AS can usually have a default route to its parent. A Multi-homed AS may use either default-less routing, or
setup a default route to one of its neighbor AS's, but this will probably result in poor quality routing.

Module 1 – 28
© 2016 Nokia
ISP X is a multi-homed non-transit AS. It provides Internet access for the networks it directly controls - either
networks assigned to services, such as Cable/DSL broadband services, or to enterprise customers that are
utilizing the AS X’s or their own address space.
AS X is not providing transit services for any other AS’s. Recall that the definition of transit is when an AS
transports networks and traffic that are associated with another AS for a fee. In this case, the broadband and
enterprise services are not providing transit for an actual exterior AS. To the rest of the Internet, all of the
networks associated with those services have been originated by AS X, regardless of which entity those
networks serve.
AS X’s upstream transit providers (Tier 1 ISPs A and B) are providing transit services. They will advertise AS X’s
networks to the rest of the Internet. As a result, other AS’s in the Internet will send traffic to AS X via Tier 1
ISP’s A and B. Also, since both of the Tier 1’s are transit providers, the rest of the Internet still views AS X’s
networks as correctly originated from AS X (and not either ISP A or B).

Module 1 – 30
© 2016 Nokia
Both AS’s X and Y are providing transit services for two stub AS’s (Enterprise W and Z). Those 2 stub AS’s retain
their visibility on the Internet from both an AS and Network point of view. Each can originate their own routes and
the rest of the Internet will see these as having originated from either AS W or AS Z.
It is typical for transit providers like AS X or AS Y to protect themselves, and the rest of the Internet, by limiting the
actual prefixes or networks that either stub AS can announce upstream. For example, what would happen if one of
these Enterprises announced a full Internet table to either AS X or AS Y? If you were running either AS X or AS Y,
would you want to send traffic for the rest of the Internet via either Enterprise? If you were running AS X or AS Y,
what would happen if an Enterprise sent you a prefix that they did not own or have any right to? Over the past 20
years, there have been several major outages caused on the Internet when an ISP announced prefixes that did not
belong to them, or that they had no right to originate or transit. When this happens, the Enterprise or ISP causing
the situation pulls or draws all of the traffic associated with that network towards it and away from the rightful
destination - in effect, it creates a blackhole for some traffic.

Transit traffic flows can flow upstream to other transit providers and also to peers of the transit providers. The
return traffic can also flow downstream from upstream transit providers. In buying transit services from AS X,
Enterprise W can take advantage of basically all peering or transit interconnections of AS X. Notice that, from the
perspective of the Tier 1 ISPs, the downstream networks (AS X and AS Y) are able to announce across their upper
tier peering exchange points.

The objective behind a peering agreement is for AS’s to push traffic to each other that is mutually beneficial. This
includes customer to customer traffic, as described on the previous slide. Neither AS will want the other to use
them as a transit provider. For example, AS X should send routes associated with its own networks and
customers to AS Y, and expect to receive traffic destined for these networks from AS Y and its customers.
Similarly, AS Y should send routes associated with its own networks and customers to AS X, and expect to receive
traffic destined for these networks from AS X and its customers.
Neither AS X nor AS Y will want the other AS to announce their routes upstream. This would cause traffic to
transit the other AS from the upstream and would break the peering agreement. For example. AS X should not
announce AS Y’s prefixes (that it received via the peering session) to either of its upstream transit providers ISP A
or ISP B. Traffic should not flow from ISP A to AS X to AS Y, nor should traffic flow from AS Y to AS X to ISP A in
the other direction. In the latter case, AS X would have to be advertising prefixes from its upstream to AS Y.
Neither AS would want that as part of a typical peering agreement.

Two types of BGP neighbor relationships are possible. Regardless of the type, a BGP session between 2 devices is
alternatively referred to as a neighbor or peer session. A BGP router is also referred to as a BGP speaker.
A session between 2 devices in different AS’s is referred to as an eBGP session. It is typical for devices that have
an eBGP session between them to be directly connected, to share a common data link, but it is not mandatory.
Because the devices are in different AS’s, the administration of each device is typically handled separately. Care
must be taken to ensure that the configuration parameters match, so that the peering will succeed.
A session between 2 devices in the same AS is referred to as an iBGP session. It is possible for devices that have
an iBGP session between them to not be directly connected. Because the devices are in the same AS, the
administration of each device is typically handled by the same organization. Care must still be taken, however, to
ensure that the configuration parameters match, so that the peering will succeed. With the devices locally
controlled, this is often an easier task.

eBGP can be classified into two major categories: Peering and Transit. For example, the eBGP session between
Router B and Router 1 is a transit relationship, while the eBGP session run between Router A and Router 3 is a
peering relationship.
To construct an AS with BGP, an ISP will typically implement a full mesh of BGP neighbors inside of the AS. This
will accomplish all of the benefits of an iBGP mesh, as illustrated on the slide above, and ensure smooth
operation. A full mesh will require N*(N-1)/2 sessions established in the AS. If you look closely above, ISP X will
have to run 15 separate sessions across its backbone.
BGP carries reachability information for prefixes that need to traverse the AS, and the IGP decides how to switch
or route the packets across the backbone between BGP speakers. Theoretically, an AS can choose to not
advertise any prefixes associated with its internal network and still be a fully functioning AS. The global BGP table
would successfully show the external BGP routes that the AS chooses to advertise, but a ping or traceroute
directly to or across the internal backbone would be unsuccessful because the Internet would have no way of
routing to it.
The definition of internal versus external routes is interesting and significant when describing BGP operations.
An internal network is associated with the actual addressing and related subnets used to provide system,
loopback, and link addressing, for the backbone of the AS itself. By that internal definition, an external network
is, therefore, defined as any networks that are brought into the AS via BGP, even those associated with the AS’s
own prefixes assigned by their RIR. For example, from a BGP point of view, prefixes associated with a broadband
service would be considered external networks (in SR OS, BGP does not learn anything about prefixes that may
originate from the AS itself by default; you have to export these with explicit edge policy). The BGP protocol can
be configured, however, to stamp such prefixes with attributes that will make items such as origin and ownership
very clear to the rest of the Internet. Though the routes are external from a protocol point of view, the rest of
the Internet will see the prefixes as belonging to the originating AS.

Route propagation occurs at the edges of the AS accepting network layer reachability information (NLRI) into the
BGP protocol. One way this is accomplished is by exporting directly connected or static routes into the BGP
protocol. For example, if Router C is the edge router responsible for attaching the ISP X’s broadband networks
(represented by the prefix 10.5.0.0/16) to the Internet, it would export the network 10.5.0.0/16 into its own BGP
process. BGP would then advertise this prefix to all of its iBGP neighbors. That would mean that all routers in AS X
would receive that prefix and advertise it to their eBGP neighbors (if any). In the case of router B, over the eBGP
transit session with Router 1, Router 1 receives this NLRI/Prefix from Router B. Router B is representing the best
interests of ISP or AS X to other external AS’s.
Note that, at each of the 3 steps above, regional ISP X has the opportunity to impose restrictions and policy. It can
choose to limit the prefixes it allows from external sources (like directly connected and static based prefixes) at
Router C. Over the iBGP session with Router B (and all other iBGP peers for that matter), Router C can set further
policy to set different types of metrics or BGP attributes associated with the broadband prefix 10.5.0.0/16. And
finally at Router B, the AS can impose additional policy to ensure that its upstream providers (Router 1) are treating
the AS X prefixes correctly. Router B will, in turn, advertise any networks it learns from its external peers or transit
providers back to the AS. This is another primary method of getting prefixes into BGP (via BGP neighbors); by
default, any routes learned via iBGP or eBGP will be advertised to other BGP neighbors.
There is one major exception to this default behavior, namely iBGP Split Horizon. By the iBGP Split Horizon rule
Router B will NOT re-advertise routes learned internally from any neighbor inside AS X to any other internal
neighbor. It assumed that a full mesh exists and that all BGP speakers in the AS have received the prefix
themselves. For example, Router B will not re-advertise that 10.5.0.0/16 prefix back to either router D or A or any
other internal peer.
Router D, however, can advertise the same prefix 10.5.0.0/16 to the rest of the AS if it is also adjacent to the same
network as Router C and is learning the prefix another way from iBGP. Each internal BGP neighbor will now receive
the same prefix from 2 routers. The BGP protocol is specifically designed to deal with this situation, where more
than one path exists to any given prefix. BGP will select a best path based on the local policy specified and the
default behaviors of its best path selection criteria.

The data plane follows a path through the ISP X, based on the configuration of the IGP. Packets destined for a
BGP learned destination are forwarded, hop-by-hop, across the AS, based on the next-hop address associated
with the BGP route. In the above slide, the prefix 10.5.0.0/16 is learned from downstream Router C. Router B
advertises the route to upstream Router 1 in ISP A, and Router 1 is sends traffic downstream towards that prefix.
In terms of actual packet forwarding on Router B:
1. The route for the broadband networks in AS X in Router B’s BGP table has a next-hop address of the router
C (BGP does not insist that neighbors be directly adjacent each other).
2. The IGP (IS-IS or OSPF) resolves the remote next-hop (Router C) to either of the directly attached networks,
Routers E or F (with recursion).
3. If Router B receives a packet for 10.5.1.1/32 from the Tier 1 ISP A, it forwards the packet to the locally
attached next-hop.
4. This internal router (either E or F) now has a route to the external network because it received it directly via
iBGP from Router C (because AS X is running a full iBGP mesh).
5. This process continues until the packet arrives at Router C, which forwards it out towards the destination.
This is the default packet flow, wherein the IGP decides which directly connected next hop to use. However, this
may not be the desired behavior.
The policy of ISP X is to send prefix 10.5/16 towards ISP A to this specific neighbor. As a result of this policy,
traffic will now flow from ISP A towards ISP X. With no other policy specified, sending the NLRI for the prefix alone
is all that is required to get traffic flowing. If no other route for 10.5/16 exists in the Internet table, whether ISP X
intended it or not, the entire Internet will now send traffic for any hosts addresses inside of 10.5/16 via the
Router 1 – Router B link through transit ISP A. This is the simplest policy implementation possible, but is also
actually the most significant. Recall that the longest prefix match is always used, regardless of vendor router
implementation; if a more specific route exists, or if there is only a single route to any given prefix, the Internet
will use it.

In the above slide, AS X is a transit provider for AS Y and AS Z. The routes learned by R4 from AS Y are propagated
to R1 through an iBGP session and then passed on to AS Z. For R1, the BGP routes have a next hop of R4 which is
resolved by the IGP to R2 as the next hop for transit traffic. This allows the external route information to be
propagated across the network to AS Z, but AS X cannot forward transit data traffic across the network. Traffic
from R1 destined to 192.168.1.0/24 will be forwarded to R2, but R2 does not have a route to the external
destination.
The solution to this problem can be either by injecting the external routes learned from BGP into IGP (Not
practical), or run BGP on all transit routers (R2, and R3) to learn the external destination (iBGP full mesh as
explained earlier). This substantially increases the control processing requirements for the transit routers and in a
large network requires many more iBGP peering sessions. An alternative solution is to use BGP shortcuts as
described in the following slide.

In addition to using MPLS to provide VPN Services and Traffic Engineering, Service Providers benefit from
implementing MPLS in the core of their network to provide a “BGP free-core” design. Using MPLS switching to
remove BGP full mesh from the core network to route Internet traffic is sometimes referred to as BGP Shortcuts
With MPLS shortcuts for BGP, MPLS tunnels are used to forward transit traffic across the network as shown in the
slide above. In this case, only the external facing routers (R1 and R4 in this case) need to run BGP and have
knowledge of the external routes. Transit traffic is sent in an MPLS tunnel to the next hop BGP router and is label-
switched across the AS. The transit routers (R2 and R3) do not need to know the external routes – they only label
switch the transit traffic.
The figure above shows only one MPLS tunnel – in reality there will be a full mesh of LSPs between all external
facing routers that have the full BGP routes. These LSPs can be signaled with either LDP or RSVP-TE.

The MPLS tunneling mechanism allows core routers to forward packets using labels only without the need to look
up the destination addresses in their IP routing tables. Therefore the core routers do not need to participate in
BGP thus optimizing processing power by saving routing space.
The edge routers however do need to run BGP to learn the destination addresses in their routing tables. An
ingress PE router looks up the destination address in its routing table and resolves it to a transport tunnel
established towards the egress PE router.

To configure BGP shortcuts, MPLS transport tunnels need to be established between PEs. These tunnels could be
either RSVP-TE LSPs or LDP-based LSPs. In addition, the PEs need to be configured to use transport tunnels
when resolving the next-hop of BGP routes.
The configure router bgp next-hop-resolution shortcut-tunnel family ipv4 command
specifies two options to resolve the next-hop of unlabelled IPv4 BGP routes:
• resolution any resolves the next-hop to any available RSVP-TE LSP or LDP. RSVP-TE is preferred over
LDP, and the lower metric RSVP-TE tunnel is preferred if multiple ones exist.
• resolution filter resolves the next-hop to a tunnel type specified in the resolution-filter
• resolution-filter ldp – use LDP tunneling for next-hop resolution
• resolution-filter rsvp – use RSVP tunneling for next-hop resolution
If there is no valid tunnel to resolve the next-hop, the router uses native IP forwarding unless the disallow-igp
option is specified.

Module 1 – 42
© 2016 Nokia
Module 1 – 43
© 2016 Nokia
To discuss the BGP protocol and its operation, it was first necessary to describe the basic elements of the
system, such as peers, neighbors, policy, AS’s, NLRI, networks, and so on. Now that these elements are
understood, the operations of BGP can become more precise. The rest of this module describes the high level
operations that BGP performs when exchanging NLRI.

BGP is an enhanced distance vector protocol, specifically called a path vector protocol.
BGP learns multiple paths to each route
• BGP selects the best path
• Best path is used to forward traffic
• Only the best path is sent along to other BGP neighbors
Neighbor relationships in BGP are somewhat different from what is normal in the IGP context. Traditionally, a
neighbor is always a directly connected router. With BGP, this is not the case. Neighbors may be directly
connected, but it is not required. Because of this, BGP relies on an IGP to route between peers that are not
directly connected.
BGP uses unicast TCP/IP for neighbor establishment. It is possible for neighbor relationships to be established
with any device that is IP-reachable. There is no guarantee that the neighbor relationship will succeed, because
factors such as firewalls or access control lists may prevent certain types of traffic from passing, but the
relationship is possible and likely to occur.
At the application layer, BGP functions similarly to TCP/IP applications such as Telnet, FTP, and HTTP. BGP is
viewed as an application because it uses registered port number 179 in the TCP/IP model.
Generic TCP/IP applications use a 3-way handshake for session establishment. After the session is established,
the applications exchange or negotiate a set of parameters for the session. In Telnet, for example, parameters
such as terminal types and passwords are typically negotiated. If application-level parameters are also
acceptable, a session is established at the application layer and data is exchanged. Periodic user data keeps the
session alive and, when the session is to be terminated, either user input or an inactivity timeout will cause the
application session to be torn down. TCP/IP initiates the 4-way session teardown.

Module 1 – 46
© 2016 Nokia
Protocols that are based on distance vector mechanisms, such as path vector, share certain characteristics. The
two that are significant to BGP are hop count and split horizon. Note that these two behaviors are present in BGP.
Adding to the complexity of BGP is the size of the topology and routing tables, which are much larger than in an
IGP environment. The increased size of these tables means that factors such as CPU loading, memory utilization,
update generation, and route processing, have a far greater implication in BGP.
These factors, and others, affect convergence. Convergence may be viewed in two ways. Local convergence is the
time taken for a single router to receive and process all outstanding messages, and settle on a stable topology.
Network convergence is the time taken for all routers in the system to settle on a stable topology. In IGP terms,
the system is usually the local AS. In BGP terms, the system is the Internet.
Because the entire Internet is the scope of BGP, the administration is typically more complex than the
administration for a single AS.

BGP currently defines 5 message types. Types 1 through 4 are defined in RFC 4271, and type 5 is defined in RFC
2918.
 An open message is used to initially request a BGP session with a peer and is the message that exchanges the
BGP parameters so that peers can determine whether their configuration parameters are compatible.
 Update messages are used to exchange the routing information between peers.
 Notification is the BGP term for error and is used to close down a peer session.
 A keepalive message manages the TCP session in the case of inactivity and is also used to respond to an
open message from a peer.
 A route-refresh message is an additional BGP capability that is negotiated by peers in the open exchange by
using the BGPv4 capabilities advertisement, as defined in RFC 3392. It is used to request that a BGP peer
resends the routes it advertised at the session establishment time.

To initiate BGP peering, the devices configured for BGP attempt a TCP/IP session to the target IP address, using
port number 179. Both devices must be configured for BGP; each device therefore attempts to establish a
session with the other device. The source IP address of the connection request must match what is locally
configured as the peer’s address, otherwise the connection is rejected.
Authentication is performed between neighboring routers before setting up the BGP session by verifying the
password. Authentication is performed using the MD-5 message based digest. The authentication key can be any
combination of ASCII characters up to 255 characters long.
The command authentication-key [authentication-key | hash-key] [hash | hash2] is used to configure the BGP
authentication key.
If both routers have established a session, the session initiated by the device with the lower BGP router ID is
terminated.
Periodic keepalive messages are exchanged to maintain the session.

 ConnectRetry Timer – When this timer expires, BGP reinitializes a TCP connection with its peer. The default
value is 120 seconds.
 Hold Time – This timer specifies the maximum time that BGP waits between successive messages (KEEPALIVE
or UPDATE) from its peer, before closing the connection. The default value is 90 seconds. The Hold Time is
sent in the BGP Open Message. Unlike some protocols, such as OSPF, if the hold time value does not match
between prospective neighbors, the value is negotiated to the lowest value proposed by either neighbor.
 KeepAlive – A KEEPALIVE message is sent every time this timer expires. The keepalive timer is not negotiated
between BGP peers; it is configured locally. The keepalive value is generally one-third of the hold-time
interval. The default value is 30 seconds. Under the following circumstances, the configured keepalive value
is overridden by the hold-time value:
• If the specified keepalive value is greater than the configured hold-time, the specified value is ignored,
and the keepalive is set to one third of the current hold-time value.
• If the specified hold-time value is less than the configured keepalive value, the keepalive value is reset to
one third of the current hold-time value.
• If the hold-time interval is set to zero, the configured value of the keepalive value is ignored. This means
that the connection with the peer is up permanently and no keepalive packets are sent to the peer.
All of the above timers can be configured at the global level (applies to all peers), group level (applies to all peers
in peer-group), and neighbor level (only applies to specifier peer). The most specific value is used.

In order to make decisions in its operations with peers, a BGP peer uses a simple finite state machine (FSM) that
consists of six states: Idle; Connect; Active; OpenSent; OpenConfirm; and Established. For each peer-to-peer
session, a BGP implementation maintains a state variable that tracks which of these six states the session is in.
The BGP protocol defines the messages that each peer should exchange in order to change the session from one
state to another. The first state is the “Idle” state. In the “Idle” state, BGP initializes all resources, refuses all
inbound BGP connection attempts and initiates a TCP connection to the peer. The second state is “Connect”. In
the “Connect” state, the router waits for the TCP connection to complete and transitions to the "OpenSent"
state if successful. If unsuccessful, it starts the ConnectRetry timer and transitions to the "Active" state upon
expiration. In the "Active" state, the router resets the ConnectRetry timer to zero and returns to the "Connect"
state. In the "OpenSent" state, the router sends an Open message and waits for one in return in order to
transition to the "OpenConfirm" state. Keepalive messages are exchanged and, upon successful receipt, the
router is placed into the “Established” state. In the “Established” state, the router can send/receive: Keepalive;
Update; and Notification messages to/from its peer.
The above slide illustrates a successful set of transitions leading up to an established BGP peer or neighbor
session. Once this state is achieved, NLRI can be passed back and forth between peers. The “rec/act/sent”
indicates received, active, and sent prefixes to/from this established peer in the show router bgp summary
command.
Under normal neighbor establishment procedures, BGP peers can exist in one of six defined states. Idle is the
initial state, established is the operational state, and all other states are transitional. Peers that exist in one of
these transitional states for extended intervals usually indicate a connection problem.
A neighbor may also be in the Idle state, if it is administratively shut down.

The above slide illustrates the show router bgp neighbor command output. In this case, the remote
neighbor has BGP enabled but is not configured to accept a connection from this peer. As a result, the State is
Active and the Last State is OpenSent. This is because the TCP session targeted to port 179 was successful and
the local peer sent an open message, but the remote peer did not respond.
Below is the list of possible Last Events in the show router bgp neighbor output. These events are the
trigger of BGP state transition.
 Start – BGP has initialized the BGP neighbor
 Stop – BGP has disabled the BGP neighbor
 Open – BGP transport connection opened
 Close – BGP transport connection closed
 openFail – BGP transport connection failed to open
 Error – BGP transport connection error
 connectRetry – Connect retry timer expired
 holdTime – Hold time timer expired
 keepAlive – Keepalive timer expired
 recvOpen – Receive an OPEN message
 revKeepalive – Receive a KEEPALIVE message
 recvUpdate – Receive an UPDATE message
 recvNotify – Receive a NOTIFICATION message
 None – No events have occurred

The above slide illustrates the show router bgp neighbor command output. In this case, the router has an
established connection with the remote peer, as shown by State: Established. The Last Event field also indicates
the receipt of a keepalive message, which indicates that the session is still functioning.

The partial bit or flag is used to indicate that a BGP speaker has performed an operation on the Path that would
cause some loss of information or lack of function. For example, if a BGP implementation did not implement a
specific optional BGP attribute, it may continue to send the advertisement, but set the partial bit to inform the
receiver that it could not process the attribute itself. Another example of when this flag can become necessary is
when an AS performs aggregation on behalf of other AS’s, thus creating an AS-Path attribute that is no longer as
accurate as it could be.
Once set, other receiving BGP speakers should not clear this flag.

To maintain BGP peering, there must be some exchange of BGP messages between the neighbors.
When neighbors initially establish a session, there is an exchange of BGP tables. After this exchange, it is desirable
to have as little routing-update activity as possible. In the absence of updates, the devices send periodic
keepalive messages to maintain the session.
A BGP update or keepalive message is expected so that the session will not be torn down. The receipt of either an
update or keepalive restarts the Hold timer.
If neither message arrives within the Hold-timer interval, both the BGP and TCP sessions are terminated.
The loss of a neighbor in BGP is a significant event. When the session is terminated, all routing information
learned from the neighbor is discarded, and the entire network (in BGP’s case, potentially the entire Internet)
must converge. When the neighbor session is reestablished, the TCP and BGP sessions are set up, a bidirectional
exchange of routes occurs, any inbound or outbound policy is applied, and the route-selection criteria are
evaluated for all entries. Best routes are then offered to the RTM, where a final decision based on preference is
made on each route before it is sent to the FIB.

Module 1 – 56
© 2016 Nokia
Module 1 – 57
© 2016 Nokia
After BGP establishes a session, routing updates are exchanged. Each routing update contains a prefix and
metrics. In BGP, metrics are called attributes.
Each BGP attribute is categorized into one of two main categories: well-known and optional.
Well-known attributes have two subcategories: mandatory and discretionary.
Optional attributes have two subcategories: transitive and non-transitive.
Therefore, BGP attributes are categorized in one of 4 ways:

 Well-known mandatory
 Well-known discretionary
 Optional transitive
 Optional non-transitive
The categorization of the attributes defines their behavior and handling in BGP.

If an attribute is well-known, it is expected that all BGP-capable devices will recognize (and understand the
meaning of) the attribute.
The mandatory or discretionary classification relates to their presence in a particular BGP update message.
 Mandatory attributes must be present in every BGP update; if a well-known mandatory attribute is missing, a
notification results.
 A discretionary attribute can be present in the update; it is the sender’s choice to include it, based on its
meaning.
There are 3 well-known mandatory attributes defined in BGP, so there is always a minimum of 3 attributes in
every BGP update message.

If an attribute is optional, it is not required or expected that all BGP-capable devices will recognize (and
understand the meaning of) the attribute.
Transitive or non-transitive characteristics relate to their handling by the receiving peer.
If a device receives a recognized optional attribute, the update is accepted and processed, based on the meaning
of the attribute.
If a device receives an unrecognized transitive attribute, the update is accepted, even though the local router is
not aware of the meaning of the attribute. The router propagates the update and attribute (“transits” the
attribute) and sets the partial bit in the BGP message to 1, if not done previously.
If a device receives a non-transitive attribute, the router will rip the attribute right off regardless.The router
propagates the update, but not the attribute.

The ORIGIN attribute is generated by the speaker that originates the associated routing information. BGP uses
the origin attribute to describe how a route was learned at the origin—the point where the route was injected into
BGP. It is a well-known mandatory attribute, therefore it is included in all BGP update messages.
The ORIGIN attribute can be one of the following values:

 0 (IGP) — Network-layer reachability information is learned by means of an IGP and, therefore, is internal to
the originating AS.
 1 (EGP) — Network-layer reachability information is learned via EGP.
 2 (Incomplete) —Network-layer reachability information is unknown (learned by another means other than
IGP or EGP). However for SR OS from Release 10.0.R1 onward, direct routes distributed by a BGP export
policy will have their origin attribute set by default to “IGP”. The behavior is different from previous releases
where the origin attribute would be "Incomplete.
Once it is set, the ORIGIN attribute should never be modified.

In the figure above, a BGP update is being originated by the router in AS 65100. The prefix (NLRI) in the update
message is internal to AS 65100. Because the router is the originating BGP router for the update, the ORIGIN
code should be set to “i”.
The attribute propagates in all future BGP updates for this prefix (in this example, across AS 65200 and AS
65250) and should never be modified.

The AS_PATH attribute identifies the sequence of AS’s through which an update message has passed.
This attribute list may contain zero, one, or more entries. The leftmost entry in the list is the neighboring AS that
sent the prefix into your AS. The rightmost entry in the list is the originating AS for the prefix. Intermediate
entries are transit AS’s that the update has passed through on its way to you.
The AS number of the sender is prepended to the list whenever the update crosses an AS boundary. If you view
the update inside of the originating AS, the list will be empty or null because the update has not yet passed
through an AS.
If a router receives an update that contains its local AS number, the update is flagged as a loop.
The implementation of AS_PATH is the hop count of BGP. Note that this hop count is not an indication of the
number of routers that the update has passed through, but of the number of AS’s that the update has passed
through, regardless of the actual number of routers.

RFC 3392 (formerly RFC 2842) is a simple mechanism that allows BGP peers to advertise newer capabilities
outside of RFC 4271. Under a strict implementation of RFC 4271, a BGP peer would send a Notification message
if an Open message were received with an unsupported optional parameter. This would cause the peer to be
dropped. RFC 3392 relaxes exchange requirements to allow the peers to negotiate without dropping the session.
Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced in RFC 4893 that can be used to
propagate four-octet based AS path information across BGP speakers that do not support the four-octet AS
numbers. To preserve AS path information with 4-octet AS numbers across OLD BGP speakers, this document
defines a new AS path attribute, called AS4_PATH. This is an optional transitive attribute that contains the AS path
encoded with 4-octet AS numbers. The AS4_PATH attribute has the same semantics as the AS_PATH attribute,
except that it is optional transitive, and it carries 4-octet AS numbers.
More information on 4-Byte ASN’s and transitional issues is available at:

http://www.apricot.net/apricot2009/images/lecture_files/apricot-2008-32-bit-asn.pdf and at:
http://www.ietf.org/rfc/rfc4893.txt

In the figure above, the BGP update is originated by the router in AS 65100. The prefix in the update message is
internal to AS 65100. Because this router is inside the originating AS, the AS_PATH list is null.
The attribute propagates in all future BGP updates for this prefix (in this example, across AS 65200 and AS
65250), and each time the update crosses an AS boundary, the AS number of the sender is prepended to the
AS_PATH list.
The update crosses an AS boundary to arrive in AS 65200, so the AS_PATH attribute now contains 65100, the AS
number of the sender.
Similarly, when it arrives in AS 65250, the AS_PATH attribute now contains the sequence 65200 65100.
The AS_PATH, read from left to right, represents the sequence of AS’s that lead to the origin of the route.

The AS_PATH is not changed when sent in an iBGP update. Router A has received a BGP update originated by
neighbor AS 65100. The AS_PATH contains only 65100. The update is sent to all iBGP routers (because the full
mesh is in place), with the AS_PATH unmodified.
To BGP, a hop is a single AS. Because the update is still in the same hop, there is no change to the AS_PATH
attribute.

The above slide illustrates how 32-bit AS’s interact with 16-bit only AS’s.
1. When sending AS-PATH between 32-bit capable AS’s, the AS-PATH carries full 32-bit AS numbers
2. When sending AS-PATH from a 32-bit capable AS to a 16-bit capable AS, the AS-PATH carries only 16-bit AS
numbers, and 32-bit AS’s are converted to AS 23456. The Optional Transitive attribute AS4-PATH carries
the 32-bit AS numbers in sequence (Optional Transitive means that the receiving AS has to carry it and send
it, even if it does not understand it)
3. When sending AS-PATH from a 16-bit capable AS to a 32-bit capable AS, the AS-PATH carries only 16-bit AS
numbers (and AS4-PATH is also sent). The 16-bit only capable AS ignores the AS4-PATH attribute but sends
it anyway (transitive).
4. When receiving the AS4-Path in a 32-bit capable AS, the AS re-combines the AS-PATH and AS4-PATH into a
single AS-Path, which comprises only 32-bit AS numbers. For example, AS 230000 merges the two AS-PATH
and AS4-PATHs into: 250 150 235000 135000

The NEXT_HOP attribute defines the IP address of the border router that should be used as the next-hop to the
destinations listed in an update message.
When a BGP speaker advertises a route to an iBGP peer, the advertising speaker does not have to modify the
NEXT_HOP attribute associated with the route, but it can with next-hop-self. This ensures that iBGP peers can
always reach the next-hop addresses associated with an iBGP neighbor.
When a BGP speaker advertises a route to an eBGP peer, the advertising speaker will modify the NEXT_HOP
attribute associated with the route.
The typical behavior is to set the NEXT_HOP attribute to the IP address of the egress interface used to send the
update to the remote neighbor. There is no restriction to this action, so other scenarios are possible.

In the figure above, the BGP update is originated by the router in AS 65100. If viewed on a router inside of the
originating AS, the NEXT_HOP attribute may be one of several addresses, depending on the configuration.
If the network is directly connected to the router that originated the prefix, the next-hop is not relevant locally (it
is directly connected), and it is not present in the local BGP table. If the prefix was learned from another router in
the same AS (not shown in the figure), the next-hop is the IP address of the originating router.
In either case, the border router sets the next-hop address to the interface used to reach the router in AS 65200
when it propagates the update.
The NEXT_HOP attribute propagates in all future BGP updates for this prefix (in this example, across AS 65200
and AS 65250, and each time the update crosses an AS boundary, the NEXT_HOP attribute is set to the IP
address of the egress interface used to send the update to the remote neighbor.
When the update is sent between routers in AS 65200, NEXT_HOP is unmodified by default; it remains the
address of the router in AS 65100.
When the update arrives in AS 65250, it crossed an AS boundary to get there, so the NEXT_HOP attribute now
contains the IP address of the eBGP router that sent the update to AS 65250.

The NEXT_HOP attribute may not be modified when sent in an iBGP update. Router A has received a BGP update
originated by neighbor AS 65100, with a next-hop of 10.1.1.1. BGP is concerned with reachability to the next AS,
so NEXT_HOP reflects this information by default.
When the update propagates into the receiving AS, NEXT_HOP is not modified. When the update is received by
Routers B, C, or D, the first check performed, before selecting a route as best, is whether the next-hop is
reachable. If the next-hop is unreachable, the route is never evaluated in the route-selection criteria.
10.1.1.1 may not be reachable because this network is external to the AS and is, therefore, unknown to the IGP.
Several solutions exist for this issue. For example:

 The external next-hop networks may be advertised in the IGP; or
 The NEXT_HOP may be modified by configuration of the iBGP sessions. In this case, the next-hop of the
update sent to Routers B, C, and D would be an internal address of Router A, which should be reachable via
the IGP.
Router B sets the next-hop address to the interface used to reach router Y in AS 65250 when it propagates the
update over the eBGP session.

Next-hop treatment is a very particular design consideration. The next-hop of a route may be an address that is
internal or external to the AS, depending on the configuration. By default, the next-hop in an update propagated
in iBGP remains unchanged as the egress interface of the advertising eBGP speaker.
Changing the iBGP default behavior, such that the next-hop address sent in the iBGP update becomes an internal
address, may be done by:
 Configuring the neighbor or group with the next-hop-self command. This changes the next-hop to an
address of the sending router.
 Configuring an export route policy for the sending peer, to modify the next-hop of the update to any desired
address. This policy configuration may become unmanageable as a result of the volume of updates and
policy complexity.
If the external next-hop address is to remain unchanged in the update, that network must be reachable internal
to the AS. This may be done by:
 Configuring an export route policy to advertise (redistribute) the external next-hop interfaces into the IGP.
 Configuring the external next-hop interfaces as passive interfaces in the IGP configuration.
 Static routing, which is possible but not scalable.
The external next-hop interfaces are usually directly connected to the edge router or routers, and configuration
is required on each one. Filters should also be used to allow only the interfaces that are used as next-hops to be
redistributed.

The next-hop-self command configures the group or neighbor to always set the next-hop path attribute to its
own interface when advertising a prefix to the group or neighbor.
This is primarily used by an AS edge router when propagating routes received via eBGP to its iBGP peers, if the
eBGP next-hop is unreachable for BGP routers within the AS. It can also set the next-hop to a system address in
iBGP to load-share between redundant physical paths, or to avoid third-party next-hops when connected to a
multi-access network.
Next-hop-self is disabled by default.

In the slide above, router A is configured with next-hop-self. When router A propagates the update to its iBGP
peers, it will set the next-hop to its system address, which is reachable via IGP.
Router B sets the next-hop address to the interface used to reach router Y in AS 65250 when it propagates the
update over the eBGP session.

The above slide illustrates the default behavior for the BGP well-known mandatory attributes in iBGP. These
attributes do not change when a route is propagated over an iBGP session.

By default, BGP messages are send to EBGP neighbors with an IP time-to-live (TTL) of 1. (This can be adjusted
with multihop command attached to the desired neighbor or peer group under BGP configuration.) Sending BGP
messages with a TTL of one requires that the peer be directly connected, or the packets will expire in transit.
Likewise, a BGP router will only accept incoming BGP messages with a TTL of 1 (or whatever value is specified
by multihop), which can help mitigate spoofing attacks. When a multi-hop BGP session is required, the expected
TTL value can be set to 255 minus the configured range-of-hops.
This approach can provide a qualitatively lower degree of security for BGP.
TTL Security Hack (TSH) implementation supports the ability to configure TTL security per BGP peer and evaluate
the incoming TTL value against the configured TTL value. If the incoming TTL value is less than the configured TTL
value, the packets are discarded and a log is generated
ttl-security command is used to configure TTL security parameters for incoming packets. When the feature is
enabled, BGP will accept incoming IP packets from a peer only if the TTL value in the packet is greater than or
equal to the minimum TTL value configured for that peer.
The TTL of iBGP sessions is set to 64 to allow the BGP control packets to reach neighbors that are not directly
connected to the sending router.

The command multihop ttl-value configures the TTL value entered in the IP header of packets sent to an eBGP
peer multiple hops away. The no form of the command is used to inform the BGP instance that the eBGP peers
are directly connected. The default value is 1 for eBGP (peers are directly connected), and 64 for iBGP.

LOCAL_PREF is included in all UPDATE messages that a given BGP speaker sends to its iBGP neighbors. A BGP
speaker includes the degree of preference for each external route when it advertises the route to its iBGP peers.
The higher degree of preference is preferred.
LOCAL_PREF is only used in iBGP. A BGP speaker does not include this attribute in update messages that it sends
to its eBGP neighbors. If LOCAL_PREF is contained in an update message that is received from an eBGP neighbor,
this attribute is ignored by the receiving speaker.
The purpose of the ATOMIC_AGGREGATE attribute is to alert BGP speakers along the path that some information
have been lost due to the route aggregation process and that the aggregate path might not be the best path to
the destination. When some routes are aggregated by an aggregator, the aggregator does attach its Router-ID to
the aggregated route into the AGGREGATOR_ID attribute and it sets the ATOMIC_AGGREGATE attribute or not;
based on whether the AS_PATH information of the aggregated routes were preserved or not.
When a BGP speaker aggregates several routes for the purpose of advertisement to a particular peer, the
AS_PATH of the aggregated route normally includes an AS_SET formed from the set of ASes from which the
aggregate was formed. In many cases, the network administrator can determine if the aggregate can safely be
advertised without the AS_SET, and without forming route loops. If an aggregate excludes at least some of the AS
numbers present in the AS_PATH of the routes that are aggregated as a result of dropping the AS_SET, the
aggregated route, when advertised to the peer, should include the ATOMIC_AGGREGATE attribute.
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute:

 Should not remove the attribute from the route when propagating it to other speakers.
 Must not make the NLRI of that route more specific when advertising the route to other BGP speakers.
 Needs to recognize that the actual path to destinations may traverse AS’s that are not listed in the AS_PATH.

The AGGREGATOR may be included in route updates formed by aggregation. A BGP speaker that performs route
aggregation may add the AGGREGATOR attribute, which contains its own AS number and IP address (router ID).
Aggregates are described in more details later in the course.

The COMMUNITY attribute, defined in RFC 1997, identifies a group of routes that share a common property. This
attribute is used extensively by ISPs to influence incoming and outgoing advertisements. ISPs can apply one or
more communities to each prefix to inform their internal and external peers about certain aspects of their
peering policies. For example, internal peers can inform other internal peers about which prefixes should and
should not be advertised to upstream or to other external peers. External peers can signal their preferences to
each other, as to how the prefix should be interpreted by the external peer. Most ISPs publish external peering
and transit polices that are based on the use of the BGP community attribute.
Note on RFC 1997 communities and 4 byte ASNs: The original community attribute defined in RFC 1997 specified
only 2 bytes for the ASN part of the community. It has since been decided by the IETF that if an AS utilizing a 4
byte ASN wants to send a community, it must use extended communities (RFC 4360) to do so; extended
communities allow for 4 Byte ASN’s. Most public peering and transit policies still rely on the older, 2 byte based
communities in their policies. Also, extended communities are not interpreted like 2 byte based communities
(RFC 1997). For example, when aggregating networks, it was typical to see any communities associated with the
more specific routes reflected in the aggregate. This does not happen if you use extended communities.

There are 4 communities that have been defined globally and must be supported by any router that is compliant
with the community attribute:
 RFC 1997 based: (circa 1996)

• No-export (0xFFFFFF01 or 65535:65281) — All received routes that contain this community value must
not be advertised outside a BGP confederation boundary. A stand-alone AS that is not part of a
confederation should be considered a confederation itself. This community is all or nothing from the
receiving AS’s point of view; there is no way for the receiving AS to distinguish between Transit or
Peering exchange points, and the advertisement will not propagate, regardless of neighbor type, if this
community is attached to a prefix.
• No-advertise (0xFFFFFF02 or 65535:65282) — All received routes that contain this community value
must not be advertised to other BGP peers.
• No-export_subconfed (0xFFFFFF03 or 65535:65283) — All received routes that contain this community
value must not be advertised to external BGP peers, including peers in other member AS’s within a BGP
confederation.
 RFC 3765 based: (circa 2004)

• Nopeer (0xFFFFFF02 or 65535:65284) – Essentially this newer RFC and associated well-known
community simplifies very complex peering policies. It allows sending AS’s to influence upstream AS
peering advertisements against propagating prefixes for which there is no discernable benefit to the
sending AS.
• Note that no peer does not have a keyword in SR OS, but you can specify it manually with the
community “nopeer” “65535:65284” command. All well-known communities can be specified this
way.

The slide shows a confederated AS 65000 (described in details in module 4), has two member ASes (65001 and
65002). AS 65000 has an eBGP session to AS 65100.
Router A advertises four prefixes within the confederation member AS 65001 to Router B, no community is set
for the first prefix (192.168.0.0/16), prefix 192.168.1.0/24 is tagged with community no-export-subconfed,
prefix 192.168.2.0/24 is tagged with community no-export, and prefix 192.168.3.0/24 is tagged with community
no-advertise.
The following slide details the route advertisement for each prefix.

Prefix 192.168.0.0/16 has a community value of “internet”; therefore, no restriction is placed on the prefix. The
prefix is received by Routers RB, RC, RD, and RE.
Prefix 192.168.1.0/24 is tagged with “no-export-subconfed”, therefore, it is not advertised by RB to AS 65002.
This prefix is not received by Routers RC, RD, and RE.
Because the community for 192.168.2.0/24 is “no-export”, RB advertises the prefix to RC, and RC advertises the
prefix to RD, but RD does not advertise the prefix to RE.
Prefix 192.168.3.0/24 is advertised from Router B to Router C with “no-advertise” community. When Router C
receives the update, it does not advertise the prefix to Router D. Thus, the prefix is not known on Routers RD,
and RE.

In most multi-homed interconnection points, the sending AS (AS 6500) will typically send an aggregate out to
one neighbor or peer, and send more specific prefixes to other peers. The resulting benefit is that traffic will flow
along the path where the specifics are advertised and, if that connection were to fail, the traffic can flow along
the path where the less specific aggregate was advertised. These more specific prefixes have no value for the
destination AS’s peering exchange point peers and should not be propagated to them. “no-peer” is used in this
situation so that the more specific route is not advertised to AS 65200.
“no-peer” is used in situations where traffic engineering control over a more specific prefix is required, but to
constrain its propagation only to transit providers and not peers. That is, the prefix is advertised from AS to AS
provided there is a transit/customer relationship, unlike “no-export”, which restricts propagation of the prefix to
only the adjacent AS.

The MULTI_EXIT_DISC attribute may be used on eBGP links to discriminate among multiple entry points from a
neighboring AS to the local AS. The value of the MULTI_EXIT_DISC attribute is a 4-octet unsigned number that is
called a metric. All other factors being equal, the route with lowest MED is preferred.
If it is received over eBGP links, the MULTI_EXIT_DISC attribute may be propagated to iBGP peers.
ORIGINATOR_ID and CLUSTER_LIST are used for loop prevention within an AS when Route Reflection is deployed.
Details will be explained in Module 4, Scaling iBGP.

This course describes 12 BGP path attribute types. Types 1 to 7 are defined in RFC 4271, type 8 is defined in RFC
1997, types 9 and 10 are defined in 2796. The table above lists the BGP type code, name, category, and default
values for each attribute.
The above summary does not cover all possible BGP attributes; the IANA defines other BGP attributes.

Module 1 – 86
© 2016 Nokia
1. What is a definition of the Internet?
The Internet is defined as a distributed, open, and global network of networks that rely heavily on the
interconnections provided by Tier 1 providers, Content Providers, and regional Internet exchange points.
2. What does the level or Tier of a service provider indicate?

The level or Tier of a provider indicates its reliance on the commercial transit services of other providers.
3. Why are Tier 1 providers considered settlement-free?

Tier 1 providers are considered settlement free because they can reach any network, anywhere in the
world, without paying a fee.
4. Approximately how many Tier 1 providers exist?

There are approximately 14 Tier 1 providers worldwide.
5. Name each of the 5 RIRs.

The 5 RIRs are AfrNIC, APNIC, ARIN, LACNIC, and RIPE NCC.
6. What do the terms upstream and downstream mean, from an Internet Architecture point of view?
The terms upstream and downstream indicate the relative proximity of a network to the core of the
Internet, formed by Tier 1 providers and Internet Exchanges. For example, DSL and Enterprise customers
are downstream of their Tier 3 or Tier 2 providers, which are themselves downstream from their own
upstream Tier 1 providers.
7. What is an Internet Exchange? How many public exchanges exist worldwide?

Internet Exchanges are physical locations that bring ISPs, Publishers, Hosting sites, Social Networking and
other types of BGP speakers that will peer with one another for mutual benefit, together. There are
hundreds of public peering exchanges worldwide, serving thousands of networks.

8. What is peering?
Peering is an efficient and settlement-free way that ISPs can exchange prefixes and push traffic to each
other.
9. How does peering create value for the customers of ISPs?

Peering creates value for an ISP’s customers by bringing the customer’s network closer to the sources of
valuable content on the Internet (thus lowering latency).
10. What is a transit provider?

Transit Providers (typically Tier 1’s and Tier 2’s) sell Internet connectivity to downstream ISPs and
Enterprises. This provides the transit provider’s customers with a global presence on the Internet, through
the transit provider’s interconnections.
11. What are the 2 primary functions of BGP?

BGP allows the exchange of NLRI between Autonomous Systems and allows for the implementation of
administrative policy.
12. What is an Autonomous System, or AS?

An Autonomous System is a collection of routers that are under a single administration, which present a
consistent routing policy to other AS’s.
13. How are AS’s identified on the Internet? How are AS numbers allocated and assigned?
AS’s are identified using either a 2 or 4 byte number. AS’s are allocated by the ICANN/IANA to regional
registries who assign them to actual ISPs and Enterprises according to RFC-1930.
14. What is a private AS number? And what is a documentation AS number?

A Private AS is used when the AS in question will not connect to the global Internet or where there is no
requirement for the AS in question to be visible on the Internet. Documentation AS’s are reserved for use
by books etc. to portray networks using an AS number that does not overlap either public or private AS
space. (the labs in this course use documentation AS numbers).

15.What connection options are available to multi-homed AS’s and how are they different from the options
available to single-homed AS’s? How complex are these options?
Multi-homed networks can choose to connect either to the same or different AS’s at multiple locations in
order to provide diversity in how the network connects to the Internet. Single-homed networks have only a
single connection through a single provider to the Internet. Multi-homed networks has far more complex
routing policy, requires BGP for implementation, and has its own public AS and IP addressing. Single-homed
networks have very simple policies and typically do not require their own AS number.
16.Describe the possible types of AS’s.

AS’s fall into 3 broad categories of Stub, Transit, and Non-Transit. Stub AS’s only provide access to the
Internet for their own networks, their AS is not used by other AS’s. Non-Transit AS’s are similar to stub AS’s
in that they do not provide transit services to other AS’s but they may be multi-homed to multiple
upstream providers and other peers. Transit AS’s actually sell access to their backbone to other AS’s and
carry and advertise their client’s networks to other AS’s.
17.Describe the relationship between peering and transit.

Under a peering agreement and associated peering session, both AS’s will agree to send or announce their
own prefixes and typically those of their own transit customers too. In this case, the peers are providing
transit services to their customers and allowing their transit customer to send traffic directly to each other
through that peering point.
18.What is the difference between eBGP and iBGP?

eBGP is run between routers in two different AS’s under two different administrations. iBGP is run between
routers inside the same AS under a single administration.
19.Why is a full mesh of iBGP peers used?

A full mesh of BGP sessions internal to the AS allows for all routers in the AS to a have consistent view of all
external networks being routed by the AS. This allows there to be a clear separation between the IGP(s) that
have a consistent view of the networks internal to the AS and BGP that carries networks external to the AS.
20.What steps are necessary for BGP to propagate external routes across the AS? What should iBGP peers
avoid doing?
Step 1 - The edge router brings the NLRI or prefix into BGP (in SR OS via an export policy or via another BGP
neighbor). Step 2 - The same edge router announces the prefix to all of its iBGP peers. Step 3 - Those
receiving iBGP peers announce the route to their eBGP peers. According to BGP Split Horizon, receiving iBGP
peers should not re-advertise the prefix to each other.

21. List at least 4 basic functions of the BGP protocol.
BGP exchanges NLRI, maintains a list of AS’s through which this NLRI traversed, graphs the location or AS of
all networks which prevents routing loops, advertises only its best used route, capable of implementing very
complex routing policy, supports CIDR, and runs as an application over TCP port 179.
22. Which RFC defines BGP?

BGP is defined in RFC 4271.
23. What protocols does the BGP application enable?

BGP enables a number of applications, including ipv6, vpn-ipv4, vpn-ipv6, mcast-ipv4, mvpn-ipv4 and l2-vpn.
24. What are the five BGP message types and their basic functions?
The 5 message types are Open (exchanges and negotiates neighbor capability), Updates (transfers or
withdraws NLRI), Notification (transmits errors), Keepalive (sustains the session), Route-Refresh (allows BGP
to selectively request re-sends of NLRI).
25. Describe the neighbor establishment phases and parameters required for established neighbors.
The two main phases are TCP (bringing up the transport session) and BGP Capabilities Exchange. BGP
requires that all parameters match during the capabilities exchange including BGP version, AS numbers, Hold
time values, Router IDs and any other optional parameters that need to be negotiated.
26. What is the hold time used for?

Hold time is used for peers to recognize when a peer is no longer responding. It is the maximum amount of
time that can elapse before receiving either a Keepalive or an Update from the peer.

27. Which 5 states are typical for a successful BGP neighbor establishment?
The BGP neighbors will transition from Idle to Connect to OpenSent to OpenConfirm to Established.
28. What is necessary for the successful transition from OpenSent to OpenConfirm, and OpenConfirm to
Established?
To reach an OpenConfirm state, the BGP neighbor must receive an OPEN message with the correct neighbor
capability parameters. To reach Established, the neighbor must receive a keepalive message.
29. What are the four categories of BGP attributes?

The four categories of BGP attributes are Well-Known Mandatory, Well-Known Discretionary, Optional
Transitive, and Optional Non-Transitive.
30. What does the transitive property of some optional BGP attributes provide?
The transitive property provides a way for implementations that have not implemented certain optional BGP
attributes to at least be able to either preserve (transitive), or not preserve (non-transitive), the attribute
when sending updates on to other BGP speakers. In either case, the implementation still accepts and sends
the NLRI associated with the optional attribute which it ignores.
31. Who should set the Origin attribute?

The origin should be set by the originating AS and should never be changed by any other AS.
32. What is the significance of the location of an AS number inside the AS_Path (from left to right)?
The leftmost part of the AS_PATH is where each transit AS prepends their own AS number. The originating AS
will be located at the right most part of the AS_PATH.

33. What is a “new” BGP protocol implementation? Which AS number is used to provide backward
compatibility?
A “new” BGP protocol implementation can advertise itself as 4 byte AS number capable
implementation which means it can understand and process 4 byte AS numbers inside of the AS_PATH
attribute and also a 4 byte AS number inside of the AGGREGATOR attribute. AS 23456 is used to
provide backward compatibility for 2 Byte only AS’s that do not understand 4 Byte ASNs.
34. How does iBGP treat the AS_PATH attribute?

iIBGP does not modify the AS_PATH attribute. Updates that are sent via iBGP are considered the same
hop from an AS_PATH point of view.
35. What is a common method to stabilize and scale BGP, so it does not create dependencies on other
networks?
By implementing the next-hop-self feature and using only internal (to the AS) address space to move
packets between iBGP peers.
36. When is the ATOMIC-AGGREGATE flag set?

The ATOMIC-AGGREGATE flag is set when a router advertises an aggregate on behalf of the other AS’s
and the AS_PATH information of the aggregated routes are not preserved
37. What organization documents well-known communities?

The 4 well-known communities are documented by the ICANN/IANA.
38. What does the nopeer community do?

The nopeer community allows an ISP to inform other ISPs that it does not want them to advertise
routes tagged with the nopeer community to other peers. Theoretically, this reduces the size of the
BGP routing table.

Module 1 – 93
© 2016 Nokia
Module 1 – 94
© 2016 Nokia
Module 1 – 95
© 2016 Nokia
Module 1 – 96
© 2016 Nokia
Module 2 – 1
© 2016 Nokia
Nokia Border Gateway Protocol
This course is part of the Nokia Service Routing Certification (SRC) Program. See www.networks.nokia.com/src for
more information on the SRC program.
 Technical Practices for the specific product
 Technical support pages of the Nokia website located at: http://www.networks.nokia.com/support

Module 2 – 3
© 2016 Nokia
Module 2 – 4
© 2016 Nokia
When a routing protocol learns routes from its neighbors, it populates these routes into its RIB, where they are
stored.
For each destination in the RIB, the routing protocol selects the best route based on the lowest metric. These
best routes are sent to the RTM.
Multiple routes to the same destination can be learned by the router. If these routes are learned from the same
routing protocol, the metric for the protocol is used as a selection criterion. The route with the lowest metric is
selected as the best route and is sent to the RTM.
If multiple routing protocols are in use, each protocol selects its best route, based on the lowest metric from its
RIB. At this point, there are multiple best routes, (one from each protocol), and each protocol sends its best route
to the RTM.
The RTM can choose only one of these best routes because there can be only one best route for each destination
in the routing table.

Because metrics from different protocols are not comparable, the RTM uses preference to select from the best
routes it receives. The lower the protocol’s preference, the more likely that the best or active route will be
selected from that protocol.
Default Preferences are as follows:

Route Type Preference Configurable
Direct attached 0 No
Static routes 5 Yes
OSPF internal 10 Yes
IS-IS level 1 internal 15 Yes
IS-IS level 2 internal 18 Yes
RIP 100 Yes
OSPF external 150 Yes
IS-IS level 1 external 160 Yes
IS-IS level 2 external 165 Yes
BGP 170 Yes
Different protocols should not be configured with the same preference. If this occurs, the tiebreaker is based on
the default preference table (shown on the following page).
If the RTM learns multiple routes from the same protocol, and the metrics are equal, the best route decision is
determined by the configuration of ECMP in the config>router context.
The best routes from the RTM are placed in the FIB and RT (Routing Table).
The FIB is distributed to the various IOMs on the Nokia 7750 SR.

BGP is unlike other IGPs in that it uses three databases to operate. They are (as described in RFC 4271):
 Adj-RIBs-In (abbreviated to RIB-IN above) – This database comprises updates received from BGP
neighbors as input to the BGP decision process (prior to applying ingress policies).
 Loc-RIB – This database results when BGP selects its best path and submits it to the RTM.
 Adj-RIBs-Out (abbreviated to RIB-OUT above) – This database comprises only the subset of best paths
placed in Loc-RIB, and processes them based on the export policies applied to BGP neighbors.

The default BGP behavior, with no route policies configured, is as follows:
 Accept all BGP routes into the RTM for consideration, according to the route-selection criteria.
 Announce all used BGP learned routes to other BGP peers.
 Do not announce IGP, static, or local routes to BGP peers.
Because of the last behavior stated above, local networks are reachable by external ASes only when an export
policy is specified.

A policy is an administrative means to control the updates between BGP peers.
Export policy controls both the routes that are sent into BGP from other protocols and the routes that are
propagated to BGP neighbors.
For the local router, strict control is required to ensure that only public networks are reachable externally and are
exported from the IGP. This helps to ensure that restricted or private internal networks are not compromised by
packets originating from outside the domain.
With export route policies, the BGP neighbor also benefits from the reduction of BGP updates. These benefits
include:
 Reduced control plane traffic on the physical links between the neighbors.
 Reduced control plane processing for the neighbor that manages the BGP updates.
 Less memory is required, because tables are smaller.

Import policies applied to BGP neighbors filter or modify incoming BGP updates. Import route policies also offer
additional benefits.
For the local router, the BGP overhead should be reduced because there are fewer updates to process. Also, less
control plane processing is required, and table sizes are reduced.
The physical links between the routers also experience decreased control plane traffic.
Proper configuration of the import policy also protects the local AS from invalid or unwanted updates that may be
propagated from networks as a result of neighbor misconfigurations or a potential attack by a hacker attempting
a flooding or DoS attack on the BGP router.

The above slide illustrates the internal process used to keep the various BGP databases up-to-date and to
reflect any routing policy specified. The rest of this course will examine how policies—either import or
export—are designed, documented, and applied to SR OS to ensure that correct route selections are made and
that the right BGP updates are sent to internal and external BGP neighbors.
A BGP export policy can also incorporate non-BGP routes from other IGP protocols (RIP, OSPF, ISIS, Static) and
locally connected networks. This allows internal routes to be advertised by BGP to other BGP neighbors.
The initial exchange between BGP neighbors includes used routes in the BGP table and local networks that are
explicitly advertised into BGP. By default, local networks exist solely in the IGP and are not propagated into
BGP unless explicitly configured. Nokia’s implementation of BGP uses route policies extensively. The
implied or default route policies can be overridden by customized route policies.
If the path is resolved to a single prefix with the highest local preference, Next-hop is reachable (route is
valid), and there is no AS loop, then the route is installed into LOC-RIB. Otherwise, perform Tie Breaker (on next slide)

The above slide lists the BGP route selection criteria, as implemented on Release 13 of the 7750 SR. When BGP
receives multiple routes to the same destination prefix with the same subnet mask, the route-selection criteria
are used to select the best route.
It is important to understand that a longer prefix match automatically makes any given prefix better than a similar
shorter length prefix, regardless of which BGP attributes are set. the longest prefix match is always used,
regardless of vendor router implementation; if a more specific route exists, or if there is only a single route to any
given prefix, the Internet will use it.
A route is not considered if it does not have the valid flag associated with it, if it contains an AS_PATH loop, or if
the next-hop is unreachable.
For each prefix in the BGP route table, all entries for that prefix are compared, using the route selection criteria,
to choose the best route for that prefix.
The “Multipath” command can be used to allow BGP to load shares traffic across multiple links. Multipath can be
configured to load share traffic across a maximum of 32 routes. If the equal cost routes available are more than
the configured value, then routes with the lowest next-hop IP address value are chosen.

BGP does not set any explicit policies (or modify BGP attributes from their own defaults) by default.
Recall the default BGP behavior:

• Accept all BGP routes into the RTM for consideration, according to the route-selection criteria.
• Announce all used BGP learned routes to other BGP peers.
• Do not announce IGP, static, or local routes to BGP peers.
As a result of the last statement, an export policy must be specified for local networks to be reachable by external
AS’s.
With only these defaults set, the BGP selection process cannot take advantage of any of the key BGP attributes
that can produce the most desirable outcomes, as described on the slide above. Following modules describe how
to plan, design, and configure BGP and the IGP to accomplish all of these outcomes.

Module 2 – 14
© 2016 Nokia
Module 2 – 15
© 2016 Nokia
Whether to use IS-IS or OSPFv2 is a decade-old debate on the Internet. There are many references that describe
the benefits of each protocol, but for many Tier 1 and Tier 2 ISPs, IS-IS is a preferred IGP. The BGP labs depend
on IS-IS to act as the IGP for the AS.

The following information summarizes BGP configuration defaults.
 The Nokia 7750 SR is not assigned to an AS. AS configuration is mandatory.
 BGP instances, groups, and neighbors are all created in the administratively-enabled state.
 If a BGP router ID is not specified, BGP uses the router system interface address as the router ID. Although
this serves as a valid router ID for BGP, best practice is to explicitly configure a router ID value in the BGP
instance.
 The Nokia 7750 SR OS BGP timer defaults are the values recommended in IETF drafts and RFCs. Timer
settings may be found in the BGP section of Nokia 7750 SR OS Routing Protocols Guide.
 If no import route-policy statements are specified, all BGP routes are accepted.
 If no export route-policy statements are specified, all BGP routes are advertised, and all non-BGP routes are
not advertised.
 An export route policy must be defined to explicitly allow local networks, for example, IGP, static, direct, and
aggregate, to be reachable outside the AS.

Consider the following guidelines when preparing for and deploying the Nokia 7750 SR in a BGP environment.
 Prepare a plan that describes the AS. Keep a diagram and documentation available, with information such as
AS numbers, router IDs, IP addresses, physical links, and peering arrangements.
 Configure each 7750 SR with an AS number.
 The BGP speaking router must have a router ID. Remember that if the router ID is not explicitly configured,
BGP uses the router’s system interface address.
 Define at least one peer group containing at least one neighbor. Define neighbors and associate each
neighbor with a peer group (each neighbor must belong to a group). The local IP address used for session
establishment with the group or neighbor is optional; the default address is used if the local IP address is not
configured.
 When defining neighbors, specify the AS number associated with each remote neighbor.

The above diagram describes the basic information associated with each AS used in our labs. This includes
system IPs, loopback addresses, AS numbers, and so on. In this module we will be focusing on the
configuration of the routers in AS 65540, and we will using the loopback interface “Loop0” on both routers R5
and R6 to demonstrate the BGP behavior

The flowchart above represents a suggested sequence for enabling and configuring basic BGP requirements on
the Nokia 7750 SR.

BGP configuration commands have three primary configuration levels:
 BGP for global configurations
 group name for BGP group configurations
 neighbor IP address for BGP neighbor configurations.
Within the three levels, many configuration commands are repeated. For repeated commands, the command that
is most specific to the neighboring router is used. In other words, neighbor settings take precedence over group
settings, and group settings take precedence over BGP global settings.

The System Interface:
 Is also referred to as the loopback address.
 Is associated with the network entity, such as a specific router or switch, and not a specific interface.
 Is used to preserve connectivity when routing reconvergence is possible and when an interface fails or is
removed.
 May be used as the router ID.
 Must have an IP address with a 32-bit subnet mask.

Module 2 – 23
© 2016 Nokia
At the global level, changing the BGP AS number causes the BGP instance to restart with the new local AS number.
At the group level, changing the AS number causes BGP to re-establish peer relationships with all peers in the
group with the new local AS number.
At the neighbor level, changing the AS number causes BGP to re-establish a peer relationship with the new local
AS number.

On the Nokia 7750 SR, the router ID is usually derived using one of the following methods:
 Defining the value in the config>router>bgp router-id context
 Defining the value in the config>router router-id context
 Configuring the system interface in the config>router>interface ip-int-name context
If the router ID is not manually configured, the system interface IP address acts as the router ID.
If neither the router ID nor the system interface address is configured, the BGP peering will not be established.
The best practice is to have a unique BGP router ID value configured in the BGP instance.
If you configure a new router ID in the config>router-id context, protocols are not automatically restarted
with the new router ID. The next time a protocol is initialized or reinitialized, the new router ID is used. Therefore,
there may be a period when different protocols use different router IDs.

Peer groups are the implementation of group policy in BGP. This grouping of peers builds a template with
common configuration parameters. Individual neighbors inherit these parameters based on their association to
the group. This makes management and administration simpler because it is easier to apply a policy or
configuration to one group that contains several members than it would be to apply the configuration to each
neighbor separately.
Recall that there are mandatory BGP configurations on the Nokia 7750 SR:
 a minimum of one group must be defined
 the group must contain at least one neighbor
 all neighbors must belong to a group.
Individual parameters may also be applied to a specific neighbor to override group settings (because the most
specific configuration applies) or to assign a unique parameter to one member of the group.

The command configure router bgp <group-name> creates a context to configure a BGP peer group.
The no form of the command deletes the specified peer group and all configuration associated with that peer
group. The group must be shut down before it can be deleted.

Whenever possible, iBGP sessions should be configured between the system addresses of the peers. The system
address must be reachable in the IGP.
The system address of router R5 is 10.16.10.5/32. When router R5 originates a BGP update to router R1 across
the iBGP session, the next- hop of the update is set to the sending router’s system address. When router R1
forwards a packet to this destination, the packet is sent to the next-hop, which is the link between routers R1 and
R5.
The IGP may have multiple paths to 10.16.10.5/32 in the routing table. If the links in the above slide are all equal-
metric and ECMP is configured, there are two available paths from router R2 to 10.16.10.5: one via router R6 to
router R5, and the other via router R1 to router R5. Packets sent to this next-hop share the available paths,
based on the ECMP algorithm.
The same behavior can be extended to customers and networks that are using AS 65540 to transit their data.
Routers in AS 65540 must simply reset the next-hops associated with external AS networks to themselves (using
the next-hop-self command).

After the group has been created, parameters that will be inherited by any neighbor within the defined group may
be assigned. The above slide illustrates a group description and the AS number common to all peers defined in
this group.
Neighbors defined in the group will inherit all group parameters. However, group parameters may be overridden
by explicit configuration at the lower neighbor level.

The neighbor context is used to apply parameters specifically to one neighbor. Any settings made at the neighbor
level override settings made at the group or BGP level.
The local-address command configures the local IP address used by the group or neighbor when
communicating with BGP peers.
Outgoing connections use the local-address as the source of the TCP connection when initiating connections with
a peer.
When a local address is not specified, the router uses the system IP address to communicate with iBGP peers and
uses the interface address to communicate with directly connected eBGP peers. This command is used at the
neighbor level to revert to the value defined under the group level.

The command configure router bgp group prefix-limit <limit> configures the maximum number of
routes that BGP can learn from a peer. When the number of routes reaches 90% of this limit, an SNMP trap is
sent. When the limit is exceeded, the BGP peering is dropped and disabled.

The following commands are useful for verifying the router ID value, depending on how it was configured:
 show router interface system
 show router bgp summary

The command show router bgp group [name][detail] displays group information for a BGP peer group. It
can be entered with or without parameters. When the command is entered without a group name, information
about all peer groups is displayed. When the command is issued with a specific group name, only information
about the specific peer group is displayed.
The State field displays the BGP group’s operational state. Other valid states are:
Up — BGP global process is configured and running
Down — BGP global process is administratively shut down and not running
Disabled — BGP global process is operationally disabled. The process must be restarted by the operator.

Context: show>router>bgp
Syntax: neighbor [ip-address [[family family] filter1]]

neighbor [as-number [[family family] filter2]]
neighbor ip-address orf [filter3]
neighbor ip-address graceful-restart
Description: This command displays BGP neighbor information. The command can be entered with or
without parameters. When the command is issued without parameters, information about all
BGP peers is displayed.
When the command is issued with a specific IP address or AS number, only information about
the specific peer, or peers with the same AS number, is displayed.
When received-routes or advertised-routes is specified, the routes received from or sent to

the specified peer are listed.
The State field displays the BGP peer’s protocol state. In addition to standard protocol
states, this field can also display the Disabled operational state, which indicates when the peer
is operationally disabled and must be restarted by the operator.
Parameters: ip-address – Displays information for the specified IP address

as-number – Displays information for the specified AS number
family – Specifies the type of routing information to be distributed by this peer group
filter1 – Displays information for the specified IP address
received-routes – Displays the number of routes received from this peer
advertised-routes – Displays the number of routes advertised by this peer
orf – Displays outbound route filtering for the BGP instance
filter3 – Displays path information for the specified IP address
send – Displays the number of paths sent from the peer
receive – Displays the number of paths received from the peer
graceful-restart – Displays the neighbors configured for graceful restart

Show router bgp summary provides an overview of all neighbors and of the stats of the BGP updates.
The “State” column indicates whether the session is established. If the session is established, the number of
routes “Received,” “Active,” and “Sent” will be displayed. Until the neighbors are established, the “State” column
will show the state of the BGP neighbor (Idle, Connect, or Active).
 Rcv: number of BGP routes received from a particular neighbor

 Sent: number of BGP routes sent to a particular neighbor
 Act: number of the active or used BGP routes selected from those received routes
The output in the slide shows that there are no BGP routes received or advertised between the iBGP neighbors.

The output in the slide shows that there are no BGP routes received from the configured BGP neighbors. Recall
the default behavior for BGP; local networks exist solely in the IGP and are not propagated into BGP unless
explicitly configured. Notice that there are 2 equal cost paths from router R2 to router R5 since ECMP is
configured as indicated before.
*A:R2# show router route-table

===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.16.0.0/30 Remote ISIS 18h27m05s 15
10.16.0.9 200
10.16.0.4/30 Local Local 01d00h30m 0
toR6 0
10.16.0.8/30 Local Local 01d00h30m 0
toR1 0
10.16.0.20/30 Remote ISIS 01d00h30m 15
10.16.0.5 200
10.16.10.1/32 Remote ISIS 18h27m05s 15
10.16.0.9 100
10.16.10.2/32 Local Local 01d00h30m 0
system 0
10.16.10.5/32 Remote ISIS 02h06m12s 15
10.16.0.5 200
10.16.10.5/32 Remote ISIS 02h06m12s 15
10.16.0.9 200
10.16.10.6/32 Remote ISIS 01d00h30m 15
10.16.0.5 100
-------------------------------------------------------------------------------
No. of Routes: 9

The flowchart above represents a suggested sequence for enabling and configuring basic BGP requirements on
the Nokia 7750 SR.

The above slide illustrates the logic behind exporting all directly connected interfaces. There is one entry, entry
10, and a statement to accept all directly connected interfaces. Once this policy is applied to BGP or a BGP group,
all interfaces are exported as BGP routes.
Remember to use the commit command for the policy modification take effect.
 To display all committed route policies, use the command show router policy.
 To display information for the specified policy, use the command show router policy <policy
name>.
 To display information for all policies, use the command show router policy admin.

The above command displays BGP route information from the RIB-IN, with additional flags provided by the Local-RIB. The
routes received from other peers that have passed through the import policies appear in the Loc-RIB.
 When this command is issued without any parameters, the entire BGP routing table is displayed.
 When this command is issued with an IP prefix/mask or IP address, the best match for the parameter is displayed.
 When this command is issued with a BGP address family, only the routes belonging to that family are displayed.
Locally exported entries (from IGP or directly connected networks) do not appear in the Loc-RIB; they appear in the RIB-OUT.
Therefore, in order to see the locally exported routes on R5 you can use either show router BGP route < > hunt or
show router bgp neighbor < > advertised routes as shown below:
*A:R5# show router bgp neighbor 10.16.10.6 advertised-routes
===============================================================================
BGP Router ID:10.16.10.5 AS:65540 Local AS:65540
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id Label
As-Path
-------------------------------------------------------------------------------
i 10.16.0.0/30 100 None
10.16.10.5 None -
No As-Path
i 10.16.0.20/30 100 None
10.16.10.5 None -
No As-Path
i 10.16.10.5/32 100 None
10.16.10.5 None -
No As-Path
i 192.168.1.8/29 100 None
10.16.10.5 None -
No As-Path
-------------------------------------------------------------------------------
Routes : 4

Showing FIB on the Control Process Module
The above slide illustrates the show router route-table command output, which displays the Nokia 7750
SR FIB.
The following are included in the list:
 the destination prefix
 the next-hop IP address
 the type of route
 the protocol that provided the route to the FIB
 the time since the route was learned or refreshed, the metric of the route (specific to each protocol)
 the assigned preference value.
The Protocol field shows the routing protocol that provided the best route to the RTM. Routes are installed in the
FIB if they are selected by the RTM as used.
Note that for local, that is directly connected entries, the next-hop indicates an interface of the local Nokia 7750
SR without an IP next-hop. Packets for these destinations are not sent to another router; they are sent on the
local broadcast domain to the destination itself. For non-local entries, the next-hop field shows the IP next-hop
address, that is the next router toward the destination.
Note that a router potentially has several next-hops available toward a given destination. If ECMP is configured to
a non-default value, as in this case where ecmp = 2, and more than one route is learned for the same destination,
from the same protocol, and with the same metric value, the router places the configured number of routes into
the FIB. OSPF, IS-IS, and BGP support up to 16 equal-cost paths per destination.
The configure router ecmp < ecmp max-ecmp-routes> command enables ECMP and configures the
number of routes for path sharing. For example, the value 2 means that two equal-cost routes will be used for
cost-sharing. ECMP can only be used for routes learned with the same preference and protocol. When there are
more ECMP routes are available at the best preference than are configured in max-ecmp-routes, the lowest next-
hop IP address algorithm is used to select the number of routes configured in max-ecmp-routes.
The [no] form of the command disables ECMP. If ECMP is disabled and multiple routes are available at the best
preference and equal cost, the route with the lowest next-hop IP address is used.

If only certain prefixes are to be advertised, they will need to be selectively exported. Therefore, a more granular
approach than simply exporting all routes “from direct” (or from a specific IGP protocol) is required.
A prefix list can be used as a further discriminator. With it, only the direct interfaces that match the pre-defined
prefix-list will be allowed.
The exact keyword defines that the specific entry should be interpreted as an exact match of the prefix. The
longer keyword defines a prefix with a longer network/subnet bits than the prefix specified.
The policy in the slide above will advertise directly connected networks to BGP peers, but only those qualified
through prefix-list “Loop_0”. You can see the beginnings of the routing policy that will be used in AS 65540 here.
In labs, Router R5 is a service edge router that is responsible for bringing NLRI (customer networks) into BGP.

The above slide illustrates the route table on the CPM.
If you want to display the FIB on a specific Input Output Module - IOM, use the show router fib
command as shown below. Notice that there are differences between the FIB or Route Table on the CPM (on the
previous slide) and the actual FIB downloaded on the IOM; IOMs actually perform the forwarding of packets
through the system on their respective forwarding silicon). Listed are the destination prefix, the next-hop IP
address, and the protocol that provided the route to the FIB only. Details such as age and metrics are not
required at the dataplane level because the silicon does not require this information to actually switch packets
through the system. It is the job of the CPM hardware and RTM software to keep the IOM FIB tables up to date.
*A:R2# show router fib 1
===============================================================================
FIB Display
===============================================================================
Prefix Protocol
NextHop
-------------------------------------------------------------------------------
10.16.0.0/30 ISIS
10.16.0.9 (toR1)
10.16.0.4/30 LOCAL
10.16.0.4 (toR6)
<output omitted>
10.16.0.9 (toR1)
10.16.10.2/32 LOCAL
10.16.10.2 (system)
10.16.10.5/32 ISIS
10.16.0.5 (toR6)
10.16.0.9 (toR1)
10.16.10.6/32 ISIS
10.16.0.5 (toR6)
192.168.1.8/29 BGP
10.16.0.5 (toR6)

In the case of remote entries in the FIB, the next-hop field indicates the IP next-hop address, that is the next
router toward the destination. The forwarding router must know the egress interface, or the packet cannot be
encapsulated and forwarded.
If the egress interface is not known, a second routing table lookup is performed. This additional lookup is called a
recursive lookup. This time, the lookup is not performed on the packet’s destination IP address, but on the next-
hop address. The next-hop address returned from the original packet lookup is matched to the FIB, based on
longest-match routing. If the lookup of the next-hop address returns an interface, the packet is encapsulated and
forwarded via the specified interface.

The show router bgp next-hop command displays the table of resolved next-hops.
The Nokia 7750 SR uses a two-step process to resolve the directly connected next-hop address associated with a
BGP next-hop.
Every BGP route is advertised with a BGP next-hop. The BGP process determines which egress interface to use to
get to this next-hop. This is the resolved next-hop address.
The network processor on the Nokia 7750 SR is able to resolve the BGP next-hop in real time on the fast path.
The advantage of resolving the next-hop on the fast path is that updates take effect instantaneously. This offers
Nokia a significant performance advantage in next-hop resolution and convergence.

The show router bgp routes command displays the entry for 192.168.1.8/29, with a next-hop of
10.16.10.5. The BGP route’s next-hop address is the system address of the sending peer because that
neighbor** originated the route and the iBGP session was established using system addresses.
The show router route-table command output shows that the next-hop is not a direct interface, because
the route to 10.16.10.5/32 is remote and was learned via IS-IS. This means that the BGP next-hop is a remote or
indirect router. BGP must determine the physical next-hop address before installing the route for
192.168.1.8/29 in the FIB.
BGP does this by performing a FIB lookup on the BGP next-hop. The FIB shows that the next-hop for the route to
10.16.10.5/32 is 10.16.0.5. Because a direct interface was not returned, address 10.16.0.5 must be looked up in
the FIB. The FIB then shows that it is connected to a local physical interface, toR6.
This recursion process resolves the BGP next-hop of 10.16.10.5 to the physical next-hop of 10.16.0.5 (address of
the IGP neighbor on interface toR6).
Therefore, the BGP route 192.168.1.8/29 is installed in the BGP Route Table, with a next-hop of 10.16.10.5. The
route is then offered to the Route Table Manager, which installs 192.168.1.8/29 into the FIB with a next-hop of
10.16.0.5.

The hunt parameter of the show router bgp route <prefix> command allows you to query SR OS to see:
 RIB-IN - BGP updates are received as they appear before policy applied
 RIB-OUT - BGP updates are sent as they will appear after export policy applied.
In the slide above, only RIB-IN is shown.
If there are multiple local next-hops resolved by the IGP (Equal Cost Multipath in effect), the router will load share
packets to a remote BGP neighbor, even though BGP has only one best path.
Note that the actual load sharing performed is flow-based. A specific flow is calculated by performing a hash of
source/destination IP addresses (in case of IP packets) to cause the router to forward packets out of a specific
local interface. With BGP networks, care should be taken to design the IGP so that flows take the correct paths
through the local Autonomous System. The following slides illustrate that this concept.

In order to prefer the route over core links, we can adjust the IGP metric on the interfaces between routers R1
and R2. The slide shows the configuration on router R1,; similar configurations are required on router R2. As a
result of that configuration, router R2 will prefer the route via router R1 to reach router R5 and similarly router
R1 will prefer the route via router R2 to reach router R6 as shown on the next slide.

The above slide shows that BGP selects the route via router R1 for prefix 192.168.1.8/29 on router R5. The
routing selection criteria used here the lowest IGP metric to next-hop.

Because a local address is not specified, BGP uses the default address, which is the egress interface for eBGP,
as the source IP address of the session to reach each neighbor. If a consistent address is desired, it can be
Configured at the group level.
Notice that routers R1, R3, and R4 are also configured with a similar configuration to the one shown for router
R2 above.
The loop-detect discard-route command discards routes that are received from a peer with the same AS
number as the router. This option prevents routes that have been looped back to the router from being
added to the RIB and consuming memory. When this option is changed, the change is not active for an
established peer until the connection is re-established. Loop detection is covered in more detail in the
following slides.
If the loop-detect discard-route was not configured, then router R2 would have the following routes in the RIB:
*A:R2# show router bgp routes

===============================================================================
===============================================================================
BGP IPv4 Routes
===============================================================================
Nexthop (Router) Path-Id Label
As-Path
-------------------------------------------------------------------------------
u*>i 192.168.1.8/29 100 None
10.16.10.5 None -
No As-Path
i 192.168.1.8/29 None None
10.0.4.1 None -
65550 65540
-------------------------------------------------------------------------------
Routes : 2

The above slide shows that the loopback interfaces on router R5 are advertised to router R4 in AS 65550 via
eBGP. Notice that a local preference of “None” means that this attribute has not been received from the eBGP
peer router (R2), as expected, since the local preference is not propagated in eBGP updates. However, for the
route received from the iBGP peer (R3) the local preference is set to the default value of 100.
Since the origin, MED and AS paths are all equal, the router prefers the eBGP peer over the iBGP peer.
Recall the BGP route selection criteria. If the entry is valid and loop-free and the next-hop is reachable, prefer
the route with:
1. Higher Local Preference
2. Higher sum of aigp metric and cost, if aigp metric applies
3. Shorter AS path
4. Lower origin code
5. Lower MED
6. Route that was learned from an eBGP peer before one learned from an iBGP peer
7. Lower IGP cost to the next-hop
8. Lower next hop type
9. Lower BGP router ID
10.Shorter cluster list
11.Lower peer IP address

The flowchart above is a basic troubleshooting guide to be used for solving BGP connectivity issues.

By default, the Nokia 7750 SR accepts received routes with AS-path loops. These routes are placed in the RIB-IN
and flagged as “Invalid” and “AS-Loop.”
Context: config>router>bgp
config>router>bgp>group
config>router>bgp>group>neighbor
Syntax: [no] loop-detect {drop-peer | discard-route | ignore-loop | off}
Description: This command configures how the BGP peer session handles loop detection in the AS path.
The configuration parameter can be set at three levels:
• global level (applies to all peers)
• group level (applies to all peers in peer-group)
• neighbor level (only applies to specified peer).
The most specific value is used. Note that dynamic configuration changes of loop-detect are
not recognized.
The [no] form of the command at the global level reverts to the default, which is loop-detect ignore-loop.
The [no] form of the command at the group level reverts to the value defined at the global level.
The [no] form of the command at the neighbor level reverts to the value defined at the group level.
Default: loop-detect ignore-loop
Parameters: drop-peer — Sends a notification message to the remote peer and drops the session
discard-route — Discards routes that are received from a peer with the same AS number as the
router itself. This option prevents routes that have been looped back to the router from being
added to the RIB and consuming memory. When this option is changed, the change is not active
for an established peer until the connection is reestablished.
ignore-loop — Ignores routes with loops in the AS path, but maintains peering.
off — Disables loop detection.

Context: config>router
Syntax: [no] aggregate ip-prefix/mask [summary-only] [as-set] [aggregator as-

number:ip-address]
Description: This command creates an aggregate route. It is used to group a number of routes with common prefixes into a
single entry in the routing table. This reduces the number of routes advertised by the router and the number of
routes in the routing tables of downstream routers.
Both the original components and the aggregated route (source-protocol aggregate) are offered
to the RTM. Subsequent policies can be configured to assign protocol-specific (BGP, IS-IS, or OSPF)
characteristics, such as the route type or OSPF tag, to aggregate routes.
Multiple entries with the same prefix, but a different mask, can be configured. For example, routes are
aggregated to the longest mask. If one aggregate is configured as 10.0.0.0/16 and another as 10.0.0.0/24, route
10.0.128.0/17 would be aggregated into 10.0.0.0/16 and route 10.0.0.128/25 would be aggregated into
10.0.0.0/24. If multiple entries are made with the same prefix and mask, the previous entry is overwritten.
Default: No aggregate routes are defined.
Parameters: ip-prefix — The destination address of the aggregate route, in dotted-decimal notation.
mask — The mask associated with the network address, length range 0 to 32.
summary-only — This optional parameter suppresses the advertisement of more specific
component routes for the aggregate. To remove the summary-only option, enter the aggregate command
without the summary-only parameter.
as-set — This optional parameter is only applicable to BGP. It creates an aggregate in which the path that is
advertised for the route is an AS_SET, which consists of all elements contained in all paths that are being
summarized. Use this feature carefully. Aggregating several paths can result in the constant withdrawal and
insertion of AS paths as associated component routes of the aggregate that are experiencing changes.
aggregator as-number:ip-address — This optional parameter specifies the BGP aggregator path attribute
for the aggregate route. When configuring the aggregator, enter a 2-octet AS number to form
the aggregate route, followed by the IP address of the BGP system that created the aggregate route.
Note that RFC 6472, Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP, recommends operators not to use
aggregate routes and AS_SETs to simplify the design and implementation of BGP and to make the semantics of the originator of a
route more clear. Refer to the RFC for more detail.

Syntax: [no] authentication-key [authentication-key | hash-key] [hash | hash2]
Description: This command configures the BGP authentication key. Authentication is performed before setting
up the BGP session. It is done between neighboring routers by verifying a password.
Authentication uses the MD5 message-based digest. The authentication key can be any combination of ASCII
characters, up to 255 characters.
The [no] form of the command reverts to the default value.
Default: By default, MD5 authentication is disabled.
Parameters: authentication-key — The authentication key; is any combination of ASCII characters up to 255
characters (unencrypted). If spaces are used in the string, the entire string is enclosed in double
quotation marks.
hash-key — The hash key; is any combination of ASCII characters up to 342 characters
(encrypted). If spaces are used in the string, the entire string is enclosed in double quotation
marks. This is useful when a user must configure the parameter, but for security purposes, the
actual unencrypted key value is not provided.
hash — Specifies that the key is entered in an encrypted form. If the hash parameter is not
used, the key is assumed to be in a non-encrypted, clear-text form. For security, all keys stored
in the configuration file are encrypted, with the hash parameter specified.
hash2 — Specifies that the key is entered in a more complex encrypted form. If the hash2
parameter is not used, the less-encrypted hash form is assumed.

Syntax: [no] triggered-policy
Description: This command triggers route policy re-evaluation. By default, when a change is made to a
policy in the config router policy options context and is then committed, it is
effective immediately. However, there may be circumstances in which the changes should or
must be delayed. For example, if a policy change that would affect every BGP peer on the 7750
SR is implemented, the consequences could be dramatic. It is more effective to control changes on a peer-by-
peer basis.
If the triggered-policy command is enabled, a given peer is established, and you want that
peer to remain up for a change to a route policy to take effect, you must use a clear
command with the soft or soft-inbound option. In other words, when triggered-policy is
enabled, a routing policy change or policy-assignment change in the protocol will not take
effect until the protocol is reset, or a clear command is issued to re-evaluate route policies,
for example, clear router bgp neighbor x.x.x.x soft. This keeps the peer up, and
the change made to a route policy is applied only to that peer or group of peers.
Default: Non-dynamic route policy is disabled.

Context: clear>router>bgp
Syntax: neighbor {ip-addr | as as-number | external | all} [soft | soft-inbound

| statistics]
Description: This command resets the specified BGP peer or peers.

NOTE: This can cause existing BGP connections to be shut down and restarted
Parameters: ip-addr — Resets the BGP neighbor with the specified IP address
as as-number — Resets all BGP neighbors with the specified peer AS number
external — Resets all eBGP neighbors
all — Resets all BGP neighbors
soft — The specified BGP neighbors reevaluate all routes in the Local-RIB against the
configured export policies.
soft-inbound — The specified BGP neighbors reevaluate all routes in the RIB-In against the
configured import policies.
statistics — The BGP neighbor statistics
Syntax: protocol
Context: clear>router>bgp
Description: NOTE: Resets the entire BGP protocol

The clear router bgp command offers several options that reduce the service impact of issuing the clear
command.
 soft — The specified BGP neighbors re-evaluate all routes in the Local-RIB against the configured export
policies.
 soft-inbound — The specified BGP neighbors re-evaluate all routes in the RIB-In against the configured
import policies.
The actual neighbor and BGP sessions are not affected.

Module 2 – 58
© 2016 Nokia
Module 2 – 59
© 2016 Nokia
Module 2 – 60
© 2016 Nokia
With the IANA's exhaustion on 03 Feb 2011, the exhaustion of the RIRs APNIC on 15 April 2011, and RIPE NCC on
14 September 2012, some parts of the world have already exhausted their IPv4 allocations, and the remaining
RIRs are expected to deplete their pools within a few years.
IP version 6 (IPv6) is a new version of the Internet Protocol, designed to be the successor to IP version 4 (IPv4).
Deploying IPv6 is the solution to the IPv4 address shortage. IPv6 is endorsed and implemented by all Internet
technical standards bodies and network equipment vendors. It encompasses many design improvements,
including the replacement of the 32-bit IPv4 address format with a 128-bit address for a capacity of about
3.4×1038 addresses. IPv6 has been actively deployed since June 2006.

IPv6 is a hierarchical 128-bit addressing scheme that consists of eight fields, each field comprised of 16 bits. An
IPv6 address is written as a hexadecimal value (0-F) in groups of four, separated by colons.
There are three types of IPv6 addresses: Unicast, Anycast, and Multicast.
 A Unicast address identifies a single interface. A packet destined for a Unicast address is delivered to the
interface identified by that Unicast address.
 An Anycast address identifies a set of interfaces. A packet destined for an Anycast address is delivered to
the nearest interface identified by that Anycast address.
 A Multicast address identifies a set of interfaces. A packet destined for a Multicast address is delivered to
all the interfaces identified by that Multicast address. There are no broadcast addresses in IPv6.
Since the IPv6 address is 128 bits, there are a number of conventions used to shorten them as much as possible.
1.Addresses are written in groups of four hex digits, separated by a single colon. For example,
2001:0db8:0000:0000:0021:0000:4ab9:0300.
2.One or more groups of zeroes can be replaced by two colons. The number above becomes:
2001:0db8::0021:0000: 4ab9:0300.
3.Only one group of zeroes can be replaced with double colons. Otherwise it would not possible to tell where the
zeroes are located. However, leading zeroes in a group can also be omitted. The address above becomes
2001:db8::21:0: 4ab9:300.

Regular IPv6 unicast addressing uses a fixed structure in which 64 bits are defined as the routing prefix and 64
bits are defined as the interface identifier. For a globally-routed address, 48 bits of the routing prefix are used as
the global routing prefix and 16 bits are the local routing prefix, or subnet.
Globally-routed IPv6 address are allocated the address space 2000::/3. An ISP is typically allocated a network
assignment of /32 or larger. ( larger assignment means the prefix will be smaller, such as /31 or /30, and hence
will have a larger network range). An individual enterprise typically receives an assignment of /48 or larger. Since
an assignment of /48 has 16 bits available for the local subnet, this provides 65,536 individual subnets.
The interface ID portion of the address is assigned locally, but can be automatically derived from the 48 bit MAC
address. It may also be assigned by a DHCPv6 server, through an auto-discovery mechanism, or assigned
manually.
To derive an IPv6 interface ID from the MAC address, create a modified EUI-64 (Extended Unique Identifier-64).
To do this, flip the seventh most significant bit of the OUI (Organizationally Unique Identifier) and insert the hex
string ff:fe between the 3 bytes of the OUI and the 3 bytes of the NIC-specific component.
For example, assume an organization is assigned the prefix 2001:db8/48. The organization has 16 bits for
subnetting. Perhaps they have 30 locations and decide to assign the first 8 bits based on the location, and the
next 8 based on the subnet at that location. Subnet 10 at location 3 gives a subnet value of 030a, for a routing
prefix of 2001:db8:0:30a::/64. With the modified EUI-64 assignment, the host with MAC address
00:16:4d:13:5c:ae has an interface ID of 0216:4dff:fe13:5cae. The resulting IPv6 address is
2001:db8::30a:216:4dff:fe13:5cae.

There are a number of other unicast addresses in IPv6 that have special meaning.
 ::/128 is the unspecified host address (all zeroes). This address may be used until an address is assigned
to the device.
 ::1/128 is the loopback address (all zeroes except the last bit). This corresponds to the address 127.0.0.1
in IPv4.
 ::/0 is the default unicast route (the same as 0.0.0.0/0 in IPv4).
 fe80::/64 is the prefix for the link-local address (binary 1111111010 followed by 54 zeroes). IPv6
requires that every IPv6 interface have a link-local address. This is not a valid routing prefix and is only
used for communications on the local link.
Typically, the link-local interface ID is assigned the same value as the global interface ID, which means using the
modified EUI-64 address. For the global address 2001:db8:0:30a:216:4dff:fe13:5cae, the link-local address
would be fe80::216:4dff:fe13:5cae.
 fc00::/7 defines a range known as Unique Local Addresses (ULA, RFC 4193). These are addresses
intended to be used on a private network and not routed on the global Internet (similar to private
addresses in IPv4). The ULA range is split into two ranges, depending on the value of the eighth bit.
 fd00::/8 is intended to be used as a 48-bit prefix with the remaining 40 bits self-assigned using a
pseudo-random generator. This means that even though addresses are self-assigned, the probability of
two networks sharing the same prefix is very small. This is intended to make it easier to interconnect
privately-addressed networks.
 fc00::/8 addresses are intended to have the remaining 40 bits allocated by a registrar to provide globally
unique private addresses, although the mechanism is not yet defined (draft-hain-ipv6-ulac-02) at the
time of writing.
 ::ffff:0:0/96 is a prefix for IPv4-mapped IPv6 addresses. This provides an IPv6 address space that can be
used by native IPv4 applications. It is acceptable to use the standard IPv4 notation for the low order 32
bits of the address. For example 192.168.0.1 is mapped to the IPv6 address ::ffff:0:0:192.168.0.1.

Configuring IPv6 interfaces and routing for IPv6 is very similar to configuring and routing IPv4. The most obvious
difference is the use of IPv6 addresses. IPv6 and IPv4 can be configured in parallel on the same network.
To use IPv6 on the Nokia 7750 SR, you must first enable chassis mode “c” or higher. IPv6 is only supported on
IOM2s or newer. As soon as we enable IPv6 on the interface, a link-local address is automatically assigned based
on the modified EUI-64 address. If it is not necessary to route to the interfaces, we do not need to assign them
global routing addresses ; we can simply use the link-local addresses.

The interfaces have already been configured with IPv4 addresses. You can see that the link-local address was
formed from the MAC address of the interfaces. The router is running both IPv4 and IPv6 and the interfaces are
up for both protocols.
IPv6 defines state for prefixes. They can be tentative, preferred, duplicated or deprecated. An address should be
preferred, which means that it can be used without restrictions. An IPv6 interface performs duplicate address
detection and the state of the prefix is Tentative until the address has been confirmed as unique.

Module 2 – 67
© 2016 Nokia
The BGP protocol in particular, and the path vector routing protocols in general, are mostly independent of the
particular Address Family for which the protocol is being used. BGP uses Multiprotocol Extensions to support IPv6.
The same procedures used for IPv4 prefixes can be applied to IPv6 prefixes as well. However, there are some
specific information that are specific to IPv4, these are the NLRI in the update message, next-hop path attribute
in the update message, and the BGP identifier in the OPEN message and the AGGREGATOR attribute.

To support Multiprotocol BGP Extensions, two new non-transitive attributes are introduced: Multiprotocol
Reachable NLRI (MP_REACH_NLRI) and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). MP_REACH_NLRI
carries the set of reachable destinations, as well as the next-hop information to be used for these destinations.
The MP_UNREACH_NLRI attribute carries the set of unreachable destinations.
Multiprotocol BGP extensions support the advertisement of IPv6 prefixes over the BGP sessions established
between two BGP speakers using either the IPv4 or the IPv6 address. Similar to IPv4 networks, IPv6 networks
should also be injected into BGP for a BGP speaker to advertise the network to its peers.

BGP runs on top of TCP, which is the same in IPv4 and IPv6. This means that the underlying network layer protocol
can be either IPv4 or IPv6 without requiring any changes to BGP.
The BGP Open message contains a field for the router ID. This field is 4 bytes long. There is no particular
requirement that this address be reachable or even an actual IPv4 address, only that it be a unique 32-bit
number.
The router generates the router ID automatically based on IPv4 addressing configured on the router; the address
configured on the loopback interface; or, if there is no loopback, the highest IPv4 address on any of the
interfaces.
In a pure IPv6 deployment, no IPv4 addressing is configured. This provides nothing for the router to use to build a
router ID. In this case, the router ID must be manually configured under the BGP process. If there is no router ID,
BGP sessions do not form.
The other component of BGP that requires a unique 4-byte number is the cluster ID, used on route reflectors.
The cluster ID is carried with the NLRI in the BGP UPDATE messages. If a router ID is configured, this value is used
for the cluster ID. The cluster ID can also be configured independent of the router ID. The originator ID attribute
is also a 4-byte value that is used with route reflection. The manual configuration of a 4-byte router ID provides
the value for the originator ID.
IPv6 needs to be enabled for the IGP used to support BGP for IPv6.
When configuring an eBGP session, link local or global IPv6 address can be used. When link local address is used,
next-hop-self is not required because the BGP speaker that advertises a route to its internal peer automatically
changes the next hop address from link local to the global address. When the global address is used for
configuring the eBGP session, then next-hop-self is required similar to IPv4 configuration.

The above slide shows the configuration of the IPv6 iBGP on router R1 of AS 65540. Routers R2, R5, and R6 also
have a similar configuration to establish the iBGP mesh in AS 65540.
Notice that we still have the IPv4 configuration, therefore we do not need to configure the BGP router ID. The
router generates the router ID automatically based on IPv4 addressing configured on the router.
Note that IPv6 needs to be enabled for the IGP within each AS. In this case IPv6 for ISIS is enabled.
Notice also that next-hop-self is not required when link local addresses are used for the eBGP sessions.

A policy is configured on router R3 to export the loop address of 2001:DB8:A:301::1/128 to BGP

The above slide shows the configuration of the IPv6 eBGP on router R1 using the global address. Routers R2, R3,
and R4 also have a similar configuration to establish the eBGP sessions between AS 65540 and AS 6550.
In this case, next-hop-self is required on the iBGP configuration of routers R1 and R2

*A:R1# show router bgp routes 2001:DB8:A:301::1/128 detail
===============================================================================
===============================================================================
BGP IPv6 Routes
===============================================================================
Original Attributes
Network : 2001:DB8:A:301::1/128
Nexthop : 2001:DB8:13::3
Path Id : None
From : 2001:DB8:13::3
Res. Nexthop : 2001:DB8:13::3
Local Pref. : n/a Interface Name : toR3
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : None
<output omitted>
Flags : Used Valid Best IGP
Route Source : External
AS-Path : 65550
Modified Attributes
Network : 2001:DB8:A:301::1/128
Nexthop : 2001:DB8:13::3
Path Id : None
From : 2001:DB8:13::3
Res. Nexthop : 2001:DB8:13::3
Local Pref. : None Interface Name : toR3
<output omitted>
AS-Path : 65550
-------------------------------------------------------------------------------
Routes : 1

The above slide shows the configuration of the IPv6 eBGP session on router R1 using link local address shown
below. Routers R2, R3, and R4 also have a similar configuration to establish the eBGP sessions between AS 65540
and AS 6550.
A:R1# show router interface "toSRA_S14_R3"

===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name Adm Opr(v4/v6) Mode Port/SapId
IP-Address PfxState
-------------------------------------------------------------------------------
toR3 Up Up/Up Network 1/1/3
10.0.2.1/24 n/a
2001:DB8:13::1/48 PREFERRED
FE80::622C:FFFF:FE00:0/64 PREFERRED
-------------------------------------------------------------------------------
Notice that –interface is required when configuring the BGP neighbor using link local address
In this case next-hop-self is not required on iBGP sessions of routers R1 and R2.

Notice that the next hop is now the link local address instead of the global
address. R1 will change the next hop to its global address when advertising the
route to its iBGP peers as shown on the next slide.

When R1 advertises the route to its iBGP peers, it changes the next hop address to
its configured global address.

Notice that the next-hop address is the IPv6 system address, which is reachable via the configured IGP as shown
below:
A:R5# show router route-table 2001:DB8:A:100::1

===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
-------------------------------------------------------------------------------
2001:DB8:A:100::1/128 Remote ISIS 03d01h36m 15
FE80::622C:FFFF:FE00:0-"toR1" 100
-------------------------------------------------------------------------------
No. of Routes: 1
Flags: L = LFA nexthop available B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================

Module 2 – 79
© 2016 Nokia
1. How are non-BGP Routes brought into BGP?
Non-BGP routes are brought into BGP by exporting used routes from the routing table managed by the RTM.
2. What commands are used to display the RIB-IN BGP routes?

show router bgp routes, show router bgp neigbor <> received routes, or show router bgp <> hunt
3. What does BGP send from its Loc-RIB to the BGP export policy process?
BGP sends its best used routes as input to the export policy process (if any). If no export policy exists, the
routes are simply installed into RIB-OUT and sent to both internal and external peers.
4. Assuming a single prefix is the longest match and has the highest local preference, what must also be true for
the route to be installed into Loc-RIB?
The route must be valid and must not have any AS-Path loops present.
5. What are the top 5 tie-breaker selection criteria?

Prefer the router with the highest preference; then prefer the shortest AS-PATH; then prefer the route with
lowest origin code (i<e); then prefer the route with the lowest MED; then prefer eBGP derived routes over
iBGP derived routes.
6. What guarantees the most traffic control with BGP? What is the danger associated with this activity?
Announcing routes with longer prefix sizes. This is not necessarily the best method because it increases the
BGP table size and some ISPs will not accept longer prefixes.

7. What tools can be used to guarantee internal traffic flows?
You can gain maximum control of traffic flows internal to the AS by adjusting IGP metrics and with traffic
engineering.
8. If no export policy is specified, which routes are sent to external BGP peers?
BGP routes are advertised; IGP routes are not advertised.
9. What does the RTM send to the Routing Table and Forwarding Information Base (FIB) on the CPM?
The RTM sends its best used routes (from BGP and IGP) to the routing table and FIB.
10. What are the three databases used by BGP?

The three BGP databases used are ADJ-RIB-IN, ADJ-RIB-OUT, and LOC-RIB. Import policy is performed on
ADJ-RIB-IN and export policy is performed on ADJ-RIB-OUT. BGP’s best learned routes reside in LOC-RIB
and, if used by the routing table manager (RTM), these routes are sent to ADJ-RIB-OUT.
11. Describe the three default behaviors of BGP.

By default, BGP accepts all routes into the RTM, announces all used BGP routes, and does not learn any IGP
learned routes.
12. Where is the FIB distributed on the Service Router platform, and which command allows you to examine
the FIB?
The FIB is distributed by the CPM to each of the installed IOMs. The contents of the distributed FIBs can be
examined with the show router fib <slot> command.

13. In which two instances is ECMP used?
Equal Cost Multipath is used for routes from the same protocol with the same metric OR if a remote next-
hop for a BGP prefix is resolved to have multiple paths by the IGP.
14. Which variant of the show router bgp <prefix> command is used to display the contents of the
various BGP databases and the results of the IGP lookup to the next-hop?
The show router bgp route <prefix> hunt command enables the examination of BGP databases
and the results of an IGP next-hop resolution.
15. When does route table lookup recursion occur?

Recursion occurs when the directly connected next-hop interface is unknown; extra routing table lookups
are performed to resolve the next-hop interface.
16. How does SR OS define 32-bit (4-byte) AS numbers?

SR OS CLI specifies 32-bit ASN in ASPLAIN notation.

17. How many iBGP sessions are required to build a full iBGP mesh in a six-router network?
# of sessions = (N * (N-1)) / 2 = (6 * (5)) / 2 = 15 sessions
18. What are some of the main configuration tasks associated with bringing local networks into BGP?
Prefix-lists associated with the AS’s address plan are configured, then a policy that accepts directly
connected or static routes is created and applied to BGP, using the export command.
19. Why is the longer keyword used with prefix-lists suitable for the AS’s CIDR space?
Because the longer keyword includes all subnets possible for any given CIDR prefix. Therefore, if
the AS/ISP assigns smaller address spaces to specific customers out of that CIDR prefix, the CIDR
prefix-lists will match any of these assignments.
20. What does the triggered-policy command accomplish?

Usually, SR OS will implement policy-options after the commit command is entered. Specifying the
global router command triggered-policy means that the BGP peers must be explicitly cleared for
the policy to take effect. This is a final safety mechanism that helps to ensure that the policy will
not be in effect until a time chosen by the operator.
21. A 32 bit router ID is required for IPv6 deployment, True or False?
True
21. Next-hop-self command is not required when eBGP sessions are configured using link local addresses. True or
False?
True

Module 2 – 84
© 2016 Nokia
Module 3 – 1
© 2016 Nokia
Module 3 – 2
© 2016 Nokia
Module 3 – 3
© 2016 Nokia
Module 3 – 4
© 2016 Nokia
Routing Policy is used to:
 Communicate regional or customer related communities of interest to the rest of the AS.
 Protect the local AS, as well as other external ASes, from bogus and unexpected NLRI from customers and other
peers.
 Protect external peer or transit networks from instability inside the AS.
 Optimize ingress and egress traffic patterns to best serve the constituent users of the AS (business, government,
consumer, and so on).
 Maintain efficient use of internal network resources and related engineering activities.
 Support and augment network operations, IP coordination and engineering (SWIP, DNS, and so on), and customer
support related activities of the AS. For example, consider the previous slide. Does it make sense for the regions to
have their own address space? Would this help or hinder customer support?

In this simple view, four regions of interest have been identified. The regions can correspond to countries, states, cities,
or even areas in a single city. They can also correspond to business services, such as a region for consumer networking
(DSL, cable Internet), one for mobile Internet services, and another for Enterprise.
 West Region – mostly associated with edge router R4 and core router R1; serves a larger Enterprise presence.
 Central Region – smaller region with edge router R5 and core router R3.
 East Region – larger region servicing DSL and GPON customers, in addition to Enterprises. Associated with edge
router R6 and core router R2.
 AS 65540’s Core – High speed links between routers R1, R2 and R3. Notice that these routers have no directly-
connected customer networks.
Knowing this, you can form policies that best serve each region.
Much of the routing policy formed will depend on this basic information. The BGP application will allow you to classify
each prefix or customer or region, and communicate this information across the entire AS. No other routing protocol
allows for this sort of arbitrary and flexible policy specification. Most ISPs use a best practice that tries to make traffic
flow into and out of a region without traversing other regions; for example, the ISP will create policy on router R1 that
will attempt to make the upstream peers send traffic to the West region, and perhaps the Central region, and may
additionally try to influence the upstream AS to send traffic associated with the East region to another entry point, like
router R2.

Address Planning
 AS 65540 should use its IGP to route internal networks only.
 Keep the address spaces separate. Assign prefixes and networks so that they are easily known as internal networks
to the rest of the AS. That is, do not mix customer assigned networks with the internal networks used to perform
internal routing by the IGP.
 Customer or service assigned address space go into BGP and become BGP NLRI for the AS.
 In most cases, the networks associated with the external links of eBGP peers are not exported into BGP and,
therefore, do not become BGP NLRI. This is particularly true if you use next-hop-self.
 Use the next-hop-self command to force BGP to use the resources provided by the IGP. Essentially, you are
taking advantage of any and all IGP design features by having internal BGP peers use the IGP to route between
system addresses exclusively.
 A sound address plan, with defined address space for internal and external networks, and a good aggregation plan,
help to make configuration, troubleshooting, and administration easier.

Between the two lists above, and possibly others, it becomes easier for the AS to implement consistent policy around
the entire AS, a policy that either accepts or rejects NLRI from various sources. These sources can be from other BGP
peers or from directly-connected or static routes associated with the business services offered by the AS. Standard
policies in the AS will always pass any prefixes brought into BGP as NLRI through a qualifying prefix-list. Operations staff
bringing up a transit customer can create a static route to the customer, but if the prefix was not pre-determined as
valid in an appropriate prefix-list, the prefix information would not make it into BGP.
Sound address planning, combined with features such as prefix-lists and unicast Reverse Path Forwarding (uRPF),
prevents much miscreant activity on the Internet. uRPF is a data path feature that will not allow a packet to be received
if the source IP of the packet is not consistent with the routing table. ISPs typically implement both prefix-lists and
uRPF.
Bogus networks are sometimes referred to as Bogons, which actually refers to Martians and un-allocated, un-assigned
address space. Most ISPs will maintain lists of standard prefixes that would never be allowed into or out of the AS,
including Martians: RFC 1918 and RFC 5735 special-use addresses. Other lists that have been identified in the Internet
community as associated with miscreant activity typically use address space that has not been assigned yet. There is a
multi-hop eBGP peering service available that allows an ISP to maintain an up-to-date list of bogus BGP prefixes that
should always be prevented from entering or leaving an AS. See http://www.team-cymru.org/Services/Bogons/ for more
information on bogons.

The prefixes listed above are not allowed by the routing protocols or the RTM, nor are they populated in the forwarding
table. By default, BGP also ignores any path with an AS-Path loop, although it is not filtered out, (that is, it will appear in
RIB-In as “invalid” so will not be offered to Local RIB).
Any other filter must be explicitly created and applied.

Optimal Routing and Redundancy
Determine the core links and adjust metrics so that the IGP prefers to route packets crossing the AS through the core
(and not edge-to-edge).
Once routing is optimized, you can make BGP automatically set the egress MED values to each iBGP prefix’s IGP cost
(MED-OUT command). As a result, prefixes announced and originated from one region will have lower MED values than
the same prefixes announced by other regions in the same AS. For example, if router R4 originates a prefix and
advertises it to both routers R1 and R2, and the MED-OUT feature is enabled, router R1’s announcement to its external
peer in AS 1239 will contain a lower MED value than the same prefix announced by router R2. All other factors being
equal, AS 1239 will choose router R1 as an entry point to AS 65540 for router R4’s prefixes, if MEDs are used as the tie
breaker. This is an example of geo-routing policy.

Implementing BGP successfully requires careful planning. One of the critical factors is the optimization of the IGP. BGP
relies on IGP, so any instabilities or misconfigurations in the IGP environment may translate into a larger problem in BGP.
As much as possible, the IGP infrastructure should be stable. If, for instance, an IGP network flaps, a neighbor or
neighbors are lost, or a router fails, the IGP must detect the failure and generate an update to its peers for route
recalculation to take place on all affected devices. If instability is restricted to the IGP, the impact is contained within the
AS.

Module 3 – 12
© 2016 Nokia
Module 3 – 13
© 2016 Nokia
Policy is useful for many reasons. They include:
 Assessing the financial cost of sending traffic over links or across some ASes
 Addressing political relationships, such as preferred peers or ISP relationships
 Implementing SLAs offered by an ISP
 Addressing security concerns
 Balancing traffic on an inbound or outbound level, and so on.

Policy implementation requires a careful plan. You must consider and decide what you are going to do and how you are
going to do it. Many tools are available for implementing policies, and more than one configuration solution is often
possible; therefore, try to be as familiar as possible with the choice of tools so that you use the best one for the task.
Prior to implementing any policy, however, it is important to understand the policy definition and what it means. First
consider the language of the policy and, whether there are any points that require clarification; do this before
attempting to design or implement the new policy.
Then, ensure that you understand the current conditions and logic before attempting to change a particular behavior.
For example, before you use a policy to modify BGP route selection so that it chooses a different route as best, it is
important to recognize why the current route is perceived as best.
Also, identify whether it is the control plane or data plane that is an issue. Recall that data plane traffic is generally
modified by control plane manipulation, but that they are inverse to each other. Therefore, modifying outbound routing
updates affects inbound traffic flow, and modifying inbound routing updates affects outbound traffic flow.
Planning also involves carefully considering the impact of the new policy on existing traffic flows. Often, the new policy
must be integrated into the existing configuration, so scalability of policy design becomes critical. Ensure that you
understand the existing traffic flow and that you test the new configuration thoroughly before committing any changes.

Border activities can apply to transit customers that are running BGP with the AS.
IP Service Edge activities:

 Safely bring NLRI into BGP from trusted sources in the IP access layer.
 Set attributes (communities, origin, and so on) that are relevant to the region or customer.
 Advertise appropriate networks to the access layer (might not need full routes).
Core activities:
 From a BGP standpoint, minimal activity required.
 Core needs to move traffic according to IGP and Traffic Engineering design.
Border activities:
 Safely advertise and receive appropriate networks from/to peers.
 Analyze path attributes set by the service edges to implement export policies.
 Implement policies that adhere to business and traffic flow goals for the AS.

IPv4 and MPLS traffic data flows through a router. The flow analysis tool, cflowd, enables traffic sampling and analysis by
ISPs and allows network engineers to support capacity planning, trends analysis, and characterization of workloads in a
network service provider environment. Refer to the Nokia SR OS router configuration guide for further details.
Most of the export policy is based on known entities and objects that the AS itself controls; therefore, the AS is able to
exert more precise control on how upstream providers and other BGP peers treat both its own and the customer
networks.
Some customers will have very specific requirements regarding how CIDR and customer-owned networks are advertised
to the rest of the Internet. Service level agreements may also point out service up-time requirements, maximum
latencies, and other performance-related service levels, including response time by operations staff.
NOTE: Some enterprises are so sophisticated that they can measure network performance based on other, seemingly
unrelated, business activities, such as credit card transaction rates and time sensitive financial trading applications. ISPs
should expect customer support calls when these types of activities are impeded or slowed down.

Six main export policy options (in order of effectiveness):
1. Prevent bogus (Bogon), miscreant, or unwanted NLRI from leaving the AS.
2. Send longer prefixes at certain entry points to the AS
• Will be noticed by the rest of the Internet and your peers
• Some ISPs have minimum prefix length import policies
3. Send aggregates that summarize the AS’s address space
• Then, for the AS’s own address space and its customers’ prefixes, advertise these prefixes with certain
attribute sets
4. Take advantage of the peer or transit provider’s own import polices that will set a Local-Preference, or other types
of policy, based on the sending AS’s use of predefined communities with certain prefixes. The receiving AS
predefines these communities.
5. Use AS-Path prepending, (lengthen AS-Path to influence path; this even works across upstream AS boundaries,
unlike a Local-Preference policy, which only works in 1 AS).
6. Send MEDs to influence ingress traffic from your peers.
This list is not exhaustive, but is typical for many ISPs.
Sending longer prefixes is one way to guarantee that certain traffic will always take a specific entry point into the AS.
However, most larger Tier 1s and Tier 2s will also impose minimum prefix length policies. The Internet community is
usually quick to notice an ISP that tries to advertise very small prefixes (smaller than /24, for example). Recall that many
legacy /24 prefixes were assigned to Enterprises and organizations before the introduction of CIDR or SWIP, used by the
RIRs. Basically, this means that there are still quite a few /24 length prefixes in the Internet table, but these should
mostly be legacy prefixes. Much of the newer prefixes that were assigned by ISPs (using SWIP processes described in RFC
2050) are part of larger aggregates and, therefore, are harder (in theory) to break up; these would draw more attention
from the Internet community if they were broken up.

Generally, incoming policy is more difficult to implement because some of the major drivers of the policies are not
directly owned or operated by the AS itself. However, accurate information can be accessed with the appropriate tools,
such as cflowd, which will make choosing the appropriate policies easier.
IPv4 and MPLS traffic data flows through a router. Cflowd enables traffic sampling and analysis by ISPs and allows
network engineers to support capacity planning, trends analysis, and characterization of workloads in a network service
provider environment.

Four main import policy options (in order of effectiveness):
1. Prevent bogus or miscreant NLRI from entering the AS.
2. Filter NLRI based on AS-Path and/or prefix-lists and/or prefix-length.
• Accepting prefixes at certain locations and not at others is a major way of influencing egress traffic flows.
3. Allow Local-Preference policy or set a Local-Preference.
4. Reset MEDs to zero or some other value. (Do not consider MED from the peer, only Local-Preference or some
other tie breaker is considered.
This list is not exhaustive, but is typical for many ISPs.

There is also a “to” construct that can be used to specify the receiving protocol. For global BGP used for routing IPv4,
this is seldom used.

Nokia’s policy implementation allows there to be a match to one or more of the above items. The “from” criteria
configure policy matches based on the source of the route or on the protocol from which it is received.
Notice that if more than one item is specified, a logical AND is used.

The “to” criteria configure policy matches based on the destination of the route or the protocol to which it is
advertised.

The “action” criterion configures the effect of a successful policy match.

With Nokia’s enhanced policy logic, route policies have the ability to match a given route policy entry and then continue
to search for other matches, in either the same route policy or the next route policy.
Also, if no default action is specified (in any given policy statement), the next policy statement specified in the export or
import command will also be processed.
If there are no further policy statements, and no default action is specified, the default BGP behavior ― to either accept
all BGP routes into the RTM for consideration, according to the route-selection criteria or announce all used BGP learned
routes to other BGP peers ― is used.

Policy Evaluation
1. If a given route does not fully match the criteria of a policy entry, the defined actions for that entry are not applied,
and the policy evaluation proceeds to the next entry in the current policy statement, or to the next defined policy
statement.
2. When a given route fully matches the match criteria of a policy entry:
 If reject is specified, the given route is not modified, policy evaluation is ended, and the routing protocol is
signaled to not accept the route on import or to block the route from being announced on export.
 If accept is specified, the given route is modified, based on the action items in the action context, policy
evaluation is ended, and the routing protocol is signaled to accept the route on import, or to announce the
route on export.
 If next-entry is specified, the given route is modified, based on the action items in the action context, and
policy evaluation continues with the next entry in the same policy. If the current entry is the last in the policy,
evaluation continues with the first entry in the next policy statement, or, if no remaining policy statements are
defined, route policy evaluation ends.
The use of next-entry and next-policy statements ensures sequential processing, regardless of matches found.

In this example, AS 65540 advertises all directly connected routes to AS65550 as a result of entry10 of “action_accept”
policy. In this case a full match is found for protocol direct in entry10, and since the action is accept, the action specified
will be applied (metric set 20) and policy evaluation will not proceed to the next entry for that match.
The routes received by AS65550 are shown on the following slides.

As shown from the output on R2, client1 route has only MED set to 20. as a result of executing entry 10 of
"action_accept" policy. Since the action of entry 10 is accept, the policy evaluation for directly connected routes will not
proceed.

Client2 is also directly connected route, and therefore community MED is set to 20 to the update for this route as
shown in the slide. Entry 30 will not be executed and therefore community “North” is not added.

In this example, AS 65540 advertises all directly connected routes to AS65550 as a result of entry10 of
“action_next_entry” policy. In this case a full match is found for protocol direct in entry10, and since the action is next-
entry, the action specified will be applied (med set to 20) and policy evaluation will proceed to the next entry. Entry20 is
evaluated and the action specified for “client1” match will be applied. Entry30 is also evaluated and the action specified
for “client2” is applied.
Notice that, you will obtain similar results if the action of entry 20 is next-entry.

As shown from the output on R2, client1 route has med set to 20 as a result of executing entry 10 of
“action_next_entry” policy. Since the action of entry 10 is next-entry, the policy evaluation will proceed, and the
community West “ 40:2000” is added to the update as a result of entry 20.

As shown from the output on R2, client2 route has med set to 20 as a result of executing entry 10 of
"action_next_entry" policy. Since the action of entry 10 is next-entry, the policy evaluation will proceed, and the
community North “40:1000” is added to the update as a result of entry 30.

When next-policy is specified, the given route is modified based on the action items in the action context. Also,
policy evaluation continues with the first entry in the next policy statement, or, if there are no remaining policy
statements defined, route policy evaluation ends.
If a given route reaches the end of the defined policy statements without an explicit accept or reject action specified,
the default route policy action for the calling protocol is used. However, if previous matches to defined route policies
resulted in modifications to the route attributes, these changes are kept and passed to the calling protocol.

In this example, AS 65540 advertises all directly connected routes to AS65550 as a result of entry10 of “policy1” policy.
In this case a full match is found for protocol direct in entry10, and since the action is next-entry, the action specified
will be applied (adding community West) and policy evaluation will proceed to the next entry. Entry20 is evaluated and
the action specified for “client1” match will be applied and policy evaluation will proceed to the next policy, which is
“policy2” in this case.
For prefix “client2” there is a match in entry 10 and entry 30 of “policy1”, therefore client2 prefix will be tagged with
both communities “West” and “North”.
Notice the order by which the policies are applied is determined by the order you export or import them, in this example
the first “policy1” is applied before “policy2”.

As shown from the output on R2, client1 route has community West “ 40:2000” added as a result of executing entry 10
of “policy1”. Since the action of entry 10 is next-entry, the policy evaluation will proceed, and the Origin is set to
incomplete. Because the action of entry 20 is next-policy, policy evaluation will proceed to “policy2” and the action
specified (setting the MED to 20) will be applied.

As shown from the output on R2, client2 route has community West “ 40:2000” added, as a result of executing entry 10
“policy1”. Since the action of entry 10 is next-entry, the policy evaluation will proceed, and the community North
“40:1000” is added to the update as a result of entry 30.

In this example, we are only changing the order by which the policies are exported, we are applying “policy2” first then
“policy1”. Since the action on entry 10 of policy 2 is “accept” policy evaluation for that match will not proceed to next
policy. As a result of that, the update received by AS65550 for prefix “client1” will not have community “West” or origin
incomplete. The detailed updates for both “client1” and “client2” are shown on the following slides.

As shown from the output on R2, client1 route has MED value of 20 as a result of executing “policy2”, since the action is
accept, no policy evaluation will proceed for this match, therefore no communities will be added and the origin will not
change.

As shown from the output on R2, client2 route has community West “ 40:2000” added, as a result of executing entry 10
of “policy1” configured. Since the action of entry 10 is next-entry, the policy evaluation will proceed, and the
community North “40:1000” is added to the update as a result of entry 30.

The action criteria configure the effect of a successful policy match. For each matching item, attributes may be
modified or added as appropriate, using any of the above options that are applicable to BGP.

The default-action command determines the result when no policy matches are successful. It can be set to any
available action state, including accept, reject, next-entry, and next-policy.
If one or more matches occur in the policy entries, the default action is not used, whether or not it is defined.
Each route-policy statement can have a default-action clause defined. If a default-action is defined for one or more of
the configured route policies, it is handled in the following ways:
 If the action is “accept” or “reject”, policy evaluation ends and the appropriate result is returned.
 If no match occurs in the policy entries, and a default action is defined, the default-action clause is used.
NOTE: Take care when specifying a default-action of reject, as all policy processing stops at this point. This means
that, if a particular route did not match any of the preceding policy entries, no further policies specified will be
processed, and the route itself will be rejected.
 If no match occurs in the policy entries, and a default action is not defined, the default action of the protocol
occurs.

Note that there is bit of implicit logic if multiple policies are specified with either the import or the export command.
If, in a given policy-statement, a specific prefix does not match any entry that makes up the policy statement, one of
the following actions will result:
1. If there is a default action of “accept” or “reject” in the policy, that action will be taken, the policy processing
will stop, and no further policies will be processed.
2. If there is a default action of “next-policy” or “next-entry” in the policy, the next entry or policy specified will
be processed.
3. If there is no default action, the next policy specified will be processed.
4. If there are no remaining policies, no match has occurred, and no default action has resulted, the default BGP
behaviors ― to send or receive routes from neighbors ― are used.
Note: SR OS Release 10.0.R4 increased the number of policies that may be applied to BGP (group or neighbor) as well as
VRF import or export statements from five (5) to fifteen (15).

Module 3 – 43
© 2016 Nokia
Module 3 – 44
© 2016 Nokia
Address planning
AS 65540 should use its IGP to route internal networks only.
Keep address spaces separate. Assign prefixes and networks so that they are easily recognizable as internal networks to
the rest of the AS. That is, do not mix customer assigned networks with the internal networks used to perform internal
routing by the IGP.
Customer or service assigned address space goes into BGP and becomes BGP NLRI for the AS.
External links with other customers or BGP peers are not exported into BGP and, in most cases, do not become BGP
NLRI. In any event, it is unnecessary for external link subnets to become NLRI if you stamp all prefixes learned with
next-hop-self.
The next-hop-self command compels BGP to use the resources provided by the IGP. This will, essentially, take
advantage of any and all IGP design features by having internal BGP peers use the IGP to route between system
addresses exclusively.
A sound address plan, with defined address space for internal and external networks; a good aggregation plan; and
subnets allocated for functions such as the router ID help to make configuration, troubleshooting, and administration
easier.

Filtering is based on known prefixes. It may be used for import or export policy purposes.
The prefix-list filter is most useful when the prefixes are known and are not likely to change.
In the above diagram, an export policy is configured on router R5 to advertise prefix 10.17.100.0/24.

In the policy illustrated above, outbound routes are filtered to prevent RFC 1918 addresses from propagating to the
peers. An export policy is configured on routers R1 and R2 to not advertise these prefixes.
NOTE: We use the 10.0.0.0/8 prefix during the labs in this course, so we do not filter all RFC 1918 space in our practice
labs. However, that would be the standard practice in global Internet policies.

Using 0.0.0.0/0 (typical default route) with prefix-lists in SR OS introduce wild-carding into your policies. This is useful
when you want to accept or deny any prefixes with a certain prefix length. For example, the entry “prefix 0.0.0.0/0
through 24” would match any prefix of length 0 (including a default) to any prefix up to and including length 24. As
mentioned earlier, some peering agreements will stipulate that you can only send prefixes of a certain length. It would
be quite easy, therefore, to configure an accept policy to match prefixes within a specified range only.
In the example above, AS 65550 would accept anything shorter than or equal to length /24. Anything longer, such as
the /29s on router R5, would not match and, therefore, would not appear in AS 65550’s network.
Many ISPs implement policies associated with prefix lengths. Most of the time, an ISP will insist on prefixes of length /24
or shorter but, depending on the transit or peering agreements, it can specify a much shorter /18-/22 range. This is
because higher tier upstream providers insist that downstream networks aggregate as much as possible, especially for
more recently assigned (within the last 15 years) CIDR prefixes.
These policies exist also because some prefixes are non-portable, that is, any given customer of an upstream provider
using that provider’s own address space cannot use another foreign provider to announce the same prefix. If a
customer were to announce a prefix that was a smaller chunk of a much larger prefix to a foreign provider, the original
upstream provider would see its own address space fragmented from many different ISPs. This is clearly an
unacceptable situation for the ISP that owns the address block. Also, the longest prefix match rule always applies, so the
foreign provider advertising the longer prefix will always be the preferred access point for the entire Internet. Such a
scenario raises issues of ownership and acceptable use.

The network diagram shown above will be used throughout this module to demonstrate the implementation of BGP
policies. The loopbacks on the edge routers (R5 and R6) simulate client routes from both CIDR space and space that is
external to the AS. Loop0 and 1 of each router simulate external networks (192.168..) and Loop2 and 3 of each router
simulate customer networks that are utilizing CIDR space from the AS itself.

In the example above, the “Client Routes” policy takes routes from directly connected networks (any interfaces)
and qualifies these with the prefix-list “Client-External”. Therefore, any direct networks that match the prefix-list
will be accepted.
Notice that the default action of this policy is “reject.” This means that, unless a route is accepted by the preceding
parts of the policy, no further policies will apply and the route will be rejected in all cases.

The defined policy must now be applied at the protocol, group or neighbor levels to take effect.
When multiple policy names are specified, the policies are evaluated in the order they were specified. A maximum of five
policy names can be configured. Then, the first policy that matches is applied.
In the example above, the goal is to advertise specific prefixes to neighbors.
The policy is applied as an export policy.

Verify that the result was what was intended with the show router bgp neighbor <neighbor> advertised-
routes command. The output in the slide shows that R5 has advertised the Client-External routes to its iBGP neighbor
router R2. This is basically the router R5 Rib-Out database.

Defined prefix-lists can be viewed with the show router policy commands, as illustrated above.

In the above slide, AS 65540 is trying to advertise prefix 10.65.1.8/29. To do that, a new entry is added to the existing
“Client Routes” policy.
This prefix overlaps with AS 65550 address space, and in practice AS 65550 would reject this prefix. The policy to do
that is shown on the next slide.

The above policy ensures that AS 65550 does not receive any prefixes that fall within its own address space. Notice that
this policy should be applied on router R4 as well. As a result of this import policy, the prefix 10.65.1.8 received from
AS65540 will be rejected.

In this case, router R3 will reject any prefixes that fall within in its own address space. The show command output shows
that the prefix 10.65.1.8/29 has been rejected. Notice the flag field “Invalid IGP Rejected”.

Module 3 – 57
© 2016 Nokia
Module 3 – 58
© 2016 Nokia
A community is an attribute with no fixed meaning. It groups a set of routes that share a common property or
characteristic so that policy may be applied to the community as opposed to the individual routes. A route may be
associated with more than one community.
By default, all routes are members of the Internet community; this requires no configuration. All other communities are
explicitly configured.

Communities can be used for virtually any route policy, including filtering received or advertised prefixes, and
influencing route selection.
A prefix may have one or more community attributes appended to it by a BGP router.

Community is an optional, transitive attribute, with type code 8, as defined in RFC 1997. The optional nature of
communities means that the attribute does not have to be supported. Transitive means that the attribute should
propagate to all neighbors.
An individual community value is a 32-bit number, commonly expressed as two 16-bit numbers separated by a colon,
for example, 65200:12345. Generally, the high-order 16-bit number is the local AS number, or, with the peer’s consent,
the neighbor’s AS number may be used for policy relating to that peer’s AS. The low-order 16-bit numbers are usually
locally defined and administered to maintain one unique value per policy definition.
The specific values have no fixed meaning, except for well-known community values. Implementing the policy defines
the action related to a particular community value.
The community attribute is more appropriately called a community-list attribute because there may be none, one,
or many community values associated with a particular route.

Context: config>router>policy-options
Syntax: [no] community name members comm-id [comm-id] … [comm-id]
Description: This command creates a route-policy community list to use in route-policy entries. Up to 15
community IDs can be specified.
The no form of the command deletes the community list or the provided community ID.
Default: no community — No community names or members are specified.
Parameters: name — Community-list name. It can be any string up to 32 characters, comprising printable, 7-bit
ASCII characters, and excluding double quotation marks. If the string contains spaces, double
quotation marks delimit the start and end of the string.
comm-id — Community ID. A community ID can be specified as:

as-num:comm-value —as-num is the AS number.
Values: as-num: 1 to 65 535
comm-value: 0 to 65 535
type {target | origin} :as-num:comm.-value — The keyword target or origin denotes the community
as an extended community of type route target or route origin. The as-num and comm.-value variables allow
the same values as described above for regular community values.
reg-exp — A regular-expression string. It can be any string up to 256 characters, comprising

printable, 7-bit ASCII characters, and excluding double quotation marks. If the string contains
spaces, double quotation marks delimit the start and end of the string.
well-known-comm — no-advertise, no-export, no-export-subconfed, none
NOTE: Well-known communities can also be set manually. That is, you can create a community called “NO-PEER” and set
its value to “65535:65284”.

By setting community values for certain prefixes, router R5 can communicate key pieces of information about the
prefixes to the rest of the AS. In this case, router R5 tells routers R1 and R2 that the prefix 10.17.100.0/24 (and others)
is originated on the West coast, and that it is a prefix associated with AS 65540’s own address space. With this
information, the borders can implement other policies.
Note that without any other policy applied, router R1 would pass on these same communities to AS 65550. AS 65550 is
under no obligation to do anything with them, however, and will simply ignore them in most cases. The details of setting
community values for certain prefixes are shown on the following slides.

An existing policy can affect the architecture of a new policy. If a policy is already present, a new policy may have to be
integrated into the existing logic, without disrupting the intention of the previous policy.
Up to 15 policies may be applied at the same time, for both import and export. Two architectural approaches to
applying additional policies are possible: the new policy requirement may be integrated into the existing policy
statement as a new entry or an additional policy statement may be applied.

Community values are set in a policy. In this case, a router has a policy to bring directly connected networks into BGP
and tag them with either “Client-External-West” or “Client-CIDR-West” community lists (each of which may
contain up to 15 member communities).
Note that prefix-list “Client-CIDR” is defined on router R5 as follows:
A:R5>config>router>policy-options# info
----------------------------------------------
prefix-list " Client-CIDR"
prefix 10.17.0.0/16 longer
exit

The output in the slide shows that router R1 has received the BGP route for 10.17.100.0/24 with the configured
communities. With this information, and in most cases, router R1 can implement other policies to make use of these
communities.

In this case, router R1 does not have any policies configured to modify the communities set by router R5. The output in
the slide shows that router R3 has received the BGP route for 10.17.100.0/24 with the configured communities. AS
65550 is under no obligation to do anything with these communities, and will simply ignore them in most cases.

AS 65540 does not want AS 65550 to send the prefixes tagged with “Client-CIDR-West” and “Client-CIDR-
East” to any other AS. To achieve that, router R1 is configured with the policy shown in the slide above, in which
router R1 is going to set the community “no-export” on the more specific prefixes of its assigned CIDR space of
10.16.0.0/12.
The output below shows the Rib-In and Rib-Out entries on router R1 for prefix 10.17.100.0/24, notice the community
value
*A:R1# show router bgp routes 10.17.100.0/24 hunt
===============================================================================
===============================================================================
RIB In Entries
-------------------------------------------------------------------------------
Network : 10.17.100.0/24
Nexthop : 10.16.10.5
Path Id : None
From : 10.16.10.5
Res. Nexthop : 10.16.0.1
Local Pref. : 100 Interface Name : toR5
Community : 40:100 40:2020
<output omitted>
Route Source : Internal
AS-Path : No As-Path
-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
Network : 10.17.100.0/24
Nexthop : 10.0.2.1
Path Id : None
To : 10.0.2.2
<output omitted>
Community : no-export
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 10.64.10.3
Origin : IGP
AS-Path : 65540

After applying the policy shown in the previous slide on router R1, the prefixes tagged with “Client-CIDR-West” and
“Client-CIDR-East” will be sent to router R3 with a new well-known “no-export” community. Therefore,
AS65550 will not send these prefixes out to any other AS(s).

Syntax: [no] disable-communities [standard] [extended]
Description: This command configures BGP to disable sending communities.
Parameters: standard — Specifies standard communities that existed before VPRNs or RFC 2547bis
extended — Specifies BGP communities that were extended after the concepts of RFC 2547 were
introduced, to include handling of the VRF target.
BGP now supports the ability to enable or disable sending regular or extended BGP communities to an associated peer
at the global, group, or neighbor level, for the base router and VPRN BGP instances. This feature overrides communities
that are already associated with a given route or that may have been added using an export route policy. In other words,
even if the export policy leaves BGP communities attached to a given route, if this feature is enabled, no BGP
communities are advertised to the associated BGP peers.

Module 3 – 71
© 2016 Nokia
In this slide, AS65540 would like to send a summary route of its address space to AS 65550 using the aggregate
protocol. Router R1 and/or Router R2 will be configured with to aggregate the address space of AS65540, and then
export the aggregate route to AS65550 using a policy as shown on the next slide. In this kind of setup, normally, one
border router (either R1 or R2) will be configured to send an aggregate route, while the other router will send the more
specific routes.

In the slide above, router R1 generates a summary of the prefix 10.16.0.0/12 into AS 65550 using the aggregate
protocol. The more specific routes are still allowed through to AS 65550 because the “summary-only” option is not
used in this case. If the “summary-only” options is used, then the specific routes will not be advertised to AS 65550. in
both cases the aggregate route appears as a black hole in the routing table.
A policy (advertise aggregate) is configured on router R1 to send the aggregate route to AS65540. If the policy was not
applied, the aggregate route 10.16.0.0/12 will not be advertised; it will still appears as black hole route in the routing
table.

Notice that the aggregate route is tagged with all the communities Client CIDR, West, and East.

<output omitted>
-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
Network : 10.17.100.0/24
Nexthop : 10.0.2.1
Path Id : None
To : 10.0.2.2
Res. Nexthop : n/a
Local Pref. : n/a Interface Name : NotAvailable
AIGP Metric : None
Connector : None
Community : 40:100 40:2020
Origin : IGP
AS-Path : 65540
-------------------------------------------------------------------------------

The slide above shows that router R3 in AS65550 has received the aggregate and the more specific routes from
AS65540.

The above slide shows an example in which the Atomic Aggregate flag is set. Router R3 is advertising Client1 prefix into
BGP. AS 65550 is advertising the route to AS 65540. AS 65540 is aggregating Client1 prefix on behalf of AS65550. In
this case, since the aggregation is done for prefix that does not belong to the AS address space, the Atomic Aggregate
flag is set on the aggregate route to indicate that there is a loss in the path information. The following slides show the
details of the configurations and verifications details.

The above slide shows the aggregate route being advertised by AS 65540 to AS 65541. Notice that the Atomic Aggr is
set (Atomic) for the aggregate route, while it is not set for Client1 route as shown below.

-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
Network : 10.65.100.0/24
Nexthop : 10.16.0.21
Path Id : None
To : 10.16.0.22
Res. Nexthop : n/a
AIGP Metric : None
Connector : None
Community : No Community Members
Origin : IGP
AS-Path : 65540 65550

The above slide shows the routes received by AS 65541, there are two routes received, Client1 route (10.65.100.0/24)
and the aggregate route. Notice the As-Path of each route. Client1 route is originated by AS65550 and transited
through AS 65540, while the aggregate route is originated in AS65540 on behalf of AS 65550.
Router R7 needs to be aware of the fact that the actual path to destinations, as specified in the NLRI of the route, while
having the loop-free property, may not be the path specified in the AS_PATH attribute of the route.

Module 3 – 79
© 2016 Nokia
The above slide shows the aggregate route being advertised by AS 65540 to AS 65541. upon using the as-set option in
the aggregate route, the Atomic Aggr is cleared (Atomic) for the aggregate route and the AS-Path information is
preserved. This does not affect the attributes for the more specific route as shown below.

-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
Network : 10.65.100.0/24
Nexthop : 10.16.0.21
Path Id : None
To : 10.16.0.22
Res. Nexthop : n/a
AIGP Metric : None
Connector : None
Origin : IGP
AS-Path : 65540 65550

Module 3 – 81
© 2016 Nokia
Module 3 – 82
© 2016 Nokia
To perform matching based on the contents of the AS-Path, the router interprets the contents of AS-Path as a string of
characters, which are then matched with a regular expression.
As a string, the character sequence of the AS-Path may now be matched with logical functions.

Regular Expressions
 AS-Paths appear in a variety of formats. A prefix that has not propagated outside of the originating AS has a null
AS-Path (an AS-Path of zero length). After it has propagated outside the receiving AS, the AS-Path contains at least
one AS number, and possibly many numbers in sequence, as the prefix propagates across through multiple ASes.
 Inside a confederation, the sequence of AS-Paths may also contain entries in parentheses, for the AS members of
the confederation.
 Any of these combinations of AS-Paths may be matched by regular expressions.
 Regular expressions also match on communities.

Operator Description
| Matches the term on alternate sides of the pipe
* Matches 0 or more occurrences of the preceding term, which must be an AS
number, a dot, an alternation, or a range.
? Matches 0 or 1 occurrences of the preceding term, which must be an AS number, a
dot, an alternation, or a range.
+ Matches 1 or more occurrences of the preceding term, which must be an AS
number, a dot, an alternation, or a range.
( ) Used to parenthesize, so that a regular expression is considered one term
[ ] Used to demarcate a set of elementary or range terms
- Used between the start and end of a range
{m, n} Matches least “m” and at most “n” repetitions of the term
{m} Matches exactly “m” repetitions of the term
{m, } Matches “m” or more repetitions of the term
^ Matches the beginning of the string – only allowed for communities
$ Matches the end of the string – only allowed for communities
\ An escape character to indicate that the following character is a match criteria and
not a grouping delimiter.
. Matches any elementary term
<> Matches any AS path numbers that contain a confederation SET or SEQ

An elementary term is the fundamental entity in a regular expression. It should always be enclosed in quotation marks
and consists of one of the following:
 A single AS number, such as “65200”
 A range term, composed of two elementary terms separated by the “-” character, such as “65200-65300”
 A regular expression enclosed in square brackets, used to specify a set of choices of elementary or range terms.
For example, “[65100-65300 65400]” matches any AS number between 65100 and 65300, or AS number 65400.
 A regular expression enclosed in parentheses “( )” provides a logical grouping of terms and should not be
interpreted as a confederation path. “(65000|65100)” matches AS number 65000 or 65100.
 The “.” dot wildcard character is a match for any elementary term. “(65000|65100).” matches AS number 65000 or
65100, followed by any other AS number.

The above slide illustrates sample regular expressions.
The left column lists the AS-Path that is to be matched, and the right column lists a regular expression that may be used
for matching.
The nature of regular expression terms and operators is such that more than one regular expression is often possible to
match a particular AS-Path sequence.
For example, an AS-Path of 65100 65250 or 65100 65300 can be matched by “(65100 65250) |(65100 65300)”.

The above slide illustrates some commonly used regular expressions.
The left column lists the AS-Path that is to be matched and the right column lists a regular expression that may be used
for matching.
The nature of regular expression terms and operators is such that more than one regular expression is often possible to
match a particular AS-Path sequence.

An AS-Path-based filter filters based on the contents of the AS-Path attribute in the BGP update. It can be used for
import or export policy purposes.
An AS-Path-based filter is most useful when the policy is specific to an AS, as opposed to specific prefixes.

In the Reject example above, AS 65540 wants to implement a policy that prevents any prefix that contains the string
“65550” in the AS-Path from being advertised to AS 65550 in the AS-Path. SR OS can reject invalid paths automatically
with the “loop-detect” BGP command, but a more explicit export policy would ensure that the prefix is not advertised
in the first place.

Applying the export policy shown on routers R1 and R2 would ensure that the prefix that contains the string “65550” is
not advertised to AS 65550.

Module 3 – 92
© 2016 Nokia
The show command output shown above indicates that traffic associated with prefix 10.16.0.0/12 would arrive on the
West Region through router R1.

The “advertise aggregate” policy configured on router R1 is modified in such a way that the AS-Path for the
aggregate prefix is made longer on router R1 (West Region of the country) using the “as-path-prepend” command
compared to the route advertised by router R2 (East Region of the country). Notice that no modification is made to the
“advertise aggregate” policy on router R2.
as-path-prepend
Syntax** as-path-prepend as-num [repeat]

no as-path-prepend
Context config>router>policy-options>policy-statement>default-action
config>router>policy-options>policy-statement>entry>action
Description The command prepends a BGP AS number once or numerous times to the AS-Path attribute of
routes matching the route policy statement entry.
If an AS number is not configured, the AS-Path is not changed.
If the optional number is specified, then the AS number is prepended as many times as indicated by
the number.
The no form of the command disables the AS-Path prepend action from the route policy entry.
Default no as-path-prepend — no AS number prepending configured.
Parameters as-num — The AS number to prepend expressed as a decimal integer.

Values 1 — 4294967295
repeat — The number of times to prepend the specified AS number expressed as a decimal integer.
Values 1 — 50

As a result of prepending the AS-Path on router R1, router R3 will now prefer the route with the shortest AS-Path; in
this case, it is the route on the East Region, to reach AS 65540.

In this example, AS65550 would limit its Local-Preference policy to AS65540 only.

Prior to applying a filter, verify the prefixes involved in the current flow.
There are two entries for the prefix originated in AS 65540: one learned directly from the neighbor router R1, and the
other via iBGP from router R4. Note that the next-hops are different.
The current best path is via the eBGP link, from router R3 to router R1.

Context: config>router>policy-options
Syntax: [no] as-path name expression {reg-exp | null}
Description: This command creates a route-policy AS-Path regular-expression statement to use in route-policy
entries.
The no form of the command deletes the AS-Path regular-expression statement.
Default: No AS-Path regular-expression statement is defined.
Parameters: name — The AS-Path regular-expression name. It can be any string up to 32 characters, comprising
reg-exp — The AS-Path regular expression. It can be any string up to 256 characters, comprising
null — The AS-Path, expressed as an empty regular-expression string.
Verify the presence of an AS-Path list with the show router policy as-path command. All AS-Path lists that are
configured on the router are summarized and displayed.
To view the logic details for a specified list, use the list name as a command-line parameter. The specified list name and
its contents are displayed.

In the example above, the goal is to qualify the AS 65550 LP Policy, such that it will only work with prefixes that originate
from AS 65540 alone. When AS 65550 receives a prefix that is originated in AS 65540 it will accept the prefix and set
the Local-Preference value of 110.

Examining the same prefix again, router R3’s Local-Preference policy has successfully set the Local-Preference for
prefix 10.17.100.0/24 to 110. As illustrated in the AS-Path filter, the policy applied accepts the prefix with AS-Path
“65540”. It would also accept AS-Paths “65540 65540,” or “65540 65540 65540”.

Module 3 – 101
© 2016 Nokia
Module 3 – 102
© 2016 Nokia
MED is an optional, non-transitive attribute, with type code 4. It has a value between 0 and 2^32 – 1; the lower the MED
value, the more preferred the path.
The optional nature of MED means that it does not have to be a supported attribute. Non-transitive means that the
attribute does not propagate outside of the receiving AS.
If it is received over external links, the MED attribute may be propagated over internal links to other BGP speakers in the
same AS. If it is received over internal links, the MED attribute is never propagated to other BGP speakers in a
neighboring AS.
As a result of this behavior, MED must be configured on the edge routers of the domain and propagated externally.
Unless the MED attribute is explicitly set by some mechanism, it is not propagated to neighbors.
By default, the Multi-Exit Discriminator (MED) path attribute is used in the decision process only if both routes in the
comparison come from the same neighbor AS. However, these rules can be modified using the “best-path-selection
always-compare-med command”.

Module 3 – 104
© 2016 Nokia
Router R6 receives the same prefix 192.168.3.0/29 from both routers R1 and R2. Neither has a MED set, so router R6
considers only the IGP metric to the next-hop (either router R1 or router R2) to determine which route is better.
In this case, router R2 is the closest IGP next-hop to the BGP prefix.

The configuration above is for router R3. Notice that it uses communities alone to classify the “from” criteria and,
based on this information, sets the metric (MED value).

On the above slide:
 AS 65550 sends a higher MED from router R4 than from router R3.
 Therefore, it wants traffic for 192.168.3.0/29 to return via router R1.
 AS 65540 is not obligated to do so, however.
Notice that the MED value received by AS65540 is not propagated to any other AS(s); router R6 resets the MED to null
before sending it to AS 65545.
The MED, also called the metric, is an attribute with limited influence. It tells the receiving AS the exit point (on the
receiving AS) that the sending AS prefers. The MED discriminates among multiple exit points from a neighbor AS, but in
the best interest of the sending AS.
In either case, route selection is changed in the neighbor AS, so that traffic flows to the local AS over the specified path.
Some ISPs choose not to support MED because traffic flow in their domain can be manipulated by a direct neighbor that
propagates a MED value to them. If the neighbor AS does not support MED, however, the effort is unnecessary.
In many cases, MED support is agreed upon in the peering policy between ASes.
Even if MED is supported and recognized, a local policy change can easily override the MED.

Router R6 now selects the route it received from router R1 (10.16.10.1), which has a MED value of 20. Based on this
policy, AS 65550 asks AS 65540 to use router R3 as the entry point into AS 65550 for prefix 192.168.3.0/29.

Module 3 – 109
© 2016 Nokia
Syntax: [no] med-out {number | igp-cost}
Description: This command enables the advertisement of the MED and assigns the MED value that is advertised to
BGP peers if the MED is not already set. The specified value can be overridden by another that is set
using a route policy. This can be set at three levels: global level (applies to all peers), group level (applies to all
peers in a peer group), or neighbor level (only applies to specified peer). The most specific value is used.
The no form of the command at the global level reverts to the default, in which the MED is not
advertised.
The no form of the command at the group level reverts to the value defined at the global level.
The no form of the command at the neighbor level reverts to the value defined at the group level.
Default: no med-out
Parameters: number — MED path-attribute value, expressed as a decimal integer
Values: 0 to 4 294 967 295 (2^32 – 1)
igp-cost — The MED is set to the IGP cost of the given IP prefix.

Module 3 – 111
© 2016 Nokia
Module 3 – 112
© 2016 Nokia
The LOCAL_PREF attribute has the greatest impact on route-selection criteria. Its objective is to indicate a preference
that remains local to the AS, and to specify which path is taken by traffic that is leaving the AS.

LOCAL_ PREF is a well-known discretionary attribute with type code 5. It has a value between [0 - 2^32 – 1]; the greater
the value, the more preferred the path.
As the name of the attribute implies, the preference is local to the AS. It should never be sent in an eBGP update to a
foreign AS. However, sending the preference to an eBGP peer in another confederation member AS is acceptable.
The default Local-Preference value is 100. This value or the configured default value, is applied to all routes that do not
have a Local-Preference set when propagated over an iBGP or confederation eBGP session.
In most cases, Local-Preference should be applied on the edge router that receives the route in the local AS, and
should be left unchanged after it is propagated internally to the AS.

What effect does Local-Preference have, by default?
Routers R1 and R2 can, in effect, guarantee which exit point to use in AS 65540.

Prior to applying a policy, determine the existing traffic flow and route selection.
In the example above, the route received over the eBGP connection direct from AS 65550 is preferred over the iBGP
route received from router R2.
It is the best route based on BGP route-selection criteria: an eBGP learned route is preferred over iBGP.

Router R1 sends the 10.65.102.0/24 and 10.65.103.0/24 prefixes to an internal neighbor, with a default Local-
Preference of 100. The “advertised-routes” form of the show router bgp command allows you to examine this
behavior.

A traceroute is used to verify the path.
The borders do not modify the default Local-Preference, therefore the edge routers receive two routes to
10.65.102.0/24. All other attributes equal, the edges of AS 65540 will use the route with the lowest IGP metric to the
next-hop address advertised by the border routers.

Context: config>router>policy-options>policy-statement>entry>from
Syntax: [no] as-path name
Description: This command configures an AS-Path regular-expression statement as a match criterion for the
route-policy entry. If no AS-Path criterion is specified, any AS-Path is considered to match. AS-
path regular-expression statements are configured at the global route-policy level
(config>router>policy-options>as-path name).
The no form of the command removes the AS-Path regular-expression statement as a match
criterion.
Default: no as-path — Matches any AS-Path
Parameters: name — The AS-Path regular-expression name. It can be any string up to 32 characters, comprising
The specified name must already be defined.

In the above slide, AS 65540 implements its own Local-Preference policy, which allows AS 65550 to influence which
Local-Preference is set on AS 65540’s borders.
The route from router R2 is the best route across AS 65540 for the prefix 10.65.102.0/24, as long as no other border
router sends a route with a higher Local-Preference for the same prefix.
Notice that router R1 sets the Local-Preference to 80, which is less than the current default of 100 in AS 65540. With
this policy applied, router R2 will attract all traffic for 10.65.102.0/24 inside of AS 65540. Router R1 does not send an
iBGP update for 10.65.102.0/24 anymore as it can no longer generate the best route to that prefix.
Router R5 sends traffic for 10.65.102.0/24 correctly via router R2. This traffic also happens to transit router R1
because router R1 is the closest IGP next-hop to router R2.
AS 65550 asks AS 65540 to use its own backbone to reach prefixes on router R8.

Router R1 now selects router R2 as the best exit point in AS 65540 for prefix 10.65.102.0/24. In fact, all routers in AS
65540 will now use router R2 as the exit point for the prefix 10.65.102.0/24.

Router R5 now prefers the router R2 exit point to AS 65550 for the prefixes 10.65.102.0/24 and 10.65.103.0/24.

Module 3 – 123
© 2016 Nokia
Syntax: [no] local-preference local-preference
Description: This command sets the BGP local-preference attribute for incoming routes (if not specified), and
configures the default value for the attribute. The value is used if a BGP route arrives from a BGP
peer without the local-preference integer set. The specified value can be overridden by any value
that is set using a route policy. The parameter can be set at three levels: global level (applies to all
peers), group level (applies to all peers in a peer group), or neighbor level (only applies to the
specified peer). The most-specific value is used.
The no form of the command at the global level specifies that incoming routes with a set local
preference are not overridden, and incoming routes without a set Local-Preference are interpreted
as having a Local-Preference value of 100.
The no form of the command at the group level reverts to the value defined at the global level.
The no form of the command at the neighbor level reverts to the value defined at the group level.
Default: no local-preference — Do not override the local-preference value set in arriving routes, and
interpret routes without a set Local-Preference as having a value of 100.
Parameters: local-preference — The local-preference value to be used as the override value, expressed as a
decimal integer.
Values: 0 to 4 294 967 295 (2^32 – 1)

Module 3 – 125
© 2016 Nokia
1. What are some of the goals of routing policy?
The goals of routing policy are to: communicate communities of interest; protect the AS and other external ASes
from bad NLRI; protect external networks from instability; optimize ingress and egress traffic patterns; maintain
efficient use of internal network resources and; support and augment network operations.
2. What are the minimum activities associated with setting routing policy in an AS?
Activities associated with setting routing policy in an AS include: laying out geographical or business regions in the
network; creating address plans; optimizing the IGP for stability; creating export and import BGP policies and;
optimizing the IGP for routing and redundancy.
3. What is the main objective of dividing the network into regions?

By dividing the network into regions, the AS can use BGP to communicate communities of interest to the rest of the
AS. BGP is unique in its ability to create arbitrary policies associated with customer, geography, or service business,
and to communicate those communities to the edges of the network, where further policy may be applied.
4. What are some common address spaces that an administrator will want to recognize in the AS? Which are typically
suited to become BGP NLRI?
Typical address spaces include: internal links; customer address space, using the AS’s own CIDR assignments;
external customer address space; and various links external to the AS itself. It is typical for the assigned customer (or
service, etc.) CIDR spaces and external customer address space to be brought into BGP as NLRI.
5. What is a Bogon? Why would an AS want to create a prefix-list that defines Bogon space?
Bogon prefixes are the combination of Martians (RFC 1918 or RFC 5735) and prefixes that are not allocated or
assigned on the Internet yet. These prefixes should, in theory, never appear in a global Internet routing table. Invalid
and Bogon prefix-lists allow the AS to sanitize networks that are advertised into or out of the AS.

6. Is 224.0.0.0/4 a valid prefix in SR OS?
No, it is an invalid prefix. By default, RTM will not allow this prefix into the routing table.
7. Which is better: exporting the IGP internal networks into BGP, or exporting BGP networks into IGP? What is an
exception?
Neither is considered a best practice, and neither would produce a very stable network. The one exception is when
you bring directly-connected or static routes (associated with customer or services) into BGP for BGP to advertise
those networks as NLRI.
8. What three major activities are associated with deploying BGP policy?
IP service edge (bringing NLRI into the AS); core activities; border activities.
9. What are the three main activities at the border of the network?
The three main activities at the border are advertising/receiving appropriate NLRI/PATH, analyzing PATH
attributes, and implementing policy that adheres to the business and traffic flow goals of the AS.
10.What are some basic criteria to know before deploying either import or export BGP policies?
The basis for import and export policies are customer requirements, flow traffic reports, network and AS origins,
communities of interest, and attributes (tools) that the AS can use to influence policy.
11.List six policy options that are typical for BGP export policies.
The six main options for BGP export policies are: rejecting bogus/invalid NLRI, sending more specifics, sending
aggregates, using local-pref policies, using AS-path prepending, and setting an inbound metric using the MED
attribute.

12. List four policy options that are typical for BGP import policies? Which traffic is affected by this type of policy?
The four main options for BGP import policies are: rejecting bogus/invalid NLRI, accepting appropriate prefixes
(for the AS’s egress traffic flows), implementing a local-pref policy, and resetting the MED attribute to an AS
known value. These options affect egress traffic patterns from the AS.
13. What can be done in the core of the network to control service edge to border traffic flow? What effect does
this have on overall traffic flow?
The AS can adjust metrics lower in the core. This forces traffic coming into, and flowing to the edges of the
network to use the core, and not to other edges of the network.
14. List four reasons to implement policy.

Policy can be implemented to assess the financial cost of sending traffic over links or across some ASes; address
political relationships, such as preferred peers or ISP relationships; implement SLAs offered by an ISP; address
security concerns; and balance traffic on an inbound or outbound level.
15. If a routing update is manipulated when it is received from a neighbor, in which direction will the change in traffic
flow be noticed?
If the routing update is manipulated in the inbound direction, outbound traffic flow will change. Similarly, if a
routing update is manipulated in the outbound direction, inbound traffic flow will change.
16. Why is an export route policy used?

Export route policies are typically used for advertising IGP or connected interfaces into BGP, and for controlling
which routes BGP advertises to its neighbors.

17.Can multiple policies be applied to a single neighbor?
Yes, up to 15 policies can be applied to a neighbor or group.
18.What are the potential benefits of import and export policies?

An import policy reduces the number of updates inserted into the RIB, which makes faster convergence and
processing times for the local BGP table. An export policy can reduce the number of prefixes advertised and cause
only specific prefixes to be advertised, which results in a corresponding effect in ingress traffic. It can also change
the BGP attributes that make up the PATH information sent to the other BGP peers, which can cause
corresponding changes in traffic flows.
19.What should be considered before implementing a new policy?

Before a new policy is implemented, its definition should be clearly understood, the existing conditions should be
established, the existing policies should be identified and understood, and a plan of action should be developed.
20.What is the behavior of a route policy when a match is successful?

Typically, a successful match terminates the policy logic; no further evaluations are possible.
21.What unique capability is offered by Nokia’s enhanced policy logic?

Nokia’s enhanced policy logic allows for further evaluations after a successful match, by using either the next-
policy or next-entry keywords.

22. List four items that can be used to match in the “from” policy context.
A route may be matched “from” a specified neighbor, protocol, origin code, or community value.
23. If a match occurs, and the specified action is “reject,” will any route modifications occur?
No, modifications do not occur if the route is rejected.
24. If a match occurs and the specified action is “accept,” which route modifications can occur?
Any supported action may occur on a successful match, including the modification of BGP attributes in the update.
25. What will happen if there are no matches in a policy and no default action is defined?
If a match does not occur and a default action is not defined, the action associated with the protocol to which the
route policy applies is performed.

26. When using a prefix list, what keyword-matching criteria are possible for the mask?
The mask options in a prefix list are to match on an exact, a longer, or a range value.
27. Which command displays the details of a prefix list?

The details of a prefix list may be displayed with the show router policy prefix-list name command.
28. If multiple policies are applied to a protocol, in which order are they evaluated?
Multiple policies are evaluated in the order in which they are configured.
29. Which commands on the local router verify the results of an export-policy filter?
The results of an export-policy filter on the local router can be verified with the show router bgp neighbor
<neighbor ip> advertised-routes command, or, on the receiving router, you can use the show router
bgp neighbor <neighbor ip> received-routes command, or any number of other show router BGP
routes variants such as hunt, community, or aspath-regexp. All are useful commands to verify that policies are
applied properly in either direction.
30. How is an AS-Path interpreted for matching purposes?

For matching purposes, an AS-Path is interpreted as a string of characters.
31. What is the significance of the “-” character in a regular expression?

The “-” character in a regular expression specifies a range of terms.

32. What is the significance of the “.” character in a regular expression?
The “.” character in a regular expression matches any elementary term.
33. What command displays the details of an AS-Path list?

The details of an AS-Path list are displayed with the show router policy AS-Path command.
34. Can a prefix list and an AS-Path list be applied in the same policy?
Yes, by combining both a prefix list and an AS-Path list into the same policy, the policy becomes even more explicit
about which routes should be matched.
35. What command can be used to view a prefix that has been denied by a policy?
A prefix that has been denied by a policy can be viewed with the show router bgp routes 192.168.3.0/29
detail command.
36. Which flags are associated with a rejected prefix?

A rejected prefix has invalid and rejected flags.
37. How does a policy change in one AS affect a neighboring AS?

A policy change in one AS can result in a number of changes of PATH attributes and available NLRI/Prefixes in a
neighbor AS.

38.What impact does the direction of traffic flow have on policy implementation?
The impact of direction of traffic flow is a major factor when forming a routing policy. Ingress traffic flows may need
to be changed via export routing policies and egress traffic flows may need to be changed via import routing
policies.
39.What ranking does Local-Preference have in route selection criteria?

Local-Preference has the highest ranking metric used in the route selection process.
40.Is Local-Preference propagated in eBGP updates?

No.
41.How does Local-Preference affect packet flow in the AS in which it is applied?

The highest Local-Preference for a specific route draws traffic towards a specific exit point in the AS.
42.What is the default Local-Preference sent in an iBGP update?

100.
43.What is another name for MED?

Metric.

44.What category of attribute is MED?
Optional Non-Transitive Attribute.
45.Is MED sent to neighbors by default?

No.
46.Which command is used to transfer the IGP metric to the BGP MED?
med-out command.
47.What is the convention for RFC 1997 community numbering?

<as-num>:<comm-val>; both 16-bit numbers.
48.How many community values can be associated with a route?

Up to 15 community values can be associated with a route.
49.What command is used to display the BGP table entries that contain a particular community value?
The show router bgp routes community <community value> command can be used.

Module 3 – 135
© 2016 Nokia
Module 4 – 1
© 2016 Nokia
Module 4 – 2
© 2016 Nokia
Module 4 – 3
© 2016 Nokia
Module 4 – 4
© 2016 Nokia
Although it is highly redundant, full mesh is inherently limited in scalability. For the administrator, the financial and
administrative cost to maintaining full mesh is very high. For the router, the number of TCP sessions and
associated overhead increases.
Using the formula n*(n-1)/2 to calculate full mesh, where n is the number of routers; for six routers, 15 logical or
physical connections are required. If the number of routers increases by four, the number of sessions required
increases by 30.
This is clearly not scalable, and better designs are required.

Confederations, defined in RFC-5065 (circa Aug 2007; making RFC 3065 obsolete), are a collection of ASes
advertised as a single AS number to BGP speakers that are not members of the confederation. The RFC 5065
update of confederations added more support for error handling.
There are several reasons that confederations are beneficial:
 They are useful to subdivide ASes that have a large number of BGP speakers into smaller domains, to control
route policy using information contained in the BGP, or to alleviate full-mesh requirements.
 Boundaries may be required to allow for regional or national policies.
 Merged ISPs can be viewed as a single entity externally, but can also maintain some separation internally.

To an AS outside of the confederation, there should be no visibility to the internal architecture of the AS. If
confederations, or any other internal design, are used, the AS is still viewed as a single AS.
Internally, up to 15 member ASes can comprise a confederation. Each member requires an AS number, typically
selected from the private range, and each member AS is treated as if it were a stand-alone AS. Each member AS
must either maintain a full mesh of iBGP sessions or use route reflection.
BGP sessions between member ASes in the same confederation are referred to as intra-confederation eBGP
sessions; sessions inside the same member AS are referred to as iBGP sessions. Sessions between the
confederation and an external AS remain eBGP sessions.

The above slide illustrates a sample confederation structure. The confederation AS, visible from the outside, is AS
65200. The peers in AS 65100 and AS 65250 do not have visibility over the internal structure of the
confederation or its member ASes. There are three member ASes, and each maintains a full mesh of iBGP
sessions internally.
eBGP sessions are maintained between member ASes and external ASes.
Note that a member AS inside a confederation need not be fully-meshed.

The sender of an update prepends its AS number to the AS_PATH attribute when the update crosses an AS
boundary. When BGP updates cross intra-confederation boundaries (between member ASes), AS_PATH must be
modified.
 If the update is sent to a neighbor in the same member AS, no modification is performed.
 If the update is sent to a neighbor in a different member AS within the confederation, the member AS
number is used.
 If the update is sent to a neighbor outside the confederation, the confederation AS number is used.

AS 65200 receives a BGP update from an eBGP peer in AS 65100. The AS_PATH of the received update is 65100,
as it originated in that AS.
When the update propagates in member AS 65202, the AS_PATH remains unmodified because it does not cross
an AS boundary.
When the update passes from a router in member AS 65202 to member AS 65204 or 65206, the AS_PATH is
modified to include the member AS that it has passed through. This is part of the same confederation and is not
a foreign AS, so a distinction is noted in AS_PATH with the use of parentheses around the confederation AS
sequence. As a result, the path received in member AS 65204 or 65206 is “(65202) 65100”.
Each member AS performs the same manipulation, so when the update received in member AS 65204
propagates to member AS 65206, the path is “(65204 65202) 65100”.
Loop detection is performed in the same way as confederation AS paths. A router that receives an update checks
for the presence of its own AS number and discards the route if it is present in the list.
A router that propagates an update to a foreign AS must never allow the confederation path to be visible. When
the update propagates to AS 65250, the confederation member portion of the path is replaced with the
confederation AS number. In this example, in the path “(65204 65202) 65100,” “(65204 65202)” is replaced with
“65200.” The route is then propagated externally with a path of “65200 65100.”

The show router bgp routes command is used to display the BGP table, as shown above. Note the routes
with confederation sequences in the path.

Routing to the next-hop is resolved by the IGP. Because the entire confederation is viewed as a single AS, as
opposed to IGP routing, which is domain-wide, BGP expects that all next-hops are reachable within the IGP.
NEXT_HOP is treated as if it were iBGP.

The table above shows the default behavior for well-known mandatory BGP attributes in BGP updates. Only the
AS_PATH is modified.
TTL values in the BGP control packets are treated as if they were eBGP.

The above slide illustrates a confederated AS 65540 with two member Ases: AS 65541, and AS 65542. The
confederated AS has an eBGP session to AS65550 and another eBGP session to AS65555. AS 65550 is
advertising Clinet1 network to the confederated AS. The following slides show the configuration of the
confederated AS and the distribution of the route update for Client1 network.

Configure the BGP confederation members using the confederation command in the config>router context.
The confederation members must be configured on each router.
According to RFC 3065, all routers must support confederations. There can be a maximum of 15 member ASes
per confederation.
To migrate from a non-confederation configuration to a confederation configuration requires a major

configuration change on each BGP speaker in the AS.

Syntax: [no] confederation confed-as-num members as-number [as-number...up to

15 maximum]
Description: This command creates a confederation AS within an AS. It reduces the number of iBGP sessions
required in an AS. Route reflection is another technique that is commonly used to reduce the
number of iBGP sessions.
The no form of the command deletes the specified member AS from the confederation.
When no members are specified in the no statement, the entire list is removed and
confederation is disabled. When the last member of the list is removed, confederation is disabled.
Default: no confederation — No confederations are defined.
Parameters: confed-as-num — Confederation AS number, expressed as a decimal integer.
Values: 1 to 65 535
Members: member-as-num — AS numbers of members that are part of the confederation, expressed as
a decimal integer. Up to 15 members per confed-as-num can be configured.
Values: 1 to 65 535

The slide above shows the BGP configurations of the routers in the member AS 65541. Router R5 has an iBGP
session to Router R1, they both belong to AS 65541. in addition to the iBGP session to Router R5, Router R1 has
a regular eBGP session to Rx of AS65550, and an intra-confederation eBGP session to Router R2. In this case, the
member ASes use the same IGP, and the system address of R2 is reachable via the IGP as shown below, therefore
we can use the system addresses to configure the BGP neighbors.
R1# show router route-table 10.16.10.2

===============================================================================
===============================================================================
-------------------------------------------------------------------------------
10.16.10.2/32 Remote ISIS 01h52m39s 15
10.16.0.10 10
-------------------------------------------------------------------------------
Note that in confederations, there is no requirement that member autonomous systems use the same IGP. It is
not necessary for each member AS to reveal its internal topology to other member autonomous systems. When
different IGPs are used, however, BGP next-hop reachability must be guaranteed within each member AS.

The slide above shows the BGP configurations of the routers in the member AS 65542. Router R6 has an iBGP
session to Router R2, and a regular eBGP session to Router Ry of AS65555. In addition to the iBGP session to
Router R6, Router R2 has an intra-confederation eBGP session to Router R1.

The show router bgp summary command is used to verify the confederation configuration. In the example
above, the confederation AS is externally visible as 65540, and the member ASes are 65541, and 65542.

The show router bgp neighbor 10.16.10.2 command is used to verify the neighbor type; in this case, it is
an eBGP neighbor. To determine whether this is a neighbor in another member AS or a true external neighbor, the
list of confederation ASes should be verified with the show router bgp summary command.

The show router bgp routes command is used to verify the BGP table and the paths received via the
member ASes. The above slide shows the route received by Router R1 for Client1 update.

Confederation ASes appear in parentheses and are visible only internally to the confederation. After the update
propagates outside the AS, the confederation AS number is automatically substituted into the path.

After the update propagates outside the AS, the confederation AS number is automatically substituted into the
path. The above slide shows the route advertised outside the confederation from Router R6 to Router RY of
AS65555, the AS-Path does not contain the member ASes.

Module 4 – 24
© 2016 Nokia
Module 4 – 25
© 2016 Nokia
Route reflection is defined in RFC 4456 (circa 2006; making RFC 2796 obsolete).
Route reflectors (RRs) are used to reduce the number of iBGP sessions required in an AS. Normally, every BGP
speaker in an AS must have a BGP peering with every other BGP speaker in the AS. An RR relaxes these
requirements by disabling iBGP split horizon for its clients.
Confederations can also be used to remove the full iBGP mesh requirement in an AS. Route reflection may be
configured as stand-alone, or inside a confederation.

Route reflection involves creating a special group of routers called route reflectors (RRs). Under this structure,
iBGP speakers are classified into three groups:
 Route reflectors (RRs)
 Route reflector clients (clients or client peers)
 Regular iBGP speakers (non-clients or non-client peers)
With route reflection, the full iBGP mesh is required only between RRs and between RRs and non-clients.

An RR and its clients form a cluster. Peers that are not part of the cluster are considered non-clients.
Client peers should have iBGP sessions only, with the route reflector or reflectors in their cluster. They do not
need to have sessions with each other and do not need to be fully meshed.
The above slide illustrates a simple RR with a single cluster. There is one RR with multiple client peers.

When an RR receives a route for a specified prefix, it first selects the best path from all paths received.
If the best route is received from a non-client peer, the RR reflects the route to all its defined client peers and
propagates the route to all eBGP peers.
On the Nokia 7750 SR, when a best route is received from an eBGP peer (or an RR client) it is advertised back to
that same peer as well as to other peers. In prior releases, the route was not reflected back to the sending peer.
To suppress this behavior in SR OS release 9.0, a BGP export policy can be configured for each neighbor to which
we do not wish to re-advertise routes. Starting in SR OS release 10.0r4, the "split-horizon" CLI command
allows the user to turn off this behavior globally, under a group, or under a neighbor.
This behavior was introduced in 7x50 SR OS release 9.0 as a result of some optimizations. It does not violate any
RFCs, and BGP loop detection using AS-Path will ensure that there are no loops. This feature improves
performance on the SR, as the processing used to reject the looped routes is less than that required to keep
track of which routes should not be re-advertised.
split-horizon
Syntax: [no] split-horizon
Context: config>router>bgp>group group-name>neighbor ip-int-name
Description: This command enables the use of split-horizon. Split-horizon prevents routes from being
reflected back to a peer that sends the best route. It applies to routes of all address families and to any
type of sending peer; confed eBGP, eBGP and iBGP.
The configuration default is no split-horizon, meaning that no effort is taken to prevent a
best route from being reflected back to the sending peer.
NOTE: Use of the split-horizon command may have a detrimental impact on peer and
route scaling and therefore operators are encouraged to use it only when absolutely needed.
Default: no split-horizon

If the best route is received from a non-client peer, the RR reflects the route to all its defined client peers and
propagates the route to any external peers. The route is not propagated to other non-clients because they are
part of the full iBGP mesh and will have received it from the original non-client peer.

If the best route is received from a client peer, the RR reflects the route to all its defined client peers, including
the originator, and propagates the route to all other peers, whether they are non-clients or eBGP peers. Non-
client peers may also include other RRs.

A best and used route received from an eBGP peer is propagated to all iBGP peers and all eBGP peers, including
the peer that sent it. The peer will reject this looped route.

An RR reduces the full-mesh requirements by disabling iBGP split horizon for its group of peers. Note that Route
Reflection can make the AS vulnerable to misconfigurations that introduce routing update loops into the AS.
In the absence of iBGP split horizon, loop detection must be performed in another way. The AS-PATH attribute
would not be useful because it is not modified in an iBGP update.
Therefore, there are two additional optional non-transitive attributes introduced in an RR environment for loop
detection and prevention.

The table above shows the optional non-transitive attributes, which are defined in RFC 4456. The attributes exist
only if RRs are configured; they remain internal to the AS and are not propagated to external peers.

The Originator-ID is used for loop prevention inside of an AS when route reflection is deployed. The attribute is
set to the Router-ID of the router that originates the route into the AS, by the RR that first reflects the route.
After it is set, the Originator-ID remains unmodified in the AS.
If a router receives an update that contains its own Router-ID in the Originator-ID field, it discards the update.

The CLUSTER_LIST is used for loop detection across the AS. It is a variable length list and is similar to AS_PATH.
The Cluster-ID of the RR is prepended to the CLUSTER_LIST attribute every time a route is reflected.
If a route is received by an RR and the local Cluster-ID is already contained in the CLUSTER_LIST, the update is
discarded.

The above slide illustrates how the CLUSTER_LIST and Originator-ID are used.
Router 1.1.1.1 originates a route into BGP. It sets the Cluster-ID to "no cluster members" and the Originator-
ID to "None", then sends a route update to its route reflector.
When the route reflector propagates/reflects this route to its iBGP peers, it adds its Cluster-ID 10.10.10.10 to
the CLUSTER_LIST, and sets router 1.1.1.1’s Router-ID as the Originator-ID.
When the route reflector propagates this route to its eBGP peer in AS 65100, it does not add the Cluster-ID nor
does it set the Originator-ID.
When the RR’s non-client sends this route to its eBGP peer in AS 65250, it resets the CLUSTER_LIST and
Originator-ID.

 A cluster is the RR and its clients. For redundancy, a cluster can have multiple RRs. All RRs in the same cluster
must be configured to have the same Cluster-ID and to have iBGP sessions with each other (full mesh).
 Multiple clusters may be configured within an AS.
 Clients in a cluster should have iBGP sessions with all RRs within their cluster. eBGP sessions are also
acceptable.

The above slide illustrates a single cluster with redundant RRs.
There are now two RRs in the cluster, and each client peer has an iBGP session to both. The RRs themselves are
fully meshed.
When router B originates a BGP route, it sends the route update to both RR 1 and RR 2. RR 1 then reflects the
route to its two other clients, and propagates the route to RR 2. RR 2 also reflects this route to its two other
clients, and propagates the route to RR 1. RR 1 flags the route it receives from RR 2 as invalid, as it sees its own
Cluster-ID in the CLUSTER_LIST of the route. RR 2 does the same.
This design eliminates a single point of failure for the RRs or for a single client session, although not in all cases.
For example, assume that router A receives the same route to 172.16.5.0/24 from both RR 1 and RR 2, and picks
one as best. If the IGP costs to router B via RR 1 and RR 2 are equal, router A starts to load share across both RRs
to get to the 172.16.5.0/24 network. There is a risk in this design because either RR is prevented from telling the
other about the prefixes in the cluster. Therefore, if one of the iBGP sessions from RR 1 or RR 2 to router B were
to go down, the RR itself could end up with no route to a previously-known destination and would start to drop
packets.

RR2# show router bgp routes 192.168.3.0/29 hunt
===============================================================================
===============================================================================
<output omitted>
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 192.168.3.0/29
Nexthop : 10.16.10.5
From : 10.16.10.5
…
Fwd Class : None Priority : None
AS-Path : 65545
Network : 192.168.3.0/29
Nexthop : 10.16.10.5
From : 10.16.10.1
…
Cluster : 10.16.10.1
Originator Id : 10.16.10.5 Peer Router Id : 10.16.10.1
Flags : Invalid IGP Cluster-Loop
AS-Path : 65545

In the network shown, AS65550 is advertising a BGP route of Client1 network (192.168.3.0/24) to AS65540 via
the eBGP session to RR1. When RR1 receives the update, it reflect it to its clients (RA and RB) and propagates it to
RR2. The update has no cluster list or originator ID at this point.
When RR2 receives the update, it adds its cluster ID to the cluster list, and set the originator ID to 10.16.10.1
before it sends it to its clients (RA and RB).
RA and RB will both have two copies of the update.
RR2 does not send to update back to RR1 due to iBGP split horizon

===============================================================================
<output omitted>
------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
...
From : 10.16.10.1
...
...
--------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
...
To : 10.16.10.5
...
Cluster : 10.16.10.1
...
To : 10.16.10.6
Cluster : 10.16.10.1

The above slide illustrates multiple clusters with clients that have redundant connections to separate RRs.
There is only one RR in each cluster, but each client peer has an iBGP session to both RRs. The RRs themselves are
fully meshed.
In the example above, when the leftmost client of RR 1 and RR 2 originates a BGP route, it sends the route update
to both RR 1 and RR 2. RR 1 then reflects the route to its clients, and propagates the route to RR 2. RR 2 also
reflects this route to its clients, and propagates the route to RR 1. RR 1 flags the route it received from RR 2 as
valid, as the Cluster-ID in the received route’s CLUSTER_LIST is different from its own. RR 2 does the same.
This eliminates a single point of failure for the RRs and improves redundancy for a single client session failure.
Both RRs learn routes from their clients and from the other RR, because each is using a different Cluster-ID. In
some situation, this is advantageous for both logical iBGP session redundancy and for physical redundancy. There
is, however, slight overhead associated with carrying the extra path information.
Using multiple cluster-IDs is considered more redundant than using a single cluster-ID. Assume that the session
between router B and RR 1 goes down, and that between router C and RR 2 goes down. If a single cluster-ID is
used, then router C will not receive an update for a route learned by router B. Router B sends the update to
router RR 2, RR 2 sends it to RR 1 and its clients (not to C because of the session failure). When router RR 1
received the update, it will flag it as invalid due to same cluster ID, therefore RR 1 will not send the update to
router C. This can be avoided if RR 1 and RR 2 use different cluster IDs.

===============================================================================
===============================================================================
<output omitted>
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 192.168.3.0/29
Nexthop : 10.16.10.5
From : 10.16.10.5
…
AS-Path : 65545
Network : 192.168.3.0/29
Nexthop : 10.16.10.5
From : 10.16.10.1
…
Cluster : 10.16.10.1
Flags : valid IGP
AS-Path : 65545

In the network shown, AS65550 is advertising a BGP route of Client1 network (192.168.3.0/24) to AS65540 via
the eBGP session to RR1. When RR1 receives the update, it reflect it to its clients (RA and RB) and propagates it to
RR2. The update has no cluster list or originator ID at this point.
When RR2 receives the update, it adds its cluster ID to the cluster list, and set the originator ID to 10.16.10.1
before it sends it to its clients (RA and RB).
RA and RB will both have two copies of the update.

===============================================================================
<output omitted>
------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
...
From : 10.16.10.1
...
...
--------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
...
To : 10.16.10.5
...
Cluster : 10.16.10.2
...
To : 10.16.10.6
Cluster : 10.16.10.2

Route reflection reduces the total number of iBGP sessions within a domain. However, because RRs must be fully
meshed with each other, the potential still exists for a large number of iBGP sessions to be required in a very large
network.
To further reduce the number of sessions, RR hierarchies can be used. Hierarchical route reflection architecture is
characterized by having more than one level of RRs, with lower-level RRs serving as the clients of the RRs that are
one level above. There is no limit on the number of levels, but having 2 to 3 levels has proven to make more
practical sense. The diagram above shows a two-level RR architecture, Level 1 RRs are also clients of Level 2 RRs.
Because they are clients themselves, Level 1 RRs do not need to be fully meshed with each other. This reduces
the number of iBGP sessions within the domain. The top-level RRs, Level 2 RRs in the diagram, must be fully
meshed, because they are not clients of any RRs. There are 15 iBGP sessions in the diagram above, compared to
55 in full mesh.
Rules for prefix advertisement for the hierarchical RRs are the same as for single-level RRs. In the above example,
when router R4 receives a BGP route update from its eBGP peer in AS 65100, as a client of router R2, it
propagates the route to router R2, and as a Level 1 RR, it advertises the route to its clients routers R8, and R9.
Router R2 propagates the route to routers R1 (non client of R2 and R3) and R3 (another Level 2 RR), and reflects
it to its clients routers R4 and R5. Note that routers R1 and R3 do not advertise the route to each other, because
they are regular iBGP peers with router R2. As RR, router R3 propagates the route to its clients routers R6 and R7.
In turn, routers R6 and R7 advertise the prefix to their clients routers R10 and R11. Router R7 then propagates
this route to AS 65250.
In most cases, the size of the top-level mesh is the main factor when considering the use of hierarchical route
reflection. If the number of full-mesh sessions is considered administratively unmanageable, you should consider
RR hierarchy.

The RR model may also be applied inside a confederation structure.
The confederation member AS is treated like a stand-alone AS, which requires a full mesh. Route reflection can
simplify the meshing requirement inside a confederation member AS by reducing the number of iBGP peers.
In the example above, AS 65202 and AS 65204 have implemented route reflection. AS 65206 still uses the full
mesh.

Configuring RR requires the addition of one command on the RR itself; no additional configuration on the clients
of the RR is necessary.
Reflection to a specific peer can be disabled, if desired.
After route reflection is configured, the full mesh is no longer required. However, the selective removal of
neighbors must be carefully managed. If too few neighbors are removed and unnecessary sessions between client
peers remain, routing loops may still occur. If too many neighbors are removed, the transit AS design may break
down.

The confederation and IP addresses above are used as a reference for examples in this section.

Notice that to configure an RR to client session, you need to configure a Cluster-ID on the RR for that client.
Nothing needs to be configured on the client.
To configure an RR to non-client session, you do not specify a Cluster-ID.
Syntax: [no] cluster cluster-id
Description: This command configures the Cluster-ID on an RR.
The no form of the command deletes the Cluster-ID and effectively disables route reflection
for
the given group.
Default: no cluster — No Cluster-ID is defined.
Parameters: cluster-id — The RR Cluster-ID, expressed in dotted-decimal notation.
Values: Any 32-bit number in dotted-decimal notation (0.0.0.1 to 255.255.255.255).

The show router bgp group command is used to verify the configuration of the RR because it displays
whether a Cluster-ID is configured.

The above slide illustrates a sample output of the show router bgp routes command. Verifying BGP routes
on the router that originated the path requires the use of the hunt option, because the route is not present in
the BGP table (Loc-RIB), but is present in the RIB-Out, waiting to be sent to neighbors.
Because the route has not yet passed through the RR, the Cluster- and Originator-ID attributes are not set.

The above slide illustrates a sample output of the show router bgp routes command with the hunt option
specified. This screen capture is from the RR itself, after it has received the route from the originating router, and
shows the additional RR attributes that will be sent to a non-client. The RR sets the two attributes before
propagating the route.
The RR sets the Cluster- and Originator-ID attributes, but they are only viewable in RIB-OUT.

specified. This screen capture is from the RR itself; it shows that the RR propagates a route received from a client
to an eBGP peer. Since this is an eBGP peer, the RR does not set the Cluster- and Originator-ID attributes

The slide shows that by default, router R1 advertises the route received from router R5 back to the sender, which
is router R5.

The above slide shows that router R5 rejects the route it received from the router R1. Router R5 sees itself as the
Originator-ID and rejects the route.

specified. This screen capture is from the client of the RR, after it has received the route from the RR.
Client router R6 receives a route for prefix 192.168.1.8/29 from its RR. A client in a different cluster originates
the route. The cluster list attribute is updated by each RR that propagates the route. Because the route has
passed through two RRs, the Cluster- and Originator(R5)- ID attributes are set accordingly.

IGP dependencies vary between route reflection and confederations. Either can run a single AS-wide IGP. One
distinct advantage of confederation is that there is no requirement that member autonomous systems use the
same IGP. It is not necessary for each member AS to reveal its internal topology to other member autonomous
systems.
It is more common for confederations to run separate IGPs inside of each member AS, and thereby have more
control over both BGP and IGP scales. When different IGPs are used, however, BGP next-hop reachability must be
guaranteed within each member AS.
ISPs typically try to regionalize traffic so that metrics are lower inside of either cluster in the case of route
reflection, or inside member ASes in the case of member ASes. This is to avoid routing information loops. The
overall objective is to increase IGP metrics between clusters or member ASes. See RFC 3345 for specific examples
of where these techniques are useful.
Both confederations and route reflection increase the chances of routing loops, so it is important that IGP
metrics are handled correctly to keep traffic flows optimal and packet loss at zero.
The scaling techniques also reduce overall iBGP session counts; route reflection is considered easier from a
migration standpoint while confederations require more operational and migration effort.

Module 4 – 58
© 2016 Nokia
1. What is a confederation?
A confederation is a collection of ASes, advertised as a single AS number to BGP speakers that are not
members of the confederation.
2. Which range of AS numbers should be used for member ASes?

In most cases, private AS numbers from 64512 to 65534 should be used within a confederation.
3. What is the main objective behind using route reflection or confederations?

They are both used to simplify the management of the iBGP full mesh. Additionally, confederations can be
used to control the routing policy inside of an AS, while route reflection can introduce hierarchical route
distribution.
4. Which well-known mandatory attribute is modified in a confederation?

The AS_PATH attribute is modified in a confederation AS.
5. What types of BGP sessions exist in a confederation?

BGP sessions between neighbors in the same member AS are iBGP, whereas BGP sessions between neighbors
in different member ASes, or to an AS outside the confederation, are eBGP known as intra-
confederation eBGP.
6. What does an RR do for its defined clients?

An RR disregards the iBGP split-horizon rule for its defined clients only.

7. Which well-known mandatory attributes are modified in an RR environment?
By default, none of the well-known mandatory attributes are modified in an RR environment.
8. What optional non-transitive attributes can be found in an RR environment, and what are they used for?
Originator-ID and CLUSTER_LIST. Both attributes are used for loop detection in an RR environment.
9. How many commands are required to configure RRs?

Only the cluster command is required to configure an RR.
10.Is the Originator-ID attribute present on the originating router?

No; the Originator-ID is set by the first RR that reflects the route, not by the originator itself (unless it is the
RR). If the route loops and returns to the originator, it is discarded.

Module 4 – 61
© 2016 Nokia
Module 5 – 1
© 2016 Nokia
Module 5 – 2
© 2016 Nokia
Module 5 – 3
© 2016 Nokia
Module 5 – 4
© 2016 Nokia
A route is considered internal if:
 It was received from an iBGP peer within the same AS
 It was originated by a router in the same or different cluster of the same AS

 It was received by an iBGP peer of the same member AS of a confederation
A route is considered external if:

 It was received from an eBGP peer in a different AS
 It was received from an eBGP peer of a different member AS of a confederation

Best-external is a BGP enhancement that allows a BGP speaker to advertise to its iBGP peers its best “external” route
for a prefix/NLRI even when its best overall route for the prefix/NLRI is an “internal” route. This is not possible in a
“normal” BGP configuration because the base BGP specification prevents a BGP speaker from advertising a non-best
route for a destination.
In certain topologies, best-external can improve convergence times, reduce route oscillation, and allow better load
sharing. This is achieved because routers internal to the AS have knowledge of more exit paths from the AS.
When two exits are available to reach a particular destination and one is preferred over the other, the availability of an
alternate path provides fast connectivity restoration when the primary path fails. Restoration can be quick since the
alternate path is already at hand. The border router could pre compute the backup route and preinstall it in FIB ready to
be switched when the primary goes away.
In certain topologies involving either route reflectors or confederations, the partial visibility of the available exit points
into a neighboring AS may result in an inconsistent best path selection decision as the routers don't have all the relevant
information. If the inconsistencies span more than one peering router, they may result in a persistent route oscillation.
Advertising the best external route will reduce the possibility of route oscillation by introducing additional information
into the iBGP system.
Enabling the best-external feature is supported only at the config>router>bgp level. This feature can be
enabled/disabled on a per address family basis, with IPv4 and IPv6 as the only options supported initially. Enabling best-
external for IPv4 causes the new advertisement rules to apply to both regular IPv4 unicast routes as well as labeled-IPv4
(SAFI4) routes. Similarly, enabling best-external for IPv6 causes the new advertisement rules to apply to both regular
IPv6 unicast routes as well as labeled-IPv6 (SAFI4) routes.

The topology shown above is used to demonstrate the BGP features discussed in this module, the first of which is
advertise (best) external. AS 65541 is advertising prefix 192.168.1.0/27. AS 65540 prefers ASBR1 as the exit point to
reach prefixes in AS 65541 by increasing the local preference on ASBR1 to 200. Route reflector topology is used for the
iBGP in AS65540, where R1 is the route reflector and ASBR1, ASBR2, and ASBR3 are the clients. AS65542 has an eBGP
session with AS65540. The following slides show the BGP configuration on each router. After that, we will show the
route distribution for prefix 192.168.1.0/27 without using advertise external and then compare it to the route
distribution when advertise external is used.

The above slide shows the BGP configuration on router R3, ASBR1, and ASBR2. Notice the local-preference value on
ASBR1.
The “exportlan” policy shown below is used to advertise the loopback interface on R3 to BGP.
R3>config>router>policy-options# info
----------------------------------------------
prefix-list "LAN3"
prefix 192.168.1.0/27 exact
exit
policy-statement "exportlan"
entry 10
from
protocol direct
prefix-list "LAN3"
exit
action accept
exit
exit
exit

This slide shows the BGP configurations on router R1, ASBR3, and rouer R4. In this case AS65540 uses route reflection
for the iBGP sessions, notice that full-mesh topology can also be used.

Router R3 advertises prefix 192.168.1.0/27 to both ASBR1 and ASBR2. ASBR1 receives the route and advertise is to RR,
which then reflect the route to its clients. ASBR1 sees itself as the originator of the route it receives from RR and flag it
as invalid.
ASBR1# show router bgp routes 192.168.1.0/27 hunt

===============================================================================
===============================================================================
RIB In Entries
-------------------------------------------------------------------------------
Network : 192.168.1.0/27
Nexthop : 10.3.5.3
Path Id : None
From : 10.3.5.3
Local Pref. : None Interface Name : toR3
<output omitted>
AS-Path : 65541
Network : 192.168.1.0/27
Nexthop : 10.10.10.5
Path Id : None
From : 10.10.10.1
Local Pref. : 200 Interface Name : system
<output omitted>
Cluster : 10.10.10.1
Flags : Invalid IGP
AS-Path : 65541

With default BGP configuration ASBR2 selects one best path to (192.168.1.0/27). All other paths remain in Rib-IN and
are never submitted to the Local RIB. ASBR2 compares the two routes based the BGP routing selection criteria, and in
this case chooses the route with the highest Local-Preference value, which is the route received from ASBR1 via RR.

ASBR2 selects the route received from ASBR1 as best and does not advertise it to router R1 because it is an internal
route. Router R1 receives only a single route from ASBR1 and reflects this route to its clients.
ASBR3 receives the route from R1 and advertises it to its eBGP peer router R4. Router R4 in AS65542 receives the
route from ASBR3 as shown below.
R4# show router bgp routes

===============================================================================
===============================================================================
BGP IPv4 Routes
===============================================================================
Nexthop Path-Id Label
As-Path
-------------------------------------------------------------------------------
u*>i 192.168.1.0/27 None None
10.2.4.2 None -
65540 65541
-------------------------------------------------------------------------------
Routes : 1

advertise-external
Syntax [no] advertise-external [ipv4] [ipv6]
Context config>router>bgp
Description This command allows BGP to advertise its best external route to a destination even when its best overall route
is an internal route. Entering the command (or its no form) with no address family parameters is equivalent to
specifying all supported address families. The no form of the command disables Advertise Best External for the
BGP family.
Default no advertise-external
Parameters ipv4 — Enable/disable best-external advertisement for all IPv4 (unicast and labeled-unicast) routes. ipv6 —
Enable/disable best-external advertisement for all IPv6 (unicast and labeled-unicast) routes.

The use of “advertise-external” allows advertisement of the best external route (192.168.1.0 next-hop ASBR2) to
an RR.
Nothing changes on ASBR2, the best route is still the route received from ASBR1
ASBR2# show router bgp routes

===========================================================================
===========================================================================
BGP IPv4 Routes
===========================================================================
As-Path
---------------------------------------------------------------------------
u*>i 192.168.1.0/27 200 None
10.10.10.5 None -
65541
*i 192.168.1.0/27 None None
10.3.6.3 None -
65541

The Route Reflector now receives both routes one from ASBR2 and one from ASBR1. advertise-external allows RR
to have knowledge of the multiple AS exit path, this is where Add-Paths (our second BGP feature) can be useful.

The route reflector will still select the BEST route and advertise it to ASBR3.

This section (advertise-external) presented a situation where the RR selected the best route and advertised only this
route to the other AS boundaries (ASBR3). Add-Paths could be used in this situation to ensure ASBR3 receives more
than one PATH for destination prefix 192.168.1.0/27. Add-Paths is discussed in more detail in the next section.

Module 5 – 18
© 2016 Nokia
Module 5 – 19
© 2016 Nokia
The procedures specified in [RFC4271] allow only the advertisement of one path for a particular address prefix. No
provisions are made to allow the advertisement of multiple paths for the same address prefix, or NLRI. In fact, a route
with the same NLRI as a previously advertised route implicitly replaces the previous advertisement.
In order for a BGP speaker to advertise multiple paths for the same address prefix, a new identifier known as "Path
Identifier" is used so that a particular path for an address prefix can be identified by the combination of the address
prefix and the Path Identifier.
The assignment of the Path Identifier for a path by a BGP speaker is purely a local matter. However, the Path Identifier
must be assigned in such a way that the BGP speaker is able to use the (prefix, path
identifier) to uniquely identify a path advertised to a neighbor. A BGP speaker that re-advertises a route must generate
its own Path Identifier to be associated with the re-advertised route.
In order to carry the Path Identifier in an UPDATE message, the existing NLRI encodings are extended by pre-pending
the Path Identifier field, which is of four-octets.

Add-Paths is a BGP enhancement that allows a BGP router to send and/or receive multiple distinct paths per prefix
to/from a peer using Path Identifier.
The benefits of using BGP Add-Paths include faster convergence (reduction in restoration time after failure), and load
sharing (The availability of multiple paths to reach the same destination
enables load balancing of traffic)
The RIB-IN may have multiple paths for a prefix D. The path selection mode refers to the algorithm used to decide which
of these paths to advertise to an Add-Paths peer. In the current implementation, SR supports only one path selection
algorithm –essentially the Add-N algorithm described in draft-ietf-idr-add-paths-guidelines-00.txt, Best Practices for
Advertisement of Multiple Paths in BGP. The Add-N algorithm implemented in SROS selects, as candidates for
advertisement, the N best overall paths for each prefix, regardless of path type (internal vs. external), degree of
difference between the paths or use in forwarding. If this set of N best overall paths includes multiple paths with the
same BGP NEXT_HOP only the best route with a particular NEXT_HOP is advertised and the others are suppressed.
In the SROS implementation N is configurable, per address-family, at the BGP instance, group and neighbor levels; N has
a minimum value of 1 and a maximum value of 16

Add-Paths capabilities are exchanged between peers during BGP session establishment in the open message. Once Add-
Paths capability has been negotiated with a peer, all advertisements and withdrawals of NLRI within that address family
by that peer shall include a path identifier. Failure to do so will result in a Notification sent by the peer receiving a PATH
with no PATH-ID.
If the combination of NLRI and path identifier in an advertisement from a peer is unique (does not match an existing
route in the RIB-IN from that peer) then the route is added to the RIB-IN. If the combination of NLRI and path identifier
in a received advertisement is the same as an existing route in the RIB-IN from the peer then the new route replaces the
existing one. If the combination of NLRI and path identifier in a received withdrawal matches an existing route in the RIB-
IN from the peer then that route is removed from the RIB-IN.

add-paths
Syntax [no] add-paths
Description This command enables BGP Add-Paths for one or more families configuration of the BGP instance, a group or a
neighbor. The BGP Add-Paths capability allows the router to send and/or receive multiple paths per prefix
to/from a peer.
The add-paths command without additional parameters is equivalent to removing Add-Paths support
for all address families, which causes sessions that previously negotiated the add-paths capability for one or
more address families to go down and come back up without the Add-Paths capability.
The no form of the command (no add-paths) removes Add-Paths from the configuration of BGP, the group or the
neighbor, causing sessions established using Add-Paths to go down and come back up without the Add-Paths
capability.
Default no add-paths
Parameters send send-limit — The maximum number of paths per IPv4 prefix that are allowed to be advertised to add-paths
peers (the actual number of advertised routes may be less depending on the next-hop diversity requirement,
other configuration options, route policies and/or route advertisement rules). The capability to receive multiple
paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive
keyword is not included in the command the receive capability is enabled by default
Values 1 — 16, none

receive — The router negotiates the add-paths receive capability for the routes with its peers
none — The router does not negotiate the Add-Paths receive capability for the routes with its peers.

The above slide shows the route distribution for prefix 192.168.1.0/27 that resulted from the previous section case
study (advertise external). The Route Reflector receives both routes one from ASBR2 and one from ASBR1. RR selects
the best route and advertises only this route to the other AS boundaries (ASBR3). Add-Paths will be used in the
following slides to ensure ASBR3 receives more than one PATH for destination prefix 192.168.1.0/27.

“receive none” indicates the router does not negotiate the Add-Paths receive capability with its peers.
“send 2” indicates the router does negotiate the Add-Paths send capability with its peers, two paths will be sent along
with a Path-ID.
In order to receive multiple paths from a peer on a particular address family, BGP advertisement capability must
indicate that the remote (Remote Add-Paths capability) peer is willing to send multiple paths and that we are willing to
receive more than one path (local Add-Paths Capability).
ASBR3# show router bgp neighbor 10.10.10.1

===============================================================================
BGP Neighbor
===============================================================================
Peer : 10.10.10.1
Group : iBGP_AS65540
-------------------------------------------------------------------------------
Peer AS : 65540 Peer Port : 51289
Peer Address : 10.10.10.1
Local AS : 65540 Local Port : 179
Local Address : 10.10.10.2
Peer Type : Internal
State : Established Last State : Established
<output omitted>
Local AddPath Capabi*: Send - IPv4 (2)
: Receive - IPv4
Remote AddPath Capab*: Send - IPv4
: Receive - None

Following the configuration of Add-Paths on RR and ASBR3, now both paths are advertised from RR to ASBR3. notice
the Path-ID associated with the path.

Both routes are stored in the RIB-IN on ASBR3 and only the best route is selected and placed in the route table as
shown below
ASBR3# show router route-table 192.168.1.0/27

===============================================================================
===============================================================================
-------------------------------------------------------------------------------
192.168.1.0/27 Remote BGP 00h03m20s 170
10.1.2.1 0
-------------------------------------------------------------------------------

A router potentially has several next-hops toward a given destination available. If ECMP is configured to a non-default
value, and more than one route is learned for the same destination, from the same protocol, and with the same metric
value, the router places the configured number of routes into the FIB. OSPF, IS-IS, and BGP support up to 16 equal-cost
paths per destination.
Syntax: [no] ecmp max-ecmp-routes
Description: This command enables ECMP and configures the number of routes for path sharing. For example,
the value 2 means that two equal-cost routes will be used for cost-sharing. ECMP can only be used for routes
learned with the same preference and protocol. When more ECMP routes are available at the best preference than
are configured in max-ecmp-routes, the lowest next-hop IP address algorithm is used to select the
number of routes configured in max- ecmp-routes.
The no form of the command disables ECMP. If ECMP is disabled and multiple routes are available at
the best preference and equal cost, the route with the lowest next-hop IP address is used.
Default: no ecmp
Parameters: max-ecmp-routes — The maximum number of equal-cost routes allowed in this routing table
instance, expressed as a decimal integer. Setting max-ecmp-routes to 1 is the same as no
ECMP.
Values: 0 to 16

Multipath
Syntax multipath integer
no multipath
Description This command enables BGP multipath.
When multipath is enabled BGP load shares traffic across multiple links. Multipath can be configured
to load share traffic across a maximum of 16 routes. If the equal cost routes available are more than the configured
value, then routes with the lowest next-hop IP address value are chosen.
This configuration parameter is set at the global level (applies to all peers).
Multipath is effectively disabled if the value is set to one. When multipath is disabled, and multiple
equal cost routes are available, the route with the lowest next-hop IP address will be used.
The no form of the command used at the global level reverts to default where multipath is
disabled.
Default no multipath
Parameters integer — The number of equal cost routes to use for multipath routing. If more equal cost routes
exist than the configured value, routes with the lowest next-hop value are chosen. Setting this
value to 1 disables multipath.
Values1 — 16
When the number of equal cost routes to use for multipath does not equal the value of the ecmp routes, the lowest
value is used for the number of routes to be installed in the route table. For example, if there are three available paths,
and ecmp = 2 and multipath = 3, then 2 paths will be installed in the route table.

In the slide above, we would like to load balance the traffic between ASBR1 and ASBR2, in order to do that, we have
removed the LP configuration on ASBR1, so the LP on both ASBR1 and ASBR2 has the same value. By enabling ECMP
and multipath on ASBR3, load balancing is achieved.

Notice that enabling Add-paths instead of advertise external on border router ASBR2 can achieve a similar result, but
Add-Paths introduces NLRI format changes that must be supported by BGP peers of the border router, and therefore
has more interoperability constraints than best-external (which requires no messaging changes). Notice the different
values of the Path-ID. Also notice that the Add-Paths receive capability is enabled on R1.
R1# show router bgp routes

===============================================================================
===============================================================================
As-Path
-------------------------------------------------------------------------------
u*>i 192.168.1.0/27 200 None
10.10.10.5 1 -
65541
*i 192.168.1.0/27 100 None
10.10.10.6 1 -
65541
R1# show router bgp neighbor 10.10.10.2 advertised-routes

===============================================================================
===============================================================================
As-Path
-------------------------------------------------------------------------------
i 192.168.1.0/27 100 None
10.10.10.6 4 -
65541
i 192.168.1.0/27 200 None
10.10.10.5 3 -
65541

Module 5 – 32
© 2016 Nokia
Module 5 – 33
© 2016 Nokia
Module 5 – 34
© 2016 Nokia
Module 5 – 35
© 2016 Nokia
Module 5 – 36
© 2016 Nokia
Our goal is not the find the optimal path, but to find a valid path. As soon as the failure is detected, the BGP control
plane will still run and find the optimal path, but until that happen we are using the data plane convergence to use an
alternate path.

Module 5 – 38
© 2016 Nokia
Module 5 – 39
© 2016 Nokia
Module 5 – 40
© 2016 Nokia
The CPM notifies the IOM when the IGP next-hop changes due to IGP convergence.

Module 5 – 42
© 2016 Nokia
Module 5 – 43
© 2016 Nokia
Module 5 – 44
© 2016 Nokia
BGP peer tracking allows a BGP peer to be dropped immediately if the route used to resolve the BGP peer address is
removed from the IP routing table and there is no alternative available. The BGP peer will not wait for the hold timer to
expire; therefore, the BGP reconvergance process is accelerated.

The above slide shows the route distribution for prefix 192.168.1.0/27 that resulted from the previous sections case
study. With Add-Paths enabled on router R1 and ASBR3, ASBR3 receives the two routes for destination prefix
192.168.1.0/27.

backup-path
Syntax backup-path [ipv4] [ipv6]
no backup-path [ipv4] [ipv6]
config>service>vprn>bgp
Description This command enables the computation and use of a backup path for IPv4 and/or IPv6 BGP routes
belonging to the base router or a particular VPRN. Multiple paths must be received for a route in
order to take advantage of this feature. When a route has a backup path and the last of its primary
paths (the equal-cost best paths selected by the multipath algorithm) becomes unreachable,
traffic matching the route is quickly diverted to the backup path. When many routes share the
same set of primary paths and the same backup path, the time to failover traffic to the backup
path is independent of the number of routes.
This feature must be enabled in the VRF for BGP FRR (Edge PIC) for VPN-IPV4/V6.
By default, IPv4 and IPv6 routes do not have a backup path installed in the FIB.
Default no backup-path
Parameters ipv4 — Enables the use of a backup path for IPv4 BGP routes (excluding labeled IPv4 routes and
VPN-IPv4 routes); disable the use of a backup path for IPv4 BGP routes when present in the no
form of the command (as in no backup-path ipv4).
ipv6 — Enables the use of a backup path for IPv6 BGP routes (excluding labeled IPv6 routes and
VPN-IPv6 routes); disable the use of a backup path for IPv6 BGP routes when present in the no form
of the command (as in no backup-path ipv6).
vpn-ipv4 — Enables the use of a backup path for vpn-ipv4 BGP routes; disables the use of a backup
path for VPN-IPv4 BGP routes when present in the no form of the command (as in no backup-
path vpn-ipv4).
vpn-ipv6 — Enables the use of a backup path for VPN-IPv6 BGP routes; disables the use of a backup
path for VPN-IPv6 BGP routes when present in the no form of the command (as in no backup-
path vpn-ipv6)

===============================================================================
===============================================================================
RIB In Entries
-------------------------------------------------------------------------------
Network : 192.168.1.0/27
Nexthop : 10.10.10.5
Path Id : 1
From : 10.10.10.1
<output omitted>
AS-Path : 65541
Network : 192.168.1.0/27
Nexthop : 10.10.10.6
Path Id : 2
From : 10.10.10.1
<output omitted>
Flags : Used Valid Backup IGP
TieBreakReason : LocalPref
AS-Path : 65541

Module 5 – ‹#›
© 2016 Nokia
The above slide shows that prefix 192.168.1.0/27 has a backup path as indicated by the flag [B]. Also notice the
number [2] which indicates there is only one backup path to this route.

===============================================================================
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network : 192.168.1.0/27
Nexthop : 10.10.10.6
Path Id : 2
From : 10.10.10.1
AIGP Metric : None
Connector : None
Cluster : 10.10.10.1
AS-Path : 65541

Once the interface toASBR3 is up, BGP will use the original path and will restore the backup path.

Module 5 – 52
© 2016 Nokia
1. List three benefits of BGP advertise-external feature.
BGP advertise-external improves convergence times, reduces route oscillation and allows better load sharing.
2. What is Path Identifier used for?

Path Identifier allows a BGP speaker to advertise multiple paths for the same prefix.
3. BGP Add-Paths can be configured at the BGP level only, true or false?
False
4. In addition to BGP Add-Paths, what configuration is required to allow BGP to install multiple best paths in the routing
table?
Multipath and ECMP should also be configured to allow BGP to install multiple best paths in the routing table.
5. What is the objective of BGP FRR?

The objective is to make the convergence time independent of number of prefixes (PIC).

Module 5 – 54
© 2016 Nokia
Module 6 – 1
© 2016 Nokia
Module 6 – 2
© 2016 Nokia
Module 6 – 3
© 2016 Nokia
Module 6 – 4
© 2016 Nokia
Module 6 – 5
© 2016 Nokia
Module 6 – 6
© 2016 Nokia
Module 6 – 7
© 2016 Nokia
Module 6 – 8
© 2016 Nokia
Module 6 – 9
© 2016 Nokia
Module 6 – 10
© 2016 Nokia
Module 6 – 11
© 2016 Nokia
Module 6 – 12
© 2016 Nokia
Module 6 – 13
© 2016 Nokia
Module 6 – 14
© 2016 Nokia
Module 6 – 15
© 2016 Nokia
Module 6 – 16
© 2016 Nokia
Module 6 – 17
© 2016 Nokia

Nokia Border Gateway Protocol SG v3.1.1

Uploaded by

Copyright:

Available Formats

You might also like

Nokia Border Gateway Protocol SG v3.1.1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nokia Border Gateway Protocol SG v3.1.1

Uploaded by

Copyright:

Available Formats

Module 0 | 1

Border Gateway Protocol v3.1.1

Module 0 | 2 Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 7 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 10 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

The 14 Tier 1 ISPs are identified as (again, subject to debate):

AT&T (AS 7018)

Module 1 – 11 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 12 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 13 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

2. Public vs. Private Peering

Module 1 – 14 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

5. Transit AS Policy / Origin of routes (perhaps the most important part)

Peering Do’s and Don’ts

Module 1 – 15 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 16 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 17 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 21 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 22 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 23 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 24 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

3. Therefore AS 135000 (ASPLAIN) is 2.3928 in ASDOT notation.

Module 1 – 25 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 26 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 27 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 29 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 31 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 32 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 33 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 34 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 35 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 36 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 37 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 38 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 39 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 40 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 41 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 44 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 45 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 47 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 48 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 49 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 50 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

A neighbor may also be in the Idle state, if it is administratively shut down.

Module 1 – 51 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 52 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 53 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 54 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 55 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Well-known attributes have two subcategories: mandatory and discretionary.

Optional attributes have two subcategories: transitive and non-transitive.

Therefore, BGP attributes are categorized in one of 4 ways:

Module 1 – 58 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Module 1 – 59 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

Transitive or non-transitive characteristics relate to their handling by the receiving peer.

Module 1 – 60 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia

The ORIGIN attribute can be one of the following values:

Once it is set, the ORIGIN attribute should never be modified.

Module 1 – 61 Nokia Border Gateway Protocol v3.1.1 © 2016 Nokia