Mailing List Archive

Max-Prefix from IX Route-Servers - from where to get it?
We are creating some auxiliary to help on the deploy of our BGP Sessions.

Most of the information we are getting from Peering DB.
For Bilateral Sessions(over Private media, or over MPLA vlan), we use the
max-prefix defined on PeeringDB profile of the partner.
(And other information also, like AS-SET)

But... Talking about MPLE?
Where do we get the max prefix expected from the route-servers?


I tried to find it on IXPDP (maintained by Euro IX / IX-F), and didn't find
that information of max-prefix.
https://ixpdb.euro-ix.net/en/ixpdb/route-servers/


Peering DB
Searching a bit on PeeringDB I saw that some IXPs has a "NET" object
created for each "IX".
This is the case of DE-CIX.

But there are other IXPs that don't have this parity between "NET" and "IX"
objects.
This is the case of IX.BR IXPs, and I Believe that is also the case of
Equinix IXPs.

And I Believe that the cause is that those entities use the same ASN to all
the IXPs.
- In IX.BR São Paulo we have around 200K routes being announced through
Route-Serves.
- In IX.BR Cascavel(my home city, ????) we have around 1,5K K routes.
Both IXPs we same 26162 ASN.

I´m pretty sure same ambiguity occurs with other IX organizations.
For example Equinix IX. The number os Routes in Ashburn is
certanly different that Seoul.


So, I brought a problem to discuss and find a solution.

My first suggestion is:
Talking about PeeringDB modeling
- Create an attribute called NET on IX objects, that will point to the NET
referent to that IXP Location.
- Open an Exception(SPECIFIC TO IXPs) about ASN being a Unique Key
- Suggest/Demands that Each IXP has their own NET Object.

PS.: This solution will also solve issues like
-> "Where do I get the AS-SET that contais all the NETs on that IXP?"

--
Douglas Fernando Fischer
Engº de Controle e Automação
Re: Max-Prefix from IX Route-Servers - from where to get it? [ In reply to ]
By Suggestion of a colleague I opened an issue about it on PeeringDB Github

https://github.com/peeringdb/peeringdb/issues/755

Em qui., 25 de jun. de 2020 às 11:59, Douglas Fischer <
fischerdouglas@gmail.com> escreveu:

> We are creating some auxiliary to help on the deploy of our BGP Sessions.
>
> Most of the information we are getting from Peering DB.
> For Bilateral Sessions(over Private media, or over MPLA vlan), we use the
> max-prefix defined on PeeringDB profile of the partner.
> (And other information also, like AS-SET)
>
> But... Talking about MPLE?
> Where do we get the max prefix expected from the route-servers?
>
>
> I tried to find it on IXPDP (maintained by Euro IX / IX-F), and didn't
> find that information of max-prefix.
> https://ixpdb.euro-ix.net/en/ixpdb/route-servers/
>
>
> Peering DB
> Searching a bit on PeeringDB I saw that some IXPs has a "NET" object
> created for each "IX".
> This is the case of DE-CIX.
>
> But there are other IXPs that don't have this parity between "NET" and
> "IX" objects.
> This is the case of IX.BR IXPs, and I Believe that is also the case of
> Equinix IXPs.
>
> And I Believe that the cause is that those entities use the same ASN to
> all the IXPs.
> - In IX.BR São Paulo we have around 200K routes being announced through
> Route-Serves.
> - In IX.BR Cascavel(my home city, ????) we have around 1,5K K routes.
> Both IXPs we same 26162 ASN.
>
> I´m pretty sure same ambiguity occurs with other IX organizations.
> For example Equinix IX. The number os Routes in Ashburn is
> certanly different that Seoul.
>
>
> So, I brought a problem to discuss and find a solution.
>
> My first suggestion is:
> Talking about PeeringDB modeling
> - Create an attribute called NET on IX objects, that will point to the NET
> referent to that IXP Location.
> - Open an Exception(SPECIFIC TO IXPs) about ASN being a Unique Key
> - Suggest/Demands that Each IXP has their own NET Object.
>
> PS.: This solution will also solve issues like
> -> "Where do I get the AS-SET that contais all the NETs on that IXP?"
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


--
Douglas Fernando Fischer
Engº de Controle e Automação