CCIE Professional Development Routing TCP-IP Volume II

CCIE BGP

Resources: CCIE Professional Development Routing TCP-IP Volume II CCIE Routing and Switching Exam Certification Guide 3rd Edition

When Tier one service providers agree to share routes and traffic they enter a peering agreement. This agreements can be bilateral or multilateral.

Effective BGP peering must involve a certain amount of both trust and distrust.

BGP uses TCP port 179 for communications

Hello timer 60 seconds, hold 180 seconds (default)

BGP is a path vector routing protocol , it knows which AS are traversed to reach the destination but still doesn’t have a SPF style topology tree.

IF a BGP router receives an update and it can see its own AS in the path it discards the update.

Cisco routers have a separate table to hold BGP routes ( show ip BGP)

The bgp table contains all known routes and the preferred route is denominated with a * BGP is classless but by default summarises at the classfull boundary.

By default BGP only uses 1 path if there are equal cost paths ( this can up set to up to 6 for EBGP but can only be 1 for IBGP)

If a peer ( neighbour) router has a different AS number then that relationship is EBGP.

If a peer router has the same AS number then it is IBGP.

BGP on connection establishment will do a full table exchange, from there only when a route changes.

EBGP packets has a TTL set to 1 this means that only directly connected EBGP can send BGP updates to each other. This breaks the usage of loopback interfaces as the source. neighbor ebgp-multihop command can change this behavior.

Network statement, the network statement in BGP is different to an IGP, it just tells BGP to advertise the NET as apposed to an IGP where the network statement specifics interfaces that the routing protocol will run on.

BGP has 4 message types: Open message: after tcp session is established it is used to specify BGP operational parameters Version number (default is 4) The AS number of the router ( to determine E or I BGP) Holdtimer, how offen a keepalive message must be received, 0 is no holdtimer , minimum of 3 seconds default 180 BGP identifier : same as OSPF ( highest loopback address used) Optional parameters : authentication etc

Keepalive message: by default set to 1/3 of the holdtimer ( 60 seconds)

Update message:

Network Layer Reachability Information (NLRI): This is one or more (Length, Prefix) tuples that advertise IP address prefixes and their lengths. If 206.193.160.0/19 were being advertised, for example, the Length portion would specify the /19 and the Prefix portion would specify 206.193.160.

Path Attributes The path attributes, are characteristics of the advertised NLRI. The attributes provide the information that allows BGP to choose a shortest path, detect routing loops, and determine routing policy.

Withdrawn Routes These are (Length, Prefix) tuples describing destinations that have become unreachable and are being withdrawn from service.

Notification message: The Notification message is sent whenever an error is detected and always causes the BGP connection to close.

BGP state machine

IDLE state.

BGP isn’t active doesn’t do anything, a start event needs to be triggered ( router BGP AS command or resetting BGP a process) it transition to the connected state. Connections to its neighbours are attempted as well as receiving incoming connection attempts.

Connected state: the router is wating for the tcp connection to be established. If it is successfully established it sends an open message and transitions to the OPENsent state. If the connect attempt fails the router will still listen for incoming connection but will transition to the ACTIVE state.

ACTIVE state: The router continues to try and establish a connection if it is successful it transistions to the Opensent state. If it cant it will go back to the connected state. Any other imput events at this time will cause the router to go back to the idle state.

Opensent state: in this state an open and been sent and the router is waiting to receive an open message from its neighbour. When it receives the open message it is checked. If there is an error a notification message is sent at the router transitions to the IDLE state.

If there is no erros a keepalive packet is sent, the hold timer is negotiated ( the lowest is accepted ) the peer either becomes internal or external and is transitioned to the OPENConfirm state.

If a tcp disconnect message is received the router is transitioned to the active state.

Openconfirm state: is waiting for the return of a keep alive message. If one is received then the router is transitioned to the established state. If it isn’t received the router transitioned to the idle state.

Established state: Peers can exchange updates, if a notification message is received the router is transitioned to IDLE state.

