Kamp Netzwerkdienste GmbH, my long-time German ISP (dating back to long gone 56kbps modem days!) has just sent me a formal notice of termination for my local DSL account. In their letter, they said that they abandoned the private DSL customers segment altogether, and wanted to concentrate on business customers and server hosting.

Needless to say, as a long-time customer of their rather expensive but excellent service, I’m somewhat miffed at their CEO Heiner Lante for not having sent an advanced warning to us oldies so we could get ahead of the pack and have enough time for a graceful migration. The letter was not even signed by Heiner himself, but by some lowly Kamp employee. Yuck! It couldn’t get more disdainful than that. Shame on you! That’s not a fine way to treat your most loyal customers!

Please note that I’ve tried to maintain my old e-mail address This email address is being protected from spambots. You need JavaScript enabled to view it. alive as long as I could by paying an extra monthly fee to Kamp just so they keep a redirect; esp. since I was foolish enough to mention it in the second edition of my Perl book in November 1999, when personal domains were still unusual. Well, there’s nothing preventing even the more trusty ISP to call it quits and go the way of the dodo.

So, I’ve got merely two weeks to find myself a new ISP in Germany before the Kamp DSL link goes down. Oh well!

Fortunately, finding a replacement was pretty fast and moderately easy. Mind you, not as easy as for Joe Sixpack, because of my minimal requirements:

  • The ISP must provide a static IP address via the T-DSL DSL carrier,
  • No port filtering (so I can run my own mail and web servers),
  • Neither censorship nor data retention,
  • A true flat rate.

After a quick lookup and a fast analysis, I’ve decided to give Manuel Schmitt‘s Manitu a try, at least as a stop gap measure. A static IP is available: check. No port filtering: check. No censorship and data retention: check. A true flat rate: FAIL. According to various sources, including their own pages, their “flatrate” is actually a pseudo flatrate with a relative low volume threshold. Exceeding that will get you kicked out, pronto! Not good, but maybe I can expect higher volumina by offering to pay twice to thrice as much as their ridiculously low 10 EUR/month? Tests will tell how much traffic they will accept before getting nervous; and wether offering them to pay more will be acceptable to them.

Fortunately, most of the migration will be as easy as editing /usr/local/etc/mpd5/mpd.conf on my FreeBSD router, and updating the DNS entries pointing to a couple of my servers on my DNS providers’ web interfaces. I’m hosting important domains and using DNS providers in different countries in real data centers anyway for added robustness, and this foresight proved invaluable again:

Never, ever, put all your eggs in the same basket: don’t host your important domains with your ISP.

I’ve got the access data from Manitu within minutes (sic!) after registering with them. Since for the next two weeks, I do have two active ISP piggy-backing on top of my T-DSL connection in Germany, I can switch from one to the other simply by starting mpd5 on the router with a different configuration file. So far, so good. I’m actually very happy with the ease of transition.

However, multihoming with T-DSL is not possible! The following configuration file, which creates a bundle for Kamp and one for Manitu (thus creating ng0 and ng1), fails to bring up L2, if L1 is up — and vice-versa if I reverse the order of the bundles:

pppoe_client:
        create bundle static B1
        set iface route default
        set iface enable nat
        set ipcp ranges 0.0.0.0/0 0.0.0.0/0
        set ipcp disable vjcomp
         
        create link static L1 pppoe
        set link action bundle B1
        set auth authname "XXXXXXXXXXXXXXXXXXXXX"
        set auth password "XXXXXXXXXXXX"
        set link max-redial 0
        set link mtu 1460
        set link mru 1460
        set link keep-alive 10 60
        set link disable acfcomp
        set link disable protocomp
        set pppoe iface sis0
        set pppoe service "KAMP"
        open
 
        create bundle static B2
        set iface route default
        set iface enable nat
        set ipcp ranges 0.0.0.0/0 0.0.0.0/0
        set ipcp disable vjcomp
         
        create link static L2 pppoe
        set link action bundle B2
        set auth authname "YYYYYYYYYYYYYYYYYYYYYY"
        set auth password "YYYYYYYYYYYYY"
        set link max-redial 0
        set link mtu 1460
        set link mru 1460
        set link keep-alive 10 60
        set link disable acfcomp
        set link disable protocomp
        set pppoe iface sis0
        set pppoe service "MANITU"
        open

That true parallel (simultaneous) multihoming doesn’t work with T-DSL is good to know, even though I didn’t find a single location on the Net where it is documented!

I can effectively register with a couple of ISPs which tunnel their traffic via T-DSL, and mpd5 will happily switch from the main ISP (the first bundle) to the backup ISPs (the next bundle(s)), should the main ISP drop its PPPoE tunnel. However, it won’t set up two parallel circuits, each one using a different ISP.

Whatever. I’ll test Manitu now and will report how they behave. Let’s hope for the best (and expect the worst). ;)