CIS 185 CCNP ROUTE Ch.

6 Border Gateway Protocol Solution for ISP Connectivity Part 1

Rick Graziani Cabrillo College graziani@cabrillo.edu Last Updated: Fall 2010

Materials
Book: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: Foundation learning for the ROUTE 642-902 Exam By Diane Teare Book ISBN-10: 1-58705-882-0 ISBN-13: 978-1-58705-882-0 eBook ISBN-10: 0-13-255033-4 ISBN-13: 978-0-13-255033-8

Terms

What is an IGP (Interior Gateway Protocol)? Routing protocol used to exchange routing information within an autonomous system. RIP, IGRP, EIGRP, OSPF, IS-IS What is an EGP (Exterior Gateway Protocol)? Routing protocol used to exchange routing information between autonomous systems. BGP (Border Gateway Protocol) is an Interdomain Routing Protocol (IDRP), which is also known as an EGP. BGP - is a path vector routing protocol. What is an Autonomous System ? (From RFC 1771) A set of routers under the single technical administration, using an IGP and common metrics to route packets within the AS, and using an EGP to route packets to other ASs.

 BGP version 4 (BGP-4) (latest version of BGP) It is defined in Requests for Comments (RFC) 4271, A Border Gateway Protocol (BGP-4). As noted in this RFC, the classic definition of an AS is A set of routers under a single technical administration, using an Interior Gateway Protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other [autonomous systems]. Extensions to BGP-4 (known as BGP4+) includes IPv6.

BGP Use Between Autonomous Systems

Main goal is to provide an interdomain routing systems that guarantees the loop-free exchange of routing information between ASs. BGP is a successor to Exterior Gateway Protocol (EGP). (Note the dual use of the EGP acronym.) BGP-4 is a classless routing protocols so it supports: VLSM CIDR There are more than 300,000 CIDR blocks Without CIDR full Internet routing tables would contain more than 2,000,000 entries.

Comparison with Other Scalable Routing Protocols

BGP does not look at speed for the best path. BGP is a policy-based routing protocol that allows an AS to control traffic flow using multiple BGP attributes. Routers exchange network reachability information, called path vectors or attributes These include a list of the full path of BGP AS numbers that a router should take to reach a destination network.
6

When to use BGP and when not to use BGP

Use BGP when the effects of BGP are well understood and one of the following conditions exist: The AS allows packets to transit through it to reach another AS (transit AS). The AS has multiple connections to other ASs. The flow of traffic entering or exiting the AS must be manipulated. This is policy based routing and based on attributes.
7

When to use BGP and when not to use BGP

Do not use BGP if you have one or more of the following conditions: A single connection to the Internet or another AS No concern for routing policy or routing selection A lack of memory or processing power on your routers to handle constant BGP updates A limited understanding of route filtering and BGP path selection process Low bandwidth between ASs
8

Who needs BGP?

Not as many internetworks as you may think. You should implement BGP only when a sound engineering reason compels you to do so, such as when the IGPs do not provide the tools necessary to implement the required routing policies or when the size of the routing table cannot be controlled with summarization. The majority of the cases calling for BGP involve Internet connectivity either between a subscriber and an ISP or (more likely) between ISPs. Yet even when interconnecting autonomous systems, BGP might be unnecessary. Jeff Dolye, Routing TCP/IP Vol. II

Overview of autonomous systems

AS - A group of routers that share similar routing policies and operate within a single administrative domain. An AS can be a: Collection of routers running a single IGP (Single company) Collection of routers running different protocols all belonging to one organization (ISP) In either case, the outside world views the entire Autonomous System as a single entity.
10

Overview of autonomous systems

AS Numbers Assigned by an Internet registry or a service provider. Between 1 and 65,535. 0 - Reserved 1 through 64,495 Assignable for public use 64,512 through 65,535 - Private use This is similar to RFC 1918 IP addresses. 65,535 - Reserved Because of the finite number of available AS numbers, an organization must present justification of its need before it will be assigned an AS number.
11

 Today, the Internet Assigned Numbers Authority (IANA) is enforcing a policy whereby organizations that connect to a single provider and share the provider's routing policies use an AS number from the private pool, 64,512 to 65,535.

12

 RFC 4893 BGP Support for Four-Octet AS Number Space describes 32 bit AS numbers the anticipated depletion of current BGP 16-bit AS numbers http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599 /white_paper_C11_516823.html http://www.potaroo.net/tools/asn16/ http://www.iana.org/assignments/as-numbers/as-numbers.xml

13

Using BGP

BGP dynamically exchanges routing information BGP reacts to topology changes including those changes beyond a customer-to-ISP link failure.

14

 Connection Redundancy The ISP connection can also be made redundant. A customer can be connected to a single ISP or to multiple ISPs.
15

Single-homed autonomous systems

Single-homed system AS One Link per ISP, One ISP Only one exit point to outside networks. Often referred to as stub networks or stubs. Usually use a default route to handle all traffic destined for non-local networks. BGP is not normally needed in this situation
16

