Tag Archives: internet

Rocket-solid .za DSL setup

After a couple of SOHO router iterations (not all my own, sometimes seen via other people), recurring problems:

  • overheating devices due to bad design
  • crappy stock firmware
  • bugs (that often never get fixed, or updates are never applied)
  • other assorted silly issues, like a 1000-connection session table, or small arp tables, or or or …

Much like the rest of the local linux community, I’d long just done DSL bridging and let a Linux box do the work of Real Internet Connection(tm), but that’s not the easiest pitch for Joe Average Home User. So I found an alternative set of things that works fairly well, and is solid enough for you to fire rockets at it. The recipe is as follows

  • 1x DSL bridge of some kind. Some Broadcom chipsets are excellent
    • I’ve had a hell of a lot of lifetime out of the DSL-2500U
    • if you want cheaper, this Tenda unit
  • 1x Non-shit router
    • A RB750 is pretty good for this. Gets your packets going without too much fancy. Has other benefits too
  • 1x Extra switch, because cheap gigabit is good
    • again, a Tenda unit
    • there are some cheap tp-links and HPs around too that I’ve had before

Cheap, effective, and just slightly annoying on amount of power sockets used. The power used is fairly low, too (we’ve had to test it on another project before, and it’s something like R20/month).

I’ll update the post a bit later with the basic tik config to apply.

Post-jump, things everywhere die

Always a bit interesting to check out stats for things on the internet after a major event like Felix Baumgartner’s jump from space today. Here’s a graph for JINX, one of the two .za INXs.

Interestingly, it seems to have all come from only one of the two GGCs that are visible via that path.

Elsewhere we see similar drops, and also some of the GGCs dying (502’s were served up for a while). Here’s the CAR-IX stats:

During the stream, some people were handed off to Akamai edge nodes. I don’t have that much information on what was happening in all the various networks, though. Will be interesting to see that coming to light soon from the likes of Renesys and such.

Update: I see the first image from this page made it onto one of the .za news syndicators without credit. Nice of them.

Aftermath

So we survived the day pretty well. Yay for things going as they should ;)

A quick summary would be having one query regarding being unable to hit our test site and that turned out to be a browser issue at the client. The following counters from it (stats from around 15h00 SAST):

   2012-06-06  --  228 IPv4 only
   2012-06-06  --  5 Confused
   2012-06-06  --  1 Web Filter
   2012-06-06  --  46 Dual Stack - IPv6 Preferred
   2012-06-06  --  16 Dual Stack - IPv4 Preferred

Not bad, considering we only took it live sometime last night. Some other people didn’t get by quite so well on v6 day though. Yahoo was one of them. When trying to go to ‘www.yahoo.com’, we get redirected to ‘za.yahoo.com’ with the following DNS records:

vandali % host za.yahoo.com
za.yahoo.com is an alias for fd-fp2.wg1.b.yahoo.com.
fd-fp2.wg1.b.yahoo.com is an alias for ds-fp2.wg1.b.yahoo.com.
ds-fp2.wg1.b.yahoo.com is an alias for ds-any-fp2.wa1.b.yahoo.com.
ds-any-fp2.wa1.b.yahoo.com has address 87.248.112.181
ds-any-fp2.wa1.b.yahoo.com has IPv6 address 2a00:1288:f00e:1fe::3001
ds-any-fp2.wa1.b.yahoo.com has IPv6 address 2a00:1288:f006:1fe::3000
ds-any-fp2.wa1.b.yahoo.com has IPv6 address 2a00:1288:f006:1fe::3001
ds-any-fp2.wa1.b.yahoo.com has IPv6 address 2a00:1288:f00e:1fe::3000

This then blows up at one of their Accelerators:
whoohoo

Worth a slight thought, since Yahoo actually appears to see use over much of Africa.

All said and done, a fairly good day. Didn’t notice any major blowouts elsewhere in the internet (although I should note I wasn’t tracking all news), and I look forward to some write-ups by the usual people (Renesys, HE, Evilrouters, etc) in the next few days. We appear to remain one of the most well-connected IPv6 ISPs in South Africa, and in a pretty good position overall.

In-flight wireless-less

Ah, fantastic news strikes again. From this article:

