Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network
On Tue, Sep 20, 2011 at 10:22 AM, Jon Lewis <jlewis@lewis.org> wrote:
On Tue, 20 Sep 2011, Dorn Hetzel wrote:
If what you have is LEC frame relay service over which you have PVCs to
two providers of IP transit service, then, IMO, you are multihomed. Are you protected against every single failure mode? No, but then neither are many folks with more traditional methods of multihoming. You are certainly afforded reasonable protection against routing issues on each of your two providers.
I'd agree in that case that you do have connectivity to two providers and are multihomed, though in a very foolish way.
Past experience has taught me that while Layer 2 LEC frame certainly fails, it may do so quite a bit less often than the rate of routing flaps, peering spats, and everything else that can go wrong at Layers 3..9 ... So while it's not physically diverse, it may still yield a significant reduction in downtime compared to that same T1 direct to a single Layer 3 provider...
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? Perhaps I just have a corporate ASN, and my backup connection is the most I can afford to make sure at least email gets through when the primary is down. 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... -dorn
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. 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". 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.
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. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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
I plan to announce my ASN out of 3 physically diverse hops over 100mbps or gige. I believe that qualifies as multihoming under pretty much all definitions? On that note, is anyone familiar with peering fabrics in 60 Hudson and 600 West 7th (or peering fabrics that are fiber close in those locations)? Initial connectivity/peering will be with my initial ISP friend in 600, and with KCIX in KC MO. Would like to also peer with any peering exchanges in LA and NYC. I suppose peeringdb.com would be the place to look for this? (bringing this thread back on the original topic, though multihoming discussions definitely fall under the starting an isp category) :)
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".
You say that like it's a bad thing.
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.
If you have a GRE tunnel to each of 2 ISPs and announce your route over BGP to them, or, have some other configuration with them and they both announce your prefix to the rest of the world, that meets the ARIN test. The rest is an issue for the network administrator and not a matter for ARIN policy. ARIN policy does not require your network to be functional or even useful. It's up to each administrator to decide how they want to operate their network and what level of dysfunction/lost packets they consider acceptable.
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 would oppose such a policy change. I believe it is out of scope for ARIN's mission of address administration. Owen
On Sep 20, 2011 3:21 PM, "Owen DeLong" <owen@delong.com> wrote:
If you open the door to that sort of interpretation, then every org with
You say that like it's a bad thing.
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
If you have a GRE tunnel to each of 2 ISPs and announce your route over BGP to them, or, have some other configuration with them and they both announce your prefix to the rest of the world, that meets the ARIN test. The rest is an issue for the network administrator and not a matter for ARIN
a T1 and a backup dial-up connection can claim to be "multihomed". 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. policy.
ARIN policy does not require your network to be functional or even useful.
It's up to each administrator to decide how they want to operate their network and what level of dysfunction/lost packets they consider acceptable.
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 would oppose such a policy change. I believe it is out of scope for ARIN's mission of address administration.
It should be opposed because it would smack of restraint of trade, and that is not a good place to be.
On 9/20/11 12:24 PM, Dorn Hetzel wrote:
On Sep 20, 2011 3:21 PM, "Owen DeLong" <owen@delong.com> wrote:
If you open the door to that sort of interpretation, then every org with
You say that like it's a bad thing.
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
a T1 and a backup dial-up connection can claim to be "multihomed". 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.
Yes. I've done it before. As long as the provider supports BGP communities to tweak localperf you won't get any traffic over it and you won't even need to prepend once. Prepending is really only a last resort if you got stuck with a dud provider that doesn't support communities. ~Seth
participants (5)
-
Charles N Wyble -
Dorn Hetzel -
Jon Lewis -
Owen DeLong -
Seth Mattinen