An Investigation of BGP Convergence

An investigation of
BGP convergence
How does the Routing Protocol of the
internet adapt to changes in a large
internetwork within seconds?
Naveen Nagalingam
1
Acknowledgements
Name and designation of project guide:
Dinesh Jangid
Network Engineer/Technical consultant

Technology trainer at INTER-NETWORKZ since April 2015. Delivered
Several trainings on various Networking topics
Contact no. +91-9019614116/ +91-9343836252 / +91-80-48533552
dinesh@inter-networkz.com
INTER NETWORKZ
No. 21, 2nd Floor,
Above Hotel Empire,
Kammanahalli Main Road,
Kammanahalli Circle,
Kacharakanahalli,
St. Thomas Town P.O.
Bengaluru, Karnataka 560084
Signed Bona fides

2
UNDERTAKING FROM THE CANDIDATE
This is to certify that I, Naveen Nagalingam, have completed

the Project work on the topic An investigation of BGP
convergence under the guidance of Dinesh Jangid for the
partial fulfillment of the requirement for the degree of Bachelor
of Computer Applications, Amity University Online.
This is an original piece of work & I have not submitted it earlier

elsewhere.
I declare that I have faithfully acknowledged, given credit to

and referred to research work wherever works have been cited
in the text and the body of the project. I further certify that I
have not willfully copied others work, text, data, results, etc.
reported in the journals, books, magazines, reports,
dissertations, theses, etc., or available at web-sites and have
included them in this project and cited as my own work.
I have used the APA 6th Edition citation style, as per the
requirements of the Dissertation Guidelines.
Date: 15-05-2017
Signature
Name of candidate
Naveen Nagalingam
3
Table of Contents
Acknowledgements..............................................................................................................................1
UNDERTAKING FROM THE CANDIDATE...........................................................................1
CHAPTER 1 Introduction..................................................................................................................4
CHAPTER 2: Literature Review........................................................................................................5
CHAPTER 3 Research Methodology.................................................................................................8
Tools | Files.......................................................................................................................................8
CHAPTER 4 Presentation and Analysis of Data.............................................................................11
Removing a Private (Customer) AS number before propagating the route to eBGP peers..11
Full IBGP Mesh using Route-Reflectors..................................................................................12
Mutually coexisting Interior Gateway Protocol (EIGRP) and BGP......................................14
Route filtering with a Suppress-map........................................................................................16
Unsupress-Map..........................................................................................................................18
Intra-AS route injection across an ISP.....................................................................................18
BGP and IGP Redistribution....................................................................................................21
Confederations...........................................................................................................................25
CHAPTER 6 Discussion and Interpretation of Findings................................................................26
CHAPTER 7 Conclusions and Recommendations..........................................................................26
Schedule of Work Completion......................................................................................................27
References..........................................................................................................................................28
Bibliography.......................................................................................................................................30
4
CHAPTER 1: Introduction & Literature Review
Domain: Network Protocols; Routing Protocols; Computer Communication Networks;

Internetworking
Router hardware
Current models of the distribution of the internet define a 3 tier hierarchical model, where providers of
internet access compete with each other using business contracts called Service Level Agreements
(SLA). The competition is based on guarantees of performance and availability and who owns which
physical layer interconnections. In such an environment it is commonly understood that when a
Transit provider pays for peering from another, it cannot ever establish itself at an equivalent service-
providing level as its provider. Service providers at the Tier 1 layer may connect with each other to
exchange routes and data traffic, in an arrangement known as peering, via a Network Access Point or
Point of Presence (e.g. National Internet Exchange of India (NIXI)). The main protocol responsible
for subscriber-ISP interconnections and peering at the core/backbone is Border Gateway Protocol.
(Halabi, Halabi, & McPherson, 2000)(Blum, 2012)
Routing protocols operating at these layers facilitate the transport of routing information, along with
metrics, bandwidth information, delay timers, and configurable attributes which can be filtered to
further affect the best path selection decision process. Distance-vector protocols used within campus
networks and at the edges of the network include Enhanced Integrated Gateway Routing Protocol
(EIGRP), and link-state protocols include Open Shortest Path First (OSPF), Routing Information
Protocol (RIPv2), and Intermediate System-to-Intermediate System (IS-IS). All can be used in
conjunction with BGP as Interior Intra-AS Gateway Protocols or.
A significant problem for the backbone routers early on was the speed of expansion of customer
nodes.
When businesses began seeing the value of the Internet in the early 1990s, an
explosion in growth began that eventually took its toll on the Internet's backbone
routersmostly Cisco 7500s. The traffic explosion was paralleled by an
increasing demand for reliability, as people began using the World Wide Web
and e-mail as ways of doing business. (White, Bollapragada, & Murphy, 2008)
(White et al., 2008)

Initially the solution to the scalability problem was EGP, Exterior Routing Protocol, which replaced
the Gateway-Gateway Protocol. GGP required a full-mesh topology which overburdened router
computing resources, with the number of sessions that needed to be maintained and the number of
updates that had to be sent. EGP eliminated the full-mesh requirement, introducing the division of the
single internetwork into Autonomous Systems, and allowing for routers to speak across non-EGP
protocols. However as the number of routes continued to grow exponentially, EGP, proved to be too
slow to converge and susceptible to failure. A more extensible, robust and scalable protocol was
needed. With EGP the main problems were:
No neighbour discovery function: Manually configuring neighbour addresses is required for

every core layer router.
5
Inability to detect routing loops: (extension of previous point) A TTL was set to 255 however
with the default timers used it would take 13 hours for it to expire.
No support for policy-based routing
no optimal path selection between networks
To provide this functionality Border Gateway Protocol with support for CIDR, BGP-v4 was
introduced with the RFC1771 specification in 1995, when the IPv4 address space was considered to
be depleting. The Classless InterDomain Routing (CIDR) scheme introduced route aggregation at the
Provider-Edge, where the Class A, B, and C address space of Customers were advertised into the core
as an aggregate (CIDR). An address block is allocated to Service Providers from the address, thereby
decreasing the number of routes that need to be announced. Also instabilities in last-hop customer
networks do not propagate to the internet, since only an aggregate address is announced. This
effectively made the large-scale routing more manageable and reliable.
The latest BGP implementation is defined in the Internet Engineering Task Force (IETF) RFC4271
and while mostly vendor-neutral, some minor exceptions exist in its finite-state machine. The best
path decision process flows through the following steps in determining a route with competing paths:
1. Weight (Highest)
2. Local Preference (Highest)
3. Originated locally
4. AS Path (Shortest)
5. Origin code (IGP vs. EGP vs. Incomplete)
6. MED (Lowest)
7. Path (ebgp vs. ibgp)
8. Router ID (lowest)
(Rekhter, 2006)
The internet has in various places been described as a complex natural ecosystem, and has been
extensively studied in macroscopic and microscopic views. One of A useful tthe taxonomiesy that
has been proposed for the approximately 27,000 major AS species that constitute the Internet is
International ISPs, or Large Transit Providers (LTP) : : Level3, Telia Sonera, NTT, Cogent,
Tata, GTT, Sify
Regional ISPs or Small Transit Providers (STP): Airtel, Vodafone, Idea Cellular, Reliance
Communications, BSNL
Enterprise Customers (EC): includes universities
Access/Hosting Providers (AHP) and Content Providers (CP)
This classification scheme is based on mappings of AS numbers to organisation records from the
major Regional Internet Registries RIRs, and have been observed to stably characterise the major
entities of the internet over a ten-year period. Each of these groups has different optimization
requirements based on different business interests. The group deemed to be most constantly evolving
in rewiring terms (shifting providers, multihoming degrees etc.) is AHP and CP, while the core
backbone, LTP and STP, remain relatively stable in terms of degrees of nodes. (Dhamdhere &
Dovrolis, 2011)
Two points of failure historically have arisen in BGP implementations. The first was hardware
failure. Modern core-layer router architecture has been adapted to meet the demands of the
burgeoning routing table in two ways:
6
1. Specialized ASIC hardware dedicated to the separate datapath functions respectively: making
forwarding decisions, managing queues, and bus arbitration. This replaces earlier models that
relied exclusively on general-purpose processors (White et al., 2008)
N
2. Parallel crossbar switching fabric using fixed size data cells, whereby 2 busses (N =
number of line cards) are connected at N*N crosspoints allowing multiple Line cards to
transmit and receive data simultaneously. It uses unique bus scheduler, and replaces the
shared bus architecture. (Mckeown, n.d.)
Physical layer issues that arise in a densely meshed network, such as those that are the Tier 1 ASs,
have also been addressed in software enhancements.
The circuits used in computer networks have the unfortunate property