“The system has been configured to allocate 128 IPs, with 124 IPs for passenger use. However, due to the number of passengers (115) utilising multiple devices (some as high as 2-3 devices) on the plane, more than 3 times the allowed connections were constantly requesting access to the internet,” explained WirelessG CEO Carel van der Merwe.

Now, some quick searching indicates that they’re using tech from Row 44 to do this thing. If it’s just satellite downlink, then I quite don’t get the R3.5 million (~$436k USD given a quick check of the current ZAR/USD) pricetag. If it’s the whole shebang, then I guess Row 44 is making some damn nice licensing fees out of airlines on DHCP leases.

Either way, I find it pretty damn hilarious that they didn’t plan for something like this on a flight for tech journos.

Routing for n00bs

In lieu of solar flares, and unicorns, I propose a new protocol name to use when dealing with people who don’t understand routing and friends, people to whom any level of tech explanation would be white noise:

MGP. Stands for Magic Gateway Protocol. It knows just what to do at all times.

Todo: write RFC.

IPConnect And You

The alternative title for this post would be “How your DSL connection actually works (if you’re in South Africa)”, but of course that’s silly long so we won’t go for that. This post is the one that was promised in a recent post, because it’s a subject that is often not entirely understood when being discussed, and I figured I’d rather get it done before I forget about it.

So, first things first: PPPoE. PPPoE is the protocol that’s used to dial up your session to your ISP. Okay, actually, I’ll have to back up a bit further than that. To summarise very shortly from Wikipedia, “Digital subscriber line (DSL) is a family of technologies that provides digital data transmission over the wires of a local telephone network”. The gist of this means “fast internet over your phoneline, while leaving the voice circuit free”. It accomplishes this is by sending specific digital signals over the same line at a higher frequency (this is why POTS filters are used, see more here), and these digital signals are often ethernet frames transported over an ATM circuit. This very last bit isn’t important to the layman reader, except to understand that in the configuration we have in South Africa, it’s not the ideal way to manage a connection.

Now there’s two ways one can normally work with this traffic when you, the customer, dials in. The first is how it currently works: you dial in from your computer, and Telkom “terminates” the session. What “terminates” means in this instance is that their systems are the peer that your communication speaks to (think tin-cans-with-string). The second instance (a scenario called Bitstream) is where your ISP would be the peer for your communication, and they would terminate the session on their LNS (L2TP Network Server). In either case, how this dialing works is by encapsulating a protocol called the Point-to-Point Protocol, or PPP, inside the ethernet frames (think school textbook with your notepapers pushed into the book at all the relevant pages). So effectively the PPP packets carry your actual data, with the ethernet bits being the boat for the river that is the Public Switched Telephone Network, or PSTN.

As mentioned in the previous paragraph, Telkom terminates the PPPoE session here. When you’re dialing in, their AAA servers get an access request for “alex@mydomain.co.za”, look up the AAA servers responsible for “mydomain.co.za” and sends off an access request with the same information, essentially asking “is alex@mydomain.co.za allowed to dial in with this information that was given?”. If your ISPs AAA servers respond “yes”, Telkom’s equipment will go ahead with attempting to set up your connection.

Here’s where it gets sticky. Because it’s Telkom’s network terminating the connection, there isn’t a lot of control that they can give over to the ISP on how to handle customer sessions on their equipment at a national scale, so instead they go for preconfiguring their routers with specific IP pools and routing information. This is why, if you dial from a certain line over and over again, you can quite possibly end up getting the same IP (because the device terminating your connection has a specific, finite set of IPs it could possibly give you). The configuration which Telkom uses for this is designed only around IPv4, and around their equipment “forwarding” your ISP your traffic once it has “de-encapsulated” it. Consequently, for various reasons (technical and otherwise), it is essentially impossible to deliver native IPv6 to an ADSL user in South Africa dialing up with PPPoE. This same configuration is also why all the static IP products in the market require a bit “extra” on top of just a normal dialing process.

The alternative configuration, Bitstream, is one where your ISP would be terminating all traffic, and could give you whatever services they are able to provide (within the constraints of their technical ability). Obviously the latter is the more desired option, and has been requested from Telkom for quite some time now.

Well, that’s it. I’ve tried to not go into an abundance of overly technical details in this post as I felt those could be better served elsewhere, but if there’s any questions or remarks, please do leave a comment so that I could look into it and attempt to answer or clarify.