June 2022 - Pdb-tech

new rate limiting mechanism is too strict
by Theo de Raadt 13 May '24

13 May '24

At YYCIX, we run arouteserver, which polls peeringdb. On May 15 (I think) we started seeing failures to download peeringdb records, which has resulted in our routeserver configuration not being updated as usual. I've become aware that the API has a new rate filtering mechanism, for non-APIKEY accesses. Well, arouteserver doesn't do APIKEY, and I don't see how the author of arouteserver would have received any notice that this was suddenly mandatory, nor all the arouteserver users. I think peeringdb should have looked more carefully into the no-APIKEY accesses to determine what downstream effects might occur from this change. Testing further manually, I observe some really crazy behaviour. Using a regular browser, I can keep reloading the same record over and over without hitting any limit. Using a command-line client (curl or OpenBSD ftp(1)), i hit some extremely strict limits very quickly. On the 11th lookup, I receiving this, and it started counting down: {"message": "Request was throttled. Expected available in 59 minutes. Authenticate for less restrictions. For more information: https://docs.peeringdb.com/howto/api_keys/", "meta": {"error": "Too Many Requests"}} All requests are blocked for an hour. I paused, and tried a new lookup every 5 minutes. Half an hour later it allowed me to retrieve 1 record, but then continued the countdown: {"message": "Request was throttled. Expected available in 17 minutes. Authenticate for less restrictions. For more information: https://docs.peeringdb.com/howto/api_keys/", "meta": {"error": "Too Many Requests"}} If the new limit is 10 records an hour, I mean you could really just shut down the service entirely, there's really no difference. I understand using APIKEY is the new way, but the old way has effectively been disabled without notice. But also, why does this work in the browser? I can reload hundreds of times. Is the official browser User-agent being considered exempt from the rule? If so I don't understand what the protection plan is.. maybe we should all change our commandline tools to declare they are Chrome?

5 6

PeerFinder support for API keys
by Chris Caputo 18 Jul '22

18 Jul '22

Hi all, For those using PeerFinder, I have submitted a PR to add support for API keys: https://github.com/rucarrol/PeerFinder/pull/17 Feel free to pull from my fork if you need support immediately: https://github.com/ccaputo/PeerFinder Happy to answer questions about this. Thanks, Chris

1 1

Listing
by hasnain rashid 27 Jun '22

27 Jun '22

1 0

PeeringDB API throttling status and schedule
by Chris Caputo 27 Jun '22

27 Jun '22

After the initial introduction of PeeringDB API throttling, some software both open source and private, has been identified and updated. (open source details are below; please upgrade and encourage others to do so) This API throttling is being implemented to control costs by encouraging efficient software design while making sure the PeeringDB resource is shared well. The use of API keys is being encouraged so that admins can reach out to users/orgs with runaway or inefficient software, and because it is more secure than user/pass. In addition, org API keys ease employee transitions. Some tips for coders is below. API throttling in place today: - repeated anonymous identical requests with a response size above 100k are being limited to 1/hour - repeated anonymous identical requests of any size are being limited to 2/minute - anonymous queries are being limited to 400/minute per IP address - authenticated queries are being limited to 500/minute per user/org Here is the current schedule of throttling changes. The schedule may adjust as needed as new packages that need update are discovered, so as to minimize disruption to the community... On June 27th, adjust and watch for feedback from the community: - anonymous queries limited to 300/minute per IP address - authenticated queries limited to 400/minute per user/org On July 11th, adjust and watch for feedback from the community: - anonymous queries limited to 200/minute per IP address - authenticated queries limited to 300/minute per user/org On July 18th, adjust and watch for feedback from the community: - anonymous queries limited to 100/minute per IP address - authenticated queries limited to 200/minute per user/org On July 25th, adjust and watch for feedback from the community: - anonymous queries limited to 50/minute per IP address - authenticated queries limited to 100/minute per user/org On August 1st, adjust and watch for feedback from the community: - anonymous queries limited to 30/minute per IP address - authenticated queries limited to 80/minute per user/org On August 8th, adjust and watch for feedback from the community: - anonymous queries limited to 20/minute per IP address - authenticated queries limited to 60/minute per user/org On August 15th, adjust and watch for feedback from the community: - anonymous queries limited to 10/minute per IP address - authenticated queries limited to 40/minute per user/org Feedback/questions/concerns welcome. Thanks, Chris Software: - arouteserver v1.16.0: has many updates including API key support along with more efficient querying. - PeerFinder: API key & efficient querying patches at https://github.com/rucarrol/PeerFinder/pull/17 will hopefully be integrated. Coding tips: - Begin using a PeeringDB API key for all requests: https://docs.peeringdb.com/howto/api_keys/ - Begin performing actual caching, such as by using peeringdb-py. http://peeringdb.github.io/peeringdb-py/ - If unable to use a caching agent such as peeringdb-py: - Use an API key. - Set a User-Agent: header. - Use bulk queries (asn__in=$list_of_ASN_separated_by_comma) by querying 30 to 150 ASNs at a time (tune as appropriate). - Add a delay in between queries that is randomly between 2 and 2.5 seconds, to reduce thundering herd.

2 3

PeeringDB API : Getting a 301 error when updating a "net" type object
by Marshall Mahachi 14 Jun '22

14 Jun '22

Hi pdb-tech list I am trying to update a Network ("net" type object) using the API : https://peeringdb.com/api/net/{id} and I am getting a 301 error message: <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> </body> </html> However, it seems to be working fine when on *beta* ---->> https://beta.peeringdb.com/api/net/{id} .. Has anyone run into this problem before ? or if anyone knows if it's a known issue that's being tracked and is to be released. Thanks Best regards -- *MarshallMahachi* *Network Automation* Phone: +61 7 3062 7601 [image: Connect on LinkedIn] <http://www.linkedin.com/in/marshallmahachi> *Your experience is our top priority. Let us know how we are doing: feedback(a)megaport.com <feedback(a)megaport.com>* [image: Visit Megaport.com] <https://www.megaport.com/> [image: ISO/IEC 27001 Certified] This message and the information in or attached to it, is intended for the named addressee only and may contain confidential information. If you are not the intended recipient, please delete it without retaining any copies and notify the sender. Note that all communications to and from Megaport may be stored and used in accordance with our Privacy Policy <https://www.megaport.com/legal/privacy-policy/>. Megaport (Australia) Pty Ltd. Australia. (Company No. 164 521 519). Level 3, 825 Ann Street. Fortitude Valley QLD 4006.

3 4