Routing Policy Tutorial NANOG 24 - Miami Daniel Golding

Routing Policy Tutorial Audience and Goals Who are you? –Networks Engineers with a basic knowledge of BGP and internetwork routing Why are you here? –To learn and discuss network and routing policy –To help your networks expand into new horizons

Routing Policy Tutorial Audience and Goals Why aren’t you here? –To learn what a route map is – that’s not routing policy –To learn BGP or other routing protocols – please see the NANOG archives… Questions and Comments –Please be interactive! –Rewards for participation will be distributed.

Introduction to Routing Policy What is a Routing Policy? What it isn’t – Route maps Peering policy Filter Policy Standard router configurations But those can be aspects of routing policy!

Introduction to Routing Policy What is a Routing Policy? The Expression of a network’s goals for… Selection of routes you accept from peers, customers, and upstream providers Selection and modification of routes you send to peers, customers and upstream providers Methodology of identifying routes within your own AS

Introduction to Routing Policy Why is a strong routing policy necessary? Scalability Enables ease of scaling to large numbers of peers and transit customers Troubleshooting Enables identification of where routes are entering your network Customer Features Many providers are now implementing rich community strings, which are a big plus for clueful customers CW recently did this. Others?

Introduction to Routing Policy Elements of a routing policy Written documentation – policy document Handle different types of routes, differently Customer Inbound Customer Outbound Transit/Peer Inbound Transit/Peer Outbound

Introduction to Routing Policy Customer Routes, Inbound Accept by Prefix or by AS? AS-Path lists are easier Prefix filtering is highly recommended Maximum Prefix Size /24 is generally accepted on most networks Reasons to accept smaller announcements Just because you can accept /24s doesn’t mean anyone will listen to them – especially in legacy B space

Introduction to Routing Policy Customer Routes, Inbound Trip-points for large numbers of prefixes Safety Net! Very Important! Manual element, but can prevent disasters – engineers are human! IRR Registration Autogeneration of route filters? RTConfig Customer Routes – Highest Local Preference – Why? You don’t want to be sending outbound traffic to peers that should really be going to your customers, if they prepend! MEDs are usually listened to Application is customers with multiple sites Use a route-map or policy-statement to set appropriate communities on INGRESS

Introduction to Routing Policy Customer Routes, Inbound Customer Routes – Highest Local Preference – Why? You don’t want to be sending outbound traffic to peers that should really be going to your customers, if they prepend! MEDs are usually listened to Application is customers with multiple sites Use a route-map or policy-statement to set appropriate communities on INGRESS

Introduction to Routing Policy Customer Routes, Outbound What kind of routes to send? Full Routes Partial Routes Default Route only Full Routes can be sent with or without summary aggregates – many (most?) providers do not aggregate towards customer. Some providers allow you to choose amount of aggregation.

Introduction to Routing Policy Customer Routes, Outbound Remember, that by providing customers with rich communities, they can do their own filtering - leave it to them. Example: A customer takes full routes, and filters out your peer routes by community, which gives the equivalent of Partial Routes. Don’t send Martians or Exchange blocks

Introduction to Routing Policy Customer Routes, Outbound – Martians Example ip prefix-list no-martians description no-martians-or-exchange-networks filter ip prefix-list no-martians seq 5 deny /0 ip prefix-list no-martians seq 10 deny /8 le 32 ip prefix-list no-martians seq 15 deny /8 le 32 ip prefix-list no-martians seq 20 deny /16 le 32 ip prefix-list no-martians seq 25 deny /12 le 32 ip prefix-list no-martians seq 30 deny /16 le 32 ip prefix-list no-martians seq 35 deny /24 le 32 ip prefix-list no-martians seq 40 deny /24 le 32 ip prefix-list no-martians seq 45 deny /16 le 32 ip prefix-list no-martians seq 50 deny /11 le 32 ip prefix-list no-martians seq 55 deny /24 le 32 ip prefix-list no-martians seq 60 deny /4 le 32 ip prefix-list no-martians seq 105 deny /24 ip prefix-list no-martians seq 110 deny /24 ip prefix-list no-martians seq 115 deny /24 ip prefix-list no-martians seq 120 deny /24 ip prefix-list no-martians seq 125 deny /24 ip prefix-list no-martians seq 130 deny /24 ip prefix-list no-martians seq 135 deny /24 ip prefix-list no-martians seq 140 deny /24 ip prefix-list no-martians seq 145 deny /24 ip prefix-list no-martians seq 150 deny /24 ip prefix-list no-martians seq 155 deny /24 ip prefix-list no-martians seq 200 permit /0 le 32

Introduction to Routing Policy Customer Routes, Outbound

Introduction to Routing Policy Peer and Transit Provider Routes Inbound Not usually filtered – sometimes filtered on prefix length For peers, some set limits on number of prefixes Limits possibility of a peer sending you full routes MEDs are not usually listened to Some significant exceptions, but you have to determine if the MEDs are meaningful

