Why 127.0.0.1 could trip up your Windows Server analytics
Location ought to be such a simple idea. Not since the days of the schoolyard have I wasted any serious time over that old syntax-versus-context joke: “Here? No, there. Your there is my here…”
It might have been funny the first time, but it certainly stops being funny after a few repeats. It ought to have imparted a lesson in the relativity of references that stayed with me for life, but it doesn’t seem to have worked that way; it was only recently that I realised there’s a whole category of traps for the unwary network fiddler that have this very same paradox as their underlying cause – they revolve around the ambiguity of the TCP/IP equivalent of the simple English word “me”. (Don’t let this inhibit you from puzzling and entertaining your preschool toddler with the “I am me, you are you” conundrum: preschool toddlers have a far better sense of humour about such matters than do typical network servers and workstations.)
The handling of this whole topic is shot through with bodges, laziness, contradictory positions and simple misapprehensions
The TCP/IP equivalent of “me” is actually network address 127.0.0.1 or “localhost”. This convention is ancient as network rules go, and that address and name are therefore reserved in a wide variety of fashions by all kinds of networking code, both inside your PC’s OS and outside it in things such as routers, firewalls and DSL connections.
The way this has been implemented for Windows users is patchy and scattered, mainly because the gestation of TCP/IP and the gestation of Windows weren’t tightly linked; in fact, they weren’t linked at all until rather recently. Hands up all those who know what lurks inside the folder Windows/System32/Drivers/etc?
In there you can still find, even nowadays, signs of the way that the world-spanning internet protocol was bodged into co-operating with an only partly willing desktop operating system. Never mind all the tiles and whizzy touchscreens and gesture-based control: lessons about TCP/IP that I learned back in the days of Windows for Workgroups still earn me good money for fixing up misbehaving networks almost two decades later. More than that, those old bodges can still trip up the most well intended of modern solutions.
This month, a case in point demonstrated a rather more ambitious version of that old schoolyard “here/there” jape, one that goes by the name of the Windows Server 2008 R2 Best Practices Analyzer (BPA). As I write this column I’m on a Business Clinic trip, hiding out from a proper hooley that’s going on in my B&B in Snowdonia, but even from this remote spot I can still hear the reactions of complete puzzlement from the small-business network owners, the groans from the support professionals, the weary sighs of resignation from enterprise-networking guys.
But let’s talk a bit more about 127 before we talk about BPA. As an antique, special-purpose address that dates back to the primeval specification of TCP/IP, this one is as special and peculiar as 0.0.0.0 (which is an address that may be written down, but can’t realistically ever be used). You can’t fill it in as an answer in either DHCP or DNS Windows Server administrator utilities, and if you do try to use it as a configuration, weird stuff may (or may not) happen.
Why is this? Why is Cassidy giving yet another woolly and over-complicated answer to a perfectly clear, simple four-octet IP address? Well, basically because the handling of this whole topic is shot through with bodges, laziness, contradictory positions and simple misapprehensions. One example that comes to mind was a client of mine, whose traditional 192.168.0.x network range had been replaced by 127.0.0.x, because the well-intended but somewhat confused technical man had misremembered the relationship between private address ranges, numbering and “.local” as a DNS name for your internal network and Windows domain.