To become a BGP neighbour 1.The router must receive a TCP connection request with a source address that the router finds in a BGP neighbor command. 2. A router’s ASN (on the router bgp asn command) must match the neighboring router’s reference to that ASN with its neighbor remote-as asn command. (This requirement is not true of confederation configurations.) 3. The BGP RIDs of the two routers must not be the same. 4. If configured, MD5 authentication must pass. Path attributes!!! A path attribute is a charactistic of a route and they fall into 4 categories:

Well known mandatory Well known discretionary Optional transitive Optional nontransitive

Well known must be recognised by all bgp routers, Optional is optional. Mandatory means that they must be carried in a routing update. Discretionary means that they are optional in a routing update. Trasitive means they have to be carried even if the router cant interperate them Nontransitive means they can be dropped the update if not understood. Nontrasitive attributes can be added and removed at any stage during the route propagation throughout AS’s.

Attribute Class ORIGIN Well-known mandatory AS_PATH Well-known mandatory NEXT_HOP Well-known mandatory LOCAL_PREF Well-known discretionary ATOMIC_AGGREGATE Well-known discretionary AGGREGATOR Optional transitive COMMUNITY Optional transitive MULTI_EXIT_DISC (MED) Optional nontransitive ORIGINATOR_ID Optional nontransitive CLUSTER_LIST Optional nontransitive

The ORIGIN attribute this is where the route was learnt from, IGP, the route was learnt from within an IGP (network statement) this is the most preferred ORIGIN attribute EGP- the route was learnt from EGP, is second in preference. Incomplete – the least desired, BGP cant guarantee the source of the route, redistributed routes are given the value of incomplete because there is no way to determine the exact source of the route.

AS_PATH There are four type of AS_PATH formatting, this as is only added to the path as it leaves that AS to another as (EBGP Peer).

AS_SEQUENCE A router will prepend(add to the front) the its AS number to a route update when it advertises it to external neighbours. Each router along the way does this giving an exact AS path that is taken by the route.

A router can make a path look more desirable by making another path look less desirable by prepending its own AS number multiple times to artificially increase the hop count. This is known as AS path prepending. A router will drop a update if it see’s a loop in the AS path.

AS_SET This is an unordered list of the AS numbers along a path to a destination. It is sent along with the AS-sequence. When a route is summarized the AS-sequence is lost but the AS_SET remains. When a router see’s an update that has its own AS number in the AS_SET it discards the route as it could form a loop. AS_SET isn’t used for shortest path calculations but only as a record of what AS’s this update has come from.

When the as-set option has been configured, the router creates an AS_SET segment for the aggregate route, but only if the summary route’s AS_SEQ is null.

See the confederations section for the other two.

AS NEXT-HOP

If the advertising router and receiving router are in different autonomous systems (external peers), the NEXT_HOP is the IP address of the advertising router's interface.

If the advertising router and the receiving router are in the same AS (internal peers), and the NLRI of the update refers to a destination within the same AS, the NEXT_HOP is the IP address of the neighbor that advertised the route.

If the advertising router and the receiving router are internal peers and the NLRI of the update refers to a destination in a different AS, the NEXT_HOP is the IP address of the external peer from which the route was learned. The exact wording of the rule is: if the current BGP next hop is in the same IP subnet as the receiving router the next hop address is not changed.

Local_preference

This is only used by IBGP neighbours, it is not passed to other AS’s. if there a multipule paths to a destination(another AS) an IBGP peer will look at the local preference to decided which route to use.

MULTI_EXIT_disc (MED)

This optional nontransitive attribute is carried in EBGP updates and allows an AS to inform another AS of its preferred ingress points. If all else is equal, an AS receiving multiple routes to the same destination compare the MEDs of the routes. Unlike LOCAL_PREF, in which the largest value is preferred, the lowest MED value is preferred. This is because MED is considered a metric, and with a metric the lowest value—the lowest distance—is preferred.

MED isn’t advertises any further then the directly receiving AS. SO only routes between two directly connected AS can be influenced.

MED is normally the metric from the IGP that the route was learnt from

