December 2016 - Pdb-tech

allow empty IP field or not?
by Job Snijders 28 Dec '16

28 Dec '16

Hi all, Sometimes people want to disclose their presence at an Internet Exchange, but don't want to disclose their IP address. Should PeeringDB allow the IPv4 and IPv6 field to be either of the following? "a valid globally unique IP address" "" (empty) Or should PDB only accept valid globally unique IP addresses as value for the IP Field? It appears we've gone back and forth between allowing empty and not allowing empty as is visible here: https://www.peeringdb.com/ix/1138 (currently empty is not allowed). An argument against 'empty' is that from an automation perspective the 'empty' value is quite useless. Based on the outcome of this discussion I'd like to either clean up the database, or popularise the use of the 'empty ip field' where applicable. Kind regards, Job

14 24

Respect my IP authority - a mitigation process for IP accuracy
by Martin J. Levy 28 Dec '16

28 Dec '16

All, I would strongly like to recommend a two step process that should get buy-in from the community at large. This proposal is void of the technical specifics; however, many people are both familiar with these techniques and/or are the authors of those unmentioned techniques. 1) PeeringDB starts gathering IP allocations from IX organizations and populating en-mass an "IX to IP to ASN/customer/member" database. This is kept as nothing more than "hints" (even if I'd state they are "authoritative hints" as IX own the control of that data). In most cases this is very public data. In some cases it isn't. PeeringDB should on day-one only accept public data. 2) Records being added to an IX by an ASN/customer/member should be prompted from the hints; but without a requirement to use that data. Well that day one mindset. This is a basis to further refine later. What does this achieve? It allows users that automate their peering operations to reference the hints data if the PeeringDB IP data is empty or maybe different than hints (recall that IXs are authoritative in this arena). It allows sanity checking when adding IP data; but with soft controls that don't force the user to accept the data. It reinforces, that for the most part, this is already public data. It still allows networks to be silently connected to IXs as it places the burden on non-publication back on the IX. This is already done today. I propose this as a first step. I propose this as a way of moving forward and improving PeeringDB and helping operational use of the data. Martin

1 0

Help with peeringdb app
by Regivaldo Gomes Costa 27 Dec '16

27 Dec '16

Hello All, I need help regarding peeringdb application. I'm using Ubuntu 14.04, and after have been installed the peeringdb application using pip, I made the configuration in according my database. However, when I used the sync command, the application created the tables, but in "migration" phase, occurs an error. In the attached file is the execution trail until the error occur. In the last lines I ran some command to debug as can be seen. I'll grateful for any help. Thanks a lot. Best regards, Regivaldo Costa Doe Sangue. Doe Vida.

2 2

Re: [PDB Tech] route-server information add-on
by paez juan 26 Dec '16

26 Dec '16

yes 1

1 0

route-server information add-on
by Jon Nistor 25 Dec '16

25 Dec '16

Hello everyone, I had a peer ask that I add an entry for the TorIX route-servers as entities in peeringDB as their system uses automation against peeringDB for configurations, etc. It got me thinking, could it be possible to add in an option for route-servers under Internet Exchange points that one could query via the API? Would it be worth it? Is there an alternative to this that would work (i've listed one ref below). ref: https://www.peeringdb.com/net/11429 Cheers, ________ Jon (nistor(a)snickers.org)

6 16