Single-homed autonomous systems

IGP Option IGP: Both the provider and the customer use an IGP to share information regarding the customer's networks. Customer: Sends public network address Receives default route

17

Single-homed autonomous systems

BGP Option In a single-homed autonomous system the customer's routing policies are an extension of the policies of the provider. Internet number registries are unlikely to assign public AS number. AS number from the private pool of AS numbers, 64,512 to 65,535. The provider will strip off these numbers when advertising the customer's routes towards the core of the Internet. (later)
18

Dual Homed

Option 3

Dual-homed AS Two or more links per ISP, One ISP Same options as single-homed Additional advantages: Primary and backup link functionality Load Balancing
19

Single Multi-homed

Multi-homed or Single Multi-homed One link per ISP, two or more ISPs Typically recommended to run BGP Options: (more later on these) ISP1 and ISP2: Full Internet routes ISP1: Full Internet routes; ISP2: Partial updates (selected) ISP1: Default route; ISP2: Partial updates (selected)

20

http://bgp.potaroo.net/ 10/31/2010

Caution in receiving full Internet routes: Over 300,000 summarized routes (over 2,000,000 un-summarized) 100,000 routes require about 70 MB of RAM for the BGP table

21

Dual Multi-homed

Dual Multi-homed Two or more links per ISP, Two or more ISPs Similar options as Single Multi-homed Same benefits as single multi-homed but with enhanced resiliency.

22

Using BGP in an Enterprise Network

External BGP (EBGP) - When BGP is running between routers in different autonomous systems. Internal BGP (IBGP) - When BGP is running between routers in the same AS. Understanding how BGP works is important to avoid creating problems for your AS as a result of running BGP.
23

Transit AS

Multihomed system More than one exit point to outside networks. May be a: Transit Non-transit AS Transit traffic - Traffic that has a source and destination outside the AS. Transit AS - allows transit traffic Non-transit AS - does not allow transit traffic. Advertises only its own routes to both the providers Does not advertise routes it learned from one provider to another. Therefore, ISP1 will not use AS 24 to reach destinations that belong to ISP2 24 and visa versa.

 AS 65500 is learning routes from both ISP-A and ISP-B via EBGP Also running IBGP on all of its routers. (later) Learns about routes and chooses the best way to each one based on the configuration of the routers in the AS and the BGP routes passed from the ISPs. If one of the connections to the ISPs goes down, traffic will be sent through the other ISP.

25

Transit AS

AS 65500 wants to have a redundant Internet connection, but does not want to act as a transit AS between ISP-A and ISP-B. AS 65500 learns from ISP-A is the route to 172.18.0.0/16. If that route is: Propagated through AS 65500 using IBGP And mistakenly announced to ISP-B Then ISP-B might decide that the best way to get to 172.18.0.0/16 is through AS 65500, instead of through the Internet. AS 65500 would then be considered a transit AS (an ISP) Not a very undesirable situation Careful BGP configuration is required to avoid this situation.

26

Default Route

Default Route + ISP1 Routes

Default Route

Default Route + ISP2 Routes

If an organization has determined that it will perform multihoming with BGP, three common ways to do this are as follows: Each ISP passes only a default route to the AS The default route is passed to the internal routers. Each ISP passes only a default route and provider-owned specific routes to the AS These routes can be passed to internal routers, or all internal routers in the transit path can run BGP and pass these routes between them. Each ISP passes all routes to the AS All internal routers in the transit path run BGP and pass these routes between them.

All Internet Routes

All Internet Routes

27

Multihoming with Default Routes from All Providers

Send 0.0.0.0/0

AS 65500 Networks

Send 0.0.0.0/0

First multihoming option is to receive only a default route from each ISP.

Both edge routers learn a default route from their attached ISP Propagate it into the routing domain via an IGP Requires the least resources AS 65500 propagates its owned routes to both ISPs If a router within the AS learns about multiple default routes, the local IGP installs the best default route into the routing table. This does allow AS 65500 the capability of adding new customers (new networks) without relying on upstream provider. Otherwise ISP would have to create the network and add a static route pointing to AS 65500

28

Multihoming with Default Routes and Partial Table from All Providers
Sends ISPA Prefixes and 0.0.0.0/0

AS 65500 Networks

Sends ISPB Prefixes and 0.0.0.0/0

Both ISPs pass default routes plus select specific routes to the AS. The internal routers of the customer can receive these routes via: Redistribution into IGP IBGP transit path (later) The internal routers route packets: ISP A networks via ISP A ISP B networks via ISP B Default routes via nearest edge router (possible suboptimal routing)
29

Multihoming with Full Routes from All Providers

All ISPs pass all routes to the AS IBGP is run on at least all the routers in the transit path in this AS. Requires a lot of resources within the AS because it must process all the external routes.

Sends all Internet Routes

AS 65500 Networks

Sends all Internet Routes