Default MED is 0 ( which is best) bgp bestpath med missing-as-worst command changes the above.

Enabling the bgp deterministic-med command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the bgp always-compare-med command ensures the comparison of the MED for paths from neighbors in different autonomous systems

ATOMIC_AGGREGATE and AGGREGATOR

A BGP-speaking router can transmit overlapping routes to another BGP speaker. ( 192.168.0.0/16 , 192.168.1.0 /24) routes always choose the most specific route. BGP has several options it can take with overlapping routes:

Advertise both the more-specific and the less-specific route Advertise only the more-specific route Advertise only the nonoverlapping part of the route Aggregate the two routes and advertise the aggregate Advertise the less-specific route only Advertise neither route

When routes are summarised in BGP the AS_PATH is lost the aggregator only includes its own AS number in the AS PATH.

The ATOMIC_AGGREGATE must be set anytime when routing information is lost ( number 5 on the list above) and tells routers that there has been a loss of routing information with this route and it cant do anything to the route to make it appear more specific.

When the ATOMIC_AGGREGATE is set the router can also set the AGGREGATOR attribute. This attribute has the AS number and the ip address ( for cisco the router ID ) of the router that did the aggregation.

The COMMUNITY attribute identifies a destination as a member of some community of destinations that share one or more common properties. For example, an ISP might assign a particular COMMUNITY attribute to all of its customers' routes. The ISP can then set its LOCAL_PREF and MED attributes based on the COMMUNITY value rather than on each individual route.

The COMMUNITY attribute is a set of four octets first two octets are the autonomous system and the last two octets are an administratively defined identifier giving a format of AA:NN. The default Cisco format, on the other hand, is NN:AA. You can change this default to the RFC 1997 format with the command ip bgp-community new-format.

Suppose, for example, a route from AS 625 has a COMMUNITY identifier of 70. The COMMUNITY attribute, in the AA:NN format, is 625:70 and is represented in hex as a concatenation of the two numbers: 0x02710046, where 625 = 0x0271 and 70 = 0x0046. The RFCs use the hex representation, but COMMUNITY attribute values are represented on Cisco routers in decimal. For example, 625:70 is 40960070 (the decimal equivalent of 0x2710046). The community values from 0 (0x00000000) to 65535 (0x0000FFFF) and from 4294901760 (0xFFFF0000) to 4294967295 (0xFFFFFFFF) are reserved. Out of this reserved range, several wellknown communities are defined: l INTERNET— The Internet community does not have a value; all routes belong to this community by default. Received routes belonging to this community are advertised freely. l NO_EXPORT (4294967041, or 0xFFFFFF01)— Routes received carrying this value cannot be advertised to EBGP peers or, if a confederation is configured, the routes cannot be advertised outside of the confederation. l NO_ADVERTISE (4294967042, or 0xFFFFFF02)— Routes received carrying this value cannot be advertised at all, to either EBGP or IBGP peers. l LOCAL_AS (4294967043, or 0xFFFFFF03)— RFC 1997 calls this attribute NO_EXPORT_SUBCONFED. Routes received carrying this value cannot be advertised to EBGP peers, including peers in other autonomous systems within a confederation.

The ORIGINATOR_ID is a 32-bit value created by a route reflector. The value is the router ID of the originator of the route in the local AS. If the originator sees its RID in the ORIGINATOR_ID of a received route, it knows that a loop has occurred, and the route is ignored.

CLUSTER_LIST is a sequence of route reflection cluster IDs through which the route has passed. If a route reflector sees its local cluster ID in the CLUSTER_LIST of a received route, it knows that a loop has occurred, and the route is ignored.

Weight Cisco only attribute, only on local router isn’t sent in any updates. It is a 16bit number , higher the weight more perfured the route. BGP considers weight above all other attributes. By default all learnt routes are given a value of 0 all locally generated routes given a value of 32,768.

The BGP Decision Process

The BGP Routing Information Database (RIB) consists of three parts: Adj-RIBs-In— Stores unprocessed routing information that has been learned from updates received from peers. The routes contained in Adj-RIBs-In are considered feasible routes.

