Computer Networks

Border Gateway Protocol

Presented to: Prof. Dr. Hussam Fahme Prepared by: Shahinaz Refaat Hussain
24 December 2011

Contents Introduction Routing Routing Protocols Routing Protocols Classes Border Gateway Protocol Definition History BGP Operation BGP Attributes Finite State Machine Message Format BGP Routing Connectivity and learning routes Basic updating processing Route Selection Pre neighbor decisions Decision factors at the Loc-RIB level BGP path selection summarize Communities Extended Communities BGP Multipath support Requirements of a router for use of BGP for Internet and backbone-of-backbones purposes BGP problems & issues Scalability Instability Routing table growth Load balancing Security issues BGP Configuration Requirement for running BGP BGP configuration tasks Basic configuration Advanced configuration
2

Introduction
Routing is the act of moving information across an internetwork from a source to a destination. Along the
way, at least one intermediate node typically is encountered. Routing is often contrasted with bridging, which might seem to accomplish precisely the same thing to the casual observer. The primary difference between the two is that bridging occurs at Layer 2 (the link layer) of the OSI reference model, whereas routing occurs at Layer 3 (the network layer). This distinction provides routing and bridging with different information to use in the process of moving information from source to destination, so the two functions accomplish their tasks in different ways.

Routing protocol is a protocol that specifies how routers communicate with each other, disseminating
information that enables them to select routes between any two nodes on a computer network, the choice of the route being done by routing algorithms. Each router has a priori knowledge only of networks attached to it directly. A routing protocol shares this information first among immediate neighbors, and then throughout the network. This way, routers gain knowledge of the topology of the network. It refers specifically to one operating at layer three of the OSI model (Network Layer), which similarly disseminates topology information between routers. Many routing protocols are defined in documents called RFCs *((is a memorandum published by the Internet
Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.))

The specific characteristics of routing protocols include

The manner in which they either prevent routing loops from forming or break them up if they do. The manner in which they select preferred routes, using information about hop costs. The time they take to converge. How well they scale up and other factors.

Although there are many types of routing protocols, major classes are in widespread use on IP networks:

Interior gateway routing

Exterior gateway routing

IGP EGP Also called intra-domain routing Also called inter-domain routing Is used to exchange routing information within an Is for determining network reachability autonomous system (AS) *((a collection of connected between autonomous systems and makes use of Internet Protocol (IP) routing prefixes under the control of IGPs to resolve routes within an AS, i.e. on the one or more network operators that presents a common, Internet.
clearly defined routing policy to the Internet))

EGP is a now obsolete routing protocol for the Internet originally specified in 1982 by Eric C. Rosen of Bolt, Beranek and Newman, and David L. Mills. It was first described in RFC 827 and formally specified in RFC 904 (1984). EGP in general is a simple reachability protocol, and, unlike modern distance-vector and path-vector protocols, it is limited to treelike topologies.
3

Can be divided into following categories: Examples of an EGP: 1. Distance-vector routing protocol (or path Border Gateway Protocol (BGP) vector) Exterior Gateway Protocol (Replaced by BGP) 2. Link-state routing protocol. 3. Hybrid routing protocol

Distance-vector

Link-state

