Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase IPv4/6 prefix limits #671

Open
arnoldnipper opened this issue Mar 26, 2020 · 15 comments
Open

Increase IPv4/6 prefix limits #671

arnoldnipper opened this issue Mar 26, 2020 · 15 comments
Assignees

Comments

@arnoldnipper
Copy link
Contributor

@arnoldnipper arnoldnipper commented Mar 26, 2020

Increasing limits to

  • IPv4: 700,000
  • IPv6: 70,000

could make sense, when looking at Potaroo. Ticket refers to #101. To increase the limits was suggested by Gavin Tweedie from Megaport.

@arnoldnipper arnoldnipper added this to the 1 Decide milestone Mar 26, 2020
@arnoldnipper arnoldnipper self-assigned this Mar 26, 2020
@ghankins

This comment has been minimized.

Copy link
Contributor

@ghankins ghankins commented Mar 26, 2020

Most routers support a 32 or 64-bit number in their route policies. Why not make it 0..4294967295? I don't think PeeringDB should set a limit on what we think is a reasonable value. Let the user decide that for themselves.

Plus we'll always have to monitor the internet routing table size to adjust the limit.

@gavintweedie

This comment has been minimized.

Copy link

@gavintweedie gavintweedie commented Mar 26, 2020

I don't mind there being some smarts to confirm typo's etc, especially from newbie networks. Clearly nobody (right now) needs 1Million IPv6 routes as a valid limit. Perhaps if we do have a limit it could be automated and tied to the size of the routing table at that time?

6939 is announcing north of 30k IPv6 these days, and as they participate on the route servers once you add in a number of other peers route server tables are starting to grow beyond 40k.

Gavin

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Mar 26, 2020

@peeringdb/pc any ideas?

@mcmanuss8

This comment has been minimized.

Copy link
Contributor

@mcmanuss8 mcmanuss8 commented Mar 26, 2020

I agree with Greg in principle but in reality, letting people put in any number with no safety check usually results in bad data. I think having an upper bound would be good, but doing it statically would be annoying.

Two things to consider:

  1. The limits should be controlled by config instead of code so we can easily alter the limits without doing a peeringdb release. Give a simple CRUD or something to admin committee and let them have control over it.
  2. In addition to 1, we could write something that finds a reasonable max # of prefixes by looking at potaroo or route-views and adds 10% or so on some cadence (monthly?) to automagically up the limit as the size of the global routing table increases.
@ghankins

This comment has been minimized.

Copy link
Contributor

@ghankins ghankins commented Mar 26, 2020

I think the proposed solution adds a lot of needless complexity for little gain.

But there is a more fundamental issue here in that PeeringDB should validate data to ensure it correctly matches the data type (IP addresses, ASNs (minus reserved ASNs), integer ranges, etc.), but we should not dictate what we think are valid values within the type.

This may not be the best example but I'm worried about setting a precedent where PeeringDB dictates how operators run their networks. I'm kind of surprised there are even limits that we need to increase.

@shane-kerr

This comment has been minimized.

Copy link

@shane-kerr shane-kerr commented Mar 26, 2020

While I think that I understand @mcmanuss8's point about validating data as much as reasonable, I kind of agree with @ghankins. We're not going to catch errors where someone types 81000 instead of 18000, so this is only a mild check. Given that the "reasonable" limit requires care & feeding (as @mcmanuss8 presents), I don't think it is worth it.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Mar 26, 2020

@ghankins there is difference between dictating what we think are valid values and defining ranges for reasonable values. Values have to make operational sense and hence putting in ranges is a safeguard.

Having a config file as @mcmanuss8 proposes is an excellent idea. These data may be controlled by either @peeringdb/ac or @peeringdb/oc. Which committee makes more sense.

@mcmanuss8

This comment has been minimized.

Copy link
Contributor

@mcmanuss8 mcmanuss8 commented Mar 26, 2020

Another approach here would be to shift from a hard error to a soft error. If you set the value out of the actual range (32-bit or 64-bit), we hard error. If you set it out of the configured range, we soft error: "The prefix limit of $your_input seems very high. Most are less than $what_we_have_in_config. Are you sure it is correct?"

@ccaputo

This comment has been minimized.

Copy link
Contributor

@ccaputo ccaputo commented Mar 26, 2020

There is already a config file with the settings 500000/50000. The limits in https://github.com/peeringdb/peeringdb/blob/master/config/facsimile/peeringdb.yaml are unchanged since when that file was committed on Nov 8, 2018. Updating that periodically to the Potaroo counts rounded up to nearest 100k/10k (v4/v6) seems reasonable. Ie., for now 900k/90k, or even 1M/100k would potentially be good for years.

Out of curiosity, and not because I suggest to use IRR data for this, but here are the prefix counts of the as-set's of some backbones, from a route server operator perspective, along with their current setting in PeeringDB: (left is as-set count, right is info_prefixes{4,6})

125,091 1299.v4 - 426,000
 34,180 1299.v6 - 40,000

123,690 2914.v4 - 350,000
 31,110 2914.v6 - 35,000

122,334 3257.v4 - 350,000
 30,719 3257.v6 - 35,000

113,330 3491.v4 - 500,000
 27,220 3491.v6 - 50,000

123,033 6453.v4 - 250,000
 31,109 6453.v6 - 21,000

 82,205 6461.v4 - 115,000
 14,796 6461.v6 - 8,000

 77,161 6939.v4 - 169,000
 15,628 6939.v6 - 49,000

Another data point, at present 5 networks in PeeringDB set their IPv4 prefix count to the max of 500k, while 68 networks in PeeringDB set their IPv6 prefix count to the max of 50k. I can't see what Gavin wrote in the ticket, but I am curious why there is even a need to go above the current limits.

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Mar 26, 2020

I can't see what Gavin wrote in the ticket, but I am curious why there is even a need to go above the current limits.

If you have AS6939 connected to your IX they already announce 30+k IPv6 routes. HE have set their value to 49k. So, calculating with 40k prefixes and adding headroom (+50%) that would sum up to 60k.

Increasing to 10^6/10^5 for IPv4/IPv6 seems reasonable IMHO

@ccaputo

This comment has been minimized.

Copy link
Contributor

@ccaputo ccaputo commented Mar 26, 2020

I can't see what Gavin wrote in the ticket, but I am curious why there is even a need to go above the current limits.

If you have AS6939 connected to your IX they already announce 30+k IPv6 routes. HE have set their value to 49k. So, calculating with 40k prefixes and adding headroom (+50%) that would sum up to 60k.

Very good point. Just realized my IRR as-set stats above are for aggregated prefixes, and don't account for the announcement of more specifics. (ex. HE agg count of 15,628 but specifics count of 30+k)

Increasing to 10^6/10^5 for IPv4/IPv6 seems reasonable IMHO

Agreed.

@shane-kerr

This comment has been minimized.

Copy link

@shane-kerr shane-kerr commented Mar 27, 2020

Can we set a reminder for 3 or so years from now to raise this value again? 😂

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Apr 4, 2020

@peeringdb/pc could we please vote that @peeringdb/oc sets limits to

  • IPv4: 1,000,000
  • IPv6: 100,000

in the config file

@arnoldnipper

This comment has been minimized.

Copy link
Contributor Author

@arnoldnipper arnoldnipper commented Apr 4, 2020

+1

@grizz

This comment has been minimized.

Copy link
Member

@grizz grizz commented Apr 4, 2020

+1 -- please don't PR that config, it's gone in a few days with #548

@grizz grizz modified the milestones: 1 Decide, 2 Consensus Reached Apr 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.