Transcript Peering policies and BGP configuration

Peering policies and
BGP configuration
Thomas Kernen
[email protected]
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-dsua03.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