Peering policies and BGP configuration

Peering policies and BGP configuration Thomas Kernen tkernen@deckpoint.ch

Definitions Peering is the business relationship whereby ISPs reciprocally provide connectivity to each others transit customers. Transit is the business relationship whereby one ISP provides (usually sells) access to all destinations in its routing table.

A peering policy Guideline that should be defined as a whole by the corporate running the AS under which all legal, business and technical aspects have to be taken into consideration to create a homogenous and managable network for itself and its customers.

A sample policy (1) Peer must provide connectivity in at least the 6 main cities in the country Peer must provide at least 2Mbps into the peering point and upgrade when required to maintain a good service level Peer should announce at least n*/19

A sample policy (2) Neither party shall be liable to the other for any loss or damage arising from: any failure in or breakdown of any facilities or services, whatsoever the cause and however long it shall last. any interruption of service, whatsoever the cause and however long it shall last. The parties acknowledge that this Peering Agreement is not intended to be, nor is, legally binding.

A sample policy (3) Not to peer with customers of a customer Register all routes in the related routing databases Permit LSR (Loose Source Routing) at least at the border for diagnostic purposes. Announce the same routing policy at all interconnection points Peer must provide NOC information such as email addresses, phone numbers, and 24x7 coverage.

A sample policy (4) Peer must agree to actively cooperate in chasing security violations, denial of service attacks, and similar incidents. Peer must not abuse the peering relationship by doing any of the following non exhaustive list: pointing default, resetting next hop, selling or giving next hop to others, sending prefixes longer than /24, and so forth.

Swiss SP with a policy Only 2 were located on the web: IP-Plus (http://www.ip-plus.net/technical/peering-en.html) Switch (http://www.switch.ch/lan/peering_policy.html)

Why peer? Lower transit costs Lower latency Better control over traffic flows Corporate image Part of a business transaction (acquisition, large customer requirement)

Why not peer? Lack of know-how (technical, legal, etc…) Traffic engineering (asymetric routing) Costs to setup, manage and maintain Potential customer Lack of SLAs

With whom to peer? Top traffic flows Content providers (media, services) Inter-AS VPN (large customer requirement) Open peering policy peers

Stage I: Identification of potential peer Traffic engineering Data collection Analysis

Stage II: Contact and Qualification

Contact potential peer peering@<domain.net> IX mailing list IX web site information about members RIPE entry (tech-c, admin-c, remarks) Informal meeting at an engineering forum (NANOG, RIPE, SwiNOG)

Negotiations NDA (if required) Peering requirements for each party and time for contacted party to perform in-house analysis. Bilateral peering agreement (if required).

Stage III: Implementation

Peering Methodology Interconnection locations Optimal traffic exchange behavior Direct, shared media or a mixture of both Costs related to interconnection (who pays what?)

BGP peer setup Routing database updates (RIPE, RADB) Building filters for annoucements Setting up BGP sessions Checking routes

Routing database updates Why keep the databases updated? Aut-num, AS-Macro and route objects Check for outdated data across all databases

Building filters Filter your route announcements. Rtconfig, Confgen and other automated tools to build inbound/outbound filters. Deny bogus networks (RFC 1918 + DSUA) http://www.ietf.org/internet-drafts/draft-manning-dsua- 03.txt Deny your own and your customer networks in your inbound filters.

BGP session Peer-group is useful and saves resources on the router. Route-maps are flexible Access lists or prefix lists (don’t forget to filter inbound and outbound) Use of communities for tagging entry points into your network, also useful for debugging. MEDs for better route annoucements depending on how you allocated your blocks.

IX Interface setup Don’t forget to do the following: No proxy-arp No ip redirects No ip directed-broadcast

Check route annoucements Traceroute –g if LSRR is supported http://www.traceroute.org/ to view your routing announcements from other parts of the Internet (looking glass, traceroute).

Hot vs cold potato routing Hot potato: ISP carries traffic to the closest exit to the peer network and peer handles the transport. Cold potato: ISP carries traffic as far as possible within his own network before handing it off to another network.

Warm potato routing Depends on peer backbone. (quality, size) Anyone using MEDs for routing preferences? Try to avoid asymetric routing with your direct peers. Communicate your intentions with your peer so that you design a good peering relationship!!!

Final note Each part of the peering process and the related decisions are of different importance from one Service Provider to another.

References Bill Norton's Peering decision tree Geoff Huston's ISP Survival Guide LINX sample peering agreement: http://www.linx.net/joininfo/peering-template/agreement-v4.html Multiple Tier-1, Tier-2 peering agreements

Peering policies and BGP configuration