Introduction to Routing Policy Peer and Transit Provider Routes Inbound Local Preference Hierarchy Customer Private Peering Public Peering Transit AS-Path Length Sometimes taken into account Use a route-map or policy-statement to set appropriate communities on INGRESS

Introduction to Routing Policy Peering Preference Matrix The Peering Preference Matrix is designed to properly balance between taking the shortest AS PATH to a destination route, while choosing the best outbound peer based on available capacity (with a bias towards sending more traffic out via private peers vs. public peers). This is an example of something an actual provider has done, and doesn’t necessarily reflect the “right” or best way.

Introduction to Routing Policy Peering Preference Matrix

Introduction to Routing Policy Peering Preference Matrix Example - Cisco ip as-path access-list 1 permit ^[0-9]+$ ip as-path access-list 2 permit ^[0-9]+_[0-9]+$ ip as-path access-list 2 permit ^[0-9]+_[0-9]+_[0-9]+$ ip as-path access-list 2 permit ^[0-9]+_[0-9]+_[0-9]+_[0-9]+$ ip as-path access-list 3 permit ^[0-9]+_[0-9]+_[0-9]+_[0-9](_[0-9]+)+$ ! BEST (PRIVATE) route-map set-best-local-pref deny 10 description Dont send routes that are /30 or longer match ip address prefix-list slash-30-and-more ! route-map set-best-local-pref deny 20 description Dont send routes that are martians or exchange nets match ip address prefix-list martians ! route-map set-best-local-pref permit 30 match as-path 1 set metric 0 set local-preference 140 set community 65000: : :65301 ! route-map set-best-local-pref permit 40 match as-path 2 set metric 0 set local-preference 140 set community 65000: : :65301 ! route-map set-best-local-pref permit 50 match as-path 3 set metric 0 set local-preference 130 set community 65000: : :65301

Introduction to Routing Policy Peer and Transit Provider Routes Outbound Usually filtered on the /24 boundary MEDs are usually sent (ie not zeroed), but are rarely listened to Aggregates are normally announced for your own blocks Some providers announce summary-only aggregates, which cuts down on table size but can cause a loss of routing information For Peers, usually only customer and internal routes are announced.

Introduction to Routing Policy Peer and Transit Provider Routes, Outbound

Introduction to Routing Policy Peering Policy Usually depends greatly on size of networks Some criteria: Number of locations Uniform Announcements Traffic Balances - Hot Potato Routing and backhauling other’s traffic Public vs Private Money, Money, Money

Introduction to Routing Policy Peering Policy Peering criteria and procedures should be documented early Contacts Requirements Appeals procedures BLPAs MD5 Authentication? Don’t pretend that peering is about anything other than business!

Introduction to Routing Policy Peering Policy Being willing to peer doesn’t make you a good person, and being unwilling doesn’t make you a bad person. “Acting like UUNet” hasn’t lost WorldCom any market share. Peering is the Internet’s version of the “selfish gene” – networks peer for mutual advantage ONLY That isn’t a license to be unreasonable – not peering when you should is it’s own punishment, both due to bad PR, and decreased customer satisfaction.

Introduction to Routing Policy Customer Requirements IOS/Junos Versions MD5 Authentication Requirements for customer side filters Demanding Second Announcement – Digex (ICI, ALGX.COM) Authentication of Netblock ownership How? IRR? RIR WHOIS?

Introduction to Routing Policy Community Specifications The “Heart” of a routing policy Allows you to classify routes! Why classification? Filtering Diagnosis Changing attributes

Introduction to Routing Policy Community Specifications There are a sea of routes – communities let you call some routes “tuna” and other routes “salmon”, instead of just “fish” Communities are NOT groups or sets of routes – they are tags placed on routes to enable routing policy to group them. Remember – knowledge is power, and communities are about knowledge.

BGP Communities Communities Defined RFC BGP Communities Attribute RFC An Application of the BGP Community Attribute in Multi-home Routing Community Format 32 bits, normally divided into two parts: Local AS and Value Example: 1234:5678, where 1234 is the local AS

BGP Communities Well known communities No-Export - Routes with this community will not be advertised to other AS's through EBGP. No-Advertise - Routes with this community will not be advertised to other BGP speaking routers No-Export-Subconfed - Routes with this community will not be advertised to other AS's through EBGP, or to other Confederation Sub- AS's through Confederation EBGP.

BGP Communities Proposed Well-known Community No-Peer - Routes with this community are advertised to customer AS's only, not peer AS's draft-huston-nopeer-00 Most large providers already have a community that does this - i.e. 701:666 Who comes up with these? IETF IDR WG There have been others in the past, but they have not been accepted

BGP Communities Why use Communities What do I get out of implementing a routing policy with communities? It's easy to send all routes or to send a small handful. The problem, is in sending a medium number of specific routes, say Communities let you classify and tag routes upon INGRESS to your network, allowing easier filtering on EGRESS. Don’t be the network operator who had to touch his peering routers, every time they add a customer!

