07 peering and te with bgp

53 %
47 %
Information about 07 peering and te with bgp
Entertainment

Published on October 7, 2007

Author: UpBeat

Source: authorstream.com

Peering and Traffic Engineering with BGP:  Peering and Traffic Engineering with BGP Slide2:  Nontransit vs. Transit ASes ISP 1 ISP 2 Nontransit AS might be a corporate or campus network. Could be a “content provider” NET A Traffic NEVER flows from ISP 1 through NET A to ISP 2 (At least not intentionally!) Slide3:  Selective Transit NET B NET C NET A provides transit between NET B and NET C and between NET D and NET C NET A NET D NET A DOES NOT provide transit Between NET D and NET B Most transit networks transit in a selective manner… Slide4:  Customers and Providers Customer pays provider for access to the Internet provider customer Slide5:  Customers Don’t Always Need BGP provider customer Nail up default routes 0.0.0.0/0 pointing to provider. Nail up routes 192.0.2.0/24 pointing to customer 192.0.2.0/24 Static routing is the most common way of connecting an autonomous routing domain to the Internet. This helps explain why BGP is a mystery to many … Slide6:  Customer-Provider Hierarchy IP traffic provider customer Slide7:  The Peering Relationship Peers provide transit between their respective customers Peers do not provide transit between peers Peers (often) do not exchange $$$ traffic allowed traffic NOT allowed Slide8:  Peering Provides Shortcuts Peering also allows connectivity between the customers of “Tier 1” providers. Slide9:  Peering Wars Reduces upstream transit costs Can increase end-to-end performance May be the only way to connect your customers to some part of the Internet (“Tier 1”) You would rather have customers Peers are usually your competition Peering relationships may require periodic renegotiation Peering struggles are by far the most contentious issues in the ISP world! Peering agreements are often confidential. Peer Don’t Peer Slide10:  WorldCom’s peering req 1.1Geographic Scope. The Requester shall operate facilities capable of terminating customer leased line IP connections onto a router in at least 50% of the geographic region in which the WorldCom Internet Network with which it desires to interconnect operates such facilities. This currently equates to 15 states in the United States, 8 countries in Europe, or 2 countries in the Asia-Pacific region. The Requester also must have a geographically-dispersed network. In the United States, at a minimum, the Requester must have the ability to meet WorldCom's Internet Network at an East Coast location, a West Coast location, and at least two Midwest locations. 1.2Traffic Exchange Ratio. The ratio of the aggregate amount of traffic exchanged between the Requester and the WorldCom Internet Network with which it seeks to interconnect shall be roughly balanced and shall not exceed 1.5:1. 1.3Backbone Capacity. The Requester shall have a fully redundant backbone network, in which the majority of its inter-hub trunking links shall have a capacity of at least 622 Mbps (OC-12) for interconnection with WorldCom-US, 45 Mbps (DS-3) for interconnection with WorldCom-Europe, and 12 Mbps for interconnection with WorldCom-ASPAC. 1.4Traffic Volume. The aggregate amount of traffic exchanged in each direction over all interconnection links between the Requester and the WorldCom Internet Network with which it desires to interconnect shall equal or exceed 150 Mbps of traffic for WorldCom-US, 30 Mbps of traffic for WorldCom-Europe, and 5 Mbps of traffic for WorldCom-ASPAC. Slide11:  US Tier-1 ISP Peering Policies Example: http://www.verizonbusiness.com/uunet/peering/ Geographic Scope. The Requester shall operate facilities capable of terminating IP customer leased line connections onto a device in at least 50% of the geographic region in which the Verizon Business Internet Network with which it desires to interconnect operates such facilities. This currently equates to 25 states in the United States, 9 countries in Europe, or 3 countries in the Asia-Pacific region. The Requester also must have a geographically-dispersed network. In the United States, at a minimum, the Requester must have a backbone node in each of the following eight geographic regions: Northeast; Mid-Atlantic; Southeast; North Central; South Central; Northwest; Mid-Pacific; and Southwest. Traffic Exchange Ratio. The ratio of the aggregate amount of traffic exchanged between the Requester and the Verizon Business Internet Network with which it seeks to interconnect shall be roughly balanced and shall not exceed 1.8:1. Backbone Capacity. The Requester shall have a fully redundant backbone network, in which the majority of its inter-hub trunking links shall have a capacity of at least 9953 Mbps (OC-192) for interconnection with Verizon Business-US, 2488 Mbps (STM-16) for interconnection with Verizon Business-Europe, and 622 Mbps (OC-12) for interconnection with Verizon Business-ASPAC. Traffic Volume. The aggregate amount of traffic exchanged in each direction over all interconnection links between the Requester and the Verizon Business Internet Network with which it desires to interconnect shall equal or exceed 1500 Mbps of traffic for Verizon Business-US, 150 Mbps of traffic for Verizon Business-Europe, and 30 Mbps of traffic for Verizon Business-ASPAC. Transit Autonomous Systems. The Requestor shall provide transit services to a minimum number of Internet Networks (Autonomous Systems) as follows: 1500 unique transit networks for interconnection with Verizon Business-US; 100 unique transit networks for interconnection with Verizon Business-Europe; and 10 unique transit networks for interconnection with Verizon Business-ASPAC. Settlement models:  Settlement models No peering (only customer-provider relationships) Inefficient and high cost specially for international ISPs Sender Keeps All (Peering w/o settlement) Restrict to customer traffic only Only stable when perceived parity exists Negotiated Financial Terms By volume (which way does money flow?) Packet based? Too fine-grained, drop, detour, diff to implement Flow based? Require complicated instrumentation By other factors, unsymmetrical rates Terms unrelated to costs may not be stable Packet based:  Packet based $1 $3 $1 $2 $1 Per-packet transit costs A B Reality:  Reality A B John funds partial path Mary funds partial path SKA handover John Mary customer provider customer customer provider provider Trend?:  Trend? Currently, only stable settlement models are Customer-provider SKA (no-cost peering) Given bipolar peering model, incentive toward increasing size  improve bargaining power in peering Inevitable trend towards aggregation (and monopoly)? Contrast with Telephone model:  Contrast with Telephone model Current peering/settlement partially driven by IP best-effort service model Alternative model Initiator pays  similar to telephony model The implementation of such end-to-end settlement model will require signaling and accounting infrastructure How is interconnection done?:  How is interconnection done? Internet Exchange (IX) Each peer draws a circuit to the exchange and puts a router there Exchange is usually a high-speed LAN (FDDI, Ethernet, ATM), at a high-density location Other services often provided at exchange: e.g. DNS root server, Usenet server, web caches and hosting Neutral operator, flat fee Network Access Points (NAPs) For regional ISP to peer and purchase transit service A form of exchange Run BGP with “route server” Reference:  Reference Read Geoff Huston’s paper, “Interconnection, Peering and Settlements”. There is a URL at the course web site Some slides from Tim Griffin’s BGP tutorial (with his permission) Slide19:  BGP Attributes Value Code Reference ----- --------------------------------- --------- 1 ORIGIN [RFC1771] 2 AS_PATH [RFC1771] 3 NEXT_HOP [RFC1771] 4 MULTI_EXIT_DISC [RFC1771] 5 LOCAL_PREF [RFC1771] 6 ATOMIC_AGGREGATE [RFC1771] 7 AGGREGATOR [RFC1771] 8 COMMUNITY [RFC1997] 9 ORIGINATOR_ID [RFC2796] 10 CLUSTER_LIST [RFC2796] 11 DPA [Chen] 12 ADVERTISER [RFC1863] 13 RCID_PATH / CLUSTER_ID [RFC1863] 14 MP_REACH_NLRI [RFC2283] 15 MP_UNREACH_NLRI [RFC2283] 16 EXTENDED COMMUNITIES [Rosen] ... 255 reserved for development From IANA: http://www.iana.org/assignments/bgp-parameters We only look at thesese attributes Not all attributes need to be present in every announcement Slide20:  Attributes are Used to Select Best Routes 192.0.2.0/24 pick me! 192.0.2.0/24 pick me! 192.0.2.0/24 pick me! 192.0.2.0/24 pick me! Given multiple routes to the same prefix, a BGP speaker must pick at most one best route (Note: it could reject them all!) Slide21:  Two Types of BGP Neighbor Relationships External Neighbor (eBGP) in a different Autonomous Systems Internal Neighbor (iBGP) in the same Autonomous System AS1 AS2 eBGP iBGP iBGP is routed (using IGP!) Slide22:  iBGP Peers Must be Fully Meshed iBGP neighbors do not announce routes received via iBGP to other iBGP neighbors. iBGP is needed to avoid routing loops within an AS Injecting external routes into IGP does not scale and causes BGP policy information to be lost BGP does not provide “shortest path” routing Is iBGP an IGP? NO! Slide23:  BGP Next Hop Attribute Every time a route announcement crosses an AS boundary, the Next Hop attribute is changed to the IP address of the border router that announced the route. AS 6431 AT&T Research 135.207.0.0/16 Next Hop = 12.125.133.90 AS 7018 AT&T AS 12654 RIPE NCC RIS project 12.125.133.90 135.207.0.0/16 Next Hop = 12.127.0.121 12.127.0.121 Slide24:  Forwarding Table Forwarding Table Join EGP with IGP For Connectivity AS 1 AS 2 192.0.2.1 10.10.10.10 10.10.10.10 192.0.2.0/30 destination next hop 135.207.0.0/16 Next Hop = 192.0.2.1 192.0.2.0/30 135.207.0.0/16 destination next hop 10.10.10.10 + 192.0.2.0/30 10.10.10.10 135.207.0.0/16 Slide25:  Forwarding Table Forwarding Table Next Hop Often Rewritten to Loopback AS 1 AS 2 192.0.2.1 135.207.0.0/16 10.10.10.10 EGP 127.22.33.44 135.207.0.0/16 destination next hop 10.10.10.10 127.22.33.44 destination next hop 135.207.0.0/16 destination next hop 10.10.10.10 + 127.22.33.44 10.10.10.10 127.22.33.44 135.207.0.0/16 Next Hop = 192.0.2.1 135.207.0.0/16 Next Hop = 127.22.33.44 Slide26:  Implementing Customer/Provider and Peer/Peer relationships Enforce transit relationships Outbound route filtering Enforce order of route preference provider < peer < customer Two parts: Slide27:  Import Routes From peer From peer From provider From provider From customer From customer Slide28:  Export Routes To peer To peer To customer To customer To provider From provider provider route customer route peer route ISP route Slide29:  192.0.2.0/24 192.0.2.0/24 Accidental or malicious announcement of your prefix can blackhole your destinations in large part of the Internet Need Filter Here! legitimate not legitimate Blackholes Slide30:  Address with special meaning 0.0.0.0/0: default 10.0.0.0/8: private 172.16.0.0/12: private 192.168.0.0/16: private 128.0.0.0/16: IANA reserved 192.0.2.0/24: test networks 224.0.0.0/3: classes D and E ….. Slide31:  Import Routes (Revisited) From peer From peer From provider From provider From customer From customer provider route customer route peer route ISP route xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx Customer address filters cccccc cccccc cccccc potential blackhole specials Slide32:  So Many Choices Which route should Frank pick to 13.13.0.0./16? AS 1 AS 2 AS 4 AS 3 13.13.0.0/16 Frank’s Internet Barn Slide33:  BGP Route Processing Best Route Selection Apply Import Policies Best Route Table Apply Export Policies Install forwarding Entries for best Routes. Receive BGP Updates Best Routes Transmit BGP Updates Apply Policy = filter routes & tweak attributes Based on Attribute Values IP Forwarding Table Apply Policy = filter routes & tweak attributes Open ended programming. Constrained only by vendor configuration language Slide34:  Tweak Tweak Tweak For inbound traffic Filter outbound routes Tweak attributes on outbound routes in the hope of influencing your neighbor’s best route selection For outbound traffic Filter inbound routes Tweak attributes on inbound routes to influence best route selection outbound routes inbound routes inbound traffic outbound traffic In general, an AS has more control over outbound traffic Attributes used for tweaking:  Attributes used for tweaking Local_pref A preference set depending on where route comes from Propagated by iBGP to AS routers in same AS Only used inside a single AS AS_path List of AS traversed by path Community An id used to tell neighbor AS how to set local pref Multi_exit_discriminator (MED) A cost indicator to discriminate between multiple exit paths from one AS to another Slide36:  Route Selection Summary Highest Local Preference Shortest ASPATH Lowest MED i-BGP < e-BGP Lowest IGP cost to BGP egress Lowest router ID traffic engineering Enforce relationships Throw up hands and break ties Longest prefix matching! Forwarding rule Slide37:  Back to Frank … AS 1 AS 2 AS 4 AS 3 13.13.0.0/16 local pref = 80 local pref = 100 local pref = 90 Higher Local preference values are more preferred Local preference only used in iBGP Slide38:  Implementing Backup Links with Local Preference (Outbound Traffic) Forces outbound traffic to take primary link, unless link is down. AS 1 primary link backup link Set Local Pref = 100 for all routes from AS 1 AS 65000 Set Local Pref = 50 for all routes from AS 1 We’ll talk about inbound traffic soon … Slide39:  Multihomed Backups (Outbound Traffic) Forces outbound traffic to take primary link, unless link is down. AS 1 primary link backup link Set Local Pref = 100 for all routes from AS 1 AS 2 Set Local Pref = 50 for all routes from AS 3 AS 3 provider provider Slide40:  ASPATH Attribute AS7018 135.207.0.0/16 AS Path = 6341 AS 1755 Ebone AT&T AS 3549 Global Crossing 135.207.0.0/16 AS Path = 7018 6341 135.207.0.0/16 AS Path = 3549 7018 6341 AS 6341 135.207.0.0/16 AT&T Research Prefix Originated AS 12654 RIPE NCC RIS project AS 1129 Global Access 135.207.0.0/16 AS Path = 7018 6341 135.207.0.0/16 AS Path = 1239 7018 6341 135.207.0.0/16 AS Path = 1755 1239 7018 6341 135.207.0.0/16 AS Path = 1129 1755 1239 7018 6341 Slide41:  Interdomain Loop Prevention BGP at AS YYY will never accept a route with ASPATH containing YYY. AS 7018 12.22.0.0/16 ASPATH = 1 333 7018 877 Don’t Accept! AS 1 Slide42:  Traffic Often Follows ASPATH AS 4 AS 3 AS 2 AS 1 135.207.0.0/16 135.207.0.0/16 ASPATH = 3 2 1 IP Packet Dest = 135.207.44.66 Slide43:  … But It Might Not AS 4 AS 3 AS 2 AS 1 135.207.0.0/16 135.207.0.0/16 ASPATH = 3 2 1 IP Packet Dest = 135.207.44.66 AS 5 135.207.44.0/25 ASPATH = 5 135.207.44.0/25 AS 2 filters all subnets with masks longer than /24 135.207.0.0/16 ASPATH = 1 From AS 4, it may look like this packet will take path 3 2 1, but it actually takes path 3 2 5 Slide44:  In fairness: could you do this “right” and still scale? Exporting internal state would dramatically increase global instability and amount of routing state Shorter Doesn’t Always Mean Shorter AS 4 AS 3 AS 2 AS 1 Mr. BGP says that path 4 1 is better than path 3 2 1 Duh! Slide45:  Shedding Inbound Traffic with ASPATH Pre-pending Pre-pending will (usually) force inbound traffic from AS 1 to take primary link AS 1 192.0.2.0/24 ASPATH = 2 2 2 customer AS 2 provider 192.0.2.0/24 backup primary 192.0.2.0/24 ASPATH = 2 Slide46:  Pre-pending May Not Shut Off All Traffic AS 1 192.0.2.0/24 ASPATH = 2 2 2 2 2 2 2 2 2 2 2 2 2 2 customer AS 2 provider 192.0.2.0/24 192.0.2.0/24 ASPATH = 2 AS 3 provider AS 3 will send traffic on “backup” link because it prefers customer routes and local preference is considered before ASPATH length! Pre-pending in this way is often used as a form of load balancing backup primary Slide47:  COMMUNITY Attribute to the Rescue! AS 1 customer AS 2 provider 192.0.2.0/24 192.0.2.0/24 ASPATH = 2 AS 3 provider backup primary 192.0.2.0/24 ASPATH = 2 COMMUNITY = 3:70 Customer import policy at AS 3: If 3:90 in COMMUNITY then set local preference to 90 If 3:80 in COMMUNITY then set local preference to 80 If 3:70 in COMMUNITY then set local preference to 70 AS 3: normal customer local pref is 100, peer local pref is 90 Slide48:  Hot Potato Routing: Go for the Closest Egress Point 192.44.78.0/24 15 56 IGP distances egress 1 egress 2 This Router has two BGP routes to 192.44.78.0/24. Hot potato: get traffic off of your network as Soon as possible. Go for egress 1! Slide49:  Getting Burned by the Hot Potato 15 56 17 2865 High bandwidth Provider backbone Many customers want their provider to carry the bits! tiny http request huge http reply SFF NYC San Diego Slide50:  Cold Potato Routing with MEDs (Multi-Exit Discriminator Attribute) 15 56 17 2865 192.44.78.0/24 192.44.78.0/24 MED = 15 192.44.78.0/24 MED = 56 This means that MEDs must be considered BEFORE IGP distance! Prefer lower MED values Note1 : some providers will not listen to MEDs Note2 : MEDs need not be tied to IGP distance Slide51:  Recall route selection rules Highest Local Preference Shortest ASPATH Lowest MED i-BGP < e-BGP Lowest IGP cost to BGP egress Lowest router ID traffic engineering Enforce relationships Throw up hands and break ties Longest prefix matching! Forwarding rule Slide52:  Multi-homing and addressing Both ISP 1 and 2 are providers for customer Where should customer get its addresses? Options: From ISP 1 From ISP 2 From both ISP 1 and 2 From address registry independently Option 4 assumed for discussion so far ISP 3 ISP 1 ISP 2 customer Slide53:  Option 1 or 2 Customer gets address from ISP 1 ISP 1 will aggregate customer’s address into its address before announcing routes to ISP 3 Due to longest prefix matching, both ISP 3 and 2 send traffic via ISP 2 Address delegation affects load sharing configuration! ISP 3 ISP 1 138.38/16 ISP 2 Customer 138.38.1/24 138.38.1/24 138.38.1/24 138.38/16 138.39.1/24 138.38.1/24 138.38/16 ? “Solutions”: Providers may filter out announcements with shorter prefixes (e.g. ISP 3 only accepts /19 or shorter) ISP 1 does not aggregate, and advertise 138.38.1/24 Slide54:  Option 3 Customer gets address from both ISP’s Announces only addresses from respective ISP Good aggregation, load sharing maybe okay; but no backup If both addresses announced on both links, same situation as options 1 and 2 ISP 3 ISP 1 138.38/16 ISP 2 204.70/16 Customer 138.39.1/24 204.70.1/24 204.70.1/24 204.70/16 138.38/16 138.38.1/24 204.70/16 138.38/16 iBGP:  iBGP Loop-back address BGP extensions to make iBGP scalable Slide56:  iBGP What is the IP address of a router? Interface address okay for eBGP if link down, then no BGP session Not okay for iBGP there are other IGP paths connecting iBGP routers R1 R2 138.39.1.1/30 138.39.1.2/30 R1 R2 138.39.1.1/30 138.39.1.2/30 R3 Slide57:  Loopback address Configure loopback addresses for routers (loopback interfaces) IGP must know about these addresses and how to route to them. iBGP sessions can be set up even if link down R1 R2 138.39.1.1/30 138.39.1.2/30 R3 138.39.128.5/30 138.39.128.1/30 Slide58:  iBGP scalability iBGP cannot rely on ASPATH to avoid loops Brute-force solution: all iBGP routers form a full mesh Number of iBGP sessions = n(n-1)/2 For large AS, this is not scalable Cost in configuring each BGP router CPU and memory requirements for each BGP router Solutions: Buy bigger routers Divide AS into smaller AS’s Route reflector Confederation Slide59:  Route Reflector Introduce hierarchy to iBGP Route reflector Configured to have a number of clients Maintains full mesh with other route reflectors configured to re-advertise routes to its clients Route reflector client behaves as regular iBGP Only maintain a session with its route reflector Cluster Each route reflector and its clients form a cluster Has a cluster ID (set to route reflector’s router ID) Slide60:  Two more attributes Originator ID Identifies the router that introduced the route to this AS Never reflect a route to its originator Cluster List Shows the set of clusters the route advertisement has gone through Used to prevent loop Cluster 192.168.1.2 Cluster 192.168.1.1 Cluster 192.168.1.3 139.0.0.0/8 Cluster ID 192.168.1.1 139.0.0.0/8 Cluster ID 192.168.1.1 192.168.1.2 139.0.0.0/8 Cluster ID 192.168.1.1 192.168.1.2 192.168.1.3 Loop detected! Slide61:  Confederation Divide a big AS into smaller sub-AS’s Each router configured with ASN, and list of sub-AS numbers E.g. AS1, (AS10, AS11, AS12) In each sub-AS There is a full mesh Routers speak iBGP Routers from diff sub-AS Speak eBGP, except Allow local_pref Next_hop unchanged Include sub-AS in ASPATH with special tags, removed when exit AS Sub-AS hidden from external routers AS1 AS10 AS11 AS12 Summary:  Summary Two type of ISP peering relationships Customer-provider Peers BGP protocol basics Over TCP, BGP session and protocol messages eBGP vs iBGP BGP processing Using BGP attributes to implement routing policies LOCAL_PREF, AS_PATH, COMMUNITY, MED Supporting peering relationships, route filtering Backup, multi-homing load-balancing techniques using above BGP attributes, and more specific prefix Shortest path, loop prevention

