GithubHelp home page GithubHelp logo

docs's Introduction

PeeringDB Documentation

As viewable at https://docs.peeringdb.com/

NOTE Please do not put issues here anymore, new issues should be created at https://github.com/peeringdb/peeringdb/issues

Modifying these docs

To work on and change these documents, you'll need git, python, and pip.

  • CentOS
    sudo yum install python-pip

Fork the repo

Clone the repo

cd ~/src # Adjust here and below as appropriate.
git clone [email protected]:$GITHUB_USERNAME/docs.git

Install MkDocs and other requirements

cd ~/src/docs
python3 -m venv venv
source venv/bin/activate
python -m pip install --upgrade pip
python -m pip install --upgrade poetry
poetry install --no-root

Start mkdocs

cd ~/src/docs
source venv/bin/activate
mkdocs serve

or, if you'd like to specify the port, use -a $ADDRESS:$PORT, for example:

cd ~/src/docs
source venv/bin/activate
mkdocs serve -a 0.0.0.0:7889

You should now see a message similar to: Serving on http://127.0.0.1:8000

Point your browser at that URL, and you'll get real time updates to the generated documentation as you edit.

Markdown has its own formatting syntax, to get started look here for an excellent cheatsheet.

Updating the site

Once you are happy with your changes, commit and push, then run

cd ~/src/docs
git commit -a
git push

If you want to be able to view your changes at $GITHUB_USER.github.io/docs, just run:

cd ~/src/docs
source venv/bin/activate
mkdocs gh-deploy

To get your changes pushed to the live site, just create a pull request, if you're unfamiliar with how to do that, GitHub has documentation.

Updating your fork

The first time you want to do it, you need to add a remote with

cd ~/src/docs
git remote add upstream [email protected]:peeringdb/docs.git

After that, to sync to the upstream repo and install requirements/updates

cd ~/src/docs
git fetch upstream
git merge upstream/master
source venv/bin/activate
poetry install

docs's People

Contributors

aarongroom avatar aaronw112358 avatar arnoldnipper avatar asbjornst avatar ccaputo avatar dependabot[bot] avatar dvanallen avatar eloos avatar fakela avatar ghankins avatar grizz avatar jason20c avatar job avatar koalafil avatar leovegoda avatar mcmanuss8 avatar vegu avatar zxyz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

docs's Issues

ix_lan API not working

/api/ixlan/ not returning any useful data, also asking for basic authentication.

Need this if I am to identify IX memberships from ASNs (since ixlink_set only links ix_lan ids)

IXP Search

Moved from comment to new issue @huggi

Old database:
Search with longname in the exchange name field does not result anything, sample: Cameroon =0 for e.g. for CAMIX =1.

In the new database if you search for Cameroon you will get only the ISPs and Faciltiies, but not the IXP which would be nice. Thanks!

"humanize" speeds?

It might be nice to "humanize" the speeds, instead of having values like 20000 or 100000 instead show 20g or 100g

API field names inconsistencies

An "asn" query returns "network" and "ix_lan" fields under the "ixlink_set", but these need to be queried by hitting the "net" and "ixlan" endpoints. I'm not sure if there are more cases like those yet.

Link not working

This one is easy: the "log in" link under the SEARCH option in the main page is not leading to the login page. :)

DB: Some v6 addresses wrongly imported

It seems, that if a network got text in their IP field for an IXP, it gets converted to a very strange IPv6 address. Also sometimes entries appear for those "weird" IPv6 addresses, even when there is no weird entry in PDB1:

For example:
Case 1:
https://www.peeringdb.com/private/participant_view.php?id=433&peerParticipantsPublics_mPage=2
CIX 36040 via CIX route server 10000
"via CIX route server" becomes "4349:5820:726f:7574:6520:7365:7276:6572"