that they can intermittently fail and then recover. This was an especially
common failure mode for copper-based circuits. Under such circumstances,
when there was a BGP speaker on both ends of the circuit, any prefixes
advertised across the link would tend to oscillate at the frequency induced by the
intermittent link.
(Li, 2007)
The particular problem quoted above led to a software feature called route-flap damping a timer
based penalty value is assigned to a route that appears to have a continuously alternating
availability status(indicating a hardware or software failure).(Mcpherson & Patel, 2006)
Since the early 2000s various non-commercial tools have been developed to collect and analyze BGP
data. When combined withMaintained by RIRs, BGP data is collated collected byfrom individual
ISPs to form as well as by public archives such as RouteViews and RIPE RIS, and Looking
Glasses. tThese tools cancontinue to be exploited and developed potentiallyfor providinge
invaluable insight into the operations of inter-domain routing, providing the
basis for much of the research into improvements made in the Sspecificity of BGP. Studies have
determined the statistical performance of daily BGP update stability using this data over periods of
several months, and the continental RIRs are constantly engaged in this effort. (Morley Mao, Bush,
Griffin, & Roughan, 2003)(Labovitz, Malan, & Jahanian, 1999)(Orsini, King, Giordano, Giotsas, &
Dainotti, n.d.)(Calvert, Doar, & Zegura, 1997)(Donnet & Friedman, 2007)
The second cause for routing instability, though very infrequent, is misconfiguration due to human
error. In BGP conflicting routing policies may lead to persistent cycles, increasing router workload by
overburdening the routing tables with redundant information. Misconfigurations due to human error
have historically resulted in connectivity failures for large regions of the Internet for several hours.
Knowledge of vendor-specific routing policy configuration including BGP semantics continue to be
recognised through professional certification by companies specialising in data communications and
storage networking products, such as Brocade, Juniper, Cisco, etc. The complexity of inter-AS
systems has led to development of high-level language checkers, which check for the consistency of
policy semantics. These tools have not been widely deployed by ISPs mainly because the multiplicity
of router vending equipment and product versions make such tools unwieldy and quickly outdated.
(Mahajan, Wetherall, & Anderson, 2002) This warrants the study of configuration semantics
7
features in meeting network requirementsCHAPTER 3

Research Methodology
Tools | Files
Minimum Hardware Requirements
Processor 2 or more Logical cores
Virtualizatio Virtualization extensions required. You may need to enable this via your computer's
n BIOS.
Memory 4 GB RAM
Storage 1GB available space (Windows Installation is < 200MB).
Software Requirements
Graphical Network Simulator 3 v2.0 can also be downloaded here with a free account here.
https://www.gns3.com/software/download
Valid Cisco c7200 Router images running IOS 15.0 or later can also be purchased here.
https://software.cisco.com/download/release.html?
mdfid=282188585&softwareid=280805680&release=15.2.4S7&flowid=812
We will be concerned only with the behavior of e-BGP and i-BGP features and the implementation of
consistent policies that allow for route stability on the internet. The main objective of this study is to
investigate the (inter-domain, and intra-domain) BGP decision process in order to.
propagate new information

prevent routing loops
validate peers
mutually redistribute routes and coexist with IGP's
implement routing scalability features: clustering, confederations
Graphical Network Simulator (GNS3) was used with Cisco software images, to create the topology.
An emulated CLI running Cisco Internetwork Operating System (IOS) 15.0 was used to configure
each router for a basic level of BGP connectivity. Then a subset of BGP features was implemented
over a simulated internetwork to create route stability. For this,The features and dynamics tested in
this simulation are specifically (refer to next page). Routers were initially configured as per the
topology diagram with loopback and physical interface addresses
AS100 to AS200: Routing a Private AS over the Internet by using remove-private-as

AS 200: Full IBGP mesh using route-reflectors
AS200: Route suppression
AS300: Full IBGP mesh using an Interior Gateway Protocol EIGRP
AS400: Intra-AS routing over an ISP
8
AS500: Confederations
These requirements are relevant in the peering and transit relationships of large ISPs and enterprise
customers.We evidenced the protocols behaviour in the BGP and routing tables after configuration by
using show commands, the results of which are in the following section.
Figure 1: Topology
9
10
Figure 2 : Topology constructed in

GNS3 with virtual Cisco 7200
11
routers
CHAPTER 5 Presentation and Analysis of Data

12
Removing a Private (Customer) AS number before propagating the route to eBGP peers
(AS100 AS200)
AS65000 is in the private AS space of 64512 to 65535. It has been assigned to R3, which is a single-
homed customer network.
Problem
Before removing the private-as number R1s BGP table in AS100, contains the private-as number
R1#show ip bgp
BGP table version is 16, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path

Output truncated
*> 2.2.2.2/32 10.10.2.1 0 0 100 i
*> 3.3.3.3/32 10.10.2.1 0 100 65000
Configuration
R2:
router bgp 100
neighbor 10.10.1.1 remote-as 65000
neighbor 10.10.2.2 remove-private-as
Result
R1#sh ip bgp
R1#sh ip bgp
internal,

*> 1.1.0.0/21 0.0.0.0 32768 i
s> 1.1.1.1/32 0.0.0.0 0 32768 i
s> 1.1.2.1/32 0.0.0.0 0 32768 i
s> 1.1.3.1/32 0.0.0.0 0 32768 i
*> 1.1.4.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.10.2.1 0 0 100 i
*> 3.3.3.3/32 10.10.2.1 0 100 i
* i4.4.4.4/32 10.10.5.1 0 100 0 i
*>i 10.10.3.2 0 100 0 i
*> 10.10.1.0/24 10.10.2.1 0 0 100 i
r> 10.10.2.0/24 10.10.2.1 0 0 100 i
13
Full IBGP Mesh using Route-Reflectors (AS200)

Problem
To create a full IBGP mesh, which also advertises EBGP learned routes.
Configuration
BGP uses cluster-ids to identify a group of reflecting routers, not accepting reflected routes within the
same id. Thus we can create a full mesh iBGP with route reflectors, by configuring unique cluster-ids
and each node as a client of the others.
R1
router bgp 200

bgp router-id 1.1.1.1
bgp cluster-id 1.1.1.1
network 1.1.1.1 mask 255.255.255.255
network 1.1.2.1 mask 255.255.255.255
network 1.1.3.1 mask 255.255.255.255
network 1.1.4.1 mask 255.255.255.255
neighbor 10.10.2.1 next-hop-self
neighbor 10.10.3.2 route-reflector-client
R4
router bgp 200

bgp log-neighbor-changes
network 4.4.4.4 mask 255.255.255.255
R5
router bgp 200

bgp log-neighbor-changes
network 5.5.5.255 mask 255.255.255.255
neigh 10.10.5.1 remote-as 200
neigh 10.10.5.1 route-reflector-client
neigh 10.10.4.1 next-hop-self
neigh 10.10.4.1 route-reflector-client
14
Results
R1, R4 and R5 now have a full view of routes in AS 200, and AS100 with each loopback reachable by both
routes. Example below
R1s BGP table

R5#show ip bgp

internal,

