1. Introduction to Border Gateway Protocol Azher Amin NIIT

2. 2 Routing Protocol Foundation

3. 3 Interdomain Routing AS65001AS65000 An autonomous system (AS) is a collection of networks under a single technical administration Interior routing protocol (IGP) run inside an autonomous system resulting in optimum intra-AS routing OSPF EIGRP Exterior routing protocol (EGP) run between autonomous systems to enable routing policies and improve security BGP

4. 4 Interdomain Routing Goals Scalability –Internet has over 219,260 BGP routes and is still growing Secure routing information exchange –Routers from another autonomous system cannot be trusted –Tight filters are required, authentication is desirable Routing policies support –Routing between autonomous systems might not always follow the optimum path

5. 5 Routing Policies - Case Study Q:Assuming standard IGP route selection rules, how will the traffic between AS1 and AS20 flow? Q:Will AS 2 allow this traffic? Q:How would you solve this problem with OSPF or EIGRP? Company B (AS 2)Company A (AS 1) Service Provider (AS 10) Company X (AS 20) 64 kbps 2 Mbps

6. 6 IGP Interior Gateway Protocol Within a network/autonomous system Carries information about internal infrastructure prefixes Examples – OSPF, ISIS, EIGRP

7. 7 Why do we need an IGP? ISP Backbone Scaling –Hierarchy –Modular infrastructure –Limiting scope of failure –Healing of faults with fast convergence

8. 8 EGP Exterior Gateway Protocol Used to convey routing information between networks/ASes De-coupled from the IGP Current EGP is BGP4

9. 9 Why Do We Need an EGP? Scaling to large network –Hierarchy –Limit scope of failure Define administrative boundary Policy –Control reachability of prefixes

10. 10 Interior vs. Exterior Routing Protocols Interior –Automatic neighbour discovery –Generally trust your IGP routers –Routes go to all IGP routers –Binds routers in an AS together Exterior –Specifically configured peers –Connecting with outside networks –Set administrative boundaries –Binds ASes together

11. 11 Interior vs. Exterior Routing Protocols Interior –Carries ISP infrastructure addresses only –ISPs aim to keep IGPs small for scalability and efficiency Exterior –Carries customer prefixes –Carries Internet prefixes –EGPs are independent of ISP network topology

12. 12 Do we really need BGP ?

13. 13 BGP Intro BGP is a distance vector protocol used on the Internet to exchange routing information between Autonomous Systems or the among service providers, and to propagate external routing information through networks. “The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems”. RFC 4271

14. 14 Reference http://www.cisco.com/en/US/tech/tk365/tk80/tsd_technology_ support_sub-protocol_home.html http://www.estoile.com/links/bgp4.htm http://ispcolumn.isoc.org/2006-05/bgp.html http://www.itprc.com/routing.htm http://www.cidr-report.org Books: –Internet Routing Architecture 2 nd Edition by Basam Halabi

15. 15 Autonomous System The classic definition of an Autonomous System is: –a set of routers –under a single technical administration using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASs.

16. 16 Autonomous System

17. 17 Autonomous System Number Each autonomous network is called an Autonomous System. ASs which inject routing information on their own behalf require ASNs. IANA assigns ASN Numbers to Regional Network Information Centers: –ARIN RIPE-NCC –APNIC AfriNIC Example : ASN ranges assigned to APNIC are: –4608 - 4864, 7467 - 7722, 9216 - 10239, 23552 - 24575, 37888 – 38911 ASN: 64512 - 65534 are designated for private use (Allocated to the IANA) ASN 0 and 65535 are not used Source: http://www.iana.org/assignments/as-numbers

18. 18 WHOIS Report for AS 17491 [APNIC] whois -h whois.apnic.net "AS17491“ % [whois.apnic.net node-1] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html as-block: AS17408 - AS18409 descr: APNIC ASN block remarks: These AS numbers are further assigned by APNIC remarks: to APNIC members and end-users in the APNIC region admin-c: HM20-AP tech-c: HM20-AP mnt-by: APNIC-HM mnt-lower: APNIC-HM changed: hm-changed@apnic.net 20060517 source: APNIC

