BGP peering question
owen at delong.com
Thu Jul 13 19:27:56 CST 2017
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).
> On Jul 13, 2017, at 11:04 , Baldur Norddahl <baldur.norddahl at 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 the route
> server or they can peer with Hurricane Electric. The later option will get
> the traffic to us almost as efficiently as peering directly with us. In
> this sense we outsourced the peering to them.
> Den 11. jul. 2017 18.42 skrev "craig washington" <
> craigwashington01 at hotmail.com>:
>> 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 someone from
>> an ISP point of view.
More information about the NANOG