Stupid Question maybe?

Wed Dec 26 13:56:26 UTC 2018

When I first started working with Cisco products (around 1999) I came upon
a router doing NAT for internet access that used a discontiguous mask to
determine which address to PAT the hosts against as they were doing some
creative load balancing.  It worked really well, no matter what part of the
'block' the DHCP server gave inside addresses out to.  I was stumped for
the longest time trying to figure out what this did.

Chuck

On Mon, Dec 24, 2018 at 3:11 PM Tony Finch <dot at dotat.at> wrote:

>
> 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/20181226/78a1f9a9/attachment.html>