*> 1.1.0.0/21 0.0.0.0 32768 i
s> 1.1.1.1/32 0.0.0.0 0 32768 i
s> 1.1.2.1/32 0.0.0.0 0 32768 i
s> 1.1.3.1/32 0.0.0.0 0 32768 i
*> 1.1.4.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.10.2.1 0 0 100 i
*> 3.3.3.3/32 10.10.2.1 0 100 i
*>i4.4.4.4/32 10.10.3.2 0 100 0 i
*>i5.5.5.5/32 10.10.4.2 0 100 0 i
Route filtering with a Suppress-map (AS200)
Basic intra-BGP set-up has given R5 a complete view of AS200.
Problem
We want to filter the following routes from R1s four loopbacks from being advertised to R5
1.1.1.1/32
1.1.1.2/32
1.1.1.3/32
This prevents these routes being propagated further. .

Addresses in the range 1.1.2.1 1.1.3.1 will be filtered from being advertised to R5, preventing these
routes being spread to other ASs.
To filter an aggregate address range like this, we can create an access-list of the routes to be filtered
inside a route-map, then reference it using the suppress-map option under the BGP process.
Configuration
An access-list is used specifying for the address-range to be filtered out.
BGP understands prefix-lists, route-maps and peer-templates. For a simple list of addresses in an
aggregate address range, we can use an access-list, matched in a route-map clause. Since these
addresses are classful (/29) the BGP suppress-map feature can be used referring the route-map to an
aggregate-address range.
R1
ip access-list standard SUPPRESS-Lo1-2

permit 1.1.1.1 0.0.0.255
permit 1.1.2.1 0.0.0.255
15
permit 1.1.3.1 0.0.0.255

exit
route-map Suppress-Map
match ip address SUPPRESS-Lo1-2
exit
router bgp 200

aggregate-address 1.1.0.0 255.255.248.0 suppress-map Suppress-Map
no auto-summary
exit
Result
R4#sh ip bgp

internal,

*>i1.1.0.0/21 10.10.4.1 0 100 0 i
*>i1.1.4.1/32 10.10.3.1 0 100 0 i
* i 10.10.4.1 0 100 0 i
*>i2.2.2.2/32 10.10.3.1 0 100 0 100 i
* i 10.10.4.1 0 100 0 100 i
*>i3.3.3.3/32 10.10.3.1 0 100 0 100 i
* i 10.10.4.1 0 100 0 100 i
*> 4.4.4.4/32 0.0.0.0 0 32768 i
R5#sh ip bgp

internal,

*>i1.1.0.0/21 10.10.4.1 0 100 0 i
*>i1.1.4.1/32 10.10.4.1 0 100 0 i
*>i2.2.2.2/32 10.10.4.1 0 100 0 100 i
r>i3.3.3.3/32 10.10.4.1 0 100 0 100 i
*>i4.4.4.4/32 10.10.5.1 0 100 0 i
* i 10.10.3.2 0 100 0 i
*> 5.5.5.5/32 0.0.0.0 0 32768 i
R5#sh ip bgp
*>i1.1.0.0/21 10.10.4.1 0 100 0 i
*>i1.1.4.1/32 10.10.4.1 0 100 0 i
*>i2.2.2.2/32 10.10.4.1 0 100 0 100 i
r>i3.3.3.3/32 10.10.4.1 0 100 0 100 i
* i4.4.4.4/32 10.10.3.2 0 100 0 i
16
Mutually coexisting Interior Gateway Protocol (EIGRP) and BGP

Configuration
EIGRP was used as the IGP in AS 300. OSPF may also have been used to the same effect
however the configuration would have been slightly longer.
To form a complete IBGP mesh in AS300, an IGP was configured with routers not directly
connected to each other configured as BGP next-hop neighbours.
R6 R10
router eigrp 300 router eigrp 300
network 10.10.1.0 0.0.0.255 network 10.10.1.0 0.0.0.255
network 10.10.9.0 0.0.0.255 network 10.10.11.0 0.0.0.255
network 6.6.6.6 0.0.0.0 network 10.10.10.10 0.0.0.0
router bgp 300 router bgp 300
neigh 11.11.11.11 remote-as 300 neigh 9.9.9.9 remote-as 300
neigh 11.11.11.11 update-sour lo0 neigh 9.9.9.9 update-sour lo0
neigh 11.11.11.11 next-hop-self neigh 9.9.9.9 next-hop-self
R9 R11
network 10.10.9.0 0.0.0.255 network 10.10.11.0 0.0.0.255
network 10.10.12.0 0.0.0.255 network 10.10.12.0 0.0.0.255
network 9.9.9.9 0.0.0.0 network 11.11.11.11 0.0.0.0
neigh 10.10.10.10 update-sour lo0 neigh 6.6.6.6 update-sour lo0
17
Results
i. Intra-AS full connectivity

ii. Full installation of routes
Pings between R6 to R11
R11#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Success rate is 80 percent (4/5), round-trip min/avg/max = 284/374/448 ms
R6#ping 11.11.11.11
!!!!!
R6#
Pings between R10 and R9
R10#ping 9.9.9.9
!!!
%BGP-5-ADJCHANGE: neighbor 10.10.11.2 Up
%BGP-5-ADJCHANGE: neighbor 10.10.1.1 Up !!
R9#ping 10.10.10.10
!!!!!
iii. Routes from both protocols have been installed the routing table, evidenced
from R6s show ip route output
R6#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
18.0.0.0/24 is subnetted, 1 subnets

B 18.18.18.0 [20/0] via 10.10.7.2, 01:26:26
B 20.20.20.20 [20/0] via 10.10.7.2, 01:26:26
18
6.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C 6.6.6.0/24 is directly connected, Loopback0
D 6.0.0.0/8 is a summary, 00:16:24, Null0
B 8.8.8.8 [20/0] via 10.10.7.2, 01:26:26
C 10.10.1.0/24 is directly connected, Serial1/1
D 10.10.10.0/24 [90/2297856] via 10.10.1.2, 00:16:30, Serial1/1
B 10.10.17.0/24 [20/0] via 10.10.7.2, 01:26:38
B 10.10.18.0/24 [20/0] via 10.10.7.2, 01:26:38
Unsuppress-Map (AS200)
Problem
We want to filter routes specifically for R5, advertising all R1s loopback addresses unfiltered to R4.
Configuration
R1
ip prefix-list Unsuppress-Map seq 5 permit 0.0.0.0/0 le 32

exit
route-map Unsuppress-Map permit 10
match ip address prefix-list Unsuppress-Map
router bgp 100

neighbor 10.10.3.2 unsuppress-map Unsuppress-Map
With Route Reflectors in place, R3 will reflect the Unsuppress-Map to R5. Since Route-Reflectors do
not accept information from the same cluster, we configure R5 with the same cluster-id as R4.
R5
router bgp 200

Results
R4#sh ip bgp

internal,

*>i1.1.0.0/21 10.10.3.1 0 100 0 i
* i 10.10.4.1 0 100 0 i
*>i1.1.1.1/32 10.10.3.1 0 100 0 i
19
*>i1.1.2.1/32 10.10.3.1 0 100 0 i

*>i1.1.3.1/32 10.10.3.1 0 100 0 i
*>i1.1.4.1/32 10.10.3.1 0 100 0 i
* i 10.10.4.1 0 100 0 i
R5#sh ip bgp
internal,