The internal routers of the customer can receive these routes via: Redistribution into IGP (ex: OSPF): Not recommended! IBGP transit path (later): Well say this is the case. The ISP that a specific router within AS 64500 uses to reach the external networks is determined by the IBGP protocol. The routers in AS 64500 can be configured to influence the path to certain networks. For example, Router A and Router B can influence the outbound traffic from AS 64500. (Later - Attributes)

30

BGP Path Vector Characteristics

Path Advertised: 64520 64600 64700

Networks in AS 64700: 192.168.24.0 192.168.25.0 172.20.0.0

IGP routing protocols use metrics to determine best path. Cost (Bandwidth), BW+DLY-REL-Load, Hop Count BGP routers exchange network reachability information, called path vectors, made up of path attributes The path vector information includes a list of the full path of BGP AS numbers (hop-by-hop) necessary to reach a destination network. Other attributes include: IP address of the next-hop AS (the next-hop attribute) How the network was introduced into BGP (the origin code attribute) And more later!

31

 AS Path information is used to construct a graph of loop-free ASs and to identify routing policies (later) AS 64512: AS Path to 192.168.24.0 = 64520 > 64600 > 64700 BGP AS Path is guaranteed to be loop free. BGP router does not accept a routing update that already includes its own AS number in the AS Path list.

32

Loop Free Path

172.16.0.0/16 (4, 2, 1) 172.16.0.0/16 (6, 5, 3, 1)

AS7 AS4

AS6 AS2

AS5

AS3

AS1
172.16.0.0/16

AS_PATH List of AS numbers associated with a BGP route One of several path attributes associated with each route. Path attributes will be discussed in much more detail later. We will discuss how BGP chooses best path later. The shortest inter-AS path is very simply determined by the least number of AS numbers. In this example, AS7 will choose the shortest path (4, 2, 1). We will see later what happens with equal cost paths.
33

172.16.0.0/16 (7,4,2,1)

Loop Free Path

172.16.0.0/16 (8,7,4,2,1)

AS8 AS9
172.16.0.0/16 (4, 2, 1)

X
172.16.0.0/16 (9,8,7,4,2,1)

AS7 AS4

AS6 AS2

AS5

AS3

AS1
172.16.0.0/16

Routing Loop Avoidance Route loops can be easily detected when a router receives an update containing its local AS number in the AS_PATH. When this occurs, the router will not accept the update, thereby avoiding a potential routing loop.
34

 Possible paths for AS 64512 to reach networks in AS 64700, through AS 64520: 64520 64600 64700 64520 64600 64540 64550 64700 64520 64540 64600 64700 64520 64540 64550 64700 AS 64512 does NOT see all these possibilities. AS 64520 advertises to AS 64512 only its best path: 64520 64600 64700 (assuming no other policies supersede AS Path) AS 64512 could also get a best path from AS 64530 AS 64512 would then decide which path is best (via 64530 or via 64520) based on its own AS policies.

35

Multihomed nontransit autonomous systems

Here are the networks you can reach through me. Here are the networks you can reach through me. I will try and make it so that you prefer me. We have a choice on which way to send our traffic.

Incoming route advertisements influence your outgoing traffic, and outgoing advertisements influence your incoming traffic.

36

Multihomed nontransit autonomous systems

These are the networks you can reach through me, but I will not include ISP2 networks.

These are the networks you can reach through me. I will include ISP1 networks but include my AS number multiple times so you may prefer another route.

Incoming route advertisements influence your outgoing traffic, and outgoing advertisements influence your incoming traffic.

37

BGP Hazards Inadvertent Transit Domain

We inadvertently advertise routes learned from ISP2 to ISP1. ISP1 customers will see our network as the best path to ISP2 customers. We have become a transit domain for packets from ISP1 to ISP2. More later
38

BGP Hazards Doyle, Routing TCP/IP

BGP Peering Creating a BGP peering relationship involves an interesting combination of trust and mistrust. You must trust the network administrator on that end to know what they are doing. At the same time, if you are smart, you will take every practical measure to protect yourself in the event that a mistake is made on the other end. Paranoia is your friend.

39

BGP Hazards Doyle, Routing TCP/IP

Your ISP will show little patience with you if you make mistakes in your BGP configuration. Suppose, for example, that through some misconfiguration you advertise 207.46.0.0/16 to your ISP. On the receiving side, the ISP does not filter out this incorrect route, allowing it to be advertised to the rest of the Internet. This particular CIDR block belongs to Microsoft, and you have just claimed to have a route to that destination. A significant portion of the Internet community could decide that the best path to Microsoft is through your domain. You will receive a flood of unwanted packets across your Internet connection and, more importantly, you will have black-holed traffic that should have gone to Microsoft. They will be neither amused nor understanding.

40

YouTube Hijacking: A RIPE NCC RIS case study

YouTube Hijacking: A RIPE NCC RIS case study