Loc-RIB— Contains the routes that the BGP speaker has selected by applying its local routing policies to the routes contained in Adj-RIBs-In. Adj-RIBs-Out— Contains the routes that the BGP speaker advertises to its peers.

The BGP decision process selects routes by applying local routing policies to the routes in the Adj-RIBs-In and by entering the selected or modified routes into the Loc-RIB and Adj-RIBs-Out.

Phase 1 calculates the degree of preference for each feasible route. It is invoked whenever a router receives a BGP Update from a peer in a neighboring AS containing a new route, a changed route, or a withdrawn route. Each route is considered separately, and a nonnegative integer is derived that indicates the degree of preference for that route. Phase 2 chooses the best route out of all the available routes to a particular destination andinstalls the route in the Loc-RIB. It is invoked only after phase 1 has been completed. Phase 3 adds the appropriate routes to the Adj-RIBs-Out for advertisement to peers. It is invoked after the Loc-RIB has changed, and only after phase 2 has been completed. Route aggregation, if it is to be performed, happens during this phase. if the address specified by the route's NEXT_HOP attribute is unreachable, the route is not selected

1. Prefer the route with the highest administrative weight. This is a Cisco-specific function, because BGP administrative weight is a Cisco parameter.

2. If the weights are equal, prefer the route with the highest LOCAL_PREF value.

3. If the LOCAL_PREF values are the same, prefer the route that was originated locally on the router. That is, prefer a route that was learned from an IGP on the same router. 4. If the LOCAL_PREF is the same, and no route was locally originated, prefer the route with the shortest AS_PATH.

5. If the AS_PATH length is the same, prefer the path with the lowest origin code. IGP is lower than EGP, which is lower than Incomplete.

6. If the origin codes are the same, prefer the route with the lowest MULTI_EXIT_DISC value. This comparison is done only if the AS number is the same for all the routes being considered.

7. If the MED is the same, prefer EBGP routes over confederation EBGP routes, and prefer confederation EBGP routes over IBGP routes.

8. If the routes are still equal, prefer the route with the shortest path to the BGP NEXT_HOP. This is the route with the lowest IGP metric to the next-hop router. 9. If the routes are still equal, they are from the same neighboring AS, and BGP multipath is enabled with the maximum-paths command, install all the equal-cost routes in the Loc-RIB.

10. If multipath is not enabled, prefer the route with the lowest BGP router ID.

Route Dampening It is used to stop flapping routes to cause network instability caused by overloading of updates. A dynamic number is used to determine if a route should be suppressed. The more a route flaps the more likely it is to be surpressed.