*>i1.1.0.0/21 10.10.4.1 0 100 0 i
*>i1.1.4.1/32 10.10.4.1 0 100 0 i
*>i2.2.2.2/32 10.10.4.1 0 100 0 100 i
r>i3.3.3.3/32 10.10.4.1 0 100 0 100 i
*>i4.4.4.4/32 10.10.5.1 0 100 0 i
* i 10.10.3.2 0 100 0 i
*> 5.5.5.5/32 0.0.0.0 0 32768 i
*>i10.10.1.0/24 10.10.4.1 0 100 0 100 i
*>i10.10.2.0/24 10.10.4.1 0 100 0 100 i
20
Mutually coexisting Interior Gateway Protocol (EIGRP) and BGP (AS300)
Problem
We need full Intra-AS connectivity i.e. an IBGP full mesh.
Configuration
EIGRP was chosen as the IGP in AS 300. OSPF may also have been used to the same effect however
the configuration is slightly longer, since metrics need to be specified.
EIGRP requires only network commands for directly connected networks and the loopback interface
To form a complete IBGP mesh in AS300, an IGP was configured for each node in the AS.
Then BGP neighbour relationships are established with non-adjacent nodes, using two extra
commands
1. Neighbour [ip address] update-source loopback 0

A request to peer must come in from a IP address specified within a neighbour
statement. Since we are using loopbacks, this command
2. Neighbour [ip address] next-hop self
By default advertised routes are installed into the BGP table as they are received with
the next-hop unchanged. For the purposes of a mesh this can be corrected with this
command on the advertising router to change the next-hop for the specified neighbour
to the its own loopback.
R6 R10

network 10.10.1.0 0.0.0.255 network 10.10.1.0 0.0.0.255
network 10.10.9.0 0.0.0.255 network 10.10.11.0 0.0.0.255
network 6.6.6.6 0.0.0.0 network 10.10.10.10 0.0.0.0

neighbor 10.10.10.10 remote-as 300 neighbor 6.6.6.6 remote-as 300
neighbor 10.10.10.10 update-source Loopback0 neighbor 6.6.6.6 update-source Loopba
neighbor 10.10.10.10 next-hop-self neighbor 6.6.6.6 next-hop-self
neighbor 9.9.9.9 update-source Loopback0 neighbor 11.11.11.11update-source Lo
neighbor 9.9.9.9 next-hop-self neighbor 11.11.11.11next-hop-self
neigh 11.11.11.11 update-source lo0 neigh 9.9.9.9 update-source lo0
R9 R11

network 10.10.9.0 0.0.0.255 network 10.10.11.0 0.0.0.255
21
network 10.10.12.0 0.0.0.255 network 10.10.12.0 0.0.0.255

network 9.9.9.9 0.0.0.0 network 11.11.11.11 0.0.0.0

neighbor 6.6.6.6 update-source Loopback0 neighbor 10.10.10.10 update-source Lo
neighbor 6.6.6.6 next-hop-self neighbor 10.10.10.10 next-hop-self
neighbor 11.11.11.11update-source Loopback0 neighbor 9.9.9.9 update-source Loopba
neighbor 11.11.11.11next-hop-self neighbor 9.9.9.9 next-hop-self
neigh 10.10.10.10 update-source lo0 neigh 6.6.6.6 update-source lo0
Results
Pings between R6 to R11
R11#ping 6.6.6.6

R6#ping 11.11.11.11

!!!!!
R6#
Pings between R10 and R9
R10#ping 9.9.9.9

!!!
R9#ping 10.10.10.10

!!!!!
Example routing tables from R6 showing a full mesh the entire AS is installed
22
R6#show ip route

C 6.6.6.6/32 is directly connected, Loopback0
D 9.9.9.0 [90/2297856] via 10.10.9.2, 00:01:13, Serial1/2
D 10.10.10.0/24 [90/2297856] via 10.10.1.2, 00:03:33, Serial1/1
D 10.10.11.0/24 [90/2681856] via 10.10.1.2, 00:01:14, Serial1/1
D 10.10.12.0/24 [90/2681856] via 10.10.9.2, 00:01:15, Serial1/2
D 11.11.11.11 [90/2809856] via 10.10.9.2, 00:01:35, Serial1/2
[90/2809856] via 10.10.1.2, 00:01:35, Serial1/1
23
Removing a Private (Customer) AS number before propagating the route to eBGP peers
AS65000 is in the private AS space of 64512 to 65535. It has been assigned to R3, which is a single-
homed customer network. P---------------------------------------
Before removing the private-as number R1s BGP table in AS100 :
Problem
R1#sh ip bgp
* 2.2.2.2/32 10.10.2.1 0 0 100 i
* 3.3.3.3/32 10.10.2.1 0 100 65000 i
* i4.4.4.4/32 10.10.3.2 0 100 0 i
* i6.6.6.0/24 10.10.5.2 0 100 0 300 i
* i10.10.6.0/24 10.10.5.2 0 100 0 300 i
* i10.10.10.0/24 10.10.5.2 0 100 0 300 i
Configuration
R2:
router bgp 100
neighbor 10.10.2.2 remove-private-as
Result
R1#sh ip bgp
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

*> 1.1.0.0/21 0.0.0.0 32768 i
s> 1.1.1.1/32 0.0.0.0 0 32768 i
s> 1.1.2.1/32 0.0.0.0 0 32768 i
s> 1.1.3.1/32 0.0.0.0 0 32768 i
*> 1.1.4.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.10.2.1 0 0 100 i
*> 3.3.3.3/32 10.10.2.1 0 100 i
Intra-AS route injection across an ISP (AS400)
Problem
R8 and R18 are two branch routers of an enterprise.
Both networks have neither visibility nor connectivity.
R8#ping 18.18.18.18

.....
24
Success rate is 0 percent (0/5)
R18(config-router)#do ping 8.8.8.8

.....
Success rate is 0 percent (0/5)
Both run BGP using the same AS while connecting through an ISP. The BGP loop prevention
mechanism is to drop a route received with the same AS as that of the receiving router in the
AS_PATH.
Final Configuration
For BGP updates to flow here, the allowas-in feature is used.
R18(config-router)#do sh ip bgp
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r> 10.10.18.0/24 20.20.20.20 0 0 800 i
*> 18.18.18.18/32 0.0.0.0 0 32768 i
r> 20.20.20.20/32 20.20.20.20 0 0 800 i
R18s connection to ISP ebgp-multihop feature was used to indicate the nature of the ISP
R18(config-router)#

neighbor 10.10.18.1 ebgp-multihop 4
neighbor 10.10.18.1 allowas-in
R8(config-router)#

neighbor 10.10.17.2 ebgp-multihop 4
neighbor 10.10.17.2 allowas-in
Result
Successful pings between R18 and R8 show reachability
R18(config-router)#do ping 8.8.8.8

!!!!!
R8#ping 18.18.18.18

25

!!!!!
AS400 has now been installed with the >* symbol indicating valid and best routes exist.
R18#show ip route

B 8.8.8.8 [20/0] via 10.10.18.1, 00:04:09
B 10.10.17.0/24 [20/0] via 10.10.18.1, 00:04:39
L 10.10.18.2/32 is directly connected, Serial1/0
C 18.18.18.18 is directly connected, Loopback0
S 20.20.20.20 [1/0] via 10.10.18.1
26
Redistribution into BGP BGP and IGP Redistribution (AS400 AS300)
Problem
R7 runs EIGRP100 with R8, and BGP1000 with R6.
R8
router eigrp 100

network 10.10.8.0 0.0.0.255
R7
router eigrp 100

network 7.7.7.7 0.0.0.0
network 10.10.8.0 0.0.0.255
The goal is to establish connectivity and visibility between AS300 and AS400 across R7 by
redistributing routes between the IGP and BGP processes. We will also redistribute a static
route to the ISP (AS800) to R6.
Configuration
R7 is configured with a static route to the ISP network.
R7(config)#ip route 10.10.17.2 255.255.255.255 10.10.8.1
R7 is configured for the BGP process 1000.
Redistribute the static route, directly connected routes and eigrp.
Neighbor statements for R6.
R7
router bgp 1000

network 7.7.7.7 mask 255.255.255.255
redistribute connected
redistribute static
redistribute eigrp 100
Redistribute EIGRP learned routes from R8 into R7s BGP Updates sent to R6
R7
redistribute bgp 1000

27
R6
R8
router eigrp 100

