Stupid Question maybe?

Tony Finch dot at dotat.at
Mon Dec 24 20:08:40 UTC 2018


> On 18 Dec 2018, at 22:30, Joel Halpern <jmh at joelhalpern.com> wrote:
> 
> History of non-contiguous network masks, as I observed it. [snip]
> 
> When we were done, other folks looked at the work (I don't know if the Internet Drafts are still in repositories, but they shoudl be.)  And concluded that while this would work, no network operations staff would ever be able to do it correctly.  So as a community we decided not to go down that path.

In the late 1990s I was doing web server things at Demon Internet. Our “Homepages” service provided an IP-based virtual host for each customer (it predated widespread support for HTTP Host: headers), and by the time I joined the service had two /18s and a /16 of web sites (if my memory is correct). We were allocating addresses to customers sequentially, so the /18s were full and the /16 was in progress.

We had a small number of front-end Squid reverse proxy caches which owned all the IP addresses, using a BSD kernel hack (which I worked on to get published but it never got committed upstream https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12071)

The problem was that the entirely static load spreading relied on the routing config upstream from the reverse proxies, and IIRC it just divided the space into /18s and allocated them to proxies. So the load allocation was very uneven.

I thought up a cunning hack, to divide the /16 by using a non-contiguous netmask of 0xffff0003 instead of 0xffffc000, so that successive customers would be allocated to front ends 0,1,2,3 cyclically. Fun :-)

But I observed that one of my colleagues had a CIDR chart stuck on the side of his monitor, and that all the documentation in this area warned of dragons and bugs, and I realised that it would be unwise to do more than try it out experimentally :-)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181224/b7044463/attachment.html>


More information about the NANOG mailing list