This presentation is taken from RIPE NCC web site. For more detailed information, please consult this web site: http://www.ripe.net/news/study-youtube-hijacking.html Movie: BBC Report Movie: RIPE NCC The following presentation is an accurate representation of what took place, but using a simplified topology. On Sunday, 24 February 2008, Pakistan Telecom (AS17557) started an unauthorised announcement of the prefix 208.65.153.0/24. One of Pakistan Telecom's upstream providers, PCCW Global (AS3491) forwarded this announcement to the rest of the Internet, which resulted in the hijacking of YouTube traffic on a global scale.
42

Before, during and after Sunday, 24 February 2008

Internet

BGP

DNS servers resolve www.youtube.com to: 208.65.153.251 208.65.153.253 208.65.153.238

43

Before, during and after Sunday, 24 February 2008

Internet

BGP 208.65.152.0/22

YouTube summarizes (CIDR) its /24 networks as a single /22: 208.65.152.0/24 11010000. 01000001.10011000.00000000 208.65.153.0/24 11010000. 01000001.10011001.00000000 208.65.154.0/24 11010000. 01000001.10011010.00000000 -------------------------------------208.65.152.0/22 11010000. 01000001.10011000.00000000
44

Before, during and after Sunday, 24 February 2008

Internet

BGP 208.65.152.0/22

Before, during and after Sunday, 24 February 2008: AS36561 (YouTube) announces 208.65.152.0/22. Note that AS36561 also announces other prefixes, but they are not involved in the event.
45

Before, during and after Sunday, 24 February 2008

Internet

2 hops

1 hop

BGP
4 hops 3 hops 3 hops 2 hops 1 hop

208.65.152.0/22

BGP Unless other policies are used, routers will choose the shortest AS path. This is a simplification of BGP, assuming shortest AS-Path is being used.

46

Before, during and after Sunday, 24 February 2008

www.youtube.com 206.65.153.0/24

ip route 206.63.153.0 255.255.255.0 null0

Internet

2 hops

1 hop

BGP
4 hops 3 hops 3 hops 2 hops 1 hop

208.65.152.0/22

Pakistan Telecom Wants to block traffic within its own AS from going to www.youtube.com. Note: Details of how they did this is not known at them time this presentation was created. Most likely they created a route within their own AS that sent any traffic to 208.65.153.0/24 (DNS address for www.youtube.com) to a non-existent network, in effect denying their own customers access to www.youtube.com. Their mistake was that they propagated this route to PCCW Global.

47

Sunday, 24 February 2008, 18:47 (UTC)

Internet

2 hops 2 hops

1 hop 3 hops

BGP
4 hops 3 hops 1 hop 3 hops 2 hops 1 hop 4 hops

208.65.152.0/22

208.65.153.0/24

2 hops 3 hops

Sunday, 24 February 2008, 18:47 (UTC): AS17557 (Pakistan Telecom) starts announcing the more specific route of 208.65.153.0/24. AS3491 (PCCW Global) propagates the announcement. Routers around the world receive the announcement, and YouTube traffic is redirected to Pakistan.

48

Internet
Routed traffic to youtube.com

BGP

?
208.65.153.0/24

208.65.152.0/22

Dest IP = 208.65.153.251 Why do the ISP routers forward traffic to Pakistan Telecom? When a router receives packets for 208.65.153.251 which path will it choose? Routers will learn about both 208.65.153.0/24 and 208.65.152.0/22 networks and install the both routes in their routing tables. When a router receives packets for 208.65.153.251 it will choose the longest prefix match (more specific match): 208.65.153.0/24 24 bits is a longer (better) match than 22 bits

49

Sunday, 24 February 2008, 20:07 (UTC):

Internet
Routed traffic to youtube.com

BGP 208.65.152.0/22 208.65.153.0/24

208.65.153.0/24

Sunday, 24 February 2008, 20:07 (UTC): AS36561 (YouTube) starts announcing the same, more specific prefix of 208.65.153.0/24. With two identical prefixes in the routing system, BGP policy rules, such as preferring the shortest AS path, determine which route is chosen. This means that AS17557 (Pakistan Telecom) continues to attract some of YouTube's traffic.

50

Sunday, 24 February 2008, 20:07 (UTC):

Internet
Routed traffic to youtube.com

BGP 208.65.152.0/22 208.65.153.0/24 208.65.153.0/25 208.65.153.128/25

208.65.153.0/24

Sunday, 24 February 2008, 20:18 (UTC): AS36561 (YouTube) starts announcing an even more specific prefixes of 208.65.153.128/25 and 208.65.153.0/25. Because of the longest prefix match rule, every router that receives these announcements will send the traffic to YouTube.
51

Sunday, 24 February 2008, 20:07 (UTC):

Internet
Routed traffic to youtube.com

For CCNP students

BGP 208.65.152.0/22 208.65.153.0/24 208.65.153.0/25 208.65.153.128/25

208.65.153.0/24 For CCNP students