network 10.10.8.0 0.0.0.255
Results
R6 is now aware of the EIGRP routes via BGP.

AS400 has visibility of AS300 through EIGRP redistribution, and vice-versa
o D EX in the R8 IP routing table indicates the route was learned via external EIGRP
o R18 across the ISP has routing table entries from R6
R7s BGP table showing EIGRP learned routes the metric indicates redistribution
R7#

*> 7.7.7.7/32 0.0.0.0 0 32768 i
*> 8.8.8.8/32 10.10.8.1 2297856 32768 ?
*> 10.10.7.0/24 0.0.0.0 0 32768 ?
*> 10.10.8.0/24 0.0.0.0 0 32768 ?
*> 20.20.20.20/32 10.10.8.1 0 32768 ?
R7s advertised routes to R6. Highlighted as well is the redistributed static route and EIGRP
learned route.
R6#show ip bgp neighbor 10.10.7.2 received-routes
R6#show ip bgp neighbor 10.10.7.2 received-routes

internal,

*> 7.7.7.7/32 10.10.7.2 0 0 1000 i
*> 8.8.8.8/32 10.10.7.2 2297856 0 1000 ?
* 10.10.7.0/24 10.10.7.2 0 0 1000 ?
*> 10.10.8.0/24 10.10.7.2 0 0 1000 ?
*> 10.10.17.2/32 10.10.7.2 0 0 1000 ?
R6s Routing table with entries for R8 and the redistributed static route
R6#sh ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B -
BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
28
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
level-2
ia - IS-IS inter area, * - candidate default, U - per-user
static route
o - ODR, P - periodic downloaded static route, + - replicated
route
Gateway of last resort is not set

B 1.1.0.0/21 [20/0] via 10.10.6.1, 00:02:43
B 1.1.4.1/32 [20/0] via 10.10.6.1, 00:02:43
B 2.2.2.2 [20/0] via 10.10.6.1, 00:02:43
B 3.3.3.3 [20/0] via 10.10.6.1, 00:02:43
B 4.4.4.4 [20/0] via 10.10.6.1, 00:02:43
B 5.5.5.5 [20/0] via 10.10.6.1, 00:02:43
B 7.7.7.7 [20/0] via 10.10.7.2, 00:00:28
B 8.8.8.8 [20/2297856] via 10.10.7.2, 00:00:28
B 10.10.1.0/24 [20/0] via 10.10.6.1, 00:02:46
B 10.10.2.0/24 [20/0] via 10.10.6.1, 00:02:46
B 10.10.8.0/24 [20/0] via 10.10.7.2, 00:00:28
B 10.10.17.2/32 [20/0] via 10.10.7.2, 00:00:28
R8S routing table now has redistributed routes for R6
R8#SHOW IP ROUTE

D EX 6.6.6.6 [170/26112256] via 10.10.8.2, 00:11:24, Serial1/0
D 7.7.7.7 [90/2297856] via 10.10.8.2, 00:27:07, Serial1/0
D EX 10.10.6.0/24 [170/26112256] via 10.10.8.2, 00:11:24, Serial1/0
B 10.10.18.0/24 [20/0] via 20.20.20.20, 01:05:21
29
R8#PING 6.6.6.6

!!!!!
30
Confederations (AS500)
Problem
Each node in AS500 may connect to external BGP nodes in the future, and the goal is to maintain an
intra-AS mesh while minimising physical interconnections and rewiring.
Configuration
R12
interface Loopback0
ip address 14.14.14.14 255.255.255.255
interface Serial1/0
ip address 10.10.13.2 255.255.255.0
no shutdown
interface Serial1/0
ip address 10.10.14.1 255.255.255.0
no shutdown
interface Serial1/0
ip address 10.10.15.1 255.255.255.0
no shutdown
interface Serial1/0
ip address 10.10.16.1 255.255.255.0
no shutdown
bgp confederation identifier 500

bgp confederation peers 502 503 504
neighbour 10.10.13.1 remote-as 300
R13
interface Loopback0
ip address 13.13.13.13 255.255.255.255
interface Serial1/0
ip address 10.10.14.2 255.255.255.0
no shutdown
router bgp 502

bgp confederation peers 501
network 10.10.14.0 mask 255.255.255.0
network 13.13.13.13 mask 255.255.255.255
31
R14
interface Loopback0
ip address 14.14.14.14 255.255.255.255
interface Serial1/0
ip address 10.10.15.2 255.255.255.0
no shutdown
router bgp 503

network 14.14.14.14 mask 255.255.255.255
R15
interface Loopback0
ip address 15.15.15.15 255.255.255.255
interface Serial1/0
ip address 10.10.16.2 255.255.255.0
no shutdown
router bgp 504

network 15.15.15.15 mask 255.255.255.255
Results
R12 sends an Update to AS300, All routers are advertised appearing to R11as a single AS.
R11#show ip bgp neighbors 10.10.13.2 received-routes

internal,

*> 10.10.14.0/24 10.10.13.2 0 500 i
*> 12.12.12.12/32 10.10.13.2 0 0 500 i
*> 13.13.13.13/32 10.10.13.2 0 500 i
*> 14.14.14.14/32 10.10.13.2 0 500 i
*> 15.15.15.15/32 10.10.13.2 0 500 i
Total number of prefixes 5

32
If we were to place a unique cluster-id route-reflector on

R4, it would reflect the Unsuppress-Map loopback routes
to R5, negating the intended effect.
Route Reflectors
Suppress-Map
R5#sh ip bgp
Network Next Hop Metric LocPrf Weight

Path
*>i1.1.0.0/21 10.10.4.1 0 100 0i
*>i1.1.4.1/32 10.10.4.1 0 100 0i
*>i2.2.2.2/32 10.10.4.1 0 100 0 100 i
*>i3.3.0.0/21 10.10.4.1 0 100 0 100 i
r>i3.3.3.3/32 10.10.4.1 0 100 0 100 i
* i4.4.4.4/32 10.10.3.2 0 100 0i
CHAPTER 6 Discussion and Interpretation of Findings

33
The major drawback of the approach of this study is that it is computationally expensive, and
therefore not useful as a way to model real-time policy dynamics and perform engineering
tasks such as TE and maintenance.
i. The simulator used does not provide some more advanced router/switching
product virtualisation that may limit study of BGP features.
ii. The simulator is in development phase and may crash unexpectedly
iii. When all routers have been started in the topology each software image is
must be loaded into memory for larger studies this demands dedicated server
resources
In AS 100 we created a typical scenario, where the Customer Edge router is leased a private
AS from the ISP. Since numbers in this range are reusable they not to be routed over the
Internet. We removed the customer AS, providing a route to the internet, and conserving AS
numbers.
In AS200 the critical ability to filter out a desired aggregated route range was shown. We
were also selective about the recipient of such filtering within the AS.
AS400 showed a significant issue that occurs when migrating Providers, and how to easily
maintain intra-ASN route integrity while being multihomed.
IGP and BGP coexistence using redistribution, allowed for the propagation of new routing
information in AS 400 and AS300. This is an issue that arises in the Provider-Edge of
enterprises using public ASNs.
AS500 showed the basic initial setup that allows externally learned routing information to
pass through an AS domain with limited interconnections using Confederations. This feature
along with Route Reflectors helps to reduce the physical link meshiness of a domain.
Debug views would have allowed for a analysis of the decision process, as we would receive
a detailed exposition on the Messages being passed between speakers, Error Handling,
Update Message Handling and Finite State Machine in action.
34
CHAPTER 7 Conclusions and Recommendations

We have evidenced a small subset of the features of the protocol that make it robust through
an original simulation.
Many unexplored areas exist in this study, including the use of redundant links and equal load
sharing. Link redundancy of the upstream connection has economic implications in CAHP-
TP connections and EC-LTP routing, where providing on-demand services and access is the
main business. Such a study might investigate for an efficient policy using BGP that can load
balance a multi-homing enterprise via multiple routers.
Debug views would have allowed for a analysis of the decision process, as we would receive
a detailed exposition on the Messages being passed between speakers, Error Handling,
Update Message Handling and Finite State Machine in action.
The following list may also be tested on this platform:
Active vs passive negotiation