19. 19 CIDR Reports [http://www.cidr-report.org/] DatePrefixes CIDR Aggregated 02-06-06 185948 122700

20. 20 Number of ASes in routing system 22306 Number of ASes in routing system 9351 Number of ASes announcing only one prefix

21. 21 CIDR Updates : 01-06-07 DatePrefixes CIDR Aggregated 01-06-07 219260 140227

22. 22 CIDR Updates : 01-06-07 25233 Number of ASes in routing system 10697 Number of ASes announcing only one prefix

23. 23 BGP Intro Current protocol version is 4 IETF Network Working Group –Current RFC : 4271 Obsoletes : 1771 & Obsoletes : 1654 Operates using TCP and its port number is 179 TCP eliminates the need to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing. No routing information can be exchanged until the TCP session has been established. For added security, MD5 Authentication can be used to authenticate each TCP segment.

24. 24 BGP Peering BGP-speaking routers peer with each other over TCP sessions, and exchange routes through the peering sessions. Providers typically try to peer at multiple places. Either by peering with the same AS multiple times, or because some ASs are multi-homed, a typical network will have many candidate paths to a given prefix. Typical example is Internet Exchange Points.

25. 25 BGP Route Attributes In addition to the prefix, the as-path, and the next-hop, the BGP route has other attributes, affectionately known as “knobs and twiddles” – –weight, rarely used –local-pref, sometimes used –origin code, rarely used –MED (“metric”)

26. 26 AS Path Sequence of AS(s) a route has traversed. Provides a mechanism for loop detection. Policies may be applied based on AS path. Local AS added only when send to external peer. *Shortest AS path preferred AS3847 207.240.0.0/16 AS1673 140.222.0.0/16 AS701 192.67.95.0/24 AS3561 204.70.0.0/15 192.67.95.0/24 3847 701 i 140.222.0.0 3847 1673 i 204.70.0.0/15 3847 3561 i 207.240.0.0/16 3847 i AS6201 E C F G D B A

27. 27 Next Hop Next-hop IP address to reach a network. Router A will advertise 198.3.97.0/24 to router B with a next-hop of 207.240.24.202. With IBGP, the next-hop does not change. IGPs should carry route to next- hops, using intelligent forwarding decision. AS 6201 AS 3847 198.3.97.0/24 A B 207.240.24.200/30.201 A B.202 C

28. 28 Administrative Distance Administrative distance is the feature that routers use in order to select the best path when there are two or more different routes to the same destination from two different routing protocols. It defines the reliability of a routing protocol. Each routing protocol is prioritized in order of most to least reliable (believable) with the help of an administrative distance value.

29. 29 Administrative Distance Route Source Default Distance Values Connected interface0 Static route*1 Enhanced Interior Gateway Routing Protocol (EIGRP) summary route5 External Border Gateway Protocol (BGP)20 Internal EIGRP90 IGRP100 OSPF110 Intermediate System-to-Intermediate System (IS-IS)115 Routing Information Protocol (RIP)120 Exterior Gateway Protocol (EGP)140 On Demand Routing (ODR)160 External EIGRP170 Internal BGP200 Unknown**255

30. 30 BGP - Attributes There are four basic types of attributes: 1.Well known mandatory attributes; these attributes must be recognized by all BGP speakers, and must be included in all update messages. Almost all of the attributes impacting the path decision process ( ORIGIN, AS Path, Next Hop, LOCAL_PREF ). 2.Well known discretionary attributes; these attributes must be recognized by all BGP speakers, and may be carried in updates, but are not required in every update ( ATOMIC_AGGREGATE ). 3.Optional transitive attributes; these attributes may be recognized by some BGP speakers, but not all. They should be preserved and advertised to all peers whether or not they are recognized ( Communities, AGGREGATOR ). 4.Optional non-transitive attributes; these attributes may be recognized by some BGP speakers, but not all. If an update containing an optional transitive attribute is received, the update should be advertised to peers without the unrecognized attributes ( Multiple Exit Discriminator (MED) )

31. 31 BGP - Attributes ORIGIN The ORIGIN is a well known mandatory attribute that indicates the origin of the prefix, or rather, the way in which the prefix was injected into BGP. There are three origin codes, listed in order or preference: 1.IGP, meaning the prefix was originated from information learned from an interior gateway protocol 2.EGP, meaning the prefix originated from the EGP protocol, which BGP replaced 3.INCOMPLETE, meaning the prefix originated from some unknown source router-b#sho ip bgp BGP table version is 3, local router ID is 10.0.16.10 Status codes: s suppressed, d damped, h history, * valid, > best, i -internal, r RIB-failure Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.7.7.0/24 10.0.7.4 10 0 65500 ? *> 10.0.10.0 10.0.7.4 0 0 65500 i

32. 32 BGP - Attributes AS_PATH A well-known mandatory attribute which identifies the ASs through which routing information carried in this update message has passed. Can be AS_SETs or AS_SEQUENCEs. The local autonomous system number is added by a BGP speaker when advertising a prefix to an eBGP peer NEXT_HOP A well-known mandatory attribute that defines the IP address of the router that should be used as the next hop to the destinations listed in the update message. MULTI_EXIT_DISC MED is an optional non transitive attribute. MED is a hint to external neighbors about the preferred path into an autonomous system (AS) that has multiple entry points. The MED is also known as the external metric of a route. A lower MED value is preferred over a higher value.

33. 33 MULTI_EXIT_DISC Example: Customer is advertising two prefixes with different MEDs Customer Provider

34. 34 BGP - Attributes LOCAL_PREF A well-known attribute that shall be included in all update messages to the other internal peers. A BGP speaker shall calculate the degree of preference for each external route based on the locally configured policy, and include the degree of preference when advertising a route to its internal peers. The HIGHER degree of preference must be preferred. ATOMIC_AGGREGATE A well-known discretionary attribute. AGGREGATOR An optional transitive attribute which may be included in updates which are formed by aggregation. A BGP speaker which performs route aggregation may add this attribute which shall contain its own AS number and BGP Identifier. COMMUNITIES An optional transitive attribute which specifies a community. All routes with this attribute belong to the communities listed in the attribute. Well known communities are NO_EXPORT, NO_ADVERTISE and NO_EXPORT_SUBCONFED.

35. 35 BGP Route Selection Algo

36. 36 Route reflector The route reflector (RR) offers an alternative to the logical full-mesh requirement of iBGP. A RR acts as a focal point for iBGP sessions. The purpose of the RR is concentration. Multiple BGP routers can peer with a central point, the RR - acting as a route reflector server - rather than peer with every other router in a full mesh. All the other iBGP routers become route reflector clients. This approach, similar to OSPF's DR/BDR feature, provides large networks with added iBGP scalability. A network requiring more than 100 statements just to define the remote- as of each peer quickly becomes a headache to administer. The RR can offer a viable solution for the larger networks administered by ISPs.

37. 37 Router reflector clients vs route reflector speakers IBGP peers of a route reflector fall under two categories: clients and nonclients. A route reflector and its clients form a cluster. All IBGP peers of the route reflector that are not part of the cluster are nonclients and must be fully meshed to all other IBGP routers. Configuring route reflector clients to peer with IBGP speakers outside their cluster can cause routing loops. Not exercising proper filtering of traffic entering your route reflector can also be a cause of a network-wide outage, as recently demonstrated by Level(3) Communications, LLC.

38. 38 Rules for Route Reflector RR servers propagate routes inside the AS based on the following rules: 1.If a route is received from nonclient peer, reflect to clients only. 2.If a route is received from a client peer, reflect to all nonclient peers and also to client peers, except the originator of the route. 3.If a route is received from an EBGP peer, reflect to all client and nonclient peers.

39. 39 BGP Finite State Machine

40. 40 BGP Finite State Machine A finite state machine is an abstract model of a machine that has a finite number of defined states in which it can exist at any time. Events such as timers or external inputs cause transitions between states. RFC 1771 defines what is called a "finite state model" which diagrams BGP's behavior at startup. The finite-state-machine is a description of what actions should be taken by the BGP software and when. There are six states in the model, and there are specific conditions under which each state will transition to the next during the process of establishing first a TCP connection, and then a BGP session One FSM is maintained for each BGP session, which allows sessions to operate independently of each other. BGP uses five timers that are used to cause state transitions, and each value is stored in units of seconds

41. 41 Finite State Machine Timers ConnectRetry: used only when BGP is trying to establish a TCP connection to its peer, and determines how often a TCP connection is initiated Hold: number of seconds that can elapse without receipt of an UPDATE or KEEPALIVE message before the peer is assumed to be down (Cisco’s default is 180 seconds) KeepAlive: used to generate KEEPALIVE messages at a rate of 1/3 the Hold Time (Cisco’s default is 60 seconds) MinASOriginationInterval: used to throttle how often internal changes within the AS are sent MinRouteAdvertisementInterval: used to throttle how often changes to the same route are sent

42. Pictorial Diagram for BGP FSM 26

43. 43 BGP FSM Explained 1.IDLE When a BGP speaking router is awaiting a session it sits in the IDLE state. It will not start a session until a start event occurs. Cisco classifies initial configuration or clearing of a BGP session as a start event and the system transitions to the connect state. Whenever a BGP session is shut down because of an error, it returns to the Idle state. NOTIFICATION messages used to signal connection errors return the router to this state. RS# bgp show summary Local router ID is 192.168.0.1, Local AS number 65030 BGP Route Entries 0, Unique AS Paths 2 Unique Communities 0, Unique Extended Communities 0 Neighbor V AS MsgRcvd MsgSent Up/Down Prefixes Rcvd/Sent -------- - -- ------- ------- ------- ------------------ [Group Id: VVNet] 10.0.0.2 0 65015 0 0 Idle

44. 44 BGP FSM Explained 2.CONNECT Once the BGP software and it's environment have been initialized, an OPEN message is sent. The router has attempted to open a TCP connection between itself and another BGP speaking peer. RS# bgp show summary Local router ID is 192.168.0.1, Local AS number 65030 BGP Route Entries 0, Unique AS Paths 2 Unique Communities 0, Unique Extended Communities 0 Neighbor V AS MsgRcvd MsgSent Up/Down Prefixes Rcvd/Sent -------- - -- ------- ------- ------- ------------------ [Group Id: VVNet] 10.0.0.2 0 65015 0 0 Connect

45. 45 BGP FSM Explained 3.ACTIVE The router has started the first phase of initializing a TCP three-way handshake to the remote router (peer). If a router fails to establish a TCP connection, it drops back to IDLE. RS# bgp show summary Local router ID is 192.168.0.1, Local AS number 65030 BGP Route Entries 0, Unique AS Paths 2 Unique Communities 0, Unique Extended Communities 0 Neighbor V AS MsgRcvd MsgSent Up/Down Prefixes Rcvd/Sent -------- - -- ------- ------- ------- ------------------ [Group Id: VVNet] 10.0.0.2 0 65015 0 0 Active

46. 46 BGP FSM Explained 4.OPEN SENT Once BGP has performed all the setup steps necessary, it sends out a TCP SYN on port 179. 5.OPEN CONFIRM The router enters this state after the remote router has sent back a TCP SYN packet indicating that the TCP session is being SYNchronized. 6.ESTABLISHED After each router has sent an ACKnowledge, one router has sent a SYN, and a TCP handshake has been completed, the router attempts to exchange BGP messages.. If the router is in the OPEN CONFIRM state (the TCP Handshake is complete) and receives an UPDATE or KEEPALIVE message, the BGP session state changes to ESTABLISHED.

47. 47 BGP FSM Explained Note: 1.If a BGP session is cycling between Connect and Active, there is probably a problem with IP connectivity between peers, such as a physical link failure or IP routing problem. 2.The transition from OpenSent and OpenConfirm is very fast. It is almost impossible to see these states printed in CLI output. 3.ESTABLISHED STATE! This is the ONLY state in which BGP will actually exchange routes. Established is the ONLY state that counts. If you have any other state, you have a non-functional BGP session (and possibly a broken physical link if it refuses to establish the connection). On a Cisco router, you CANNOT have an ESTABLISHED BGP session if the interface is Line Protocol Up/Network Protocol Down.

48. 48 BGP Connection Collision Detection It is entirely possible that two TCP sessions may be established between the same peers when BGP is in OpenSent and OpenConfirm. However, exactly one TCP session is required between two BGP speakers. A mechanism called Connection Collision Detection is implemented to decide which session to close and which one to keep using information from the OPEN message. The connection initiated from the router with the numerically highest router ID is kept in this situation, and the connection initiated from the router with the lowest router ID is closed.

49. 49 BGP: Route Flap A route flap is a route oscillation that occurs when a route is advertised and then withdrawn, or route is withdrawn and then re advertised in rapid succession. EBGP flapping causes global disturbance in the routing table, because the flap ripples across the Internet and each router must process the routing information change. IBGP flapping causes irregular traffic flow and reachability problems within the local AS, and can affect EBGP stability if IBGP routes are advertised to EBGP peers. Rapid flapping can consume significant CPU cycles that are spent on processing the routing updates. Route flapping usually indicates a problem, such as a circuit going up and down, or fatal recurring errors between BGP peers.

50. 50 BGP Message Types Open –Includes hold time and BGP router ID Keepalive Update –Information for one path only (could be to multiple networks) - Includes path attributes and networks Notification –When error is detected

51. 51 BGP Configuration Examples

52. 52 BGP Configuration Parameters Configuring Basic BGP Operations –router bgp –neighbor ip-address | peer-group remote-as autonomous- system If remote-as is self then its IBGP session –neighbor ip-address | peer-group update-source –neighbor ip-address | peer-group ebgp-multihop [ttl] –neighbor ip-address | peer-group password

53. 53 BGP Example Scenerio

54. 54 BGP Example Configuration

55. 55 BGP Multihop Example

56. 56 Peer Group Example

57. 57 Neighbor Authentication

58. 58 Example: Show IP BGP Command

59. 59 Clearing the BGP Session Required when policies or ACLs are changed –Some Trigger must be used ensure that policy is in immediately applied Ways to trigger an update –Hard Reset –Soft Reset –Route Refresh

60. 60 Hard Reset of BGP Sessions

61. 61 Soft Reset OutBound

62. 62 BGP Synchronozation Rule Do not use or advertise to an external neighbor a route learned by IBGP until a matching route has been learned from an IGP –Off by default in Cisco IOS –Ensure Information consistency in AS Example: no synchronization (a router will advertise routes in BGP without learning from an IGP) Synhronization (routes will not be advertised unless learned from IGP)

63. 63 Synchronization Example Scenario

64. 64 MultiHoming Concepts