Sunday, 24 February 2008, 20:51 (UTC): All prefix announcements, including the hijacked /24 which was originated by AS17557 (Pakistan Telecom) via AS3491 (PCCW Global), are seen prepended by another 17557. This makes the route via AS17557 look like more hops. The longer AS path means that more routers prefer the announcement originated by YouTube.

52

Sunday, 24 February 2008, 20:07 (UTC):

Internet
Routed traffic to youtube.com

X
208.65.153.0/24

BGP 208.65.152.0/22 208.65.153.0/24 208.65.153.0/25 208.65.153.128/25

Sunday, 24 February 2008, 21:01 (UTC): AS3491 (PCCW Global) withdraws all prefixes originated by AS17557 (Pakistan Telecom), thus stopping the hijack of 208.65.153.0/24. Note that AS17557 was not completely disconnected by AS3491. Prefixes originated by other Pakistani ASs were still announced by AS17557 through AS3491.

53

Back to BGP

BGP Characteristics

BGP updates are carried using TCP on port 179. In contrast: RIP updates use UDP port 520 EIGRP uses EIGRPs RTP OSPF does not use a Layer 4 protocol but uses OSPF mechanisms for reliability (OSPF ACKs) Because BGP requires TCP: IP connectivity must exist between BGP peers. TCP connections must also be negotiated between them before updates can be exchanged. BGP inherits those reliable, connection-oriented properties from TCP. Flow control properties as well (sliding windows) BGP assumes that its communication is reliable and therefore, BGP does not have to implement any retransmission or error-recovery mechanisms, like EIGRP or OSPF does.

55

BGP Neighbor Relationships

Neighbors or peers - Two routers that establish a TCP-enabled BGP connection between each other. BGP speaker - Each router running BGP. A BGP speaker has a limited number of BGP neighbors with which it peers and forms a TCP-based relationship. BGP peers can be either: Internal to the AS External to the AS

56

External BGP Neighbors EBGP: BGP is running between routers in different autonomous systems. Routers running EBGP are usually directly connected to each other EBGP multi-hop allows EBGP neighbors not to be directly connected (later)

57

There are several requirements for EBGP neighborship: Different AS number: EBGP neighbors must reside in different autonomous systems to be able to form an EBGP relationship. Define neighbors: A TCP session must be established prior to starting BGP routing update exchanges. Reachability: The IP addresses used in the neighbor command must be reachable EBGP neighbors are usually directly connected.

58

EBGP
RTA(config)#router bgp 100 RTA(config-router)# RTB(config)#router bgp 200 RTB(config-router)# Configuring EBGP neighbors (more later) To begin configuring a BGP process, issue the following familiar command: Router(config)#router bgp AS-number BGP configuration commands appear similar to familiar IGP but it is different! Note: Cisco IOS permits only one BGP process to run at a time, thus, a router cannot belong to more than one AS. Because the two AS numbers are different, BGP will start an EBGP connection with RTA.

59

EBGP
RTA(config)#router bgp 100 RTA(config-router)#neighbor 10.1.1.1 remote-as 200 RTB(config)#router bgp 200 RTB(config-router)#neighbor 10.1.1.2 remote-as 100 Configuring EBGP neighbors (more later) Neighbor command - Used to establish a neighbor relationship with another BGP router. Router(config-router)#neighbor ip-address remote-as AS-number Identifies a peer router with which the local router will establish a session. The AS-number argument determines whether the neighbor router is an EBGP or an IBGP neighbor Different AS numbers mean EBGP peers Same AS numbers mean IBG peers

60

Internal BGP Neighbors IBGP: When BGP is running between routers within the same AS IBGP is run within an AS to exchange BGP information so that: All internal BGP routers have the same BGP routing information about outside autonomous systems This information can be passed to other autonomous systems. Typically full-mesh on all routers in the transit path between ASs
61

There are several requirements for IBGP neighborship: Same AS number: IBGP neighbors must reside in the same AS to be able to form an IBGP relationship. Define neighbors: A TCP session must be established between neighbors prior to start exchanging BGP routing updates. Reachability: IBGP neighbors must be reachable; an IGP typically runs inside the AS. Do not have to be directly connected.

62

RTB(config)#router bgp 200 RTB(config-router)#neighbor 172.16.1.2 remote-as 200

RTC(config)#router bgp 200 RTC(config-router)#neighbor 172.16.1.1 remote-as 200

The remote-as value (200) is the same routers will attempt to establish an IBGP session. Note: AS 200 is not a remote AS , for simplicity, the keyword remote-as is used.
63

Transit Path

Transit Path

Described more in the next section You must set up IBGP sessions between all routers in the transit path in AS 65500 so that each router in the transit path within the AS learns about paths to the external networks via IBGP. Note: Can also redistribute into the IGP but this is not usually recommended.

64

IBGP in a Transit AS
Transit Path

Transit Path

BGP was originally intended to run along the borders of an AS, with the routers in the middle of the AS ignorant of the details of BGP A transit AS is an AS that routes traffic from one external AS to another external AS. Transit autonomous systems are typically ISPs. All routers in a transit path must have complete knowledge of external routes. Run IBGP on all routers within the AS transit path Redistribute BGP routes into an IGP at the edge routers (however, this approach has problems)

