nanog mailing list archives
Re: BGP peering question
From: H I Baysal <hibaysal () gmail com>
Date: Fri, 14 Jul 2017 16:46:12 +0200
Hi, I'm not sure if this is mentioned already but here goes, You need to understand the difference between peering and a direct interconnect. with an interconnect you have to think about is the traffic enough to "dedicate" a port for that connection on your edge. ( cost of port vs cost if you would send the traffic over an IX or transit) peering it does not matter that much, as in someone mentioned to peer as much as you can, this will give you more control over announcements per peer and the announcement to the IX. for example you could not advertise the prefixes that attract alot of traffic through the IX RR but to individual members. basically it gives you more control over your announcement to different isps/network over an IX. however you do have to think about the load on your router on the edge, the more sessions the more "power" it needs and more processing when things go wrong or flap. I hope i didn't give redundant information and it helps. good luck!!! Regards, Halil 2017-07-13 21:27 GMT+02:00 Owen DeLong <owen () delong com>:
If you develop a well tuned process for creating BGP sessions and even a moderate system for monitoring not the individual sessions, but meaningful traffic events on your network, then, maintaining a large number of peers and a promiscuous peering policy is not such a daunting process. As a general rule, promiscuous peering improves efficiency and keeps your options for traffic delivery open. Restrictive peering generally has the opposite effect. Route servers are a lazy form of promiscuous peering, with an attendant fate sharing which can produce suboptimal results. YMMV. I’ve worked for several networks of various sizes and observed the industry in general for many years. As a general rule, a restrictive peering policy is a great way to lose momentum in the market and convert a major ISP into a bit-player (e.g. SPRINT), whereas promiscuous peering can be a key component in moving a trivial ISP into a major player in the industry (e.g. HE). Again, YMMV. OwenOn Jul 13, 2017, at 11:04 , Baldur Norddahl <baldur.norddahl () gmail com>wrote:Speaking as a small ISP with 10 to 20 Gbps peak traffic. We are heavy inbound as a pure eyeball network. We use the route servers. We only maintain direct BGP sessions with a few large peers. Think Google, Netflix, Akamai etc. The reason for this is simply administrative overhead. Every BGP session has to be configured and monitored. We know that it will not move a large percentage of our traffic. We simply do not have the ressources currently when the gain is so little. Anyone who wants to pass traffic efficiently to us can either use therouteserver or they can peer with Hurricane Electric. The later option willgetthe traffic to us almost as efficiently as peering directly with us. In this sense we outsourced the peering to them. Regards Baldur Den 11. jul. 2017 18.42 skrev "craig washington" < craigwashington01 () hotmail com>:Hello, Newbie question, what criteria do you look for when you decide that you want to peer with someone or if you will accept peering with someonefroman ISP point of view. Thanks.
-- Met vriendelijke groet / kind regards, Halil Ibrahim Baysal T: +31 (0)6 20 14 20 79 E: hibaysal () gmail com
Current thread:
- Re: BGP peering question, (continued)
- Re: BGP peering question Bob Evans (Jul 11)
- Re: BGP peering question Ethan E. Dee (Jul 11)
- Re: BGP peering question Patrick W. Gilmore (Jul 11)
- Re: BGP peering question William Herrin (Jul 11)
- Re: BGP peering question Bob Evans (Jul 11)
- Re: BGP peering question craig washington (Jul 14)
- Re: BGP peering question Owen DeLong (Jul 13)
- Re: BGP peering question H I Baysal (Jul 14)