hello,
I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24…
I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly NAT’ed, 32 IPv4s are sufficient for most of the small and medium sized organizations and also home office workers like youtubers, and professional gamers and webmasters!
It is because BGP research and experiment networks can not get /24 due to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world.
What do you think about this?
What could be done here?
Is it unacceptable; considering most big networks that do full-table-routing also use multi-core routers with lots of RAM? those would probably handle /27s and while small networks mostly use default routing, it should be reasonable to allow /25-/27?
Thanks for reading, regards…
Not going to happen any time soon (if at all).
#show ip route summary | i Source|---|bgp
Route Source Number Of Routes
------------------------------------- -------------------------
bgp 925809
Think about how much network gear is out there that is straining under the current size of the global table. Opening the flood gates to many more prefixes with /25-/27 routes in the global table would mean lots of gear needs to be upgraded/replaced sooner rather than later.
Wasn’t it about 1997 or so when we ran into deployed Cisco gear (5500s back then) running out of memory for BGP routes? Been there, done that. -Joe
Wouldn’t /48s be a better solution to this need?
Owen
CIDR and aggregation in the early 1990s was developed in response to AGS+ routers falling over under
the strain of the global size back then. Since then, IPv4 has been a progressive loosing proposition and
only gets worse every year. This proposal could certainly accelerate the rate at which it continues to get worse.
Owen
I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24..
It is because BGP research and experiment networks can not get /24 due to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world.
Hello,
Each BGP route advertised into the global table is expensive. Not for
the advertiser... for everyone else. See
https://bill.herrin.us/network/bgpcost.html
Caveat that the document is based on 2008 data. The numbers (though
probably not their shape) have changed.
What do you think about this?
I think you'll convince the IETF to release the Class-E space before
you convince the ISPs to broadly honor sub-/24 prefixes.
What could be done here?
In principle, a company could make a business out of announcing a
large block from a bunch of peering points and then tunneling (vpn)
parts of it back to customers with sub-/24 assignments. With a broad
enough selection of peering points, the routing would not be too
inefficient. And it would divorce the IP addresses from the last-mile
Internet infrastructure, allowing you to take your addresses with you
as long as you kept paying the tunnel company.
In practice... there's not enough money in it. If you could ante up
the cost, you could find a way to qualify for and acquire a full /24.
Is it unacceptable; considering most big networks that do full-table-routing also use multi-core routers with lots of RAM?
You're thinking of DRAM. But that's not the way it works. Some routers
use heavily parallel routing engines, each of which need enough dram
to hold the full forwarding information base and which can suffer from
CPU cache exhaustion even then. Others use an expensive kind of memory
called a TCAM that's very fast but both expensive and power hungry, so
generally not sized for huge numbers of tiny routes.
Regards,
Bill Herrin
IMO, No. ipv4 is not dead yet. we need to raise it, a bit.
Agree to disagree… We need to put the final stake through its heart and move on.
EINAT solutions are OK
I presume you mean CGNAT? Otherwise, not sure what EINAT is and couldn’t find
a reference with a quick google search.
Again agree to disagree. NAT is bad and more NAT is just worse.
The future will come very quickly, right now.
One can hope, but it seems to be taking a long time so far.
We just need to invest in the internet.
Yes, but let’s focus that investment where it makes sense. IPv4 isn’t that.
Owen
Take that to its logical conclusion and you'll invent MPLS.
Regards,
Bill Herrin
In principle, a company could make a business out of announcing a
large block from a bunch of peering points and then tunneling (vpn)
parts of it back to customers with sub-/24 assignments. With a broad
enough selection of peering points, the routing would not be too
inefficient. And it would divorce the IP addresses from the last-mile
Internet infrastructure, allowing you to take your addresses with you
as long as you kept paying the tunnel company.
Actually, such a service would be much easier to stand up as a bunch
of virtual routers running on VPS instances in various cloud providers.
Simple as standing up a VPS running Debian 12 and FRR, then sell
routed blocks to people.
Personally, I think that’s fairly hideous, but someone can probably find a
way to make money doing it.
I know that there are companies charging $ridiculous for “SDN” solutions
that are literally not much more than a tunnel running between two
AWS nodes.
In practice... there's not enough money in it. If you could ante up
the cost, you could find a way to qualify for and acquire a full /24.
Given what some of the SDN providers out there are charging, I’m not
so sure that’s true. YMMV.
Is it unacceptable; considering most big networks that do full-table-routing also use multi-core routers with lots of RAM?
You're thinking of DRAM. But that's not the way it works. Some routers
use heavily parallel routing engines, each of which need enough dram
to hold the full forwarding information base and which can suffer from
CPU cache exhaustion even then. Others use an expensive kind of memory
called a TCAM that's very fast but both expensive and power hungry, so
generally not sized for huge numbers of tiny routes.
Trio and Later generations of Juniper MX line cards (which are getting fairly
long in the tooth these days) can handle more than 5M routes in the FIB.
Even the old (now ancient) DPCs can handle ~1.5M routes if you don’t
need a boatload of access lists. (Basically you have to steel FIB memory
from the Access List memory partition, but that’s a simple software
command and a reboot of the line card).
Owen
> In principle, a company could make a business out of announcing a
> large block from a bunch of peering points and then tunneling (vpn)
> parts of it back to customers with sub-/24 assignments. With a broad
> enough selection of peering points, the routing would not be too
> inefficient. And it would divorce the IP addresses from the last-mile
> Internet infrastructure, allowing you to take your addresses with you
> as long as you kept paying the tunnel company.
Actually, such a service would be much easier to stand up as a bunch
of virtual routers running on VPS instances in various cloud providers.
Simple as standing up a VPS running Debian 12 and FRR, then sell
routed blocks to people.
Sure, depending on the data rates. I do something similar with my own network.
It would be a challenge to push multiple gbps of data this way. Just
because a user's demand for IP addresses is small doesn't mean their
demand for bandwidth is.
> You're thinking of DRAM. But that's not the way it works. Some routers
> use heavily parallel routing engines, each of which need enough dram
> to hold the full forwarding information base and which can suffer from
> CPU cache exhaustion even then. Others use an expensive kind of memory
> called a TCAM that's very fast but both expensive and power hungry, so
> generally not sized for huge numbers of tiny routes.
Trio and Later generations of Juniper MX line cards (which are getting fairly
long in the tooth these days) can handle more than 5M routes in the FIB.
Maybe. That's where my comment about CPU cache starvation comes into
play. I haven't delved into the Juniper line cards recently so I could
easily be wrong, but if the number of routes being actively used
pushes past the CPU data cache, the cache miss rate will go way up and
it'll start thrashing main memory. The net result is that the
achievable PPS drops by at least an order of magnitude.
No free lunch I'm afraid. The exact characteristics differ, but both
approaches grow rapidly in expense with the size of the forwarding
information base (FIB).
Regards,
Bill Herrin
When you say, you've not delved into the Juniper line cards recently,
to which specific Juniper linecard your comment applies to?
Hi,
For testing/research take a look on dn42.net.
Thanks,
Well, it depends.
The question below was evidently related to business.
IPv6 does not have yet a normal way of multihoming for PA prefixes.
If IETF (and some OTTs) would win blocking NAT66,
Then /48 propoisiton is the proposition for PA (to support multihoming).
Unfortunately, it is at least a 10M global routing table as it has been shown by Brian Carpenter.
Reminder, The IPv6 scale on all routers is 2x smaller (if people would use DHCP and longer than/64 then the scale would drop 2x additionally).
Hence, /48 proposition may become 20x worse for scale than proposed initially in this thread.
Eduard
RAM is not the issue... it's FIB.
If you pay me for FIB slots, I'm happy to install /32's to your heart's content :-).
Mark.
For that to be an issue, packets would need to be CPU switched which isn’t the case on the MX platform.
Owen
IMO, No. ipv4 is not dead yet. we need to raise it, a bit.
EINAT solutions are OK
The future will come very quickly, right now.
We just need to invest in the internet.
Thanks for sharing ideas. I respect them all.
how would you route 800 Gigabit-ethernet that will soon be released as IEEE standart?
we were paying 1 usd per megabit several years ago. now it is as low as 4 usd cent.
As i said before, the future is coming just now. There must be ways to increase CPU caches and memories of routers.
It is also about wholesale. When you buy cheaper routers, powerful routers stay expensive.
But when everybody upgrades, memory and processor unit prices decrease… Vendors gain from demand.
Also keep in mind;
single-homed networks never need full-table…
multi-homed networks could also do default routing just packet-mark incoming interface and then route packets out via same interface…
I do not see gain in running BGP full-table, excluding networks using Intelligent routing optimizers that run jitter and ping tests…
but these are just my ideas…, i respect all ideas… we are here to discuss…
There are people running full-table of v4 and v6 just for fun… I guess it makes them happy when they look thousands of routes available on single interface!
I am pretty sure Tier-1 and Tier-2 networks have enough money for upgrades. But i may be wrong. What do you think?
Thanks and regards