Uses the Bellman-Ford Each router possesses algorithm* ((computes information about the single-source shortest paths complete network in a weighted digraph *((is a topology. pair G = (V,A) where v are Each router then vectors or notes and A are independently arcs or arrows between calculates the best next nodes)). hop from it for every possible destination in In these protocols, each the network using local router does not possess information of the information about the topology. The collection full network topology. of best next hops forms It advertises its distance the routing table. value (DV) calculated to This contrasts with other routers and distance-vector routing receives similar protocols, which work advertisements from by having each node other routers unless share its routing table changes are done in with its neighbors. In a local network or by link-state protocol, the neighbors (Routers). only information passed Using these routing between the nodes is advertisements each information used to router populates its construct the routing table. In the connectivity maps. next advertisement cycle, a router advertises updated information from its routing table. This process continues until the routing tables of each router converge* ((in a
converged network all routers "agree" on what the network topology looks like)) to stable

During the early days of the Internet, EGP version 3 (EGP3) was used to interconnect autonomous systems. Currently, BGP version 4 is the accepted standard for Internet routing and has essentially replaced the more limited EGP3. BGP is used by companies with more than one Internet provider to allow them to have redundancy and load balancing of their data transported to and from the Internet. Border Gateway Protocol (BGP) is the report scope.

values.
4

Some examples of Some examples of LinkDistance Vector routing State routing protocol protocol are: are: 1.Routing Information 1. Open Shortest Path Protocol (RIP) First (OSPF) 2.Interior Gateway 2. Intermediate system Routing Protocol (IGRP) to intermediate system 3.Enhanced Interior (IS-IS) Gateway Routing Protocol (EIGRP)

Some of these protocols have the disadvantage of slow convergence. Hybrid routing protocol Hybrid routing protocols have both the features of distance vector routing protocols & linked state routing protocols. An example of this protocol is EIGRP.

BGP: Border Gateway Protocol

Definition: A protocol that backs the core routing decisions on the Internet.
It is used to exchange routing information in the Internet and is the protocol used by default to communicate between Internet service providers (ISP) It maintains a table of IP networks, or prefixes, that represent paths to a particular AS (Autonomous system) or set of ASs, tracking both direct neighbors and more remote ones. It is described as a path vector protocol *((is a computer network routing protocol which maintains the path
information that gets updated dynamically. Updates which have looped through the network and returned to the same node are easily detected and discarded. This algorithm is sometimes used in BellmanFord routing algorithms to avoid "Count to Infinity" problems))

BGPD * ((Border Gateway Protocol daemon which manages the network routing tables)) instance runs on a router and makes routing decisions to select preferred routes based on Path availability, Network policies, or Operator-defined databases of routing rules (patterns the operator has defined). It then advertises reachable prefixes by publishing sets of attributes that include the paths. As routing changes, BGPD exchanges updates with its peers that might add to the list of reachable prefixes or retract some prefixes; those peers are expected to update their own states accordingly. BGP allows BGPD instances to apply routing updates in an unsynchronized, distributed manner, but normally the delay between when one router applies an update and when its neighbor does is negligible, hence this asynchrony isnt noticed: most routers are working with very similar routing tables at any given moment. BGP neighbors exchange full routing information when the TCP connection between neighbors is first established. When changes to the routing table are detected, the BGP routers send to their neighbors only those routes that have changed. BGP routers do not send periodic routing updates, and BGP routing updates advertise only the optimal path to a destination network. BGP was created to replace the Exterior Gateway Protocol (EGP) protocol to allow fully decentralized routing in order to transition from the core ARPAnet model * ((The world's first operational packet switching network
and the core network of a set that came to compose the global Internet. The network was funded by the Defense Advanced Research Projects Agency (DARPA) of the United States Department of Defense for use by its projects at universities and research laboratories in the US. The packet switching of the ARPANET was based on designs by Lawrence Roberts of the Lincoln Laboratory)) to a decentralized system that included the NSFNET *((The NSFNET is a loosely organized community of networks funded by the National Science Foundation to support the sharing of national scientific computing resources, data and information. NSFNET consists of a large number of industry and academic campus and experimental networks, many of which are interconnected by a smaller number of regional and consortium networks. The NSFNET Backbone Network is a primary means of interconnection between the regional networks it interconnects six supercomputer sites, several regional networks and ARPANET. It supports the DARPA Internet protocol suite and DCN subnet protocols, which provide delay-based routing and very accurate time-synchronization services)) backbone and its associated regional

networks. This allowed the Internet to become a truly decentralized system

History:
Since 1994, (BGP4) version four of the BGP has been in use on the Internet. All previous versions are now obsolete. The major enhancement in version 4 was support of Classless Inter-Domain Routing*((is a method for allocating IP addresses and routing Internet Protocol packets)) and use of route aggregation*((Process of
combining the characteristics of several different routes in such a way that a single route can be advertised. Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers.)) to decrease the size of routing tables.

For example, assume that an ISP owns the IP address block 195.10.x.x from the traditional Class C address space. This block consists of 256 Class C address blocks, 195.10.0.x through 195.10.255.x. Assume that the ISP assigns a Class C block to each of its customers. Without CIDR, the ISP would advertise 256 Class C address blocks to its BGP peers. With CIDR, BGP can supernet the address space and advertise one block, 195.10.x.x. This block is the same size as a traditional Class B address block. The class distinctions are rendered obsolete by CIDR, allowing a significant reduction in the BGP routing tables. Since January 2006, version 4 is codified in RFC 4271, which went through more than 20 drafts based on the earlier RFC 1771 version 4. RFC 4271 version corrected a number of errors, clarified ambiguities and brought the RFC much closer to industry practices. The current version in use is BGP4 and is supported by most router manufacturers including Cisco, Lucent/Bay, Juniper and many others, as well as by Unix and Linux programs such as Zebra. BGP uses a TCP connection to send routing updates using TCP port 179. BGP is therefore by definition a 'reliable' protocol. While BGP version 3 provides for the dynamic learning of routes, BGP 4 adds additional route dampening functionality, communities, MD5 and multicasting capability.

BGP Operation:
Any two routers that form a TCP connection in order to exchange BGP routing information are "peers" or "neighbors". BGP parties are:

Internal BGP
IBGP: Interior Border Gateway Protocol When BGP runs between two peers in the same autonomous system (AS)

External BGP

Border routers

EBGP: Exterior Border Gateway Called also edge routers Protocol When it runs between Routers on the boundary autonomous systems of one AS exchanging information with another AS

Figure: EBGP and IBGP

BGP routers exchange network reachability information. This information is mainly an indication of the full paths that a route must take in order to reach the destination network. The paths are BGP AS numbers. This information helps in the construction of a graph of ASs that is loop-free. The graph also shows where to apply routing policies in order to enforce some restrictions on the routing behavior. BGP neighbors, peers, are established by manual configuration between routers to create a TCP session on port 179. Among routing protocols, BGP is unique in using TCP as its transport protocol. BGP peers initially exchange the full BGP routing tables. After this exchange, the peers send incremental updates as the routing table changes. BGP keeps a version number of the BGP table. The version number is the same for all the BGP peers. The version number changes whenever BGP updates the table with routing information changes. A BGP speaker will periodically send 19-byte keep-alive messages to maintain the connection (every 60 seconds by default). Notification packets go out in response to errors or special conditions. BGP uses Classless Inter-Domain Routing (CIDR) notation for masks. When advertising routes, BGP will include prefixes in it's advertisements. A prefix is the network IP address plus the mask in CIDR notation.
8

Below are tables showing how IP masks and CIDR masks are related. In every IP address, certain bits are used to identify the network, and certain bits are used for host. The mask allows the receiver to tell which bits are network, and which are host. Ones are used to mark the Network bits, and zeroes are used to mark the Host bits.
CLASS 'A' NETWORKS BINARY CIDR 11111111.00000000.00000000.00000000 /8 CLASS 'B' NETWORKS BINARY CIDR 11111111.11111111.00000000.00000000 /16 CLASS 'C' NETWORKS BINARY CIDR 11111111.11111111.11111111.00000000 /24 DECIMAL 255.255.255.0 DECIMAL 255.255.0.0 DECIMAL 255.0.0.0

noted that the number in the CIDR mask notation is equal to the number of 1's in the binary mask. The same holds true for subnets: 1/2 CLASS 'C' NETWORK BINARY CIDR And for supernets as well: 2 CLASS 'C' NETWORKS BINARY 11111111.11111111.11111110.00000000 DECIMAL 255.255.254.0 CIDR /23 So for CIDR notation, the number after the slash is equal to the number of network bits (1's) in the mask. In brief; BGP General Operations Learns multiple paths via internal and external BGP speakers Picks the best path and installs in the forwarding table Best path is sent to external BGP neighbors Policies applied by influencing the best path selection BGP is not to be used when The network is singularly hommed. Not providing downstream routing. When using default routing 11111111.11111111.11111111.10000000 /25 DECIMAL 255.255.255.128

BGP Attributes:
As the focus of BGP design and implementation was always on security and scalability, it's harder to configure than other routing protocols, more complex and one of the slowest converging routing protocols. All other routing protocols are concerned solely with finding the optimal path toward all known destinations. BGP cannot take this simplistic approach because the peering agreements between ISPs almost always result in complex routing policies and also due to desire of achieving scalability at high level. To help network operators implement these policies, Routes learned via BGP have associated properties that are used to determine the best route to a destination when multiple paths exist to a particular destination. These properties are referred to as BGP attributes, and an understanding of how BGP attributes influence route selection is required for the design of robust networks and also to maintain a stable routing environment. This section describes the attributes that BGP uses in the route selection process: Weight, Local preference, Multi-exit discriminator, Origin, AS path, Next hop, Community

Weight
In Figure: BGP Weight Attribute, Router A is receiving an advertisement for network 172.16.1.0 from routers B and C. When Router A receives the advertisement from Router B, the associated weight is set to 50. When Router A receives the advertisement from Router C, the associated weight is set to 100. Both paths for network 172.16.1.0 will be in the BGP routing table, with their respective weights. The route with the highest weight will be installed in the IP routing table.
Figure: BGP Weight Attribute

10

Local Preference Attribute

The local preference attribute is used to prefer an exit point from the local autonomous system (AS). Unlike the weight attribute, the local preference attribute is propagated throughout the local AS. If there are multiple exit points from the AS, the local preference attribute is used to select the exit point for a specific route. In Figure: BGP Local Preference Attribute, AS 100 is receiving two advertisements for network 172.16.1.0 from AS 200. When Router A receives the advertisement for network 172.16.1.0, the corresponding local preference is set to 50. When Router B receives the advertisement for network 172.16.1.0, the corresponding local preference is set to 100. These local preference values will be exchanged between routers A and B. Because Router B has a higher local preference than Router A, Router B will be used as the exit point from AS 100 to reach network 172.16.1.0 in AS 200.
Figure: BGP Local Preference Attribute

Multi-Exit Discriminator Attribute

The multi-exit discriminator (MED) or metric attribute is used as a suggestion to an external AS regarding the preferred route into the AS that is advertising the metric. It was originally intended to show to another neighbor AS the advertising AS's preference as to which of several links are preferred for inbound traffic. Another application of MEDs is to advertise the value, typically based on delay, of multiple AS that have presence at an IXP,that they impose to send traffic to some destination The term suggestion is used because the external AS that is receiving the MEDs may be using other BGP attributes for route selection. We will cover the rules regarding route selection in the next section. In Figure: BGP Multi-Exit Discriminator Attribute, Router C is advertising the route 172.16.1.0 with a metric of 10, while Route D is advertising 172.16.1.0 with a metric of 5. The lower value of the metric is preferred, so AS 100 will select the route to router D for network 172.16.1.0 in AS 200. MEDs are advertised throughout the local AS.
Figure: BGP Multi-Exit Discriminator Attribute

11

Origin Attribute
The origin attribute indicates how BGP learned about a particular route. The origin attribute can have one of three possible values:

IGP - The route is interior to the originating AS. This value is set when the network router configuration command is used to inject the route into BGP. EGP - The route is learned via the Exterior Border Gateway Protocol (EBGP). Incomplete - The origin of the route is unknown or learned in some other way. An origin of incomplete occurs when a route is redistributed into BGP.

The origin attribute is used for route selection and will be covered in the next section.

AS_Path Attribute
When a route advertisement passes through an autonomous system, the AS number is added to an ordered list of AS numbers that the route advertisement has traversed. Figure: BGP AS-path Attribute shows the situation in which a route is passing through three autonomous systems. AS1 originates the route to 172.16.1.0 and advertises this route to AS 2 and AS 3, with the AS_path attribute equal to {1}. AS 3 will advertise back to AS 1 with AS-path attribute {3,1}, and AS 2 will advertise back to AS 1 with AS-path attribute {2,1}. AS 1 will reject these routes when its own AS number is detected in the route advertisement. This is the mechanism that BGP uses to detect routing loops. AS 2 and AS 3 propagate the route to each other with their AS numbers added to the AS_path attribute. These routes will not be installed in the IP routing table because AS 2 and AS 3 are learning a route to 172.16.1.0 from AS 1 with a shorter AS_path list.
Figure: BGP AS-path Attribute

12

Next-Hop Attribute
The EBGP next-hop attribute is the IP address that is used to reach the advertising router. For EBGP peers, the next-hop address is the IP address of the connection between the peers. For IBGP, the EBGP next-hop address is carried into the local AS, as illustrated in Figure: BGP Next-Hop Attribute.
Figure: BGP Next-Hop Attribute

Router C advertises network 172.16.1.0 with a next hop of 10.1.1.1. When Router A propagates this route within its own AS, the EBGP next-hop information is preserved. If Router B does not have routing information regarding the next hop, the route will be discarded. Therefore, it is important to have an IGP running in the AS to propagate next-hop routing information.

Community Attribute
The community attribute provides a way of grouping destinations, called communities, to which routing decisions (such as acceptance, preference, and redistribution) can be applied. Route maps are used to set the community attribute. Predefined community attributes are listed here: no-export - Do not advertise this route to EBGP peers. no-advertise - Do not advertise this route to any peer. internet - Advertise this route to the Internet community; all routers in the network belong to it. Figure: BGP no-export Community Attribute illustrates the no-export community. AS 1 advertises 172.16.1.0 to AS 2 with the community attribute no-export. AS 2 will propagate the route throughout AS 2 but will not send this route to AS 3 or any other external AS.
Figure: BGP no-export Community Attribute

13

In Figure: BGP no-advertise Community Attribute, AS 1 advertises 172.16.1.0 to AS 2 with the community attribute no-advertise. Router B in AS 2 will not advertise this route to any other router.
Figure: BGP no-advertise Community Attribute

Figure: BGP internet Community Attribute demonstrates the internet community attribute. There are no limitations to the scope of the route advertisement from AS 1.
Figure: BGP internet Community Attribute

14

Finite state machine (FSM)

In order to make decisions in its operations with other BGP peers, a BGP peer uses a simple finite state machine (FSM). It 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. 1. 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. 2. 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. 3. If unsuccessful, it starts the ConnectRetry timer and transitions to the "Active" state upon expiration. 4. In the "Active" state, the router resets the ConnectRetry timer to zero and returns to the "Connect" state. 5. In the "OpenSent" state, the router sends an Open message and waits for one in return. 6. 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.

Idle State: o Refuse all incoming BGP connections o Start event triggers the initialization of o Initiates a TCP connection with its configured BGP peer. o Listens for a TCP connection from its peer. o Changes its state to Connect. o If an error occurs at any state of the FSM process, the BGP session is terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are: TCP port 179 is not open. A random TCP port over 1023 is not open. Peer address configured incorrectly on either router. AS number configured incorrectly on either router.
15

Connect State: o Waits for successful TCP negotiation with peer. o BGP does not spend much time in this state if the TCP session has been successfully established. o Sends Open message to peer and changes state to OpenSent. o If an error occurs, BGP moves to the Active state. Some reasons for the error are: TCP port 179 is not open. A random TCP port over 1023 is not open. Peer address configured incorrectly on either router. AS number configured incorrectly on either router. Active State: o If the router was unable to establish a successful TCP session, then it ends up in the Active state. o BGP FSM will try to restart another TCP session with the peer and, if successful, then it will send an Open message to the peer. o If it is unsuccessful again, the FSM is reset to the Idle state. o Repeated failures may result in a router cycling between the Idle and Active states. Some of the reasons for this include: TCP port 179 is not open. A random TCP port over 1023 is not open. BGP configuration error. Network congestion. Flapping network interface. OpenSent State: o BGP FSM listens for an Open message from its peer. o Once the message has been received, the router checks the validity of the Open message. o If there is an error it is because one of the fields in the Open message doesnt match between the peers, e.g. BGP version mismatch, MD5 password mismatch, the peering router expects a different My AS. The router will then send a Notification message to the peer indicating why the error occurred. o If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm. OpenConfirm State: o The peer is listening for a Keepalive message from its peer. o If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state. o If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state. Established State: o In this state, the peers send Update messages to exchange information about each route being advertised to the BGP peer. o If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions back to the Idle state. o If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.

16

Message Format:
The following is the BGP version 4 message header format: bit offset 0 32 64 96 128

015

1623

2431

Marker

Length

Type

Marker: Included for compatibility, must be set to all ones. Length: Total length of the message in octets, including the header. Type: Type of BGP message. The following values are defined: o Open: used to start a BGP session by requesting that a BGP session be opened over an existing TCP/IP session. o Update: This message type contains the actual route updates. The route updates are composed of the
following:

1. Network Layer Reachability Information 2. AS-Path 3. AS-Path Attributes

Updates received are placed in the Routing Information Base (RIB). If a route in an Update message is better than all other routes in the RIB, then that route is placed in the Forwarding Information Base (FIB).

Notification: Notifications are used to send error messages when an update is received but is corrupt, or when the router needs to turn down the session unexpectedly. o KeepAlive: This is the packet used to keep the session running when there are no updates. They are sent between BGP speakers to let each other know they are still there. When a BGP router fails to hear a Keepalive message, it removes all routes heard from that peer from it's forwarding information base (FIB).
o

BGP router connectivity and learning routes

In the simplest arrangement all routers within a single AS and participating in BGP routing must be configured in a full mesh: each router must be configured as peer to every other router. This causes scaling problems, since the number of required connections grows quadratically with the number of routers involved. To alleviate the problem, BGP implements two options: route reflectors (RFC 4456) and confederations (RFC 5065). The following discussion of basic UPDATE processing assumes a full IBGP mesh.

Basic update processing

A given BGP router may accept NLRI *((is exchanged between BGP routers using UPDATE messages. An NLRI is composed of a LENGTH and a PREFIX. The length is a network mask in CIDR notation (eg. /25) specifying the number of network bits, and the prefix is the Network address for that subnet. The NLRI is unique to BGP version 4 and allows BGP to carry super netting information, as well as perform aggregation. The NLRI would look something like one of these:
17

/25, 204.149.16.128 /23, 206.134.32 /8, 10 Only one NLRI is included in an UPDATE Message, though there may be multiple AS-paths and AS-path attributes.)) in UPDATEs from

multiple neighbors and advertise NLRI to the same, or a different set, of neighbors. Conceptually, BGP maintains its own "master" routing table, called the Loc-RIB (Local Routing Information Base), separate from the main routing table of the router. For each neighbor, the BGP process maintains a conceptual Adj-RIB-In (Adjacent Routing Information Base, Incoming) containing the NLRI received from the neighbor, and a conceptual Adj-RIB-Out (Outgoing) for NLRI to be sent to the neighbor. Conceptual, in the preceding paragraph, means that the physical storage and structure of these various tables are decided by the implementer of the BGP code. Their structure is not visible to other BGP routers, although they usually can be interrogated with management commands on the local router. It is quite common, for example, to store the two Adj-RIBs and the Loc-RIB together in the same data structure, with additional information attached to the RIB entries. The additional information tells the BGP process such things as whether individual entries belong in the Adj-RIBs for specific neighbors, whether the per-neighbor route selection process made received policies eligible for the Loc-RIB, and whether Loc-RIB entries are eligible to be submitted to the local router's routing table management process. By eligible to be submitted, BGP will submit the routes that it considers best to the main routing table process. Depending on the implementation of that process, the BGP route is not necessarily selected. For example, a directly connected prefix, learned from the router's own hardware, is usually most preferred. As long as that directly connected route's interface is active, the BGP route to the destination will not be put into the routing table. Once the interface goes down, and there are no more preferred routes, the Loc-RIB route would be installed in the main routing table. Until recently, it was a common mistake to say BGP carries policies. BGP actually carried the information with which rules inside BGP-speaking routers could make policy decisions. Some of the information carried that is explicitly intended to be used in policy decisions are communities and multi-exit discriminators (MED).

Route selection
The BGP standard specifies a number of decision factors more than are used by any other common routing process, for selecting NLRI (Network Layer Reachability Information) to go into the Loc-RIB (Routing Information Base). The first decision point for evaluating NLRI is that its next-hop attribute must be reachable (or resolvable). Another way of saying the next-hop must be reachable is that there must be an active route, already in the main routing table of the router, to the prefix in which the next-hop address is located. Next, for each neighbor, the BGP process applies various standard and implementation-dependent criteria to decide which routes conceptually should go into the Adj-RIB-In *(( contains unprocessed routing information that has been advertised to the local BGP speaker)). The neighbor could send several possible routes to a destination, but the first level of preference is at the neighbor level. Only one route to each destination will be installed in the conceptual Adj-RIB-In. This process will also delete, from the Adj-RIB-In, any routes that are withdrawn by the neighbor. Whenever a conceptual Adj-RIB-In changes, the main BGP process decides if any of the neighbor's new routes are preferred to routes already in the Loc-RIB. If so, it replaces them. If a given route is withdrawn by a neighbor, and there is no other route to that destination, the route is removed from the Loc-RIB, and no longer sent, by BGP, to the main routing table manager. If the router does not have a route to that destination from any non-BGP source, the withdrawn route will be removed from the main routing table.
18

Per-neighbor decisions
After verifying that the next hop is reachable, if the route comes from an internal (i.e. IBGP) peer, the first rule to apply according to the standard is to examine the LOCAL_PREF attribute. If there are several IBGP routes from the neighbor, the one with the highest LOCAL_PREF is selected unless there are several routes with the same LOCAL_PREF. In the latter case the route selection process moves to the next tie breaker. While LOCAL_PREF is the first rule in the standard, once reachability of the NEXT_HOP is verified, Cisco and several other vendors first consider a decision factor called WEIGHT which is local to the router (i.e. not transmitted by BGP). The route with the highest WEIGHT is preferred. LOCAL_PREF, WEIGHT, and other criteria can be manipulated by local configuration and software capabilities. Such manipulation is outside the scope of the standard but is commonly used. For example the COMMUNITY attribute (see below) is not directly used by the BGP selection process. The BGP neighbor process however can have a rule to set LOCAL_PREFERENCE or another factor based on a manually programmed rule to set the attribute if the COMMUNITY value matches some pattern matching criterion. If the route was learned from an external peer the per-neighbor BGP process computes a LOCAL_PREFERENCE value from local policy rules and then compares the LOCAL_PREFERENCE of all routes from the neighbor. At the per-neighbor level - ignoring implementation-specific policy modifiers - the order of tie breaking rules is: 1. Prefer the route with the shortest AS_PATH. An AS_PATH is the set of AS numbers that must be traversed to reach the advertised destination. AS1-AS2-AS3 is shorter than AS4-AS5-AS6-AS7. 2. Prefer routes with the lowest value of their ORIGIN attribute. 3. Prefer routes with the lowest MULTI_EXIT_DISC (multi-exit discriminator or MED) value. Before the most recent edition of the BGP standard, if an UPDATE had no MULTI_EXIT_DISC value, several implementations created a MED with the least possible value. The current standard however specifies that missing MEDs are to be treated as the highest possible value. Since the current rule may cause different behavior than the vendor interpretations, BGP implementations that used the nonstandard default value have a configuration feature that allows the old or standard rule to be selected.

Decision factors at the Loc-RIB level

Once candidate routes are received from neighbors, the Loc-RIB software applies additional tie-breakers to routes to the same destination. 1. If at least one route was learned from an external neighbor (i.e., the route was learned from EBGP), drop all routes learned from IBGP. 2. Prefer the route with the lowest interior cost to the NEXT_HOP, according to the main Routing Table. If two neighbors advertised the same route, but one neighbor is reachable via a low-bitrate link and the other by a high-bitrate link, and the interior routing protocol calculates lowest cost based on highest bitrate, the route through the high-bitrate link would be preferred and other routes dropped. If there is more than one route still tied at this point, several BGP implementations offer a configurable option to load-share among the routes, accepting all (or all up to some number). 1. Prefer the route learned from the BGP speaker with the numerically lowest BGP identifier 2. Prefer the route learned from the BGP speaker with the lowest peer IP address
19

BGP Path Selection summarize

BGP could possibly receive multiple advertisements for the same route from multiple sources. BGP selects only the first valid path and assigns as the current best path. BGP then compares the best path with the next path in the list, until BGP reaches the end of the list of valid paths. The following list provides the rules that are used to determine the best path: 1. Prefer the path with the highest WEIGHT. Note: WEIGHT is a Cisco-specific parameter. It is local to the router on which it is configured. 2. Prefer the path with the highest LOCAL_PREF. Note: A path without LOCAL_PREF is considered to have had the value set with the bgp default localpreference command, or to have a value of 100 by default. 3. Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP. Local paths that are sourced by the network or redistribute commands are preferred over local aggregates that are sourced by the aggregate-address command. 4. Prefer the path with the shortest AS PATH. Note: Be aware of these items: o This step is skipped if you have configured the bgp bestpath as-path ignore command. o An AS_SET counts as 1, no matter how many ASs are in the set. o The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_PATH length. 5. Prefer the path with the lowest origin type. Note: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE. 6. Prefer the path with the lowest multi-exit discriminator (MED). Note: Be aware of these items: o This comparison only occurs if the first (the neighboring) AS is the same in the two paths. Any confederation sub-ASs are ignored. In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same for multiple paths. Any preceding AS_CONFED_SEQUENCE is ignored. o If bgp always-compare-med is enabled, MEDs are compared for all paths. You must disable this option over the entire AS. Otherwise, routing loops can occur. o If bgp bestpath med-confed is enabled, MEDs are compared for all paths that consist only of AS_CONFED_SEQUENCE. These paths originated within the local confederation. o THE MED of paths that are received from a neighbor with a MED of 4,294,967,295 is changed before insertion into the BGP table. The MED changes to to 4,294,967,294. o Paths received with no MED are assigned a MED of 0, unless you have enabled bgp bestpath med missing-as-worst . If you have enabled bgp bestpath med missing-as-worst , the paths are assigned a MED of 4,294,967,294. o The bgp deterministic-med command can also influence this step. Refer to How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection for a demonstration. 7. Prefer eBGP over iBGP paths. If bestpath is selected, go to Step 9 (multipath). Note: Paths that contain AS_CONFED_SEQUENCE and AS_CONFED_SET are local to the confederation. Therefore, these paths are treated as internal paths. There is no distinction between Confederation External and Confederation Internal.
20

8. Prefer the path with the lowest IGP metric to the BGP next hop. Continue, even if bestpath is already selected. 9. Determine if multiple paths require installation in the routing table for BGP Multipath. Continue, if bestpath is not yet selected. 10. When both paths are external, prefer the path that was received first (the oldest one). This step minimizes route-flap because a newer path does not displace an older one, even if the newer path would be the preferred route based on the next decision criteria (Steps 11, 12, and 13). Skip this step if any of these items is true: o You have enabled the bgp best path compare-routerid command. Note: Cisco IOS Software Releases 12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T, and 12.1.3.E introduced this command. o The router ID is the same for multiple paths because the routes were received from the same router. o There is no current best path. The current best path can be lost when, for example, the neighbor that offers the path goes down. 11. Prefer the route that comes from the BGP router with the lowest router ID. The router ID is the highest IP address on the router, with preference given to loopback addresses. Also, you can use the bgp router-id command to manually set the router ID. Note: If a path contains route reflector (RR) attributes, the originator ID is substituted for the router ID in the path selection process. 12. If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length. This is only present in BGP RR environments. It allows clients to peer with RRs or clients in other clusters. In this scenario, the client must be aware of the RR-specific BGP attribute. 13. Prefer the path that comes from the lowest neighbor address. This address is the IP address that is used in the BGP neighbor configuration. The address corresponds to the remote peer that is used in the TCP connection with the local router.

When the path is selected, BGP puts the selected path in the IP routing table and propa gates the path to its neighbors.

21

Communities
BGP communities are attribute tags that can be applied to incoming or outgoing prefixes to achieve some common goal (RFC 1997). While it is common to say that BGP allows an administrator to set policies on how prefixes are handled by ISPs, this is generally not possible, strictly speaking. For instance, BGP natively has no concept to allow one AS to tell another AS to restrict advertisement of a prefix to only North American peering customers. Instead, an ISP generally publishes a list of well-known or proprietary communities with a description for each one, which essentially becomes an agreement of how prefixes are to be treated. Examples of common communities include local preference adjustments, geographic or peer type restrictions, DoS avoidance (black holing), and AS prepending options. An ISP might state that any routes received from customers with community XXX:500 will be advertised to all peers (default) while community XXX:501 will restrict advertisement to North America. The customer simply adjusts their configuration to include the correct community(ies) for each route, and the ISP is responsible for controlling who the prefix is advertised to. The end user has no technical ability to enforce correct actions being taken by the ISP, though problems in this area are generally rare and accidental. It is a common tactic for end customers to use BGP communities (usually ASN:70,80,90,100) to control the local preference the ISP assigns to advertised routes instead of using MED (the effect is similar). It should also be noted that the community attribute is transitive, but communities applied by the customer very rarely become propagated outside the next-hop AS.

Extended communities
The BGP Extended Community Attribute was added in 2006 in order to extend the range of such attributes and to provide a community attribute structuring by means of a type field. The extended format consists of one or two octets for the type field followed by seven or six octets for the respective community attribute content. The definition of this Extended Community Attribute is documented in RFC 4360. The IANA administers the registry for BGP Extended Communities Types.[4] The Extended Communities Attribute itself is a transitive optional BGP attribute. However, a bit in the type field within the attribute decides whether the encoded extended community is of a transitive or non-transitive nature. The IANA registry therefore provides different number ranges for the attribute types. Due to the extended attribute range, its usage can be manifold. RFC 4360 exemplarly defines the "Two-Octet AS Specific Extended Community", the "IPv4 Address Specific Extended Community", the "Opaque Extended Community", the "Route Target Community" and the "Route Origin Community". A number of BGP QoS drafts[5] also use this Extended Community Attribute structure for inter-domain QoS signalling.

22

BGP Multipath Support

When a BGP speaker learns two identical EBGP paths for a prefix from a neighboring AS, it will choose the path with the lowest route-id as the best path. This best path is installed in the IP routing table. If BGP multipath support is enabled and the EBGP paths are learned from the same neighboring AS, instead of picking one best path, multiple paths are installed in the IP routing table. During packet switching, depending on the switching mode, either per-packet or per-destination load balancing is performed among the multiple paths. A maximum of six paths is supported. The maximum-paths router configuration command controls the number of paths allowed. By default, BGP will install only one path to the IP routing table.

Requirements of a router for use of BGP for Internet and backbone-of-backbones purposes
Routers, especially small ones intended for Small Office/Home Office (SOHO) use, may not include BGP software. Some SOHO routers simply are not capable of running BGP using BGP routing tables of any size. Other commercial routers may need a specific software executable image that contains BGP, or a license that enables it. Open source packages that run BGP include GNU Zebra, Quagga, OpenBGPD, BIRD, XORP and Vyatta. Devices marketed as Layer 3 switches are less likely to support BGP than devices marketed as routers, but high-end Layer 3 Switches usually can run BGP. Products marketed as switches may or may not have a size limitation on BGP tables, such as 20,000 routes, far smaller than a full Internet table plus internal routes. These devices, however, may be perfectly reasonable and useful when used for BGP routing of some smaller part of the network, such as a confederation-AS representing one of several smaller enterprises that are linked, by a BGP backbone of backbones, or a small enterprise that announces routes to an ISP but only accepts a default route and perhaps a small number of aggregated routes. A BGP router used only for a network with a single point of entry to the Internet may have a much smaller routing table size (and hence RAM and CPU requirement) than a multihomed network. Even simple multihoming can have modest routing table size. See RFC 4098 for vendor-independent performance parameters for single BGP router convergence in the control plane. The actual amount of memory required in a BGP router depends on the amount of BGP information exchanged with other BGP speakers, and the way in which the particular router stores BGP information. The router may have to keep more than one copy of a route, so it can manage different policies for route advertising and acceptance to a specific neighboring AS. The term view is often used for these different policy relationships on a running router. If one router implementation takes more memory per route than another implementation, this may be a legitimate design choice, trading processing speed against memory. A full BGP table as of November 2011 is in excess of 370,000 prefixes. Large ISPs may add another 50% for internal and customer routes. Again depending on implementation, separate tables may be kept for each view of a different peer AS.

23

BGP Problems & Issues:

BGP has been proven to be secure, efficient, scalable, and robust. However, with the rapid evolving of the Internet in the past few decades, there are increasing concerns about BGSs ability to meet the needs of the Internet routing. BGP sometimes causes serious instability and outages. Unlike other routing protocols that have limited failing impact and scope, BGP problems may result in significant and widespread damage. The problems of BGP mainly caused by the following reasons: 1. Uncertainty about the relationship between IP prefixes and the AS numbers of the ASs who manage them. 2. The use of the Transmission Control Protocol (TCP) as the underlying transport protocol, and 3. The potential to tamper with route announcements in order to subvert BGP routing policy

The problems may be summarized as follow

1.

IBGP scalability issue

EBGP is a path vector protocol, which means that loops in routing paths are detected and avoided by checking for multiple occurrences of an AS in the AS_PATH at each BGP node. However, this scheme cannot be used to detect loops in IBGP since all the speakers belong to the same AS. Thus, to avoid loops in IBGP, every BGP router is required to maintain an IBGP session with all other BGP routers within the AS. Obviously maintaining a full mesh of IBGP sessions is not scalable. To overcome this scalability issue, there are two common IBGP configuration schemes: AS confederations*((A collection of autonomous systems
advertised as a single AS number to BGP speakers that are not members of the confederation. Another alternative to the "full mesh" requirement.)) and route reflections*((BGP speakers within a single AS must be fully meshed. Route Reflection is an alternative in alleviating the need for a "full mesh" and allows a BGP speaker (known as "Route Reflector") to advertise IBGP learned routes to certain IBGP peers))

Both techniques reduce the number of IBGP sessions need to be maintained in the network and consequently reduce processing overhead. While route reflectors are considered a pure performance-enhancing technique, route confederations are mainly used to implement more fine-grained policy. However, these alternatives can introduce a set of problems of their own, including the following: 1. Route oscillation. 2. Rub-optimal routing. 3. Increase of BGP convergence time. Varadhan et.al. *((K. Varadhan, R. Govindan, D. Estrin, Persistent Route Oscillations in Inter-Domain Routing, Computer Networks, 1999.)) were the first to discuss the possibility of persistent route oscillations in BGP even in simple topologies. They showed that the oscillation cause was not the policy configuration of one AS alone; but it occurs due to interaction between the policies of several ASs. They further showed that these anomalies can occur without any misconfiguration and they are difficult to diagnose and resolve. Griffin et.al. *((T. G. Griffin and G. Wilfong, On the correctness of IBGP configuration, in Proceedings of ACM SIGCOMM, August 2002.)) Introduced the Stable Paths Problem (SPP) as a formal model for vector routing model in general and for BGP specifically. They used their framework to provide a sufficient condition for protocol convergence, which is the absence of dispute wheels. Unfortunately, they showed that the problem of detecting whether stable routing exists, given all the policies in the network, is NP-complete. They also
24

showed that the existence of a stable solution does not automatically imply that a routing protocol can find it. Later Griffin et al. showed that route oscillations can occur even without taking MED. There have been several follow ups to investigate these routing anomalies. One of the approaches to eliminate MED oscillations, was proposed by Basu et al. *((A. Basu, C.-H. L. Ong, A. Rasala, F. B. Shepherd, and G. Wilfong, .Route oscillations in IBGP with route refection, in Proc. ACM SIGCOMM, August 2002. )) They proposed to change the protocol such that the oscillation problem vanishes. Basu et al. also presented a counter example for the solution provided by Walton et al. *((D. Walton, D. Cook, A. Retana, and J. Scudder, BGP persistent route oscillation solution, IETF, Internet Draft, July 2000. )) However, Griffin *(( T. G. Griffin
and G. Wilfong, Analysis of the MED oscillation problem in BGP, in Proceedings of IEEE International Conference on Network Protocols (ICNP), 2002. )) showed that the method proposed in Basu et al. has had scaling issues. Griffin et al.

analyzed the oscillations and loops due to path asymmetry using a graph theoretic approach. They further proved that detecting such anomalies is NP hard. Musunuri et al. *((R. Musunuri and J. A. Cobb, Scalable IBGP through selective path dissemination, in Proceedings of IASTED International Conference on Parallel and Distributed Computing and Systems (PDCS), November 2003. )) proposed to modify the IBGP protocol to eliminate these anomalies. Their method is based on applying IBGP with some restrictions on the IBGP configuration. They also assume a full mesh of IBGP sessions among all the border speakers. However, this is not very practical as it seems similar to assuming a full mesh of IBGP sessions between all the BGP speakers. Gobjuka*((H. Gobjuka, Forwarding-loop-free configuration for ibgp networks, in Proceedings of IEEE International Conference on Networks (ICON), September 2003.)) studied forwarding loops caused by IBGP misconfiguration. He showed that finding forwarding loops in IBGP networks are inherently hard. He further proposed a polynomial-time algorithm for clustering ASes and he showed that the AS configured using his method results in forwardingloop free network. Later, Musunuri et al. *((R. Musunuri and J. A. Cobb, Complete solution to stable IBGP, in Proceedings of IEEE International Conference on Communications, June 2004.)) proposed another changes to IBGP to solve the problems due to both MED attribute and path asymmetry. Gao and Rexford *((L. Gao, T. G. Griffin, and J. Rexford. Inherently Safe Backup Routing with BGP. In Proceedings of IEEE INFOCOM 2001. IEEE Computer Society, IEEE Press, April 2001.)) studied the Internet economics and showed that it could naturally guarantee route stability. Specifically, they show that a hierarchical business structure underlying the graph representation of the AS, in combination with routing policies is sufficient for protocol convergence. In this structure, they followed the customer-provider relationships between different ASes. Feamster et.al.*((N. Feamster, J. Winick, and J. Rexford, .A model of BGP routing for network engineering,. in Proc. ACM SIGMETRICS, June 2004.)) improved this result and demonstrate that certain rankings that are commonly used in practice may not ensure routing stability. Further, they proved that the routing system will converge to a stable path when providers can set rankings and filters autonomously.
2.

Instability issue

Since routing table have to be consistent with network, the routing tables managed by a BGP implementation are adjusted continually to reflect actual changes in the network infrastructure. Examples of such changes are links breaking and being restored or routers going down and coming back up. These events happen almost continuously in the network as a whole and they are considered normal. However, the frequency of these events should be low for a specific router or link. When a router is misconfigured or mismanaged then it may get into a frequent cycle of going down (withdrawal) and then up (reannouncement). Consequently, this pattern of repeated route withdrawal and then reannouncement can result in abnormal activity in all the routers that know about the broken link, as the same route is continuously injected and withdrawn from the routing tables. This problem is known as route flapping *((occurs when a router alternately
25

advertises a destination network via one route then another (or as unavailable, and then available again). A closely related term is interface flapping where an interface on a router has a hardware failure that will cause the router to announce it alternately as "up" and "down".)) which can cause excessive activity in all the other routers that know about the broken link, as the same route is continuously injected and withdrawn from the routing tables. The BGP design is such that delivery of traffic may not function while routes are being updated. On the Internet, a BGP routing change may cause outages for several minutes.

A feature known as route flap damping (RFC 2439) is built into many BGP implementations in an attempt to mitigate the effects of route flapping. Without damping the excessive activity can cause a heavy processing load on routers, which may in turn delay updates on other routes, and so affect overall routing stability. With damping, a route's flapping is exponentially decayed. At the first instance when a route becomes unavailable and quickly reappears, damping does not take effect, so as to maintain the normal fail-over times of BGP. At the second occurrence, BGP shuns that prefix for a certain length of time; subsequent occurrences are timed out exponentially. After the abnormalities have ceased and a suitable length of time has passed for the offending route, prefixes can be reinstated and its slate wiped clean. Damping can also mitigate denial of service attacks; damping timings are highly customizable. It is also suggested in RFC 2439 (under "Design Choices -> Stability Sensitive Suppression of Route Advertisement") that route flap dampening is a feature more desirable if implemented to Exterior Border Gateway Protocol Sessions (EBGP sessions or simply called exterior peers) and not on Interior Border Gateway Protocol Sessions (IBGP sessions or simply called internal peers); With this approach when a route flaps inside an autonomous system, it is not propagated to the external ASs - flapping a route to an EBGP will have a chain of flapping for the particular route throughout the backbone. This method also successfully avoids the overhead of route flap dampening for IBGP sessions. However, subsequent research has shown that flap damping can actually lengthen convergence times in some cases, and can cause interruptions in connectivity even when links are not flapping. Moreover, as backbone links and router processors have become faster, some network architects have suggested that flap damping may not be as important as it used to be, since changes to the routing table can be absorbed much faster by routers. This has led the RIPE Route Working Group to write that "with the current implementations of BGP flap damping, the application of flap damping in ISP networks is NOT recommended. ... If flap damping is implemented, the ISP operating that network will cause side-effects to their customers and the Internet users of their customers' content and services. These side-effects would quite likely be worse than the impact caused by simply not running flap damping at all."Improving stability without the problems of flap damping is the subject of current research. Another approach is to activate a BGP feature called graceful restart, which exploits routing tables that were downloaded into the hardware line cards prior to the crash. Assuming the crash left the routing tables intact, when the new BGP service starts up, the router will still be running using the old routing table, a bit like an airplane on autopilot. The router wont be adapting to new routing updates and is thus frozen in time, but at least it was initially in a consistent state. Graceful restart tells the neighboring routers to continue to route packets through the impacted router, even as the restarting BGPD resynchronizes with its peers. The problem, however, is that while this is happening, BGP updates continue to stream in at a furious pace, so routing tables can become inconsistent within seconds. This creates a strong motivation to improve routing daemon availability. For example, some work has aimed at running BGP in a movable virtual machine (but VM migration is slow, and offers no help for fault tolerance), and some hand-tuned BGP migration mechanisms exist.2 Our approach offers fault tolerance, can support BGP upgrades (patching), and works with routing daemons other than BGPD, yet is fast and built from surprisingly simple technologies .
26

Other approach in *((Andrei Agapi, Ken Birman, Robert M. Broberg, Chase Cotton,Thilo Kielmann, Martin Millnert,
Rick Payne, Robert Surton,and Robbert van Renesse , Routers for the Cloud Can the Internet Achieve 5-Nines Availability?))

uses software to transform a standard BGPD implementation into a fault-tolerant service. It involves minimal changes to the existing BGPD, the operating system, and existing protocols such as TCP, IP, and UDP. The first step is to wrap BGPD in a fault-tolerance layer, the fault-tolerance shim. The shim helps the underlying routing protocol handle failures in ways invisible to remote peers.
3.

Routing table growth issue

This issue comes into picture when the routing table grows to the point where some older, less capable, routers cannot cope with the resource requirements for maintaining the routing table. Thus, these routers will cease to be effective gateways between the parts of the Internet they connect. Furthermore, larger routing tables usually take longer time to stabilize on a path when a major routing table change occurs, which affects the network service reliability and availability. Until late 2001, the global routing table was growing exponentially, threatening an eventual widespread breakdown of connectivity. In an attempt to prevent this, ISPs cooperated in keeping the global routing table as small as possible, by using Classless Inter-Domain Routing (CIDR) and route aggregation. While this slowed the growth of the routing table to a linear process for several years, with the expanded demand for multihoming by end user networks the growth was once again superlinear by the middle of 2004. As of April 2010, the routing table has in excess of 310,000 entries

BGP table growth on the Internet. 4.

Number of AS on the Internet vs number of registered AS.

Load-balancing issue

Another factor is the need for load balancing of multi-homed networks. It is not a trivial task to balance the inbound traffic to a multi-homed network across its multiple inbound paths, due to limitation of the BGP route selection process. For a multi-homed network, if it announces the same network blocks across all of its BGP peers, the result may be that one or several of its inbound links become congested while the other links remain underutilized, because External networks all picked that set of congested paths as optimal. Like most other routing protocols, the BGP protocol does not detect congestion. To work around this problem, BGP administrators of that multihomed network may divide a large continuous IP address block into smaller blocks, and tweak the route announcement to make different blocks look optimal on different paths, so that external networks will choose a different path to reach different blocks of that multi-homed network. Such cases will increase the number of routes as seen on the global BGP table.

27

5.

Security Issues

In the last decade, several major incidents and attacks have been reported regarding compromising of the routing infrastructure on the Internet. Many of these incidents and attacks have resulted in issues such as misrouted traffic and denial of services (DoS). One of the subjects that have been studied widely is the prefix hijack attack in which hackers update BGP routing tables with false origin information which causes serious consequences when this information are propagated. These attacks need to be detected early and accurately so that their propagation through the Internet can be stopped and damage can be mitigated quickly. Early approaches to develop BGP security extensions have failed, but new research directions in heuristic, data driven approaches to suppressing erroneous and malicious BGP messages show some practical promise. The BGP security issues have been widely investigated by the research community, some proposals might be summarized as follow. The Internet Engineering Task force (IETF) has discussed some of the main security problems related to BGP, proposed possible In attempt to overcome BGP security issues, several extensions for BGP have been proposed. Kent et al. *(( S. Kent, C. Lynn, J. Mikkelson, K. Seo, Secure Border Gateway Protocol (S-BGP) Real World Performance and Deployment Issues, IEEE Journal on Selected Areas in Communications, 2000. )) proposed a secure, scalable, deployable architecture (S-BGP) for an authorization and authentication system that addresses most of the security problems associated with BGP. They discussed the vulnerabilities and security requirements associated with BGP, described the S-BGP countermeasures. They also provided a comparison of their architecture to other approaches that have been proposed, analyzed the performance implications of the proposed countermeasures, and addressed operational issues. White et al.*((R. White. Securing BGP through secure origin BGP. Technical report, Cisco Internet Protocol Journal, September 2003)) proposed secure origin BGP (soBGP), where origin authentication is accomplished in an oligarchy PKI similar to that in S-BGP. The main difference between S-BGP and soBGP is that soBGP does not use cryptographic mechanisms to secure the authenticity of the entire AS PATH. It instead verifies AS paths against a database of AS-to-AS routing relationships. soBGP validates the correctness and authorization of the data carried within BGP, and also prevents the sorts of attacks resulting from misconfiguration or intentional insertion of bad data into the Internet routing system. Kruegel et al.*((C. Kruegel, D. Mutz, W. Robertson, and F. Valeur. Topology-based detection of anomalous BGP messages. In Proceedings of the 6th Symposium on Recent Advances in Intrusion Detection (RAID), 2003)) proposed a method for detecting malicious inter-domain routing update messages by monitoring BGP traffic. Goodell et al. propose IRV *((G. Goodell, W. Aiello, T. Griffin, J. Ioannidis, P. McDaniel, and A. Rubin. Working around BGP:
An incremental approach to improving security and accuracy in interdomain routing. In Proceedings of Symposium on Network and Distributed System Security (NDSS03), February 2003.)) that works with BGP to maintain dedicated verification

servers and to verify the authenticity of BGP advertisements. Yu et al. *((Harlan Yu, Jennifer Rexford, and Edward W. Felten. A distributed reputation approach to cooperative internet routing protection. In Workshop on Secure Network Protocols, 2005.)) propose a mutual trust-based scheme to evaluate authenticity of BGP advertisements . Their method is incrementally deployable, protects against shilling attacks, and deters malicious operator behavior. Aiello et al. *((W. Aiello, J. Ioannidis, and P. McDaniel. Origin authentication in interdomain routing. In ACM Conference on Computer and Communications Security (CCS 2003), 2003. )) also address the problem of origin authentication through the use of Address Delegation Graph (ADG). Subramanian et al. propose a method called Listen and Whisper *((L. Subramanian, V. Roth, I. Stoica, S. Shenker, and
R. Katz. Listen and whisper: Security mechanisms for BGP. In Proc. of the First Symposium on Networked Systems Design and Implementation (NSDI04), 2004 )) , which eliminates a large number of problems due to router

28

misconfigurations and can detect and contain isolated adversaries that propagate even a few invalid route announcements. Hu et al. *((Y.-C. Hu, A. Perrig, and M. Sirbu. SPV: Secure path vector routing for securing BGP. In Proceedings of ACM SIGCOMM 2004, September 2004.))propose a new protocol called Secure Path Vector (SPV) focus on securing BGP update messages against attacks and addresses AS PATH authentication through the use of one-time signatures and symmetric cryptographic primitives. They also limit the use of expensive public-key cryptography.

BGP Configuration
The BGP configuration tasks are divided into basic and advanced tasks. The first two basic tasks are required to configure BGP; the remaining basic and advanced tasks are optional.

Requirement for running BGP

To run BGP it is required to have the following: 1. An AS Number 2. Multi-homed to the Internet 3. BGP4 Capable Router 4. Sufficient Router Memory 5. Fully Functional IGP 6. Qualified Internet Engineer 1. AS NUMBER An AS number can ONLY be purchased from one of the Regional Internet Registries (RIR's). Which registry you obtain your AS number from is based upon where in the world your network resides physically and will be connecting.

AMERICAS/AFRICA - American Registry for Internet Numbers EUROPE - Reseaux IP Europeens (RIPE) ASIA - Asian Pacific Network Information Center (APNIC)

2. MULTI-HOMED To receive an AS number from ARIN, RIPE, or APNIC, you must be able to prove your network is connected to more than one Internet Provider running BGP by providing the contact phone number. This is called being 'multi-homed'. 3. BGP4 CAPABLE ROUTER USE A BRAND OF ROUTER YOUR PROVIDER SUPPORTS. This reduces the chances of incompatibility issues and allows your provider to give you better support, as they will have experience with the equipment already. Cisco routers must be running version 10.3 of the IOS or later to support BGP version 4.

29

4. ROUTER MEMORY Router will need sufficient memory to process the BGP routes your providers will be sending you. The table below gives a GENERAL outline of how much RAM will be required. Most providers support most of the following ranges of routes. RECEIVING FULL ROUTES (entire Internet routing table) PARTIAL ROUTES BACKBONE ONLY NO ROUTES* # ~ 135 K 45 K+ 10 - 2K 0 or 1 TOTAL RAM REQ'D 128 MB 64 MB - 128 MB 32 MB - 64 MB --

* If you are receiving NO ROUTES from your provider, you will either need a static default route, or ask your provider to send you the default route via BGP. If your ISP uses a Cisco router, your ISP can install the 'neighbor x.x.x.x default-originate' command in their neighbor statements for your BGP session. 5. FULLY FUNCTIONAL IGP Interior Gateway Protocol (Static routes, RIP, OSPF, EIGRP) should be completely configured and functioning correctly. ALL internal networks should be completely installed, powered on, and routing correctly internally, as well as having the correct default routes pointing to your soon-to-be-installed Internet BGP4 gateway. Unless these are complete, BGP will NEVER advertise your route unless you take extreme measures, and even then your connectivity to the Internet will likely STILL not work. By default, BGP DOES NOT advertise networks it cannot reach. Thus, an interior IP address range must be fully synchronized with the IP route table before BGP will advertise it to the Internet. You can of course set a Cisco router to use the 'no-synchronization' command, but all that will happen is that traffic will be sent to your Internet router, but your traffic will die right there on the spot unless your Internet router is also the ONLY router on your network and it is directly connected to ALL your networks. 6. QUALIFIED INTERNET ENGINEER If your company's engineer cannot answer the following questions, have someone who CAN answer these questions configure your BGP: 1. 2. 3. 4. 5. 6. 7. What is your AS number? What is your router's PUBLIC and ROUTABLE IP address? Who are your neighbors and what are their IP addresses? What CIDR prefixes will you advertise? Will you be aggregating? What is your routing policy? Will you be accepting full, partial or no routes from your provider?

30

 BGP configuration tasks: Basic BGP configuration tasks:

Basic BGP configuration tasks are: Enable BGP Routing Configure BGP Neighbors Configure BGP Soft Reconfiguration Reset BGP Connections Configure BGP Interactions with IGPs Configuring BGP Weights Configure BGP Route Filtering by Neighbor Configure BGP Path Filtering by Neighbor Disable Next-Hop Processing on BGP Updates Configure the BGP Version Set the Network Weight Configure the Multi Exit Discriminator Metric

Advanced BGP Configuration Tasks

Advanced, optional BGP configuration tasks are: Use Route Maps to Modify Updates Reset EBGP Connections Immediately upon Link Failure Configure Aggregate Addresses Disable Automatic Summarization of Network Numbers Configure BGP Community Filtering Configuring BGP Conditional Advertisement Configure a Routing Domain Confederation Configure a Route Reflector Configure BGP Peer Groups Indicate Backdoor Routes Modify Parameters While Updating the IP Routing Table Set Administrative Distance Adjust BGP Timers Change the Local Preference Value Redistribute Network 0.0.0.0 Select Path Based on MEDs from Other Autonomous Systems Configure the Router to Use the MED to Choose a Path from Sub-AS Paths Configure Route Dampening Monitor and Maintain BGP

Attached a document with full description for the configuration tasks for BGP.

31

References:
http://www.academ.com/nanog/feb1997/BGPTutorial/tsld001.htm A Survey on BGP Issues and Solutions- http://arxiv.org/ftp/arxiv/papers/0907/0907.4815.pdf http://en.wikipedia.org/wiki/Routing_protocol http://en.wikipedia.org/wiki/Border_gateway_protocol http://en.wikipedia.org/wiki/Autonomous_system_%28Internet%29 http://www.inetdaemon.com/tutorials/internet/ip/routing/bgp/index.shtml http://www.academ.com/nanog/feb1997/BGPTutorial/sld001.htm http://docwiki.cisco.com/wiki/Internetworking_Technology_Handbook#Routing http://docwiki.cisco.com/wiki/Border_Gateway_Protocol http://searchtelecom.techtarget.com/definition/BGP http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml http://www.estoile.com/links/bgp4.htm http://www.potaroo.net/papers/phd/refs/ Configuring BGP http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cbgp.html?referring_site=bodynav#wp 4723

32