nanog mailing list archives
Re: multi homing pressure
From: "Justin M. Streiner" <streiner () cluebyfour org>
Date: Wed, 19 Oct 2005 12:55:52 -0400 (EDT)
On Wed, 19 Oct 2005, Todd Vierling wrote:
That's the operators' view, but not the customer's. The customer wants redundancy.That's why SLAs exist.
SLAs exist to provide a means of allowing a vendor to 'feel your pain' when you experience some type of a service outage. They generally do not exist to act as a cost recovery mechanism for customers who lose revenue when mission critical app XYZ can't access 'the network', people coming in from 'the network' cannot access it. Being able to deduct some percentage of your monthly spend with your carrier often doesn't balance well against a network outage that affects the mission critical app that brings in a substantial percentage of the company's revenue.
Each organization's tolerance for outages (read: revenue impact) must be weighed against the costs of multihoming and making the investments in infrastructure to improve relibility.
Something like that, but not quite. Whenever one of these reports, which boil down to "everyone must multi-home!", appears, it typically has a stark lack of information on alternatives to *direct* multi-homing.
Hence Chris's earlier post about the multitude of think tanks which exist to state the obvious and make a buck while doing it :-)
Many customers would rather not multihome directly, and prefer "set it and forget it" connectivity. It's much easier to maintain a multi-pipe connection that consists of one static default route than a pipe to multiple carriers. The former requires simple physical pipe management, which can be left alone for 99% of the time. The latter requires BGP feed, an ASN, and typically much more than 1% of an employee's time to keep running smoothly.
I disagree with some of this. I've set BGP up for customers before on many occasions. Many were quite happy with a primary-backup mode of connectivity, which can be accommodated by getting an ASN, configuring BGP on your router(s) and with your upstreams, announcing your route(s) and accepting a default route from those upstreams. My experience has been that these types of setups are also pretty much 'fire and forget' as far as the customer is concerned - *once they're up and running*. If customer XYZ doesn't have the expertise in-house to set it up, they will often bring in a consultant to do it. I do agree that the process of applying for an ASN and so forth can take some time, but it's typically a one-time process.
Customers who want to actually attempt to tune traffic to fit the size oftheir pipes are the ones who require much more time in the maintenance of their BGP environment, and often have higher capex and opex to go with it (bigger router to handle full BGP feeds, $router_vendor support contracts for same, etc).
Obtaining single-homed connectivity from a Tier-2 mostly "outsources" network support, and small to medium size businesses tend to like that. It's not the only leaf end solution to the problem, but it's a viable one (and can be less costly to the rest of the world in turn).
That depends greatly on the business need that drives the decision in the first place. Plus, some organizations are finding that locating critical service outside of their borders either voliates their security policies, or can hamper compliance with outside security mandates (GLB, SOX, HIPAA, etc). Maintaining compliance + improving reliability can motivate organizations to multihome.
jms
Current thread:
- Re: multi homing pressure, (continued)
- Re: multi homing pressure David G. Andersen (Oct 19)
- Re: multi homing pressure Michael . Dillon (Oct 20)
- Re: multi homing pressure David Andersen (Oct 20)
- Re: multi homing pressure Todd Vierling (Oct 19)
- Re: multi homing pressure Christopher L. Morrow (Oct 19)
- Re: multi homing pressure Todd Vierling (Oct 19)
- Re: multi homing pressure Elmar K. Bins (Oct 19)
- Re: multi homing pressure Todd Vierling (Oct 19)
- Re: multi homing pressure Edward Lewis (Oct 19)
- Re: multi homing pressure Patrick W. Gilmore (Oct 19)
- Re: multi homing pressure Justin M. Streiner (Oct 19)
- Re: multi homing pressure Edward B. Dreger (Oct 19)
- Re: multi homing pressure John Payne (Oct 19)
- Re: multi homing pressure Mark Radabaugh (Oct 19)
- Re: multi homing pressure Patrick W. Gilmore (Oct 19)
- RE: multi homing pressure Peter Kranz (Oct 19)
- Re: multi homing pressure Christopher L. Morrow (Oct 19)
- RE: multi homing pressure Ejay Hire (Oct 21)
- Re: multi homing pressure Todd Vierling (Oct 19)
- Re: multi homing pressure Owen DeLong (Oct 19)
- Re: multi homing pressure Jon Lewis (Oct 19)
- Re: multi homing pressure Owen DeLong (Oct 19)