65

IBGP in a Nontransit AS

X X

I learned about networks from ISP2 but I cant tell ISP1 or ISP1 might forward packets to me to get to those networks making me a transit AS.

A Nontransit AS: AS multihoming with two ISPs But does not pass routes between the ISPs

66

BGP Peers IBGP IBGP

EBGP

The designers of BGP could not guarantee that an AS would run BGP on all routers So a method had to be developed to ensure that IBGP speakers could pass updates to one another while ensuring that no routing loops would exist. All IBGP routers (in the transit path) need to peer with each other (full mesh) Note: Although this presentation refers to all IBGP routers in the transit path must be fully-meshed, it is recommended that all IBGP routers in the AS are fully-meshed IBGP. This will be discussed in Part 2. BGP specifies that routes learned through IBGP are never propagated to other IBGP peers. By default, each BGP speaker is assumed to have a neighbor statement for all other IBGP speakers in the ASthis is known as full mesh IBGP. When a change is received from an external AS: The BGP router is responsible for informing all other IBGP neighbors of the change. 67 IBGP neighbors that receive this update do not send it to other IBGP neighbors

BGP Partial-Mesh and Full-Mesh Examples

68

IBGP update behavior in a partially meshed neighbor environment

BGP Update

Router B receives a BGP update from Router A. Router B has two IBGP neighbors, Routers C and D Router B does not have an IBGP neighbor relationship with Router E. Routers C and D learn about any networks that were added or withdrawn behind Router B. Routers C and D have IBGP neighbor sessions with Router E but do not replicate the update and send it to Router E. Sending the IBGP update to Router E is Router Bs responsibility Router E does not learn of any networks through Router B and does not use Router B to reach any networks in AS 65101 or other autonomous systems behind AS 65101.

69

IBGP update behavior in a fully meshed neighbor environment

BGP Update

When Router B receives an update from Router A Router B updates all three of its IBGP peers, Router C, Router D, and Router E. OSPF, the IGP, is used to route the TCP segment containing the BGP update from Router B to Router E, because these two routers are not directly connected. The update is sent once to each neighbor and not duplicated by any other IBGP neighbor Reduces unnecessary traffic. In fully meshed IBGP, each router assumes that every other internal router has a neighbor statement that points to each IBGP neighbor.

70

Routing Issues if BGP Not on in All Routers in a Transit Path

BGP Update

In this example, Routers A, B, E, and F are the only ones running BGP. Router B has an: EBGP neighbor statement for Router A IBGP neighbor statement for Router E Router E has an: EBGP neighbor statement for Router F IBGP neighbor statement for Router B. Routers C and D are not running BGP. Routers B, C, D and E are running OSPF as their IGP.

71

BGP Update

Network 10.0.0.0

Network 10.0.0.0 is owned by AS 65101 and is advertised by Router A to Router B via an EBGP session. Router B advertises it to Router E via an IBGP session. Routers C and D never learn about this network because: BGP is not redistributed into the local routing protocol (OSPF) Routers C and D are not running BGP Router E advertises this network to Router F in AS 65103

72

BGP Update

Network 10.0.0.0
No route to 10.0.0.0 Drop packet

Packet to Network 10.0.0.0

So far Routers A, B, E and E all know about the 10.0.0.0 network Routers C and D do not have a route for the 10.0.0.0 network If Router F has a packet for 10.0.0.0 Router F would forward the packet to Router E Router E would send the packets to its BGP peer, Router B To get to Router B packets must go through Router C or D Neither of these routers have an entry in their routing tables for network 10.0.0.0. When this packet to 10.0.0.0 is forwarded to either Routers C or D, those packets would be discarded.

73

BGP Update

Transit Path

Network 10.0.0.0

Transit Path Default Route

Packet to Network 10.0.0.0

Even if Routers C and D have a default route going to the exit points of the AS (Routers B and E) Those packet for 10.0.0.0 might go back to Router E causing a routing loop. To solve this problem: BGP must be implemented on all routers in the transit path Routers C and/or D This leads us to the question Can BGP help ensure that all routers AS 65102 know about these external networks in other ASs?

74

BGP Synchronization
Note: There is not a physical link b/t A and B

I learned about 172.16.0.0 via IBGP from Router B. I will not advertise 172.16.0.0 to Router E via EBGP unless I see this network in my routing table leaned via an IGP (OSPF).

?
OSPF
IBGP
AS 65000 networks Into OSPF

BGP synchronization rule states: A BGP router should not use or advertise to an external BGP neighbor a route learned by IBGP, unless that route is directly connected or learned from the IGP. In the past this use to be the default. If there were small enough number of BGP routes they could be redistributed into the IGP (by Router A and Router B). Routers C and D would then know about 172.16.0.0 and all AS 65000 networks via redistribution by Router B. Then IBGP would not have to run on all routers in the transit path.
75

