In my (rather extensive) practice, multihoming by itself is usually a major source of connectivity problems. Whoever arguing _for_ mulihoming for everyone forgets that taking more routing information in has dangers not present when you don't do routing yourself. I never saw any customer who had the ability to configure a multihomed site properly on their own; and most of the bogus routing information comes from multihomed customer sites. It is _much_ better to multihome to the same provider who then can take care of messy global routing. --vadim PS A UPS for CPE usually fixes 95% of transmission problems. I've seen people willing to spend money on multihoming but doing things on commercial power.
Vadim Antonov writes:
In my (rather extensive) practice, multihoming by itself is usually a major source of connectivity problems.
Agreed.
Whoever arguing _for_ mulihoming for everyone forgets that taking more routing information in has dangers not present when you don't do routing yourself.
I never saw any customer who had the ability to configure a multihomed site properly on their own; and most of the bogus routing information comes from multihomed customer sites.
It is _much_ better to multihome to the same provider who then can take care of messy global routing.
Agreed. The arguement here (if there is one) is that their is a demand in the marketplace for multihoming to different providers and what is the best way to treat these customers. Sprint's filtering is a good arguement for having multiple Sprint connections or non at all. The customer that is multihomed to Sprint and a different provider, however, is still paying Sprint to move their bits around even if their Sprint connection goes down. I support all incentives to reduce the number of multihomed customers.
--vadim
PS A UPS for CPE usually fixes 95% of transmission problems. I've seen people willing to spend money on multihoming but doing things on commercial power.
And not plugging their routers into outlets on light switches would also help. -Hank
On Mon, 19 Aug 1996, Vadim Antonov wrote:
Whoever arguing _for_ mulihoming for everyone forgets that taking more routing information in has dangers not present when you don't do routing yourself.
Many end-users use the term "multi-homing" as a synonym for "redundant connectivity". In other words there are ways to satisfy such a customer's needs without having then run BGP or even having them visible in the routing tables of the core mesh. However, if an ISP does not inquire into the customer's needs but merely assumes that they want to run BGP and be globally visible then you are right, they expose the customer to the dangers of global routing needlessly.
I never saw any customer who had the ability to configure a multihomed site properly on their own; and most of the bogus routing information comes from multihomed customer sites.
It is _much_ better to multihome to the same provider who then can take care of messy global routing.
Exactly! And we should promote those tier 2 providers like IXA, Netaxs, TLG and others who can provide this kind of service. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
In my (rather extensive) practice, multihoming by itself is usually a major source of connectivity problems.
in my meager and bottom-feeding scum-sucking practice, multi-homing decreased unreliability delivered to our customers by a factor of ten or more. this very moment i am sitting at a site which is single-homed to an anonymous NSP's major POP in a farming town in mid-Cal. i can not get to www.cisco.com from here. yet i can get to my home net, which is quite multi-homed, and get to cisco from there. so, as we say in my family, i smell cows.
It is _much_ better to multihome to the same provider who then can take care of messy global routing.
just what i always wanted, two connections to a broken provider. you must be kidding. randy
From: randy@psg.com (Randy Bush) Subject: Re: Customer AS
It is _much_ better to multihome to the same provider who then can take care of messy global routing.
just what i always wanted, two connections to a broken provider. you must be kidding.
I guess this brings to mind the question: Why would you want *any* connections to a broken provider? RobS
Randy Bush writes:
just what i always wanted, two connections to a broken provider. you must be kidding. I guess this brings to mind the question: Why would you want *any* connections to a broken provider?
all providers break.
Most providers also pretend this doesn't happen. One thing I'm increasingly impatient with is the following: You call up operations center for provider X. "Why is it that I'm having trouble contacting node N?" "Well, the router in Foostown is down." "What do you mean, *THE* router in Foostown? You only have ONE!?" When I've worked on building internal networks for banks, we've typically done "no single point of failure" designs. Two links everywhere over diverse paths, two routers carrying the traffic from every point, etc. This means that no single router or piece of equipment or cable dying can bring you down. If you architect things right, it doesn't even cost that much more -- routers end up handling disjoint subsets and the like. The real expense is multiple lines, but that can often be used as a way to upgrade your bandwidth. We can't pretend to be able to replace the phone networks until we can achieve similar reliability. Phone networks typically are spec'ed to two minutes a year downtime. We have a giant advantage in so far as our protocols allow us to do failover far more gracefully. People should start taking advantage of that. The fact that things aren't nearly that reliable yet is the reason people are forced to multihome their customer networks. Perry
Randy Bush writes:
In my (rather extensive) practice, multihoming by itself is usually a major source of connectivity problems.
in my meager and bottom-feeding scum-sucking practice, multi-homing decreased unreliability delivered to our customers by a factor of ten or more.
Same with my customers, usually.
It is _much_ better to multihome to the same provider who then can take care of messy global routing.
just what i always wanted, two connections to a broken provider. you must be kidding.
No, frighteningly they are not kidding. I tend to find people recommending not multihoming or getting multiple connections to one provider typically work for a provider and have a serious case of head swelling. My customers who want to make sure that their net connections are almost always up multihome, and are almost always happy for it, because there is no alternative. Equipment breaks, people fumble while typing into their Ciscos, and backhoe fade cuts off entire POPs. The internet has this wonderful technology associated with it that lets you route around breaks, but it doesn't work if you don't have a second path to follow. I'm unaware of the provider that has not had a meltdown of one sort or another at at least once in the last couple of years. Shit happens. Thats why customers multihome. In the telephony industry, a usual standard to hold a section of the network to is two minutes of downtime per year. I'll stop having my customers multihome when most providers are operating up to that spec. Perry
In message <199608191914.MAA02347@quest.quake.net>, Vadim Antonov writes:
In my (rather extensive) practice, multihoming by itself is usually a major source of connectivity problems.
Whoever arguing _for_ mulihoming for everyone forgets that taking more routing information in has dangers not present when you don't do routing yourself.
I never saw any customer who had the ability to configure a multihomed site properly on their own; and most of the bogus routing information comes from multihomed customer sites.
Doesn't that only happen when you don't filter routing information you get from your customers and peers. ;-) Curtis
participants (7)
-
Curtis Villamizar -
Henry Kilmer -
Michael Dillon -
Perry E. Metzger -
randy＠psg.com -
Rob Skrobola -
Vadim Antonov