The Cisco defaults for the various route-dampening variables are as follows: Penalty— 1000 per flap (added every flap) Suppress limit— 2000 ( stop advertising the route) Reuse limit— 750(when a route is suppressed it must fall below this to be advertised Half-life— 15 minutes ( the dynamic figure is ½ every half life timer) Maximum suppress time— 60 minutes, or 4 times the half-life ( max time a route can be suppressed)

IBGP only exchanges directly connected routes. If IBGP was the only IGP running this means there would need to be a full mesh of tcp sessions between every IBGP router to exchange all routes with an AS. This pint is mute because BGP rule for Synchronization states that the rule must first be learnt via an IGP before IBGP is allowed to enter that route into the routing table.

If a bgp router forwards a packet Destined for an external and the internal (IGP without IBGP) IGP router wouldn’t have enough routing information to route the packet to the correct IBGP router and discard the packet. Synchronization prevents packets from being black-holed within a transit AS by an IGP with insufficient information. IBGP Synchronization can be disabled if needed two. This need can arise when routers running IBGP have enough routing information to route the packet the destination EBGP peer but there is no IGP running on those routers.

For IBGP to work correctly one of two configuration options must be chosen:

The external routes must be redistributed into the IGP to ensure that the IGP can synchronize with BGP. The drawback to this approach is that if you are taking a large number of routes from BGP, such as a full Internet routing table, you are placing a huge processing and memory burden on the IGP routers.

The IBGP routers must be fully meshed, and synchronization must be disabled. Every router then has knowledge of the external routes via BGP, and disabling synchronization allows the routes to be entered into the routing table without having to first inform the IGP. The drawback to this approach is that in an AS where there are more than a few IBGP routers, peering every router with every other router becomes an administrative challenge. Nonetheless, this is the approach that is almost always used when dealing with Internet routes.

If you turn off synchronization on a working BGP process, you must reset the BGP connections with the clear ip bgp * command before the changes will take effect.

Managing Large-Scale BGP Peering

Peer Group: Helps control routing policy between peers Routers can be added to a peer group, when configuration for a routing policy needs to be changed changing it on one router will change it on all routers within the peer group. This simplifies administration work. Additional polices that need to be applied on a per router bases ( not sent to other routers in the peer group) can also be configured.

Communities Helps control routing policy between peers Communities a very similar to peer groups but they act on routes not routers. A router sets the community attribute on the route update. Other routers within the AS then know that this route is apart of a community and applies routing policy that is setup for that community. A route can have more then one community value set.

Route Reflectors Simply IBGP management Route Reflectors can be used when an AS has a large amount of IBGP peers.

Route reflectors offer an alternative to fully meshed IBGP peers. A router is configured as a route reflector (RR), and other IBGP routers, known as clients, peer with the RR only, rather than with every other IBGP router As a result, the number of peering sessions is reduced from n(n – 1)/2 to n – 1. A router reflector and its clients are known collectively as a cluster. Route reflectors work by relaxing the rule that IBGP peers cannot advertise routes learned from other IBGP peers.The route reflector learns routes from each of its clients. Unlike other IBGP routers, the RR can advertise these routes to its other clients and to nonclient peers. In other words, the routes from one IBGP client are reflected from the RR to the other clients. To avoid possible routing loops or other routing errors, the route reflector cannot change the attributes of the routes it receives from clients.

A client router in a route reflection cluster can peer with external neighbors, but the only internal neighbor it can peer with is a route reflector in its cluster or other clients in the cluster. However, the RR itself can peer with both internal and external neighbors outside of the cluster and can reflect their routes to its clients.

If an RR receives multiple routes to the same destination, it uses the normal BGP decision process to select the best path.

Rules used to determine which routers an RR will advertise to:

If the route was learned from a nonclient IBGP peer, it is reflected to clients only.

If the route was learned from a client, it is reflected to all nonclients and clients, except for the originating client.

If the route was learned from an EBGP peer, it is reflected to all clients and nonclients. A RR Cluster can have more then 1 RR for redundancy purposes.

Because clients do not know they are clients, a route reflector can itself be a client of another route reflector.

Each cluster within an AS must be identified with a unique 4-octet cluster ID. If the cluster contains a single route reflector, the cluster ID is the router ID of the route reflector. If the cluster contains multiple route reflectors, each RR must be manually configured with a cluster ID.

Two attributes are used to control route reflection to stop routing loops.

The ORIGINATOR_ID is the router ID of the originator of a route within the local AS. A route reflector does not advertise a route back to the originator of the route; nonetheless, if the originator receives an update with its own RID, the update is ignored.

CLUSTER_LIST Is used the same way AS_PATH is used, each time a route hits a RR the CLUSTER_ID is added, if a RR sees its own CLUSTER_ID in a update it ignores the update.

Confederations

A confederation is an AS that has been subdivided into a group of subautonomous systems, known as member autonomous systems. Each sub has a private AS number and uses EBGP to talk to other subs Within the Confederation. The confederation is assigned a Confederation ID which is the AS number that is sent to EBGP outside the confederation. Confederations add two more types of AS_PATH, both of these are only used locally within the confederation and are stripped at the confederation boundary.

AS_CONFED_SEQUENCE A order list of sub AS’s that are passed within the confederation.

AS_CONFED_SET A list of all sub AS’s works the same way as AS_SET so sub AS info is kept in the event of summarization

When an update is sent to a peer external to the confederation, the AS_CONFED_SEQUENCE and AS_CONFED_SET information is stripped from the AS_PATH attribute, and the confederation ID is prepended to the AS_PATH. Because of this, external peers see the confederation as a single AS rather than as a collection of autonomous systems.

When choosing a route, the BGP decision process remains the same, with one addition: EBGP routes external to the confederation are preferred over EBGP routes to member autonomous systems, which are preferred over IBGP routes. Another difference between confederations and standard autonomous systems is the way in which some attributes are handled. Attributes such as NEXT_HOP and MED can be advertised unchanged to EBGP peers in another member AS within the confederation, and the LOCAL_PREF attribute also can be sent.

Regular expressions

Character Special Meaning period . Matches any single character, including white space. asterisk * Matches 0 or more sequences of the pattern. plus sign + Matches 1 or more sequences of the pattern. question ? Matches 0 or 1 occurrences of the pattern. mark caret ^ Matches the beginning of the input string. dollar sign $ Matches the end of the input string. Matches a comma (,), left brace ({), right brace (}), left parenthesis, right underscore _ parenthesis, the beginning of the input string, the end of the input string, or a space. brackets [] Designates a range of single-character patterns. hyphen - Separates the end points of a range.

Matches any of the following a b c d A BC D [a-dA-D]

Match just AS 4 ( no other AS in as sequence) ^4$

Match any route that has passed AS 4 _4_

Match any routes that are learnt from AS4 and all AS’s behind it ^4_[0-9]*$

Drop all AS’s ^$

Outbound route filtering Uses prefix lists, configure on local router and gets sent to neighbour to control how you want routes filted to the local router. Remember implicate deny at the end.

Batch updates

BGP will batch updates together per batch interval, this helps protect BGP from fast flapping interface.

IBGP batch update every 5 seconds EBGP batch update every 30 seconds

Singled homed customer reasons:

Need/want own internet routable address space. for EBGP the neighbour address must be reachable by a route other then 0.0.0.0/0 show ip bgp summary: inQ and outQ: are updates yet to be sent or processed Tblver: every change to the BGP table on a router causes this value to be incremented by 1

BGP scan time:

is used for 2 things, 1 to test reachabiltiy to BGP net hops the other is to bring routes into a BGP VPN. By default it is 60 seconds for BGP reachability and 15 seconds for VPN. Decreasing these numbers decreases convergence time. iBGP multipath For multiple paths to the same destination to be considered as multipaths, the following criteria must be met:

• All attributes must be the same. The attributes include weight, local preference, autonomous system path (entire attribute and not just length), origin code, Multi Exit Discriminator (MED), and Interior Gateway Protocol (IGP) distance.

• The next hop router for each multipath must be different.

Even if the criteria are met and multiple paths are considered multipaths, the BGP speaking router will still designate one of the multipaths as the best path and advertise this best path to its neighbors.

BGP Link Bandwidth The Border Gateway Protocol (BGP) Link Bandwidth feature is used to advertise the bandwidth of an autonomous system exit link as an extended community

It is used for unequal cost load balancing. • BGP load balancing or multipath load balancing must be configured before this feature is enabled.

• BGP extended community exchange must be enabled between iBGP neighbors to which the link bandwidth attribute is to be advertised. • Cisco Express Forwarding (CEF) or distributed CEF (dCEF) must be enabled on all participating routers. 1. enable 2. configure {terminal | memory | network} 3. router bgp as-number 4. address-family ipv4 [mdt | multicast | tunnel | unicast [vrf vrf-name] | vrf vrf- name] | ipv6 [multicast | unicast] | vpnv4 [unicast] 5. bgp dmzlink-bw 6. neighbor ip-address dmzlink-bw 7. neighbor ip-address send-community [both | extended | standard]

IP stuff

#ip tcp path-mtu-discovery

Is used to stop fragment packets for bgp updates

Router(config)#ip tcp path-mtu-discovery age-timer ? <10-30> Aging time infinite Disable pathmtu aging timer age time is how long before a re-estimation of the MTU is taken.