I'm guessing it follows the route of the larger block until it gets to a hop with the correct route and goes from there.
Internet routing table breaks 512,000 routes
- Thread starter Francisco
- Start date
-
- Tags
- bgp network ohgoditburns
No vote required. Nobody will be allowed to announce anything smaller than a /24 period. Some upstreams will accept /25's but only local to the AS it gets filtered upstream.
As it stands there are too many people de aggregating to /24's as space gets more fragmented for various reasons.
The DRFZ Default Routing Free Zone aka the internet if properly aggregated would just have about 288k routes in the table and a lot of us would be happy with that. Algorithms have been run to see which providers are the worst de-aggregate offenders , think the top one is in brazil with over 3000 prefixes being announced, when about 128 if it was aggregated.
You can see stats about these things @ http://www.cidr-report.org/2.0
As has been discussed on NANOG and other mailing lists is that if you were in the market today you would want a router that supported 2M routes, upgradable to 4M for the future because if the growth curve continues were looking at 1.25M routes in about 4 years.
Most providers can get away with TCAM adjustments to 768K routes because they need to leave room for IPv6 growth, but that is only expected to last a year or so.
As it stands there are too many people de aggregating to /24's as space gets more fragmented for various reasons.
The DRFZ Default Routing Free Zone aka the internet if properly aggregated would just have about 288k routes in the table and a lot of us would be happy with that. Algorithms have been run to see which providers are the worst de-aggregate offenders , think the top one is in brazil with over 3000 prefixes being announced, when about 128 if it was aggregated.
You can see stats about these things @ http://www.cidr-report.org/2.0
As has been discussed on NANOG and other mailing lists is that if you were in the market today you would want a router that supported 2M routes, upgradable to 4M for the future because if the growth curve continues were looking at 1.25M routes in about 4 years.
Most providers can get away with TCAM adjustments to 768K routes because they need to leave room for IPv6 growth, but that is only expected to last a year or so.
Wintereise
New Member
People usually set a defroute to one of their carriers to find 'stray prefixes' and route them through to that carrier.
What to do with that traffic then becomes the carrier's responsibility, but thankfully most core routers should have no issue dealing with any of this.
> No vote required. Nobody will be allowed to announce anything smaller than a /24 period. Some upstreams will accept /25's but only local to the AS it gets filtered upstream.
This is the ideal situation now, I'm really curious what happens when obtaining further allocations by any means whatsoever becomes impossible (So, say, 2-3 years down the road, I guess for all RIRs?)
As Francisco mentioned, there's a vote on it on ARIN PPML and desperate times are known to call for desperate methods.
I'm assuming if their equipment supports multi-path they, tehy'd get a default route from each upstream and then it'd round-robin it. If not, yes, they'd favor one path for a default route.
Interesting article:
http://www.bgpmon.net/what-caused-todays-internet-hiccup/
From the looks of it, it isn't like everyone went and filtered their routes or upgraded and we're over that hump. It looks like we're due for another episode like this once things grow to 512k naturally.
I'm surprised to see that liquidweb got pants on this too.
Francisco
Filtering /24 via prefix list would cause that specific route to not be installed so a more generic route (default route, or larger route will be use) , remember the specifics usually win, then if not, the default route is used or the larger allocation.
Considering these 2 situations:
Customer A is announcing 1.1.1.0/24
Customer A's ISP has 1.1.0.0/18 (or whatever)
Since Customer A is announcing 1.1.1.0/24 that is a more specific match and it will be used for transit.
But if you filter /24's via prefix list, the following will happen:
1.1.1.1/24 <-- filtered, so we go to the next 'larger' allocation.
1.1.0.0/18 <-- this will be be shown only in the routing table, and it will be used for transit.
EDIT: It amazes me there are providers out there that use a /24 and are single homed. They should use static routes or iBGP and not announce their prefixes out to the internet. Use a private AS so you can manipulate your bgp communities or whatever.
Considering these 2 situations:
Customer A is announcing 1.1.1.0/24
Customer A's ISP has 1.1.0.0/18 (or whatever)
Since Customer A is announcing 1.1.1.0/24 that is a more specific match and it will be used for transit.
But if you filter /24's via prefix list, the following will happen:
1.1.1.1/24 <-- filtered, so we go to the next 'larger' allocation.
1.1.0.0/18 <-- this will be be shown only in the routing table, and it will be used for transit.
EDIT: It amazes me there are providers out there that use a /24 and are single homed. They should use static routes or iBGP and not announce their prefixes out to the internet. Use a private AS so you can manipulate your bgp communities or whatever.
Last edited by a moderator:
Given many users on the Cisco 6500's are likely going to chop away at how much IPV6 table space they have just to make way for V4 space, don't get your hopes up.
I just think a lot of people in a position of "we must upgrade", will simply go the default route option or route filtering instead of upgrading. A lot of those people could very well be on equipment that either doesn't support IPV6 or does IPV6 in software making it useless.
Francisco
Kris
New Member
+1 on what Francisco said.
With older 6500 series and ISPs re-allocating TCAM to keep up with v4, hard limiting v6 routes = no v6. '
Especially once you can't fit the full v6 routing table once it's widely deployed.
The 6500's are work horses so yeah, I don't think people are going to rush to replace them unless they really want a full IPV6 + IPV4 table.
It's the usual catch 22. Companies aren't bothering to setup IPV6 because there's no demand. There's not a lot of demand because companies aren't bothering to set it up.
While ARIN & co are predicting 50% of all wired devices to be IPV6 capable by 2018 (https://twitter.com/TeamARIN/status/479358717126000641), that doesn't mean networks will be wired for it.
There's way too many cases on WHT lately of people getting their only /22's from RIPE and then instantly trying to sell it for a little side cash. As I and many others have been saying, expect the routing table to get huuuuge in the coming few years and more and more blocks are carved.
Francisco
Last edited by a moderator:
As I recall, IPv6 requires significantly less TCAM space for its routes than IPv4 did. 6500's with slightly less IPv6 TCAM can still hold out for some time as IPv6 begins to grow in adoption. But yes, itis a band-aid solution for the issue at hand.