This week’s snafu comes from a colleague of mine in
The networking for this organization had been outsourced to a global company whose name you would recognize. It was this company that handled the organization’s router infrastructure. My colleague was only responsible for managing the organization’s servers and workstations.
The problem with laziness only became apparent when it came time to renew the company’s domain registrations. The IP address of the registrar’s website just happened to be located in a class C range adjacent to the ranges allocated to the organization. For some reason it was simply impossible to bring up the registrar’s website, even though it was accessible when my colleague connected through his private ISP’s dialup network
It took my colleague some time to figure out why a tracert would only get to the perimeter router. As the organization was large and geographically dispersed, my colleague wasn’t sure himself what public IP address ranges had been assigned to his organization. He eventually found the original documentation and wrote up a list.
My colleague then called the organization that was responsible for managing the routers. He asked that the route table on the perimeter router be read back to him. This is where the problem lay. It turned out that more than a year before, a guy who had since left the outsourcing company, had set up the routing tables on the organization’s perimeter router. Rather than perform a complex subnetting calculation to precisely map out the 50 class C addresses, he configured the router in a blunt way, telling the perimeter router that the organization’s internal network had a range equivalent to a class B block. Rather than enter many entries in the router table, he decided he could get by with one. Although it was possible to use an elegant solution involving classless interdomain routing, the outsourcing company decided upon, the less elegant solution of entering each of the 50 internal networks manually into the routing table.