Routing Policy Tutorial NANOG 24 Miami

1
Routing Policy Tutorial NANOG 24 - Miami
Daniel Golding (dgolding_at_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 arent you here?
• To learn what a route map is thats 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 isnt
• 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 networks 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 doesnt 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 dont 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 dont 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.
• Dont 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

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 doesnt 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 6500060140 6500065300
6500065301 ! route-map set-best-local-pref
permit 40 match as-path 2 set metric 0 set
local-preference 140 set community 6500060140
6500065300 6500065301 ! route-map
set-best-local-pref permit 50 match as-path 3
set metric 0 set local-preference 130 set
community 6500060140 6500065300 6500065301
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 others 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?
• Dont pretend that peering is about anything
  other than business!

24
Introduction to Routing PolicyPeering Policy

• Being willing to peer doesnt make you a good
  person, and being unwilling doesnt make you a
  bad person. Acting like UUNet hasnt lost
  WorldCom any market share.
• Peering is the Internets version of the selfish
  gene networks peer for mutual advantage ONLY
• That isnt a license to be unreasonable not
  peering when you should is its 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 12345678, 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. 701666
• 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.
• Dont 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
• Peers 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
6500065301 ip community-list expanded
us-central permit 6500065000 ip community-list
expanded us-east permit 6500064700 ip
community-list expanded us-northcentral permit
6500064900 ip community-list expanded
us-northeast permit 6500064600 ip community-list
expanded us-southcentral permit 6500065100 ip
community-list expanded us-southeast permit
6500064800 ip community-list expanded us-west
permit 6500065300
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
• Dont 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 - 12344701, 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 - 1234666, 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 - 12349701, 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
650002548 ip community-list expanded digex-1
permit 6500012548 ip community-list expanded
digex-2 permit 6500022548 ip community-list
expanded digex-3 permit 6500032548 ip
community-list expanded customer-backup permit
65000145 ip community-list expanded
internal-global permit 6500060100 ip
community-list expanded peer-routes permit
6500060120 ! public ip community-list expanded
peer-routes permit 6500060140 ! private ip
community-list expanded internal-routes permit
6500060100 ip community-list expanded
customer-routes permit 6500060150
44
BGP CommunitiesConfiguration Example - Cisco
! digex PREPEND route-map
check-digex-prepend deny 10 description Dont
send routes tagged with 65000666 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 6500010000 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.htmlBGP

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!