BGP Synchronization
?
OSPF
IBGP
AS 65000 networks Into OSPF

I learned about 172.16.0.0 via IBGP from Router B. I will not advertise 172.16.0.0 to Router E via EBGP unless I see this network in my routing table leaned via an IGP (OSPF).

It is important that Router C and Router D learn about the networks from AS 650000 (172.16.0.0). Otherwise, when Router A forwards a packet to Router C destined for 172.16.0.0, Router C would drop the packet because that network is not in its routing table. This is why synchronization was the default on BGP routers. However, in the modern Internet it not practical to redistribute so my networks into the IGP this is no longer the best practice!
76

No BGP Synchronization ?
OSPF
IBGP
AS 65000 networks Into OSPF

I learned about 172.16.0.0 via IBGP from Router B. I will not advertise 172.16.0.0Router can advertise 172.16.0.0 to to E via EBGP EBGP unless I see this network Router E via even if this network in NOT in my routing table table leaned IGP (OSPF). in my routing leaned via anvia an IGP (OSPF).

Best practice is to no longer redistribute BGP networks into the IGP. Instead, all routers in the transit path should be fully meshed IBGP. Synchronization is disabled by default in Cisco IOS 12.2(8)T and later. This means that a BGP router can advertise to an external BGP neighbor a route learned by IBGP regardless whether or not that network is in the routing table via IGP. All routers in the in the transit path must be running IBPG and be fully meshed. Each transit router in the AS must have a neighbor relationship with all other transit routers.

77

No BGP Synchronization

I learned about 172.16.0.0 via IBGP from Router B. I can advertise 172.16.0.0 to Router E via EBGP even if this network in NOT in my routing table leaned via an IGP (OSPF).

OSPF

The BGP synchronization rule does ensure consistency of information throughout the AS and avoids black holes For example, advertising a destination to an external neighbor when not all the routers within the AS can reach the destination) within the autonomous system. So, when synchronization is disabled you must make sure that all routers in the transit path are fully meshed via IBGP. Otherwise, when Router A forwards a packet to Router C destined for 172.16.0.0, Router C would drop the packet because that network is not in its routing table. This allows the routers to carry fewer routes in IGP and allows BGP to 78 converge more quickly because it can advertise the routes as they are learned.

How does BGP choose the best path?

Is this the best path? Does it meet the path selection criteria? If so, add to routing table. BGP Update BGP Table Network Routing Table Network

BGP selects only one path as the best path. When the path is selected, BGP puts the selected path in its routing table and propagates the path to its neighbors. How does BGP choose the best path?

79

WLam

Summary of the BGPWeight Path Selection Process BGP uses the following criteria, in the order presented, to select a path for a Local Preference destination: as are NOTE: Not all of thesepathcommonly used and will be examined in more detail later in this presentation and in the next presentation. med
1. If the path specifies a next hop that is inaccessible, drop the update. 2. Prefer the path with the largest weight. 3. If the weights are the same, prefer the path with the largest local preference. 4. If the local preferences are the same, prefer the path that was originated by BGP running on this router. 5. If no route was originated, prefer the route that has the shortest AS_path. 6. If all paths have the same AS_path length, prefer the path with the lowest origin type (where IGP is lower than EGP, and EGP is lower than Incomplete). 7. If the origin codes are the same, prefer the path with the lowest MED attribute. 8. If the paths have the same MED, prefer the external path over the internal path. 9. If the paths are still the same, prefer the path through the closest IGP neighbor. 10. Prefer the path with the lowest IP address, as specified by the BGP router ID

80

BGP Message Types

Before establishing a BGP peer connection the two neighbors must perform the standard TCP three-way handshake and open a TCP connection to port 179. After the TCP session is established, BGP peers exchanges several messages to open and confirm connection parameters and to send BGP routing information. All BGP messages are unicast to the one neighbor over the TCP connection. There are four BGP message types:

Type 1: OPEN Type 2: KEEPALIVE Type 3: UPDATE Type 4: NOTIFICATION

81

Type 1: BGP Open Message

After the TCP session is established, both neighbors send Open messages. This message is used to establish connections with peers. Each neighbor uses this message to identify itself and to specify its BGP operational parameters including: BGP version number (defaults to version 4) AS number: AS number of the originating router, determines if BGP session is EBGP or IBGP. BGP identifier: IP address that identifies the neighbor using the same method as OSPF router ID. Optional parameter: authentication, multiprotocol support and route refresh.

82

Type 2: BGP Keepalive Message

This message type is sent periodically between peers to maintain connections and verify paths held by the router sending the keepalive. If a router accepts the parameters specified in its neighbors Open message, it responds with a Keepalive. Subsequent Keepalives are sent every 60 seconds Holdtime: The maximum number of seconds that can elapse between successive keepalives or update messages. Cisco default holdtime is 180 seconds Will use the smaller of the two neighbor holdtimes. Router ID is includeds (determined same as OSPF or EIGRP Router ID)
83

