On Tue, Sep 20, 2011 at 12:13 PM, Jon Lewis <jlewis@lewis.org> wrote:
Dorn, you have some interesting mail habits. Your message was sent directly to me (without list). My reply to that message was to you (without the list). Now you're replying to that reply and including the list again. That's generally frowned upon, but in this particular case, no harm done.
My apologies on that. I made the first reply from my droid, meant to reply/all, but somehow failed that and just used reply. When I got your reply to just me, I realized what I had done, and tried to correct it by including the last two bits of conversation and changing it back to reply/all. The original conversation had started as public, so I admit I probably assumed that I could revert it back to public with no harm. Nonetheless, you are correct, it was not the best form overall...
More inline....
On Tue, 20 Sep 2011, Dorn Hetzel wrote:
How about a hard T1 to provider A and a GRE tunnel over a 3G router for a
backup? That's certainly physically diverse...
If I was the ARIN auditor, I'd say that's borderline acceptable as multihomed. It's not much different from one of your connections being "wireless", as long as that 3G connection is of sufficient bandwidth to of meaningful utility if the T1 is down. If your primary connection is T1/T3/ethernet/etc. and your second is a v.90 modem, then I'd probably call BS on the claim of being multihomed.
So now you think ARIN should be judging how much bandwidth is enough,
and how much is not?
To a certain degree, yes. If your normal traffic level is several hundred mbit/s for instance, and you're doing that with one provider via gigabit ethernet, then a 3g wireless connection and GRE tunnel to a second AS is not multihoming.
If you open the door to that sort of interpretation, then every org with a T1 and a backup dial-up connection can claim to be "multihomed".
Well, if their backup dial-up connection is *normally dialed up* and *normally announcing routes* I would certainly agree that it is. Note that I use the word *normally* instead of *always*, since very nearly nothing can manage to do something *always* in the strictest sense of the word :)
In either of these cases, it's not enough to just have the connection. The ARIN NRPM definition of Multihomed includes "has one or more routing prefixes announced by at least two of its upstream ISPs." Are you really going to announce your prefix[es] to both your real provider _and_ your ridiculously low bandwidth provider? Even if you prepend the latter considerably, you're likely to receive some traffic via that path.
Well, it's ugly, but it's possible to announce more specific prefixes over the route you want the traffic to take, say announcing two /24's over the main connection and one /23 over the backup. Yes, I know it pollutes the route table, etc etc, but it can work and I have held my nose and done it when it was the only feasible solution...
It's a slippery slope from "v.90 not good enough" to "less than 2xOCn not
good enough" where n can be adjusted to suitably limit competition...
Perhaps the manual should be updated to replace "full-time connectivity" with something a bit more fleshed out specifying that the full-time connectivity be via dedicated circuit [frame-relay permanent virtual circuits included, if you can still find a LEC willing to sell them] or PTP wireless.
I use a LEC frame PVC every day, so I can vouch for their continued
existence :) My personal opinion is that full-time connectivity just needs to mean "normally connected", and that questions of transmission technology and bandwidth are out of scope with regards to this discussion. Frankly, even a second BGP session over a GRE tunnel riding the Layer 3 connectivity provided by the primary connection is STILL redundant for some types of failures as long as the failure is not in the middle of the portion of the primary network that the GRE tunnel transits... Regards, -Dorn