Routing Policy Tutorial NANOG 24 - Miami

1. Routing Policy TutorialNANOG 24 - Miami Daniel Golding (dgolding@sockeye.com

2. Routing Policy TutorialAudience 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

3. Routing Policy TutorialAudience 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.

4. Introduction to Routing PolicyWhat 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!

5. Introduction to Routing PolicyWhat 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

6. Introduction to Routing PolicyWhy 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?

7. Introduction to Routing PolicyElements of a routing policy • Written documentation – policy document • Handle different types of routes, differently • Customer Inbound • Customer Outbound • Transit/Peer Inbound • Transit/Peer Outbound

8. Introduction to Routing PolicyCustomer 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

9. Introduction to Routing PolicyCustomer 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

10. Introduction to Routing PolicyCustomer 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

11. Introduction to Routing PolicyCustomer 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.

12. Introduction to Routing PolicyCustomer 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

13. Introduction to Routing PolicyCustomer 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.0.0.0/0 ip prefix-list no-martians seq 10 deny 10.0.0.0/8 le 32 ip prefix-list no-martians seq 15 deny 127.0.0.0/8 le 32 ip prefix-list no-martians seq 20 deny 128.0.0.0/16 le 32 ip prefix-list no-martians seq 25 deny 172.16.0.0/12 le 32 ip prefix-list no-martians seq 30 deny 191.255.0.0/16 le 32 ip prefix-list no-martians seq 35 deny 192.0.0.0/24 le 32 ip prefix-list no-martians seq 40 deny 192.0.2.0/24 le 32 ip prefix-list no-martians seq 45 deny 192.168.0.0/16 le 32 ip prefix-list no-martians seq 50 deny 224.0.0.0/11 le 32 ip prefix-list no-martians seq 55 deny 223.255.255.0/24 le 32 ip prefix-list no-martians seq 60 deny 240.0.0.0/4 le 32 ip prefix-list no-martians seq 105 deny 192.41.177.0/24 ip prefix-list no-martians seq 110 deny 198.32.128.0/24 ip prefix-list no-martians seq 115 deny 198.32.136.0/24 ip prefix-list no-martians seq 120 deny 198.32.139.0/24 ip prefix-list no-martians seq 125 deny 198.32.176.0/24 ip prefix-list no-martians seq 130 deny 198.32.184.0/24 ip prefix-list no-martians seq 135 deny 198.32.186.0/24 ip prefix-list no-martians seq 140 deny 198.32.187.0/24 ip prefix-list no-martians seq 145 deny 198.32.200.0/24 ip prefix-list no-martians seq 150 deny 206.220.243.0/24 ip prefix-list no-martians seq 155 deny 198.32.177.0/24 ip prefix-list no-martians seq 200 permit 0.0.0.0/0 le 32

14. Introduction to Routing PolicyCustomer Routes, Outbound

15. Introduction to Routing PolicyPeer 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

16. Introduction to Routing PolicyPeer 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

17. Introduction to Routing PolicyPeering 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.

18. Introduction to Routing PolicyPeering Preference Matrix

19. Introduction to Routing PolicyPeering 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:60140 65000:65300 65000:65301 ! route-map set-best-local-pref permit 40 match as-path 2 set metric 0 set local-preference 140 set community 65000:60140 65000:65300 65000:65301 ! route-map set-best-local-pref permit 50 match as-path 3 set metric 0 set local-preference 130 set community 65000:60140 65000:65300 65000:65301

20. Introduction to Routing PolicyPeer 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.

21. Introduction to Routing PolicyPeer and Transit Provider Routes, Outbound

22. Introduction to Routing PolicyPeering 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

23. Introduction to Routing PolicyPeering 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!

24. Introduction to Routing PolicyPeering 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.

25. Introduction to Routing PolicyCustomer 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?

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

27. Introduction to Routing PolicyCommunity 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.

28. BGP CommunitiesCommunities Defined • RFC 1997 - BGP Communities Attribute • RFC 1998 - 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

29. BGP CommunitiesWell 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.

30. BGP CommunitiesProposed 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

31. BGP CommunitiesWhy 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 1000. • 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!

32. BGP CommunitiesWays 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!

33. BGP CommunitiesGeographical 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

34. BGP CommunitiesGeographical 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

35. BGP CommunitiesRoute 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!

36. BGP CommunitiesSelective 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!

37. BGP CommunitiesSelective Prepending • Example format - 1234: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.

38. BGP CommunitiesSelective Prepending

39. BGP CommunitiesNo-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 - 1234:666, where 1234 is your AS.

40. BGP CommunitiesNo-Peer

41. BGP CommunitiesSelective 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 - 1234: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”

42. BGP CommunitiesSelective Suppression

43. BGP CommunitiesConfiguration 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

44. BGP CommunitiesConfiguration 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 65000 to the as-path we send to peer match community digex-1 set as-path prepend 65000 ! route-map check-digex-prepend permit 60 description Add two instances of 65000 to the as-path we send to peer match community digex-2 set as-path prepend 65000 65000 ! route-map check-digex-prepend permit 70 description Add three instances of 65000 to the as-path we send to peer match community digex-3 set as-path prepend 65000 65000 65000 ! 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 !

45. BGP CommunitiesOther 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

46. BGP CommunitiesOther 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. • http://mail-abuse.org/rbl/usage.html#BGP

47. ApplicationsOr, why go to all this trouble? • Selling Transit • Getting Peering • Troubleshooting Your Network • Enhanced Flexibility

48. Writing It UpDocumenting Your Routing Policy • Community System • Local Preference Hierarchy • List of Atomic Policies • Filtering Policies • Peering Policy • Interaction with BGP-speaking Customers

49. Questions?Or comments, complaints or suggestions…

50. Thanks You!