Add a comment

Related presentations

Related pages

BGP peering with ISP | WAN, Routing and Switching | Cisco ...

BGP peering with ISP. ... 07:21. It s only in a DR scenario that the link will be used. ... from two different BGP peers, ...
Read more

BGP Traffic Engineering Using RSVP-TE? - Meet us in ...

BGP Traffic Engineering Using RSVP-TE? ... peering router • RSVP-TE LSPs built to an interface generally are treated like a ... NANOG_BGP_TE-4 ...
Read more

Module 07 - BGP IPv6 Route Filtering and Advanced Features

BGP peerings to demonstrate neighbour filtering and more advanced IOS features. Prerequisite: Module 6 Topology: ... 10/21/2009 7:33:07 AM ...
Read more

Module 7 - BGP Route Filtering and Advanced Features

... use various configuration methods on BGP peerings to demonstrate neighbour ... BGP Route Filtering and Advanced ... Each router te Checkpoint #3 ...
Read more

How to Extract BGP Peering Information from the Internet ...

How to Extract BGP Peering Information from the Internet Routing Registry ... provide the peerings extracted from the IRR on 04/07/04. The work in ...
Read more

juniper-nsp: Re: Juniper BGP Peering with cisco 7206 come with

Subject: Re: Juniper BGP Peering with cisco 7206 come with error message ... > >On Mon, Jan 07, 2002 at 04:35:24PM +0800, Raymond Leung wrote:
Read more

MPLS: Layer 3 VPNs Configuration Guide, Cisco IOS Release ...

MP-BGP peering must be configured on all PE devices within a VPN community. ... In Cisco IOS Release 12.2(9)S, 12.2(17b)SXA, 12.2(27)SBB, 12.3(8)T, ...
Read more

bgpPeeringMap download | SourceForge.net

Draw a complete or partial dynamic map of the Internet BGP peering; Zoom in/Zoom out into the map; Redraw around certain BGP autonomus system ...
Read more

Configuring the BGP Maximum-Prefix Feature

The BGP Maximum-Prefix feature allows you to control how ... Know how many routes the remote BGP peering router ... *Mar 12 07:39:21.228: BGP(0): ...
Read more

Using HSRP VIP address as BGP peer ? | WAN, Routing and ...

... Cisco Technical Support Forum | 5991 | 10136176 ... Moreover it's not practical to use HSRP address for BGP peering as address doesn ... 07/30 /2007 ...
Read more