Saturday, January 28, 2006
Tunnelling through the Internet
Some of the networking we're doing at The Office is beginning to scare me, and not because it's complex, but because … well … it's complex and it seems like a kludge.
Basically, we're providing a backup Internet connection for one of our customers via DSL; they have an existing Internet connection with another provider. We are also giving them a block of IP addresses to use even when their primary Internet connection is working! So we need to route a portion of our network through some other provider to our customer.
And yes, it can be done, but the way it's being done leaves a … bad taste in my mouth. Basically, traffic for the customer's network arrives in our network, hits our router, the router will then encapsulate that network traffic within another IP connection back out out network and through the customer's existing provider to a router (which we set up) at the customer's office.
Yes, we're tunnelling IP packets within IP packets.
There's nothing inherently wrong with that, but it does have all sorts of fun implications for the customer's network traffic (for instance, they also have a wireless router at their office. They could only bring up Google. Any other site would fail to load, or only load a partial page. Turns out that since we're tunnelling IP packets within IP packets, the maximum packet size we can transmit is a bit smaller than normal, only the wireless router couldn't figure this out—I had to manually set the packet size to be about 3% smaller than normal on their wireless router. Why could they get to Google? Probably because Google configured their routers to send small packets).
(Oh, another for instance: it's almost impossible to traceroute to the customer's network, so now it's harder to trackdown networking problems. Oh, and another one I just remember: it adds an additional 11 hops that packets have to travel to reach their final destination.)