4 byte as numbers
add-path
as-set
Attributes manipulation
BGP backdoors
BGP timers
Communities/Extended Communities
Conditional advertisement
Dampening
Default routes
distribute lists
Dynamic peers
local-as
MP-BGP and Address Families
MRAI
NHT
Peer Groups - Soft-reconfiguration and route-refresh
Peer session and policy templates
Prefix Independent Convergence
route injection
route-server
summarization/aggregation
35
36
References
Blum, A. (2012). Tubes: a journey to the center of the Internet. Ecco. Retrieved from
https://books.google.co.in/books?
id=g0sOC4JDOM8C&printsec=frontcover&dq=tubes&hl=hi&sa=X&ved=0ahUK
Ewjx1Mry6-TTAhXJPo8KHe5iBcQQ6AEIOjAD#v=onepage&q=tubes&f=false
Calvert, K. L., Doar, M. B., & Zegura, E. W. (1997). Modeling internet topology. IEEE
Communications Magazine, 35(6), 160163. https://doi.org/10.1109/35.587723
Dhamdhere, A., & Dovrolis, C. (2011). Twelve years in the evolution of the internet
ecosystem. IEEE/ACM Transactions on Networking, 19(5), 14201433.
https://doi.org/10.1109/TNET.2011.2119327
Donnet, B., & Friedman, T. (2007). Internet topology discovery: a survey. IEEE
Communications Surveys & Tutorials. Retrieved from
https://scholar.google.co.in/citations?view_op=view_citation&continue=/scholar
%3Fhl%3Den%26start%3D10%26as_sdt%3D0,5%26scilib%3D1%26scioq
%3DInternet%2BRouting%2BArchitectures&citilm=1&citation_for_view=ek-
OhOwAAAAJ:IjCSPb-OGe4C&hl=en&oi=p
Halabi, B., Halabi, S., & McPherson, D. (2000). Internet routing architectures.
Retrieved from https://scholar.google.co.in/citations?
view_op=view_citation&continue=/scholar%3Fhl%3Den%26start
%3D20%26as_sdt%3D0,5%26scilib%3D1%26scioq%3DInternet%2BRouting
%2BArchitectures&citilm=1&citation_for_view=ek-OhOwAAAAJ:u-
x6o8ySG0sC&hl=en&oi=p
Labovitz, C., Malan, G. R., & Jahanian, F. (1999). Origins of Internet routing
instability. In IEEE INFOCOM 99. Conference on Computer Communications.
Proceedings. Eighteenth Annual Joint Conference of the IEEE Computer and
Communications Societies. The Future is Now (Cat. No.99CH36320) (pp. 218226
vol.1). IEEE. https://doi.org/10.1109/INFCOM.1999.749286
Li, T. (2007). draft-li-bgp-stability-01 - BGP Stability Improvements. Retrieved from

http://www.ietf.org/ietf/1id-abstracts.txt.
Mahajan, R., Wetherall, D., & Anderson, T. (2002). Understanding BGP

misconfiguration. ACM SIGCOMM Computer Communication Review, 32(4), 3.
https://doi.org/10.1145/964725.633027
37
Mckeown, N. (n.d.). Fast Switched Backplane for a Gigabit Switched Router. Retrieved
from http://yuba.stanford.edu/~nickm/papers/cisco_fasts_wp.pdf
Mcpherson, D., & Patel, K. (2006). RFC 4277 - Experience with the BGP-4 Protocol.
Retrieved from https://www.rfc-editor.org/rfc/pdfrfc/rfc4277.txt.pdf
Morley Mao, Z., Bush, R., Griffin, T. G., & Roughan, M. (2003). BGP beacons. Internet
Measurement Conference, 1. https://doi.org/10.1145/948206.948207
Orsini, C., King, A., Giordano, D., Giotsas, V., & Dainotti, A. (n.d.). BGPStream: A
Software Framework for Live and Historical BGP Data Analysis.
https://doi.org/10.1145/2987443.2987482
Rekhter, Y. (2006). RFC 4271 - A Border Gateway Protocol 4 BGP-4.
White, R., Bollapragada, V., & Murphy, C. (2008). Inside Cisco IOS Software
Architecture (Google eBook). Cisco Press. Retrieved from
http://books.google.com/books?id=-8RA47mPxZgC&pgis=1
38
Bibliography
This is a complete list of works referenced during the project.
https://lg.airtel.in/
https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-
routing-beacons
http://as-rank.caida.org/
(2006, jan). A Border Gateway Protocol 4 (BGP-4). Tech. rep. doi:10.17487/rfc4271
Abley, J., & Lindqvist, K. (2006, dec). Operation of Anycast Services. Tech. rep.
doi:10.17487/rfc4786
Abuzneid, A., & Stark, B. J. (2010). Improving BGP convergence time via MRAI timer. Novel
Algorithms and Techniques in Telecommunications and Networking, (pp. 105-110).
doi:10.1007/978-90-481-3662-9-17
Al-Fares, M., Loukissas, A., & Vahdat, A. (2008). A scalable, commodity data center network
architecture. Proceedings of the ACM SIGCOMM 2008 conference on Data
communication - SIGCOMM '08 (p. 63). New York, New York, USA: ACM Press.
doi:10.1145/1402958.1402967
Beijnum, l. v. (2002). BGP.
Blum, A. (2012). Tubes : a journey to the center of the Internet. Ecco. Retrieved from
id=g0sOC4JDOM8C&printsec=frontcover&dq=tubes&hl=hi&sa=X&ved=0ahUKEwjx
1Mry6-TTAhXJPo8KHe5iBcQQ6AEIOjADv=onepage&q=tubes&f=false
Boutros, S., Binderberger, E. M., & Haas, C. S. (2014). RFC 7130 - Bidirectional Forwarding
Detection BFD on Link Aggregation Group LAG Interfaces. Retrieved from
http://www.rfc-editor.org/info/rfc7130.
Calvert, K. L., Doar, M. B., & Zegura, E. W. (1997). Modeling internet topology. IEEE
Communications Magazine, 35, 160-163. doi:10.1109/35.587723
Chandra, R. (1996). RFC 1997 - BGP Communities Attribute. Retrieved from