Case 2:
https://www.peeringdb.com/private/participant_view.php?id=433&peerParticipantsPublics_mPage=4
ECIX-HAM 15169 2001:7f8:8:10::3b41:0:1/64 10000
this entry becomes in v2 (https://beta.peeringdb.com/ix/341)
ECIX-HAM 15169 None 2001:7f8:8:10:0:3b41:0:1 10000
ECIX-HAM 15169 None 3139:332e:3432:2e31:3535:2e34:362f:3234 10000

There are other networks affected as well (so far found https://beta.peeringdb.com/net/433, https://beta.peeringdb.com/net/670, https://beta.peeringdb.com/net/1964, https://beta.peeringdb.com/net/1728, https://beta.peeringdb.com/net/2310, etc.). Just have a look at https://beta.peeringdb.com/ix/9 to figure out more networks.

ixlan missing ID attribute

The ixlan API endpoints is missing a way to uniquely identify specific objects when queried in bulk, such as an "id", "ix_lan", or "ixlan" attribute (related to API field names inconsistencies). Thus if performing a bulk request, there is no way to accurately map the attributes of a given object to its identifier. Attempting to do this based on array positioning is possible, but seems convoluted, especially when other API endpoints provide some unique identifier.

https://beta.peeringdb.com/api/ixlan/194 doesn't include 194 in the entry. Thus if just requesting https://beta.peeringdb.com/api/ixlan it's necessary to know that ix_lan 194 is actually array position 193 (based on a typical 0 start).

{
  "meta": {}, 
  "data": [
    {
      "ix": 236, 
      "name": "", 
      "descr": "", 
      "mtu": null, 
      "dot1q_support": false, 
      "rs_asn": 0
    }
  ]
}

While something like https://beta.peeringdb.com/api/ix/236 will include its id (236) in the response, which is particularly useful when requesting https://beta.peeringdb.com/api/ix.

{
  "meta": {}, 
  "data": [
    {
      "id": 236, 
      "name": "Equinix Chicago", 
      "name_long": "Equinix Chicago Exchange", 
      "city": "Chicago", 
      "country": "US", 
      "region_continent": "North America", 
      "media": "Ethernet", 
      "notes": "", 
      "proto_unicast": false, 
      "proto_multicast": false, 
      "proto_ipv6": false, 
      "website": "https://ix.equinix.com", 
      "url_stats": "", 
      "tech_email": "[email protected]", 
      "tech_phone": "", 
      "policy_email": "[email protected]", 
      "policy_phone": ""
    }
  ]
}

Database is not accurate

Hello Peeringdb,

For AS8551
The details on the 2.0 version is not updated with the old peeringdb website.

Thanks.

Lookup of arbitrary parameters in REST API

I am currently using the MySQL interface for building peering configurations, for this I'm querying the table peerParticipantsPublics for local_ipaddr with where clauses for "local_asn" and "public_id".

This is currently not possible with the REST API - I cannot lookup the IXP id by name and especially cannot query the IP addresses in the peering LAN for an ASN. Is there some way this functionality can be extended to the REST API?

Thanks in advance,

Marcus

Discrepancy between v1 and v2 for ASN 29676

I am seeing the following:

https://beta.peeringdb.com/net/2582
LONAP 29676 5.57.80.202 None 1G

vs
http://www.peeringdb.com/view.php?asn=29676
LINX Extreme LAN 29676 195.66.238.139 1000
LINX Extreme LAN 29676 2001:7f8:4:1::73ec:1 1000
LINX Juniper LAN 29676 195.66.226.139 1000
LINX Juniper LAN 29676 2001:7f8:4::73ec:1 1000
LONAP 29676 2001:7f8:17::73ec:1 1000
LONAP 29676 5.57.80.202 1000

It looks like some of the entries are missing in the new version.

API exposes internal database ids

Hi

The new http/json api exposes internal database id (AFAICT), which is considered bad practice, as it exposes internal structure, and makes any future internal changes, such as schema changes very tricky.

So, this is good:
curl -X GET https://beta.peeringdb.com/api/asn/2603

Bad:
curl -X GET https://beta.peeringdb.com/api/net/1721

Similarly, database ids are exposed in a lot of the exposed data:
{
"network": 1721,
"facility": 536,
"local_asn": 2603
}

    {
      "network": 1721, 
      "ix_lan": 27, 
      "notes": "", 
      "speed": 10000, 
      "asn": 2603, 
      "ipaddr4": "193.239.116.53", 
      "ipaddr6": "2001:7f8:13::a500:2603:1"
    }, 

Generally internal database ids, should only be used in joins, etc. and should never leave the application. Only "business" data should be exposed to the client.

I realize this may complicate some things.

Thanks for making peeringdb. It has been a huge help in automating parts of our peering setup at NORDUnet.

no API for searching by ISP type

Right now, with the mysql dump, you can pull out which ASNs are what (eyeball, content, etc.). This is quite useful for traffic engineering and analytics. As far as I can see there's no way to do that easily with the v2 API without spamming it with requests concerning every ASN we're interested in :(

PoCs, emails

It's currently impossible to fetch emails (or phone numbers) for contact points (at least in the ASN view). This seems deliberate, presumably for privacy reasons (which is good!) but considering that both the beta web interface and the MySQL API just provides access to those and are much easier to harvest, I'm not sure what's the point... Maybe that should be a v2 feature?

Note that I tried accessing /poc/ endpoints (after authenticating) too, but:

  • "asn" doesn't point to "poc" IDs, so it's impossible to figure out the URL
  • the random PoC IDs I tried resulted in errors

api: additional relationship filters

right now it is only possible to filter by fields existing on the serializers, ideally we want to be able to filter by any relationship, (e.g /api/net?ix=1, /api/net?ix_lan=1)

GUI: Screen refresh "resets" cursor location and causes typos

OS: Mac OS X
Browser: Firefox v35.0.1

When typing in a search term the screen refreshes from the "center" text box to the "upper right" text box. When it refreshes the screen, the cursor resets the location. The result that if a user is typing, it introduces a typo and makes the search results useless.

Have field for v6 prefix

Right now peeringdb only has a generic field for number of prefixes.

Having a seperate field for v6 prefixes would be nice.

Get by ASN only searches primary ASN

A network that has multiple ASNs isn't returned when requesting non-primary ASN.

For example, APNIC (id=3103) has the primary ASN 4608, but different ASNs at different IXs (for example ASN 18369 at Equinix-Ashburn (fac=1))

https://beta.peeringdb.com/api/asn/4608 returns APNIC's record, but https://beta.peeringdb.com/api/asn/18369 does not.

Searching on the web interface yields the same results (specifically, searchers for 18369 returns no results).

Shouldn't a get or search work for all ASNs for a given org?

API versioning

I would highly recommend versioning the API (e.g. /api/v1) — no matter how good of a job you & the community will do to vet the current API now, there's always going to be a need to evolve it after the fact and it'd be nice to do so without breaking everyone's assumptions/code.

Record / retrieve ARP sponge MAC address for IXPs

It would be useful if the ARP Sponge's MAC address can be retrieved from PeeringDB.

Unsure if there already is a good datasource (like Euro-IX DB) for this? If not PeeringDB should have a field where IXPs can fill this in or Euro-IX DB should be extended to record that.

autofil recommend_max_prefix_v6

In the old PeeringDB we only have 1 field for "recommended max prefix setting" which is called "Approx Prefixes". Almost all networks have filled in the recommended max prefix setting for IPv4.

Going forward in 2.0 we'll have two fields, one max prefix recommendation for IPv4 and one for IPv6. I recommend that the initial autofill of the recommended_max_prefix_v6 field is done by taking the "Approx Prefixes" value from PDB1, and multiplying it with 0.05. recommended_max_prefix_v4 should just be copied from "Approx Prefixes" in PDB1.

IXP Data wrong

for network 116 (as8426), PDB2 GUI and API shows we are on ix 1 (LINX Extreme) twice, whereas in fact we are on both Extreme and Juniper. PDB1 does not have this problem. PDB2 only has an IX entry for Extreme, not Juniper, were they accidentally merged?

Search: Does not work with ASNs

I just realized that for e.g. 'Epsilon' https://www.peeringdb.com/private/participant_view.php?id=6852 they are using AS44356 as their primary ASN and use: AS23936 as their Also Known field.

  • When I search for 'Epsilon' I will find them, but if I use AS44356 or AS23936 I will not find them.
  • When I search for 'AS13030' I also don't get anything
  • When I use 13030 it shows me the right entry of: https://beta.peeringdb.com/net/163

Is there any chance to make this happen in the new search? I know the value in your db is 13030 but I'm used to type asXYZ.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.