Routing Policy Tutorial NANOG 24 - Miami

Routing Policy Tutorial NANOG 24 - Miami

Daniel Golding([email protected]

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

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.

Introduction to Routing PolicyWhat is a Routing Policy?

What it isn’t – Route mapsPeering policyFilter PolicyStandard router configurations

But those can be aspects of routing policy!

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 providersSelection and modification of routes you send to peers, customers and upstream providers Methodology of identifying routes within your own AS

Introduction to Routing PolicyWhy is a strong routing policy necessary?

ScalabilityEnables ease of scaling to large numbers of peers and transit customers

TroubleshootingEnables identification of where routes are entering your network

Customer FeaturesMany providers are now implementing rich community strings, which are a big plus for clueful customersCW recently did this. Others?

Introduction to Routing PolicyElements of a routing policy

Written documentation – policy documentHandle different types of routes, differently

Customer InboundCustomer OutboundTransit/Peer InboundTransit/Peer Outbound

Introduction to Routing PolicyCustomer Routes, Inbound

Accept by Prefix or by AS?AS-Path lists are easierPrefix filtering is highly recommended

Maximum Prefix Size /24 is generally accepted on most networksReasons to accept smaller announcementsJust because you can accept /24s doesn’t mean anyone will listen to them – especially in legacy B space


Trip-points for large numbers of prefixesSafety Net! Very Important!Manual element, but can prevent disasters – engineers are human!

IRR RegistrationAutogeneration 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 toApplication is customers with multiple sites

Use a route-map or policy-statement to set appropriate communities on INGRESS


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 toApplication is customers with multiple sites


Introduction to Routing PolicyCustomer Routes, Outbound

What kind of routes to send?Full RoutesPartial RoutesDefault 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.


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 PolicyCustomer Routes, Outbound – Martians Example

ip prefix-list no-martians description no-martians-or-exchange-networks filterip prefix-list no-martians seq 5 deny 0.0.0.0/0ip prefix-list no-martians seq 10 deny 10.0.0.0/8 le 32ip prefix-list no-martians seq 15 deny 127.0.0.0/8 le 32ip prefix-list no-martians seq 20 deny 128.0.0.0/16 le 32ip prefix-list no-martians seq 25 deny 172.16.0.0/12 le 32ip prefix-list no-martians seq 30 deny 191.255.0.0/16 le 32ip prefix-list no-martians seq 35 deny 192.0.0.0/24 le 32ip prefix-list no-martians seq 40 deny 192.0.2.0/24 le 32ip prefix-list no-martians seq 45 deny 192.168.0.0/16 le 32ip prefix-list no-martians seq 50 deny 224.0.0.0/11 le 32ip prefix-list no-martians seq 55 deny 223.255.255.0/24 le 32ip prefix-list no-martians seq 60 deny 240.0.0.0/4 le 32ip prefix-list no-martians seq 105 deny 192.41.177.0/24ip prefix-list no-martians seq 110 deny 198.32.128.0/24ip prefix-list no-martians seq 115 deny 198.32.136.0/24ip prefix-list no-martians seq 120 deny 198.32.139.0/24ip prefix-list no-martians seq 125 deny 198.32.176.0/24ip prefix-list no-martians seq 130 deny 198.32.184.0/24ip prefix-list no-martians seq 135 deny 198.32.186.0/24ip prefix-list no-martians seq 140 deny 198.32.187.0/24ip prefix-list no-martians seq 145 deny 198.32.200.0/24ip prefix-list no-martians seq 150 deny 206.220.243.0/24ip prefix-list no-martians seq 155 deny 198.32.177.0/24ip prefix-list no-martians seq 200 permit 0.0.0.0/0 le 32


Match Community Internal RoutesMatch Prefixes /24 or less

SendRoutes

Match Community Customer-RoutesMatch Prefixes /24 or less

Deny Martians

Deny Exchange Networks

Match Community PeersMatch Prefixes /24 or less

Match Community TransitsMatch Prefixes /24 or less

Introduction to Routing PolicyPeer and Transit Provider Routes Inbound

Not usually filtered – sometimes filtered on prefix lengthFor peers, some set limits on number of prefixes

Limits possibility of a peer sending you full routes

MEDs are not usually listened toSome significant exceptions, but you have to determine if the MEDs are meaningful

Introduction to Routing PolicyPeer and Transit Provider Routes Inbound

Local Preference HierarchyCustomerPrivate PeeringPublic PeeringTransitAS-Path Length Sometimes taken into account


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.

Introduction to Routing PolicyPeering Preference Matrix

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

!


match as-path 2

set metric 0


set community 65000:60140 65000:65300 65000:65301

!


match as-path 3

set metric 0


set community 65000:60140 65000:65300 65000:65301

Introduction to Routing PolicyPeer and Transit Provider Routes Outbound

Usually filtered on the /24 boundaryMEDs are usually sent (ie not zeroed), but are rarely listened toAggregates 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 PolicyPeer and Transit Provider Routes, Outbound


SendRoutes


Deny Martians


Introduction to Routing PolicyPeering Policy

Usually depends greatly on size of networksSome criteria:

Number of locationsUniform AnnouncementsTraffic Balances - Hot Potato Routing and backhauling other’s trafficPublic vs PrivateMoney, Money, Money


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!


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 ONLYThat 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 PolicyCustomer Requirements

IOS/Junos Versions

MD5 Authentication

Requirements for customer side filters

Demanding Second Announcement – Digex (ICI, ALGX.COM)

Authentication of Netblock ownershipHow? IRR? RIR WHOIS?

Introduction to Routing PolicyCommunity Specifications

The “Heart” of a routing policyAllows you to classify routes!

Why classification?Filtering

Diagnosis

Changing attributes

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.

BGP CommunitiesCommunities Defined

RFC 1997 - BGP Communities AttributeRFC 1998 - An Application of the BGP Community Attribute in Multi-home Routing Community Format

32 bits, normally divided into two parts: Local AS and ValueExample: 1234:5678, where 1234 is the local AS

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.

BGP CommunitiesProposed Well-known Community

No-Peer - Routes with this community are advertised to customer AS's only, not peer AS'sdraft-huston-nopeer-00Most large providers already have a community that does this - i.e. 701:666

Who comes up with these?IETF IDR WGThere have been others in the past, but they have not been accepted

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!

BGP CommunitiesWays of Classifying Routes

GeographicalRoute TypeEgress Information

Selective PrependingNo-PeerSelective Supression

Peer’s AS or Exchange PointRBL or other uses

Blackhole this route!

BGP CommunitiesGeographical Classification

Mark at Ingress!By POP

Distinct community per POP or city

By RegionMany providers split North America into several regions – 6 to 12

By ContinentThis enables you to send “US Routes” or “European Routes” while maintaining a single AS

BGP CommunitiesGeographical Classification - Example

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

BGP CommunitiesRoute Type Classification

Customer Routes - Most important!!Customer Backup Routes

Usually assigned a lower local preference value

Private Peering RoutesPublic Peering RoutesTransit Provider Routes – (I.e. your providers)Internal Routes

Don’t forget May take some footwork to get these routes with proper communities!

BGP CommunitiesSelective Prepending

Allows customers to prepend their prefixes to only some of your peers, allowing finer grained control of incoming trafficYou must decide who you want this enabled towards

This can lead to a more complicated peering router configSome folks enable it to all peers, some just to major peersBy necessity you will be documenting who you peer with!


Example format - 1234:4701, where you wish to prepend four times towards AS701. There is usually a maximum number of prepends, like 5 or 6Implementation – 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.



SendRoutes


Deny Martians



Match Community Prepend One


Match Community Prepend Two

PrependOne

PrependTwo

SendRoutes

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.

BGP CommunitiesNo-Peer


SendRoutes


Deny Martians




Match Community No-Peer

PrependOne

Deny

SendRoutes

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”

BGP CommunitiesSelective Suppression


SendRoutes


Deny Martians




Match Community No-Peer

PrependOne

Deny

SendRoutes

Match Community Customer-RoutesMatch Community Suppress Deny

BGP CommunitiesConfiguration Example - Cisco

ip community-list expanded digex-0 permit 65000:2548




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 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

!


Description Dont send routes longer then /25

match ip address prefix-list slash-25-or-more

!


description Dont send routes that are considered martians or exchange nets

match ip address prefix-list martians

!


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


set as-path prepend 65000

!


description Add two instances of 65000 to the as-path we send to peer


set as-path prepend 65000 65000

!


description Add three instances of 65000 to the as-path we send to peer


set as-path prepend 65000 65000 65000

!


description Send remaining internal routes to peers unchanged

match community internal-routes

!


description Send remaining customer routes to peers unchanged

match community customer-routes

!

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

BGP CommunitiesOther Communities

RBLeBGP Multihop peering with AS7777, allowing you to blackhole prefixes which may contain spammersI have absolutely no opinion on whether the life should be crushed out of scumbag spammers. None.http://mail-abuse.org/rbl/usage.html#BGP

ApplicationsOr, why go to all this trouble?

Selling TransitGetting PeeringTroubleshooting Your NetworkEnhanced Flexibility

Writing It UpDocumenting Your Routing Policy

Community SystemLocal Preference HierarchyList of Atomic PoliciesFiltering PoliciesPeering PolicyInteraction with BGP-speaking Customers

Questions?Or comments, complaints or suggestions…

Thanks You!

Documents

Routing Policy Tutorial NANOG 24 - Miami