https://tools.ietf.org/pdf/rfc1997.pdf
Chandra, R. (2006). RFC 4456 - BGP Route Reflection: An Alternative to Full Mesh Internal
BGP IBGP. Retrieved from https://tools.ietf.org/pdf/rfc4456.pdf
Clos, C. (1953, mar). A Study of Non-Blocking Switching Networks. Bell System Technical
Journal, 32, 406-424. doi:10.1002/j.1538-7305.1953.tb01433.x
Colitti, L., Di Battista, G., Patrignani, M., Pizzonia, M., & Rimondini, M. (2007). Investigating
prefix propagation through active BGP probing. Microprocessors and Microsystems, 31,
460-474. doi:10.1016/j.micpro.2007.05.001
39
Dhamdhere, A., & Dovrolis, C. (2011). Twelve years in the evolution of the internet ecosystem.
IEEE/ACM Transactions on Networking, 19, 1420-1433. doi:10.1109/TNET.2011.2119327
Dimitropoulos, X., Krioukov, D., Vahdat, A., & Riley, G. (2009). Graph annotations in modeling
complex network topologies. ACM Transactions on Modeling. Retrieved from
https://scholar.google.co.in/citations?viewop=viewcitation&continue=/scholar%3Fhl
%3Den%26assdt%3D0,5%26scilib%3D1%26scioq%3DInternet%2BRouting
%2BArchitectures&citilm=1&citationforview=ek-
OhOwAAAAJ:WF5omc3nYNoC&hl=en&oi=p
Donnet, B., & Friedman, T. (2007). Internet topology discovery: a survey. IEEE
Communications Surveys {\&} Tutorials. Retrieved from
%3Den%26start%3D10%26assdt%3D0,5%26scilib%3D1%26scioq%3DInternet
%2BRouting%2BArchitectures&citilm=1&citationforview=ek-OhOwAAAAJ:IjCSPb-
OGe4C&hl=en&oi=p
Doyle, J. (n.d.). Routing TCP/IP. Volume 2.
Duan, Z., Chandrashekar, J., Krasky, J., Xu, K., & Zhang, Z. L. (2007). Damping BGP route
flaps. Journal of Communications and Networks, 9, 490-498.
doi:10.1109/PCCC.2004.1394959
Dunbar, L., Perlman, R., & Gashinsky, I. (2013, nov). Directory Assistance Problem and High-
Level Design Proposal. RFC 7067, 1-15. doi:10.17487/rfc7067
Elmokashfi, A., & Dhamdhere, A. (n.d.). Revisiting BGP Churn Growth.
Feamster, N., Winick, J., & Rexford, J. (2004). A model of BGP routing for network engineering.
ACM SIGMETRICS Performance Evaluation. Retrieved from
%2BRouting%2BArchitectures&citilm=1&citationforview=ek-
OhOwAAAAJ:UeHWp8X0CEIC&hl=en&oi=p
Gill, V., Heasley, J., Meyer, D., & Pignataro, C. (2007, oct). The Generalized TTL Security
Mechanism (GTSM). Tech. rep. doi:10.17487/rfc5082
Goodell, G., Aiello, W., Griffin, T., Ioannidis, J., Mcdaniel, P. D., & Rubin, A. D. (2003).
Working around BGP: An Incremental Approach to Improving Security and Accuracy
in Interdomain Routing. Network and Distributed System Security Symposium. Retrieved
from http://www.internetsociety.org/doc/working-around-bgp-incremental-approach-
improving-security-and-accuracy-interdomain-routing
Govindan, R., & Reddy, A. (1997). An analysis of Internet inter-domain topology and route
stability. INFOCOM'97. Sixteenth Annual Joint Conference of the. Retrieved from
OhOwAAAAJ:roLk4NBRz8UC&hl=en&oi=p
40
Goyvaerts, J. (n.d.). Regular Expressions The Complete Tutorial. Retrieved from

https://www.princeton.edu/ mlovett/reference/Regular-Expressions.pdf
Greenberg, A., Hamilton, J., Maltz, D. A., & Patel, P. (2008, dec). The cost of a cloud. ACM
SIGCOMM Computer Communication Review, 39, 68. doi:10.1145/1496091.1496103
Griffin, T. G., & Premore, B. J. (2001). An experimental analysis of BGP convergence time.
Protocols, 2001. Ninth International Conference on. Retrieved from
OhOwAAAAJ:Y0pCki6qDkC&hl=en&oi=p
Halabi, B., Halabi, S., & McPherson, D. (2000). Internet routing architectures. Retrieved from
%2BRouting%2BArchitectures&citilm=1&citationforview=ek-OhOwAAAAJ:u-
x6o8ySG0sC&hl=en&oi=p
Hanif, S. (2010). Impact of Topology on BGP Convergence. Retrieved from

https://www.nlnetlabs.nl/downloads/publications/bgp-topology-thesis.pdf
Hares, S., Rekhter, Y., & Li, T. (n.d.). A Border Gateway Protocol 4 (BGP-4). Retrieved from
https://tools.ietf.org/html/rfc4271
Hawkinson, J., & Bates, T. (1996). Guidelines for creation, selection, and registration of an
Autonomous System (AS). Retrieved from https://scholar.google.co.in/citations?
viewop=viewcitation&continue=/scholar%3Fhl%3Den%26assdt%3D0,5%26scilib
%3D1%26scioq%3DInternet%2BRouting
OhOwAAAAJ:eQOLeE2rZwMC&hl=en&oi=p
Heffernan, A. (1998, aug). Protection of BGP Sessions via the TCP MD5 Signature Option. Tech.
rep. doi:10.17487/rfc2385
Heffernan, A. (1998). RFC 2385 - Protection of BGP Sessions via the TCP MD5 Signature
Option. Retrieved from https://tools.ietf.org/pdf/rfc2385.pdf
Hopps, C. (2000, nov). Analysis of an Equal-Cost Multi-Path Algorithm. Tech. rep.

doi:10.17487/rfc2992
Huston, G. (1999). ISP survival guide : strategies for running a competitive ISP. Wiley.
Huston, G. (2001). Analyzing the Internet BGP routing table. The Internet Protocol Journal.
Retrieved from https://scholar.google.co.in/citations?
viewop=viewcitation&continue=/scholar%3Fhl%3Den%26start%3D10%26assdt
%3D0,5%26scilib%3D1%26scioq%3DInternet%2BRouting
OhOwAAAAJ:qjMakFHDy7sC&hl=en&oi=p
41
Information, R. (2001). Achieve Optimal Routing and Reduce BGP Memory Consumption.
Memory, 12-15. Retrieved from http://www.cisco.com/c/en/us/support/docs/ip/border-
gateway-protocol-bgp/12512-41.html
Katz, D. (2010). RFC 5880 - Bidirectional Forwarding Detection (BFD). Retrieved from
http://www.rfc-editor.org/info/rfc5880.
Krishnamurthy, V., Faloutsos, M., Chrobak, M., & Cui, J. H. (2007). Sampling large Internet
topologies for simulation purposes. Computer Networks. Retrieved from
OhOwAAAAJ:zYLM7Y9cAGgC&hl=en&oi=p
Labovitz, C., Malan, G. R., & Jahanian, F. (1999). Origins of Internet routing instability. IEEE
INFOCOM '99. Conference on Computer Communications. Proceedings. Eighteenth
Annual Joint Conference of the IEEE Computer and Communications Societies. The
Future is Now (Cat. No.99CH36320) (pp. 218--226 vol.1). IEEE.
doi:10.1109/INFCOM.1999.749286
Li, T. (2007). draft-li-bgp-stability-01 - BGP Stability Improvements. Retrieved from

http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/shadow.html.
http://www.ietf.org/ietf/1id-abstracts.txt.%0Ahttp://www.ietf.org/shadow.html.
Loibl, C. (2017). BGP Flow Specification Multi Vendor and Inter AS Interoperability. Retrieved
from https://www.nextlayer.at/flowspec-paper.pdf
Mahajan, R., Wetherall, D., & Anderson, T. (2002). Understanding BGP misconfiguration. ACM
SIGCOMM Computer Communication Review, 32, 3. doi:10.1145/964725.633027
Mao, Z. M., Govindan, R., Varghese, G., & Katz, R. H. (2002). Route flap damping exacerbates
internet routing convergence. ACM SIGCOMM Computer Communication Review, 32,
221. doi:10.1145/964725.633047
Massey, D., Wang, L., Zhang, B., & Zhang, L. (2007). A scalable routing system design for
future internet. Proc. of ACM SIGCOMM Workshop on IPv6. Retrieved from
OhOwAAAAJ:d1gkVwhDpl0C&hl=en&oi=p
Mcauley, J. J., Da Fontoura Costa, L., & Caetano, T. S. (2007). Rich-club phenomenon across
1complex network hierarchies. doi:10.1063/1.2773951
1
Mcpherson, D., & Patel, K. (2006). RFC 4277 - Experience with the BGP-4 Protocol. Retrieved
from https://www.rfc-editor.org/rfc/pdfrfc/rfc4277.txt.pdf
Minoli, D. (2003). Telecommunications technology handbook. Artech House. Retrieved from