Type 3: BGP Update Message

The UPDATE messages contain all the information BGP uses to construct a loop-free picture of the internetwork. Update messages advertises feasible routes, withdrawn routes, or both. The three basic components of an UPDATE message are: Network-Layer Reachability Information (NLRI) Path Attributes Withdrawn Routes

84

Type 3: BGP Update Message

Path
Attributes Networks

Path

Attributes Networks

Path

Attributes Networks

Update message includes Paths and associated Attributes and Networks

Path Attributes This is described later, providing 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 destination that have become unreachable and are being withdrawn from service. Network-Layer Reachability Information (NLRI) This is one or more networks (IP address prefix and prefix lengths) that can be reached by this path.
85

Type 4: BGP Notification Message

A NOTIFICATION message is sent whenever an error is detected and always causes the BGP connection to close. The NOTIFICATION message is composed of the Error Code (8 bits), Error Subcode (8 bits), and a Data fields (variable length).

86

BGP FSM

The BGP neighbor negotiation process proceeds through various states, or stages, which can be described in terms of a finite-state machine (FSM).
87

BGP FSM

BGP FSM includes six states: 1. Idle 2. Connect 3. Active 4. OpenSent 5. Open Confirm 6. Established
Note: Curved arrows should show pointing back to the same state.
88

 This process can be viewed with: debug ip bgp ipv4 unicast debug ip bgp events (older IOSs)
After you enter the neighbor command BGP starts in the idle state, and the BGP process checks that it has a route to the IP address listed. BGP should be in the idle state for only a few seconds. If BGP does not find a route to the neighboring IP address, it stays in the idle state. If it finds a route, it goes to the connect state when the TCP handshaking synchronize acknowledge (SYN ACK) packet returns (when the TCP three-way handshake is complete). After the TCP connection is set up, the BGP process creates a BGP open message and sends it to the neighbor. After BGP dispatches this open message, the BGP peering session changes to the open sent state. If there is no response for 5 seconds, the state changes to the active state. If a response does come back in a timely manner, BGP goes to the open confirm state and starts scanning (evaluating) the routing table for the paths to send to the neighbor. When these paths have been found, BGP then goes to the established state and begins routing between the neighbors.

89

Idle State

BGP always begins in the Idle state, in which it refuses all incoming connections. It is normally initiated by an administrator or a network event. If BGP does not find a route to the neighboring IP address, it stays in the idle state. When Start event occurs, the BGP process: Initializes all BGP resources Starts the ConnectRetry timer Initializes a TCP connection the the neighbor Listens for a TCP initialization from the neighbor Changes its state to Connect

90

Connect State

In this state, the BGP process is waiting for the TCP connection to be completed. If it finds a route, it goes to the connect state when the TCP handshaking synchronize acknowledge (SYN ACK) packet returns (when the TCP threeway handshake is complete). If the connection is successful, the BGP process: Clears the ConnectRetry timer Completes initialization Sends an Open message to the neighbor Transitions to the OpenSent state

91

Connect State

If the connection is unsuccessful, the BGP process: Continues to listen for a connection to be initiated by the neighbor Resets the ConnectRetry timer Transitions to the Active state

92

Active State

In this state, the BGP process is trying to initiate a TCP connection with the neighbor. If the TCP connection is successful: Clears the ConnectRetry timer Completes initialization Sends an Open message to the neighbor Transitions to the OpenSent state
93

Problem

Active State

If the ConnectRetry timer expires while BGP is in the Active State, the BGP process: Transitions back to the Connect state Resets the ConnectRetry timer In general, a neighbor state that is switching between "Connect" and "Active" is an indication that something is wrong and that there are problems with the TCP connection. It could be because of many TCP retransmissions, or the incapability of a neighbor to reach the IP address of its peer.
94

OpenSent State
errors No errors

In this state an Open message has been sent and BGP is waiting to hear an Open message from its neighbor. After the TCP connection is set up, the BGP process creates a BGP open message and sends it to the neighbor. After BGP dispatches this open message, the BGP peering session changes to the open sent state. When an Open message is received, all its fields are checked. If errors exist, a Notification message is sent and the state transitions to Idle. If no errors exist, a Keepalive message is sent and the Keepalive timer is set, the peer is determined to be internal or external, and state is changed

95

OpenConfirm State
error

No errors

In this state, the BGP process waits for a Keepalive or Notification message. If a Keepalive message is received, the state transitions to Established. If a Notification message is received, or a TCP disconnect is received, the state transitions to Idle.

96

Established State

In this state, the BGP connection is fully established and the peers can exchange Update, Keepalive and Notification messages. If an Update or Keepalive message is received, the Hold timer is restarted. If a Notification message is received, the state transitions to Idle.

97

CIS 185 CCNP ROUTE Ch. 6 Border Gateway Protocol Solution for ISP Connectivity Part 1
Rick Graziani Cabrillo College graziani@cabrillo.edu Last Updated: Fall 2010