BGP Communities Ways of Classifying Routes Geographical Route Type Egress Information Selective Prepending No-Peer Selective Supression Peer’s AS or Exchange Point RBL or other uses Blackhole this route!

BGP Communities Geographical Classification Mark at Ingress! By POP Distinct community per POP or city By Region Many providers split North America into several regions – 6 to 12 By Continent This enables you to send “US Routes” or “European Routes” while maintaining a single AS

BGP Communities Geographical Classification - Example ip community-list expanded us-SFR1 permit 65000:65301 ip community-list expanded us-central permit 65000:65000 ip community-list expanded us-east permit 65000:64700 ip community-list expanded us-northcentral permit 65000:64900 ip community-list expanded us-northeast permit 65000:64600 ip community-list expanded us-southcentral permit 65000:65100 ip community-list expanded us-southeast permit 65000:64800 ip community-list expanded us-west permit 65000:65300

BGP Communities Route Type Classification Customer Routes - Most important!! Customer Backup Routes Usually assigned a lower local preference value Private Peering Routes Public Peering Routes Transit Provider Routes – (I.e. your providers) Internal Routes Don’t forget May take some footwork to get these routes with proper communities!

BGP Communities Selective Prepending Allows customers to prepend their prefixes to only some of your peers, allowing finer grained control of incoming traffic You must decide who you want this enabled towards This can lead to a more complicated peering router config Some folks enable it to all peers, some just to major peers By necessity you will be documenting who you peer with!

BGP Communities Selective Prepending Example format :4701, where you wish to prepend four times towards AS701. There is usually a maximum number of prepends, like 5 or 6 Implementation – typically a separate route-map or policy statement for each peer, with a separate section for each case – no prepend, one prepend, etc. While separate route-maps for each peer take up a lot of room in your configuration, they are all based on the same basic template, and never change.

BGP Communities Selective Prepending

BGP Communities No-Peer Allows customers to send routes to your AS and your customers only – no peers or transits. This allows a customer to “simulate” peering with you. This provides a mechanism for those who with to “pay for peering”, without compromising the integrity of your free peering process. Example format :666, where 1234 is your AS.

BGP Communities No-Peer

BGP Communities Selective Suppression Allows customers to gain finer grained control of incoming traffic by blocking the announcement of some of their prefix to specific peers. Example format :9701, where you wish to suppress announcements towards AS701. Implementation – typically added to the route-maps or route-statements for Selective Prepending, with a “Deny”

BGP Communities Selective Suppression

BGP Communities Configuration Example - Cisco ip community-list expanded digex-0 permit 65000:2548 ip community-list expanded digex-1 permit 65000:12548 ip community-list expanded digex-2 permit 65000:22548 ip community-list expanded digex-3 permit 65000:32548 ip community-list expanded customer-backup permit 65000:145 ip community-list expanded internal-global permit 65000:60100 ip community-list expanded peer-routes permit 65000:60120 ! public ip community-list expanded peer-routes permit 65000:60140 ! private ip community-list expanded internal-routes permit 65000:60100 ip community-list expanded customer-routes permit 65000:60150

BGP Communities Configuration Example - Cisco ! digex PREPEND route-map check-digex-prepend deny 10 description Dont send routes tagged with 65000:666 community to peers match community dont-send-to-peers ! route-map check-digex-prepend deny 20 Description Dont send routes longer then /25 match ip address prefix-list slash-25-or-more ! route-map check-digex-prepend deny 30 description Dont send routes that are considered martians or exchange nets match ip address prefix-list martians ! route-map check-digex-prepend deny 40 description Dont send routes with this community match community digex-0 ! route-map check-digex-prepend permit 50 description Add one instance of to the as-path we send to peer match community digex-1 set as-path prepend ! route-map check-digex-prepend permit 60 description Add two instances of to the as-path we send to peer match community digex-2 set as-path prepend ! route-map check-digex-prepend permit 70 description Add three instances of to the as-path we send to peer match community digex-3 set as-path prepend ! route-map check-digex-prepend permit 80 description Send remaining internal routes to peers unchanged match community internal-routes ! route-map check-digex-prepend permit 90 description Send remaining customer routes to peers unchanged match community customer-routes !

BGP Communities Other Communities What are some other communities you may want to set? Peer AS Community – e.g. if you are AS 65000, and you are receiving routes from AS 10000, you would mark all routes with 65000:10000 at ingress. Exchange Point Communities – Useful if you are backhauling several exchange points back to the same POP – e.g. PacBell, PAIX (SJC), MAE-West

BGP Communities Other Communities RBL eBGP Multihop peering with AS7777, allowing you to blackhole prefixes which may contain spammers I have absolutely no opinion on whether the life should be crushed out of scumbag spammers. None.

Applications Or, why go to all this trouble? Selling Transit Getting Peering Troubleshooting Your Network Enhanced Flexibility

Writing It Up Documenting Your Routing Policy Community System Local Preference Hierarchy List of Atomic Policies Filtering Policies Peering Policy Interaction with BGP-speaking Customers

Questions? Or comments, complaints or suggestions…

Thanks You!