id=ZO9RWurSS0IC&pg=PA413&dq=bgp+interoperability&hl=hi&sa=X&ved=0ahUK
Ewi2gY-YjOPTAhWKuY8KHc1bB74Q6AEIUDAGv=onepage&q&f=false
42
Mitchell, J. (2013, jul). Autonomous System (AS) Reservation for Private Use. Tech. rep.
doi:10.17487/rfc6996
Mitchell, N. a. (2016). RFC 7938 - Use of BGP for Routing in Large-Scale Data Centers.
Retrieved from https://tools.ietf.org/pdf/rfc7938.pdf
Morley Mao, Z., Bush, R., Griffin, T. G., & Roughan, M. (2003). BGP beacons. Internet
Measurement Conference, 1. doi:10.1145/948206.948207
Mhlbauer, W., Feldmann, A., Maennel, O., & Roughan, M. (2006). Building an AS-topology
model that captures route diversity. ACM SIGCOMM Computer. Retrieved from
OhOwAAAAJ:Se3iqnhoufwC&hl=en&oi=p
Murphy, S. (2006). BGP Security Vulnerabilities Analysis. 22. doi:10.17487/rfc4272
Neumann, J. C. (n.d.). The book of GNS3 : build virtual network labs using Cisco, Juniper, and
more. Retrieved from https://books.google.co.in/books?
id=BvGbCgAAQBAJ&printsec=frontcover&dq=gns3&hl=en&sa=X&ved=0ahUKEwiX
r7uxm-XTAhXEpY8KHXz9AO4Q6AEIKTABv=onepage&q=gns3&f=false
Oliveira, R. V., Zhang, B., & Zhang, L. (2007). Observing the evolution of internet as topology.
ACM SIGCOMM Computer Communication Review, 37, 313.
doi:10.1145/1282427.1282416
Patel, K., Systems, C., & Mohapatra, P. (2014). RFC 7196 - Making Route Flap Damping
Usable. Retrieved from http://www.rfc-editor.org/info/rfc7196.
Patel, K., Systems, C., Mcpherson, D., & Kumaki, V. K. (2013). draft-ietf-grow-diverse-bgp-
path-dist-08 - Distribution of Diverse BGP Paths. Retrieved from
https://tools.ietf.org/pdf/draft-ietf-grow-diverse-bgp-path-dist-08.pdf
Perlman, R., Eastlake, D., Dutt, D., Gai, S., & Ghanwani, A. (2011, jul). Routing Bridges
(RBridges): Base Protocol Specification. Tech. rep. doi:10.17487/rfc6325
Raszuk, R., Heitz, J., Lo, A., Zhang, L., & Xu, X. (2012, oct). Simple Virtual Aggregation (S-VA).
Tech. rep. doi:10.17487/rfc6769
Rekhter, Y. (2006). RFC 4271 - A Border Gateway Protocol 4 BGP-4.
Rekhter, Y. (2006). RFC 4271 - A Border Gateway Protocol 4 BGP-4. Retrieved from
https://tools.ietf.org/pdf/rfc4271.pdf
Sadasivan, G., Brownlee, J. N., Claise, B., & Quittek, J. (n.d.). Architecture for IP flow
information export. RFC Editor.
Senior, J. M., & Jamro, M. Y. (2009). Optical fiber communications : principles and practice.
Pearson. Retrieved from https://books.google.co.in/books?id=ok0XX-
3MgMoC&dq=Optical+fiber+communications&source=gbsnavlinkss
43
Shen, N. (2010, apr). Extending ICMP for Interface and Next-Hop Identification. Tech. rep.
doi:10.17487/rfc5837
Sklar, B. (1988). Digital communications : fundamentals and applications. Prentice-Hall.

Retrieved from https://www.pearsonhighered.com/program/Sklar-Digital-
Communications-Fundamentals-and-Applications-2nd-Edition/PGM127356.html
Smith, P. (2010). BGP Techniques for Internet Service Providers Will be available on. Retrieved
from
https://www.nanog.org/meetings/nanog50/presentations/Sunday/NANOG50.Talk33.NAN
OG50-BGP-Techniques.pdf
Walton, D., Chen, E., & Scudder, J. (2016). RFC 7911 - Advertisement of Multiple Paths in BGP.
Retrieved from http://www.rfc-editor.org/info/rfc7911.
White, R., Bollapragada, V., & Murphy, C. (2008). Inside Cisco IOS Software Architecture
(Google eBook). Cisco Press. Retrieved from http://books.google.com/books?id=-
8RA47mPxZgC&pgis=1
William James, D. a. (2004). Principles and Practices of Interconnection Networks. Morgan

Kaufmann Publishers. Retrieved from http://www.vpiphotonics.com/
Wojciechowski, M. (2008). Border Gateway Protocol Modeling and Simulation. Retrieved from
OhOwAAAAJ:W7OEmFMy1HYC&hl=en&oi=p
Zhang, R. (2015). Bgp design and implementation. Cisco Press.
Zhou, S., & Mondragon, R. J. (2003). The Rich-Club Phenomenon In The Internet Topology.
doi:10.1109/LCOMM.2004.823426

An Investigation of BGP Convergence

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

An Investigation of BGP Convergence

Încărcat de

Drepturi de autor:

Formate disponibile

An investigation of

Network Engineer/Technical consultant

Signed Bona fides

UNDERTAKING FROM THE CANDIDATE

This is to certify that I, Naveen Nagalingam, have completed

This is an original piece of work & I have not submitted it earlier

I declare that I have faithfully acknowledged, given credit to

CHAPTER 1: Introduction & Literature Review

Domain: Network Protocols; Routing Protocols; Computer Communication Networks;

(White et al., 2008)

No neighbour discovery function: Manually configuring neighbour addresses is required for

The circuits used in computer networks have the unfortunate property

features in meeting network requirementsCHAPTER 3

Minimum Hardware Requirements

Processor 2 or more Logical cores

Storage 1GB available space (Windows Installation is < 200MB).

propagate new information

AS100 to AS200: Routing a Private AS over the Internet by using remove-private-as

Figure 2 : Topology constructed in

CHAPTER 5 Presentation and Analysis of Data

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

Full IBGP Mesh using Route-Reflectors (AS200)

router bgp 200

router bgp 200

router bgp 200

R1s BGP table

BGP table version is 42, local router ID is 1.1.1.1

Network Next Hop Metric LocPrf Weight Path

Route filtering with a Suppress-map (AS200)

Basic intra-BGP set-up has given R5 a complete view of AS200.

This prevents these routes being propagated further. .

An access-list is used specifying for the address-range to be filtered out.

ip access-list standard SUPPRESS-Lo1-2

permit 1.1.3.1 0.0.0.255

router bgp 200

BGP table version is 163, local router ID is 4.4.4.4

Network Next Hop Metric LocPrf Weight Path

BGP table version is 53, local router ID is 5.5.5.5

Network Next Hop Metric LocPrf Weight Path

Mutually coexisting Interior Gateway Protocol (EIGRP) and BGP

i. Intra-AS full connectivity

Gateway of last resort is not set

18.0.0.0/24 is subnetted, 1 subnets

6.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

B 10.10.18.0/24 [20/0] via 10.10.7.2, 01:26:38

ip prefix-list Unsuppress-Map seq 5 permit 0.0.0.0/0 le 32

router bgp 100

router bgp 200

BGP table version is 149, local router ID is 4.4.4.4

Network Next Hop Metric LocPrf Weight Path

*>i1.1.2.1/32 10.10.3.1 0 100 0 i

Network Next Hop Metric LocPrf Weight Path

Mutually coexisting Interior Gateway Protocol (EIGRP) and BGP (AS300)

We need full Intra-AS connectivity i.e. an IBGP full mesh.

1. Neighbour [ip address] update-source loopback 0

router eigrp 300 router eigrp 300

router bgp 300 router bgp 300

router eigrp 300 router eigrp 300

network 10.10.12.0 0.0.0.255 network 10.10.12.0 0.0.0.255

router bgp 300 router bgp 300

Pings between R6 to R11

Type escape sequence to abort.