<div dir="ltr">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.<div><br></div><div>Chuck</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 24, 2018 at 3:11 PM Tony Finch <<a href="mailto:dot@dotat.at">dot@dotat.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr">On 18 Dec 2018, at 22:30, Joel Halpern <<a href="mailto:jmh@joelhalpern.com" target="_blank">jmh@joelhalpern.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>History of non-contiguous network masks, as I observed it. [snip]</span><br><br><span>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.</span></div></blockquote><br><div><span style="background-color:rgba(255,255,255,0)">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.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div>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 <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12071" target="_blank">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12071</a>)</div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">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.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">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 :-)</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">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 :-)<br><br></span><div dir="ltr"><span style="background-color:rgba(255,255,255,0)">Tony.</span><div><span style="background-color:rgba(255,255,255,0)">-- </span></div><div><span style="background-color:rgba(255,255,255,0)">f.anthony.n.finch  <<a href="mailto:dot@dotat.at" target="_blank">dot@dotat.at</a>>  <a href="http://dotat.at" target="_blank">http://dotat.at</a></span></div></div></div></div></blockquote></div>