Setting sensible max-prefix limits
As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit. I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers? Do you negotiate/exchange sensible values whenever you establish a new session? Do you rely on PeeringDB (if available)? Do you apply default values to everyone except the big fishes? Apart from your peers, do you also apply a limit to your transit sessions? Best regards, Lars
On 18 Aug 2021, at 10:33, Lars Prehn <lprehn@mpi-inf.mpg.de <mailto:lprehn@mpi-inf.mpg.de>> wrote:
As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit.
I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers? Do you negotiate/exchange sensible values whenever you establish a new session? Do you rely on PeeringDB (if available)? Do you apply default values to everyone except the big fishes?
Apart from your peers, do you also apply a limit to your transit sessions?
We always use PeeringDB data and refuse to peer with networks not in PeeingDB ( I think there are only 2 exceptions ) Automation keeps the max_prefix numbers up to date. Our transits we use data from the weekly routing table reports and allow some expansion room. So far this works for us Regards Steve
Okay, so some automated PeeringDB-based approach seems to be the preferred road. ~30% and ~40% of IPv4 and IPv6 PeeringDB prefix count recommendations are 0. How do you treat those cases? Does it also boils down to a simple "we don't peer with them" ? Best regards, Lars On 18.08.21 12:31, Denis Fondras wrote:
Le Wed, Aug 18, 2021 at 10:46:34AM +0100, Steve Lalonde a écrit :
We always use PeeringDB data and refuse to peer with networks not in PeeingDB
That !
----- On Aug 18, 2021, at 2:46 AM, Steve Lalonde steve@enta.net wrote: Hi,
We always use PeeringDB data and refuse to peer with networks not in PeeingDB
You are aware that PeerinDB refuses to register certain networks, right? It is most certainly not a single source of truth. Thanks, Sabri
On Wed, 18 Aug 2021, 21:37 Sabri Berisha, <sabri@cluecentral.net> wrote:
----- On Aug 18, 2021, at 2:46 AM, Steve Lalonde steve@enta.net wrote:
Hi,
We always use PeeringDB data and refuse to peer with networks not in PeeingDB
You are aware that PeerinDB refuses to register certain networks, right? It is most certainly not a single source of truth.
Would you care to expand on this? Matthew Walster
On Aug 18, 2021, at 5:00 PM, Matthew Walster <matthew@walster.org> wrote:
On Wed, 18 Aug 2021, 21:37 Sabri Berisha, <sabri@cluecentral.net> wrote: ----- On Aug 18, 2021, at 2:46 AM, Steve Lalonde steve@enta.net wrote:
Hi,
We always use PeeringDB data and refuse to peer with networks not in PeeingDB
You are aware that PeerinDB refuses to register certain networks, right? It is most certainly not a single source of truth.
Would you care to expand on this?
I am extremely interested in hearing about this as well. Specific examples would be useful. -- TTFN, patrick
----- On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patrick@ianai.net wrote: Hi,
On Aug 18, 2021, at 5:00 PM, Matthew Walster <matthew@walster.org> wrote:
On Wed, 18 Aug 2021, 21:37 Sabri Berisha, <sabri@cluecentral.net> wrote: ----- On Aug 18, 2021, at 2:46 AM, Steve Lalonde steve@enta.net wrote:
Hi,
We always use PeeringDB data and refuse to peer with networks not in PeeingDB
You are aware that PeerinDB refuses to register certain networks, right? It is most certainly not a single source of truth.
Would you care to expand on this?
I am extremely interested in hearing about this as well.
Specific examples would be useful.
Of course! Including headers to show authenticity. I was very amused by the explanation of the "chicken and egg" problem. Who's creating that? The networks who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't recognize ASNs that are not peering with anyone because nobody wants to peer with them because they are not registered in peeringdb because nobody wants to peer with them? You get the idea. Thanks, Sabri AS31064 Return-Path: grizz@peeringdb.com Received: from mail.cluecentral.net (LHLO mail.cluecentral.net) (195.16.84.32) by mail.cluecentral.net with LMTP; Fri, 9 Oct 2015 01:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cluecentral.net (Postfix) with ESMTP id 4CED64001EF for <sabri@cluecentral.net>; Fri, 9 Oct 2015 01:47:22 -0700 (PDT) Received: from mail.cluecentral.net ([127.0.0.1]) by localhost (mail.cluecentral.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TLvVaNdjHGA for <sabri@cluecentral.net>; Fri, 9 Oct 2015 01:47:21 -0700 (PDT) Received: from ubersmith.peeringdb.com (ubersmith.peeringdb.com [107.6.74.106]) by mail.cluecentral.net (Postfix) with ESMTP id C5B164001A9 for <sabri@cluecentral.net>; Fri, 9 Oct 2015 01:47:01 -0700 (PDT) Received: by ubersmith.peeringdb.com (Postfix, from userid 48) id D8AF377C1A; Fri, 9 Oct 2015 04:46:29 -0400 (EDT) Date: Fri, 9 Oct 2015 04:46:29 -0400 To: Sabri Berisha <sabri@cluecentral.net> From: support@peeringdb.com Reply-To: support@peeringdb.com Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New Company - Cluecentral Inc) Message-ID: <1bac170d74e5d3702d3a28b237c87260@ubersmith.peeringdb.com> Dear PeeringDB user, Registering with peeringDB and peering negotiations are sort of egg and chicken problem. We only want to have networks registered that already do have settlement free peering. After some basic checks it looks like you are only buying transit from 6939/Hurricane Electric, but are not connected to any Internet Exchange (e.g. AMS-IX/NL-ix) yet. Having said this, is it acceptable to you to wait until you have your 1st settlement free peering setup? If you already have existing peering sessions, please provide the following details to support your request for peeringdb access: Your AS number(s) Which IXP / facilities you are peering at Some of your peering partners (again AS numbers / name) Please send your answers to support@peeringdb.com or reply to this ticket. Best regards, PeeringDB admin on Duty PeeringDB Listserv information: PeeringDB Announce: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce PeeringDB Governance: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov PeeringDB Technical: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech PeeringDB User Discuss: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss -- Florian Hibler <fhibler@peeringdb.com> PeeringDB Administrator
Of course! Including headers to show authenticity. I was very amused by the explanation of the "chicken and egg" problem. Who's creating that? The networks who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't recognize ASNs that are not peering with anyone because nobody wants to peer with them because they are not registered in peeringdb because nobody wants to peer with them? You get the idea.
First, most networks do not require a PDB record to peer. (Silly of them, I know, but still true.) Second, you do not need to have a PDB record to get a link to an IXP. Even membership in a free IXP is sufficient for an account in PDB, as Grizz points out below. Third, if you have an agreement, even just an email, saying a network will peer with you once you have a record, that may well suffice. Have you asked any network to peer? Private peering (because you are not on an IXP) is usually reserved for networks with more than a modicum of traffic. If your network is large enough to qualify for private peering, I have trouble believing you cannot get another network to agree to peer so you can get a record. I guess you are right, the _Peering_DB does not register “certain” networks. Those networks would be ones that do not peer. Which seems pretty obvious to me - it is literally in the name. -- TTFN, patrick
On Aug 18, 2021, at 5:50 PM, Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patrick@ianai.net <mailto:patrick@ianai.net> wrote:
Hi,
On Aug 18, 2021, at 5:00 PM, Matthew Walster <matthew@walster.org> wrote:
On Wed, 18 Aug 2021, 21:37 Sabri Berisha, <sabri@cluecentral.net> wrote: ----- On Aug 18, 2021, at 2:46 AM, Steve Lalonde steve@enta.net wrote:
Hi,
We always use PeeringDB data and refuse to peer with networks not in PeeingDB
You are aware that PeerinDB refuses to register certain networks, right? It is most certainly not a single source of truth.
Would you care to expand on this?
I am extremely interested in hearing about this as well.
Specific examples would be useful.
Of course! Including headers to show authenticity. I was very amused by the explanation of the "chicken and egg" problem. Who's creating that? The networks who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't recognize ASNs that are not peering with anyone because nobody wants to peer with them because they are not registered in peeringdb because nobody wants to peer with them? You get the idea.
Thanks,
Sabri AS31064
Return-Path: grizz@peeringdb.com <mailto:grizz@peeringdb.com> Received: from mail.cluecentral.net <http://mail.cluecentral.net/> (LHLO mail.cluecentral.net <http://mail.cluecentral.net/>) (195.16.84.32) by mail.cluecentral.net <http://mail.cluecentral.net/> with LMTP; Fri, 9 Oct 2015 01:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cluecentral.net <http://mail.cluecentral.net/> (Postfix) with ESMTP id 4CED64001EF for <sabri@cluecentral.net <mailto:sabri@cluecentral.net>>; Fri, 9 Oct 2015 01:47:22 -0700 (PDT) Received: from mail.cluecentral.net <http://mail.cluecentral.net/> ([127.0.0.1]) by localhost (mail.cluecentral.net <http://mail.cluecentral.net/> [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TLvVaNdjHGA for <sabri@cluecentral.net <mailto:sabri@cluecentral.net>>; Fri, 9 Oct 2015 01:47:21 -0700 (PDT) Received: from ubersmith.peeringdb.com <http://ubersmith.peeringdb.com/> (ubersmith.peeringdb.com <http://ubersmith.peeringdb.com/> [107.6.74.106]) by mail.cluecentral.net <http://mail.cluecentral.net/> (Postfix) with ESMTP id C5B164001A9 for <sabri@cluecentral.net <mailto:sabri@cluecentral.net>>; Fri, 9 Oct 2015 01:47:01 -0700 (PDT) Received: by ubersmith.peeringdb.com <http://ubersmith.peeringdb.com/> (Postfix, from userid 48) id D8AF377C1A; Fri, 9 Oct 2015 04:46:29 -0400 (EDT) Date: Fri, 9 Oct 2015 04:46:29 -0400 To: Sabri Berisha <sabri@cluecentral.net <mailto:sabri@cluecentral.net>> From: support@peeringdb.com <mailto:support@peeringdb.com> Reply-To: support@peeringdb.com <mailto:support@peeringdb.com> Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New Company - Cluecentral Inc) Message-ID: <1bac170d74e5d3702d3a28b237c87260@ubersmith.peeringdb.com <mailto:1bac170d74e5d3702d3a28b237c87260@ubersmith.peeringdb.com>>
Dear PeeringDB user,
Registering with peeringDB and peering negotiations are sort of egg and chicken problem. We only want to have networks registered that already do have settlement free peering.
After some basic checks it looks like you are only buying transit from 6939/Hurricane Electric, but are not connected to any Internet Exchange (e.g. AMS-IX/NL-ix) yet.
Having said this, is it acceptable to you to wait until you have your 1st settlement free peering setup? If you already have existing peering sessions, please provide the following details to support your request for peeringdb access:
Your AS number(s) Which IXP / facilities you are peering at Some of your peering partners (again AS numbers / name)
Please send your answers to support@peeringdb.com <mailto:support@peeringdb.com> or reply to this ticket.
Best regards, PeeringDB admin on Duty
PeeringDB Listserv information:
PeeringDB Announce: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce <http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce>
PeeringDB Governance: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov <http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov>
PeeringDB Technical: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech <http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech>
PeeringDB User Discuss: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss <http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss>
-- Florian Hibler <fhibler@peeringdb.com <mailto:fhibler@peeringdb.com>> PeeringDB Administrator
----- On Aug 18, 2021, at 3:02 PM, Patrick W. Gilmore patrick@ianai.net wrote: Hi,
Those networks would be ones that do not peer. Which seems pretty obvious to me - it is literally in the name.
I have an AS, I advertise IP space to the world. I want to be a Good Netizen and register my BGP peers. Your definition of BGP peering is different from mine, at least in this context.
I guess you are right, the _Peering_DB does not register “certain” networks.
Which was my point. I'm glad you agree. My little AS is not allowed to play with the big kids. If you only want to register settlement-free peering, that's totally fine with me. Your database, your rules. But, the fact stays that you can have an AS, advertise your prefixes to the world, and not be permitted to register with peeringdb. Which means it can't be used as a single source of truth. Which would have been a shame because with a little bit of automation it would be feasible to "score" advertisements. That would help determine the likelihood of an advertisement to be erroneous (whether by accident or malice). For example, if I were to register my peers (53356 and 136620) and AS5524 would all of a sudden start to advertise my AS as behind it, you'd be able to flag that. But again, your database, your rules. Thanks, Sabri
* sabri@cluecentral.net (Sabri Berisha) [Thu 19 Aug 2021, 00:55 CEST]:
For example, if I were to register my peers (53356 and 136620) and AS5524 would all of a sudden start to advertise my AS as behind it, you'd be able to flag that.
I'm confused. When did PeeringDB turn into a routing (policy) registry? You should use an IRRdb if you want to write RPSL. -- Niels.
Currently RPKI can only validate origin, not paths. If/when a path validation solution is available, then one easy way to know that network A really means to peer with network B is to publish a path validation that B can use and/or forward A's announcements. Rubens On Wed, Aug 18, 2021 at 7:53 PM Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Aug 18, 2021, at 3:02 PM, Patrick W. Gilmore patrick@ianai.net wrote:
Hi,
Those networks would be ones that do not peer. Which seems pretty obvious to me - it is literally in the name.
I have an AS, I advertise IP space to the world. I want to be a Good Netizen and register my BGP peers. Your definition of BGP peering is different from mine, at least in this context.
I guess you are right, the _Peering_DB does not register “certain” networks.
Which was my point. I'm glad you agree. My little AS is not allowed to play with the big kids.
If you only want to register settlement-free peering, that's totally fine with me. Your database, your rules.
But, the fact stays that you can have an AS, advertise your prefixes to the world, and not be permitted to register with peeringdb. Which means it can't be used as a single source of truth. Which would have been a shame because with a little bit of automation it would be feasible to "score" advertisements. That would help determine the likelihood of an advertisement to be erroneous (whether by accident or malice).
For example, if I were to register my peers (53356 and 136620) and AS5524 would all of a sudden start to advertise my AS as behind it, you'd be able to flag that.
But again, your database, your rules.
Thanks,
Sabri
----- On Aug 18, 2021, at 4:03 PM, Rubens Kuhl rubensk@gmail.com wrote: Hi,
Currently RPKI can only validate origin, not paths. If/when a path validation solution is available, then one easy way to know that network A really means to peer with network B is to publish a path validation that B can use and/or forward A's announcements.
Yes, that would be a relatively easy thing to calculate. Niels has, of course, a fair point when he writes:
When did PeeringDB turn into a routing (policy) registry? You should use an IRRdb if you want to write RPSL.
The difference is, if you are able to use PeeringDB as a single source of truth, it is a lot easier to grab the data you need. But again, their database, their rules. Thanks, Sabri
When did PeeringDB turn into a routing (policy) registry? You should use an IRRdb if you want to write RPSL.
* sabri@cluecentral.net (Sabri Berisha) [Thu 19 Aug 2021, 01:59 CEST]:
The difference is, if you are able to use PeeringDB as a single source of truth, it is a lot easier to grab the data you need.
But again, their database, their rules.
So you were planning to abuse, er, creatively implement their datamodel to declare yourself an IXP and list all your peers as members of said IXP, and then convince the world to build filter lists based on said participant list? Creative, but indeed not what PeeringDB is about. -- Niels.
The difference is, if you are able to use PeeringDB as a single source of truth, it is a lot easier to grab the data you need.
< pushing the analogy to the absurd > great idea! please tell me when i can use peeringdb as the single source of truth for my bank balance? how about i can learn your bank balance? < / > peeringdb has a mission, public exchange point documentation. please don't get creepy. randy
On Thu, 19 Aug 2021 at 02:03, Randy Bush <randy@psg.com> wrote:
The difference is, if you are able to use PeeringDB as a single source of truth, it is a lot easier to grab the data you need.
< pushing the analogy to the absurd >
great idea! please tell me when i can use peeringdb as the single source of truth for my bank balance? how about i can learn your bank balance?
< / >
peeringdb has a mission, public exchange point documentation. please don't get creepy.
Randy, your hyperbole helps no-one. Having been on Sabri's side of your targeting before, I can attest it does little else than create veiled anger. We are all friends here. PeeringDB's mission, as stated on the front page, is: PeeringDB is a freely available, user-maintained, database of networks, and
the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.
The barrier to entry ought to be as low as possible, PeeringDB should facilitate peering, not hinder it. Right now, I believe it is a force for good. Where Sabri believes (based on a 6 year old email) a denial of presence on the platform, it has degraded the utility of PeeringDB by not allowing a network to advertise where it can be peered with -- something that extensively happens between networks in LATAM outside of public IXPs for example, which is why that statement above indicates it also facilitates the interconnection of networks outside of IXPs. Whether that is desirable or not is a topic for another day. Matthew Walster
Sabri Berisha wrote on 19/08/2021 00:57:
----- On Aug 18, 2021, at 4:03 PM, Rubens Kuhlrubensk@gmail.com wrote:
Hi,
Currently RPKI can only validate origin, not paths. If/when a path validation solution is available, then one easy way to know that network A really means to peer with network B is to publish a path validation that B can use and/or forward A's announcements. Yes, that would be a relatively easy thing to calculate.
if this were easy, we'd have solved the problem space years ago. It's complicated because the description mechanism needs to be able to describe the complete set of all inter-as connectivity arrangements written in a language which is simple enough for people to be able to update it easily, which can be parsed by language interpreters relatively easily (allowing toolkits to be written / ), and which is flexible enough to output complex instructions including optimized regexps, routing metrics, etc, on a per-prefix, per-asn, per-interconnection point basis. RPSL attempted these things and probably failed on all three points. There have been some other attempts, but none came up with any usable outputs. Nick
Currently RPKI can only validate origin, not paths.
not exactly you ar speaking of route origin validation RPKI The RPKI is an X.509 based hierarchy [RFC 6481] which is congruent with the internet IP address allocation administration, the IANA, RIRs, ISPs, ... It is just a database, but is the substrate on which the next two mechanisms are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation (ROV) RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data to allow a router to verify that the autonomous system originating an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from AlcaLu, Cisco, Juniper, and possibly others. BGPsec RPKI-based Path Validation, AKA BGPsec, a future technology still being designed [draft-ietf-sidr-bgpsec-overview], uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to cryptographically validate that the autonomous systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. Sorry to drone on, but these three really need to be differentiated.
Hi Patrick, On 08/18, Patrick W. Gilmore wrote:
Of course! Including headers to show authenticity. I was very amused by the explanation of the "chicken and egg" problem. Who's creating that? The networks who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't recognize ASNs that are not peering with anyone because nobody wants to peer with them because they are not registered in peeringdb because nobody wants to peer with them? You get the idea.
First, most networks do not require a PDB record to peer. (Silly of them, I know, but still true.)
Second, you do not need to have a PDB record to get a link to an IXP. Even membership in a free IXP is sufficient for an account in PDB, as Grizz points out below.
Third, if you have an agreement, even just an email, saying a network will peer with you once you have a record, that may well suffice. Have you asked any network to peer? Private peering (because you are not on an IXP) is usually reserved for networks with more than a modicum of traffic. If your network is large enough to qualify for private peering, I have trouble believing you cannot get another network to agree to peer so you can get a record.
I guess you are right, the _Peering_DB does not register “certain” networks. Those networks would be ones that do not peer. Which seems pretty obvious to me - it is literally in the name.
A PDB record for an Internet-connected ASN, listing no IXPs or facilities, but with a note saying approximately "We only use transit, and don't peer" has some utility: it saves prospective peers from finding contacts to ask and sending emails, etc. I'd argue this is in scope for PDB. But perhaps there was additional context to the original decision that I'm missing? Cheers, Ben
I agree with you in the utility of that, but sort of as a side topic... I wonder how many ASes are out there that have any significant volume of traffic/multi-site presences, but are exclusively 100% transit customers, do not have any PNIs at major carrier hotels, and are not members of any IX. What would be a good example of such an AS and how big of a network would it be? Undoubtedly there are some enterprise end user type customers set up like that, but I can't imagine they receive a very large volume of unsolicited peering requests. On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG <nanog@nanog.org> wrote:
Hi Patrick,
On 08/18, Patrick W. Gilmore wrote:
Of course! Including headers to show authenticity. I was very amused by the explanation of the "chicken and egg" problem. Who's creating that? The networks who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't recognize ASNs that are not peering with anyone because nobody wants to peer with them because they are not registered in peeringdb because nobody wants to peer with them? You get the idea.
First, most networks do not require a PDB record to peer. (Silly of them, I know, but still true.)
Second, you do not need to have a PDB record to get a link to an IXP. Even membership in a free IXP is sufficient for an account in PDB, as Grizz points out below.
Third, if you have an agreement, even just an email, saying a network will peer with you once you have a record, that may well suffice. Have you asked any network to peer? Private peering (because you are not on an IXP) is usually reserved for networks with more than a modicum of traffic. If your network is large enough to qualify for private peering, I have trouble believing you cannot get another network to agree to peer so you can get a record.
I guess you are right, the _Peering_DB does not register “certain” networks. Those networks would be ones that do not peer. Which seems pretty obvious to me - it is literally in the name.
A PDB record for an Internet-connected ASN, listing no IXPs or facilities, but with a note saying approximately "We only use transit, and don't peer" has some utility: it saves prospective peers from finding contacts to ask and sending emails, etc.
I'd argue this is in scope for PDB. But perhaps there was additional context to the original decision that I'm missing?
Cheers,
Ben
I have an example locally: BellMTS (ASNs 684, 7122, 4398), the local ILEC. To the best of my knowledge, they only peer with downstream customers (including myself) and their sole upstream, Bell Canada (AS577). Meanwhile that's a ~700k eyeball network (with some hosting, sure), roughly ~400Gbps upstream connectivity, and no public peering whatsoever. In fact, one might describe their peering model as "feudal", where they're subjugate to their corporate overlord (Bell Canada). It's unfortunate, I know there are some smart people working there, but either they don't understand the value of sub-1ms access to root nameservers (*cough* MBIX *cough*), or they're prevented from doing anything about it. [Disclaimer: I'm on the MBIX board. But I also used to work for MTS, and tried to setup the first peering relationship but got shot down for "marketing" reasons, something about "legitimizing the competition". Very monopolistic thinking, IMO.] Meanwhile, MTS still has a PeeringDB record, even though it documents quite nicely the fact that perhaps that record shouldn't exist, or at least doesn't need to. FWIW, their upstream, Bell Canada, is a very different story. And also mostly ~8msec away. -Adam Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Eric Kuhnke <eric.kuhnke@gmail.com> Sent: August 19, 2021 10:32 To: Ben Maddison <benm@workonline.africa>; nanog@nanog.org list <nanog@nanog.org> Subject: Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits] I agree with you in the utility of that, but sort of as a side topic... I wonder how many ASes are out there that have any significant volume of traffic/multi-site presences, but are exclusively 100% transit customers, do not have any PNIs at major carrier hotels, and are not members of any IX. What would be a good example of such an AS and how big of a network would it be? Undoubtedly there are some enterprise end user type customers set up like that, but I can't imagine they receive a very large volume of unsolicited peering requests. On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote: Hi Patrick, On 08/18, Patrick W. Gilmore wrote:
Of course! Including headers to show authenticity. I was very amused by the explanation of the "chicken and egg" problem. Who's creating that? The networks who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't recognize ASNs that are not peering with anyone because nobody wants to peer with them because they are not registered in peeringdb because nobody wants to peer with them? You get the idea.
First, most networks do not require a PDB record to peer. (Silly of them, I know, but still true.)
Second, you do not need to have a PDB record to get a link to an IXP. Even membership in a free IXP is sufficient for an account in PDB, as Grizz points out below.
Third, if you have an agreement, even just an email, saying a network will peer with you once you have a record, that may well suffice. Have you asked any network to peer? Private peering (because you are not on an IXP) is usually reserved for networks with more than a modicum of traffic. If your network is large enough to qualify for private peering, I have trouble believing you cannot get another network to agree to peer so you can get a record.
I guess you are right, the _Peering_DB does not register “certain” networks. Those networks would be ones that do not peer. Which seems pretty obvious to me - it is literally in the name.
A PDB record for an Internet-connected ASN, listing no IXPs or facilities, but with a note saying approximately "We only use transit, and don't peer" has some utility: it saves prospective peers from finding contacts to ask and sending emails, etc. I'd argue this is in scope for PDB. But perhaps there was additional context to the original decision that I'm missing? Cheers, Ben
I don't think that's a valid example at all since clearly the entity to peer with for access to the BellMTS ASes and their customers is AS577. Which definitely does peer and is present at IX points. I am familiar with another entity which has an entire regional ILEC's AS behind it, but where the newly created AS (part of the people who bought the big chunk of ILEC) is present at many IX points and peers quite widely. Was referring more to a theoretical example if somebody were to attempt to build a medium to large sized ISP exclusively as a transit customer of some top-50 CAIDA ASrank size transit providers, and do no peering whatsoever. On Thu, Aug 19, 2021 at 3:05 PM Adam Thompson <athompson@merlin.mb.ca> wrote:
I have an example locally: BellMTS (ASNs 684, 7122, 4398), the local ILEC. To the best of my knowledge, they only peer with downstream customers (including myself) and their sole upstream, Bell Canada (AS577). Meanwhile that's a ~700k eyeball network (with some hosting, sure), roughly ~400Gbps upstream connectivity, and no public peering whatsoever. In fact, one might describe their peering model as "feudal", where they're subjugate to their corporate overlord (Bell Canada). It's unfortunate, I know there are some smart people working there, but either they don't understand the value of sub-1ms access to root nameservers (*cough* MBIX *cough*), or they're prevented from doing anything about it.
[Disclaimer: I'm on the MBIX board. But I also used to work for MTS, and tried to setup the first peering relationship but got shot down for "marketing" reasons, something about "legitimizing the competition". Very monopolistic thinking, IMO.]
Meanwhile, MTS still has a PeeringDB record, even though it documents quite nicely the fact that perhaps that record shouldn't exist, or at least doesn't need to.
FWIW, their upstream, Bell Canada, is a very different story. And also mostly ~8msec away.
-Adam
*Adam Thompson* Consultant, Infrastructure Services [image: 1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson@merlin.mb.ca www.merlin.mb.ca
------------------------------ *From:* NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Eric Kuhnke <eric.kuhnke@gmail.com> *Sent:* August 19, 2021 10:32 *To:* Ben Maddison <benm@workonline.africa>; nanog@nanog.org list < nanog@nanog.org> *Subject:* Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]
I agree with you in the utility of that, but sort of as a side topic...
I wonder how many ASes are out there that have any significant volume of traffic/multi-site presences, but are exclusively 100% transit customers, do not have any PNIs at major carrier hotels, and are not members of any IX.
What would be a good example of such an AS and how big of a network would it be? Undoubtedly there are some enterprise end user type customers set up like that, but I can't imagine they receive a very large volume of unsolicited peering requests.
On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG <nanog@nanog.org> wrote:
Hi Patrick,
On 08/18, Patrick W. Gilmore wrote:
Of course! Including headers to show authenticity. I was very amused by the explanation of the "chicken and egg" problem. Who's creating that? The networks who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't recognize ASNs that are not peering with anyone because nobody wants to peer with them because they are not registered in peeringdb because nobody wants to peer with them? You get the idea.
First, most networks do not require a PDB record to peer. (Silly of them, I know, but still true.)
Second, you do not need to have a PDB record to get a link to an IXP. Even membership in a free IXP is sufficient for an account in PDB, as Grizz points out below.
Third, if you have an agreement, even just an email, saying a network will peer with you once you have a record, that may well suffice. Have you asked any network to peer? Private peering (because you are not on an IXP) is usually reserved for networks with more than a modicum of traffic. If your network is large enough to qualify for private peering, I have trouble believing you cannot get another network to agree to peer so you can get a record.
I guess you are right, the _Peering_DB does not register “certain” networks. Those networks would be ones that do not peer. Which seems pretty obvious to me - it is literally in the name.
A PDB record for an Internet-connected ASN, listing no IXPs or facilities, but with a note saying approximately "We only use transit, and don't peer" has some utility: it saves prospective peers from finding contacts to ask and sending emails, etc.
I'd argue this is in scope for PDB. But perhaps there was additional context to the original decision that I'm missing?
Cheers,
Ben
I, and many others that I know, have successfully listed our networks in PeeringDB while having no peering. You may just need to try again. On Wed, Aug 18, 2021, 5:53 PM Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patrick@ianai.net wrote:
Hi,
On Aug 18, 2021, at 5:00 PM, Matthew Walster <matthew@walster.org> wrote:
On Wed, 18 Aug 2021, 21:37 Sabri Berisha, <sabri@cluecentral.net> wrote: ----- On Aug 18, 2021, at 2:46 AM, Steve Lalonde steve@enta.net wrote:
Hi,
We always use PeeringDB data and refuse to peer with networks not in PeeingDB
You are aware that PeerinDB refuses to register certain networks, right? It is most certainly not a single source of truth.
Would you care to expand on this?
I am extremely interested in hearing about this as well.
Specific examples would be useful.
Of course! Including headers to show authenticity. I was very amused by the explanation of the "chicken and egg" problem. Who's creating that? The networks who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't recognize ASNs that are not peering with anyone because nobody wants to peer with them because they are not registered in peeringdb because nobody wants to peer with them? You get the idea.
Thanks,
Sabri AS31064
Return-Path: grizz@peeringdb.com Received: from mail.cluecentral.net (LHLO mail.cluecentral.net) (195.16.84.32) by mail.cluecentral.net with LMTP; Fri, 9 Oct 2015 01:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cluecentral.net (Postfix) with ESMTP id 4CED64001EF for <sabri@cluecentral.net>; Fri, 9 Oct 2015 01:47:22 -0700 (PDT) Received: from mail.cluecentral.net ([127.0.0.1]) by localhost (mail.cluecentral.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TLvVaNdjHGA for <sabri@cluecentral.net>; Fri, 9 Oct 2015 01:47:21 -0700 (PDT) Received: from ubersmith.peeringdb.com (ubersmith.peeringdb.com [107.6.74.106]) by mail.cluecentral.net (Postfix) with ESMTP id C5B164001A9 for <sabri@cluecentral.net>; Fri, 9 Oct 2015 01:47:01 -0700 (PDT) Received: by ubersmith.peeringdb.com (Postfix, from userid 48) id D8AF377C1A; Fri, 9 Oct 2015 04:46:29 -0400 (EDT) Date: Fri, 9 Oct 2015 04:46:29 -0400 To: Sabri Berisha <sabri@cluecentral.net> From: support@peeringdb.com Reply-To: support@peeringdb.com Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New Company - Cluecentral Inc) Message-ID: <1bac170d74e5d3702d3a28b237c87260@ubersmith.peeringdb.com>
Dear PeeringDB user,
Registering with peeringDB and peering negotiations are sort of egg and chicken problem. We only want to have networks registered that already do have settlement free peering.
After some basic checks it looks like you are only buying transit from 6939/Hurricane Electric, but are not connected to any Internet Exchange (e.g. AMS-IX/NL-ix) yet.
Having said this, is it acceptable to you to wait until you have your 1st settlement free peering setup? If you already have existing peering sessions, please provide the following details to support your request for peeringdb access:
Your AS number(s) Which IXP / facilities you are peering at Some of your peering partners (again AS numbers / name)
Please send your answers to support@peeringdb.com or reply to this ticket.
Best regards, PeeringDB admin on Duty
PeeringDB Listserv information:
PeeringDB Announce: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce
PeeringDB Governance: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov
PeeringDB Technical: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
PeeringDB User Discuss: http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss
-- Florian Hibler <fhibler@peeringdb.com> PeeringDB Administrator
On 8/19/21 12:19 PM, Ross Tajvar wrote:
I, and many others that I know, have successfully listed our networks in PeeringDB while having no peering. You may just need to try again.
Yup, can confirm I had no issues registering too and I've only got a pretty small setup these days. Looks like its a pretty good resource when people have filled out their network details, esp the contact information for abuse, etc. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On 8/19/21 11:19 AM, Ross Tajvar wrote:
I, and many others that I know, have successfully listed our networks in PeeringDB while having no peering. You may just need to try again.
All of the argument is based around an email dated in *2015*. So yeah, try again.
On 19.08.2021, at 22:39, Seth Mattinen <sethm@rollernet.us> wrote:
On 8/19/21 11:19 AM, Ross Tajvar wrote:
I, and many others that I know, have successfully listed our networks in PeeringDB while having no peering. You may just need to try again.
All of the argument is based around an email dated in *2015*. So yeah, try again.
Every public AS (queried by RIR) is welcome and accepted. It is an automated process now. If you had trouble getting your ASN registered with PeeringDB in the past, try it again or get in contact with pdbs support. -Stefan (pdb admin)
On Wed, 18 Aug 2021 at 11:33, Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit.
I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers? Do you negotiate/exchange sensible values whenever you establish a new session? Do you rely on PeeringDB (if available)? Do you apply default values to everyone except the big fishes?
- review max prefix suggestions from the peer itself, either from the email or peeringdb - check actual current prefix count (bgp.he.net et all) - check whether the disparity between the two matches your expectation of a safety margin, based on your own operational experience and context - defaults for low prefix count peers - actually monitor warning/critical levels of max-prefix counts Don't use too small a safety margin, you don't want to spend your days adjusting max-prefix levels all the time. I don't have strict rules for the safety margin itself; it depends very much on the network (size, growing rate, trust, history). lukas
On Wed, 18 Aug 2021 at 11:33, Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers?
If you have automation in place. Another approach is to count the received prefix. Store the counted value in a database. Based on the avg prefix count over X (time period). Add e.g. 10 - 25 % headroom over the avg prefix count and use the calculated value as the max-prefix limit? PeeringDB data (sometimes or often?) be somewhat misleading (in contrast to actual avg prefix count) in the sense 'some' networks will input a value with headroom percentages already included.
On Wed, 18 Aug 2021 at 12:03, Chriztoffer Hansen <ch@ntrv.dk> wrote:
'some' networks will input a value with headroom percentages already included.
That's what it's for. There is no point in periodically copying the actual prefix-count into peeringdb records, that would just be redundant data which would be wrong more often than not. PeerginDB tool tips: Recommended maximum number of IPv4 routes/prefixes to be configured on peering sessions for this ASN Recommended maximum number of IPv6 routes/prefixes to be configured on peering sessions for this ASN Lukas
On 18/08/2021 13:03, Chriztoffer Hansen wrote:
On Wed, 18 Aug 2021 at 11:33, Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers?
If you have automation in place. Another approach is to count the received prefix. Store the counted value in a database. Based on the avg prefix count over X (time period). Add e.g. 10 - 25 % headroom over the avg prefix count and use the calculated value as the max-prefix limit?
That works but all too often people forget to update it. Set a quarterly reminder in your calendar to check max-prefix setting. -Hank
Thus spake Chriztoffer Hansen (ch@ntrv.dk) on Wed, Aug 18, 2021 at 12:03:51PM +0200:
On Wed, 18 Aug 2021 at 11:33, Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers?
sadly, this is the state of the art.
If you have automation in place. Another approach is to count the received prefix. Store the counted value in a database. Based on the avg prefix count over X (time period). Add e.g. 10 - 25 % headroom over the avg prefix count and use the calculated value as the max-prefix limit?
PeeringDB data (sometimes or often?) be somewhat misleading (in contrast to actual avg prefix count) in the sense 'some' networks will input a value with headroom percentages already included.
Our code tries all 3: a) using the max values in peeringdb b) expand all the routes in the IRR record from peeringdb b.1) if no object is specified, try to guess if it's named ASnnnnn c) count the currently received prefixes Many times the values in peeringdb can be off, or increasingly this is a good warning not to peer with a negligent operator. For some peers 'b' can expand to a huge, unrealistic set (not always their fault), so if it's substantially larger than 'a' we throw it out. (c) has proven the most reliable. The count chosen then fits in the appropriate sized bin and given 30% headroom. The code compares all this and gives the user a warning that in proactive gets ignored for option 'c'. (For example we can override 'b' with a more appropriate object record in our provisioning db) Dale
On Wed, 18 Aug 2021 at 12:36, Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit.
You are missing two important questions a) should I apply it to before or after policy b) what should I do when it triggers, should I reset or stop accepting new -- ++ytti
On 18.08.21 12:36, Saku Ytti wrote:
On Wed, 18 Aug 2021 at 12:36, Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit. You are missing two important questions a) should I apply it to before or after policy b) what should I do when it triggers, should I reset or stop accepting new
When I read through [1] earlier today, I had the feeling that these question rather strictly translate to: a) Do I keep rejected routes around? b) Can I traffic-wise afford dropping the session to send a strong signal to my peer? Hence, I didn't dig deeper. Best regards, Lars [1] https://tools.ietf.org/id/draft-sa-grow-maxprefix-00.html#rfc.section.3.1
While there are good solutions in this thread, some of them have scaling issues with operator overhead. We recently implemented a strategy that I proposed a couple years ago that uses a bucket system. We created 5 or 6 different buckets of limit values (for v4 and v6 of course.) Depending on what you have published in PeeringDB (or told us directly what to expect), you're placed in a bucket that gives you a decent amount of headroom to that bucket's max. If your ASN reaches 90% of your limit, our ops folks just move you up to the next bucket. If you start to get up there in the last bucket, then we'll take a manual look and decide what is appropriate. This covers well over 95% of our non-transit sessions, and has dramatically reduced the volume of tickets and changes our ops team has had to sort through. Of course, we can also afford to be a little looser in limits based on the capability of the equipment that these sessions land on, other environments may require tighter restrictions. On Wed, Aug 18, 2021 at 5:34 AM Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit.
I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers? Do you negotiate/exchange sensible values whenever you establish a new session? Do you rely on PeeringDB (if available)? Do you apply default values to everyone except the big fishes?
Apart from your peers, do you also apply a limit to your transit sessions?
Best regards,
Lars
On Wednesday, 18 August, 2021 14:21, "Tom Beecher" <beecher@beecher.cc> said:
We created 5 or 6 different buckets of limit values (for v4 and v6 of course.) Depending on what you have published in PeeringDB (or told us directly what to expect), you're placed in a bucket that gives you a decent amount of headroom to that bucket's max. If your ASN reaches 90% of your limit, our ops folks just move you up to the next bucket. If you start to get up there in the last bucket, then we'll take a manual look and decide what is appropriate. This covers well over 95% of our non-transit sessions, and has dramatically reduced the volume of tickets and changes our ops team has had to sort through.
Depending on what failure cases you actually see from your peers in the wild, I can see (at least as a thought experiment), a two-bucket solution - "transit" and "everyone else". (Excluding downstream customers, who you obviously hold some responsibility for the hygiene of.) How often do folks see a failure case that's "deaggregated something and announced you 1000 /24s, rather than the expected/configured 100 max", vs "fat-fingered being a transit provider, and announced you the global table"? My gut says it's the latter case that breaks things and you need to make damn sure doesn't happen. Curious to hear others' experience. Thanks, Tim.
Depending on what failure cases you actually see from your peers in the wild, I can see (at least as a thought experiment), a two-bucket solution - "transit" and "everyone else". (Excluding downstream customers, who you obviously hold some responsibility for the hygiene of.)
Although I didn't say it clearly, that's exactly what we do. The described 'bucket' logic is only applied to the 'everyone else' pile ; our transit stuff gets its own special care and feeding. How often do folks see a failure case that's "deaggregated something and
announced you 1000 /24s, rather than the expected/configured 100 max", vs "fat-fingered being a transit provider, and announced you the global table"?
I can count on one hand the number of times I can remember that a peer has gone on a deagg party and ran over limits. Maybe twice in the last 8 years? It's possible it's happened more that I'm not aware of. We have additional protections in place for that second scenario. If a generic peer tries to send us a route with a transit provider in the as-path, we just toss the route on the floor. That protection has been much more useful than prefix limits IMO. On Wed, Aug 18, 2021 at 11:37 AM tim@pelican.org <tim@pelican.org> wrote:
On Wednesday, 18 August, 2021 14:21, "Tom Beecher" <beecher@beecher.cc> said:
We created 5 or 6 different buckets of limit values (for v4 and v6 of course.) Depending on what you have published in PeeringDB (or told us directly what to expect), you're placed in a bucket that gives you a decent amount of headroom to that bucket's max. If your ASN reaches 90% of your limit, our ops folks just move you up to the next bucket. If you start to get up there in the last bucket, then we'll take a manual look and decide what is appropriate. This covers well over 95% of our non-transit sessions, and has dramatically reduced the volume of tickets and changes our ops team has had to sort through.
Depending on what failure cases you actually see from your peers in the wild, I can see (at least as a thought experiment), a two-bucket solution - "transit" and "everyone else". (Excluding downstream customers, who you obviously hold some responsibility for the hygiene of.)
How often do folks see a failure case that's "deaggregated something and announced you 1000 /24s, rather than the expected/configured 100 max", vs "fat-fingered being a transit provider, and announced you the global table"?
My gut says it's the latter case that breaks things and you need to make damn sure doesn't happen. Curious to hear others' experience.
Thanks, Tim.
On Wed, 18 Aug 2021 11:33:09 +0200 Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit.
Maybe because there isn't a simple, universal approach to setting it. Probably like a lot of people, historically I'd set it to some % over the current stable count and then manually adjust when the limits were about to be breached, or often was the case when they were and I wasn't ready for it. Not ideal. I've never felt the automation of this setting however was worth the effort. Of course I am not usually responsible for hundreds of routers and thousands of peering sessions. At the risk of advocating for more junk in BGP or the RPKI, a max prefix setting might be something that could be set by the announcing peer in a BGP message, or possibly as an RPKI object with an associated ASN. I'll let the masses debate how that would work and all the reasons that isn't ideal, but I'm not sure there is a one-size-fit all solution for this in the near term. John
On Aug 18, 2021, at 9:38 AM, John Kristoff <jtk@dataplane.org> wrote:
Maybe because there isn't a simple, universal approach to setting it. Probably like a lot of people, historically I'd set it to some % over the current stable count and then manually adjust when the limits were about to be breached, or often was the case when they were and I wasn't ready for it. Not ideal.
I've never felt the automation of this setting however was worth the effort. Of course I am not usually responsible for hundreds of routers and thousands of peering sessions.
We did a variant of this at NTT, with certain baseline settings. Sometimes networks would advertise more routes because they onboarded a large customer and it would cause manual updates to be necessary. Polling daily and snapshotting these values is important to understand what is changing. The reason I just posted a message about Akamai max-prefix is we have been giving some general guidance that is out of line/norm compared to what perhaps what we want. This won’t cause a service outage per-se but will cause suboptimal routing as we continue to make improvements and upgrades to our network. - Jared
On Wed, 18 Aug 2021, John Kristoff wrote:
On Wed, 18 Aug 2021 11:33:09 +0200 Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit.
Maybe because there isn't a simple, universal approach to setting it. Probably like a lot of people, historically I'd set it to some % over the current stable count and then manually adjust when the limits were about to be breached, or often was the case when they were and I wasn't ready for it. Not ideal.
We tackled this problem at $work recently after I wrote some code to audit configured prefix-limits and found how inconsistent we were. My guess was, this was due to combination of each engineer "doing their own thing" with regard to how to set prefix-limits based on what was published in peeringdb and growth (peers increasing the suggested limits over time, after we'd configured [some of] their sessions). The solution I implemented was: In the script that builds peering config, fetch the peer's suggested limits from peeringdb via API (I still miss the open mysql access). Multiply those values by 2. If that's too close to the "full table size", try suggested limits * 1.5. If that's still too close to the "full table size", just use the suggested limits.
I've never felt the automation of this setting however was worth the effort. Of course I am not usually responsible for hundreds of routers and thousands of peering sessions.
Yeah...that changes things when you have thousands of peering sessions to maintain.
At the risk of advocating for more junk in BGP or the RPKI, a max prefix setting might be something that could be set by the announcing peer in a BGP message, or possibly as an RPKI object with an associated ASN.
It actually sounds like a cool feature, and could be implemented entirely on the sender's side. i.e. You configure a peer with a self-imposed limit of 1000 routes. If you screw up your routing policy facing that peer and leak the full table, once you hit 1001 advertised routes, your router's BGP process terminates the session. Who hasn't had a new peer leak full routes to them at least once? Who hasn't configured a new peer, only to have them immediately trip your prefix-limit because they haven't updated peeringdb for "some time" and advertise more routes than their suggested limits? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 8/18/2021 5:33 AM, Lars Prehn wrote:
As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit.
I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers? Do you negotiate/exchange sensible values whenever you establish a new session? Do you rely on PeeringDB (if available)? Do you apply default values to everyone except the big fishes?
Apart from your peers, do you also apply a limit to your transit sessions?
Best regards,
Lars
Our semi-automated process... Check the peering routers for any peers that have a prefix limit set (we don't set limits on transit or iBGP, so we skip those groups) Record what the current limit is. Check peeringDB for what the network says the limit should be. If configured max prefix < peeringDB, inform a config change is needed; if configured max prefix > peeringDB, the network isn't keeping its record up to date. no need for change I've thought about adding additional headroom to what is advertised in peeringDB, but we haven't had the limits triggered in so long, it may not be worth it.
participants (28)
-
Adam Thompson -
Andrew Gallo -
Ben Maddison -
Brielle -
Chriztoffer Hansen -
Dale W. Carder -
Denis Fondras -
Eric Kuhnke -
Hank Nussbacher -
Jared Mauch -
John Kristoff -
Jon Lewis -
Lars Prehn -
Lukas Tribus -
Matthew Walster -
Nick Hilliard -
Niels Bakker -
Patrick W. Gilmore -
Randy Bush -
Ross Tajvar -
Rubens Kuhl -
Sabri Berisha -
Saku Ytti -
Seth Mattinen -
Stefan Funke -
Steve Lalonde -
tim＠pelican.org -
Tom Beecher