Mailing List Archive

> Does anyone know of any non-ISP companies that have decided to
> multi-home? Is this a major trend for non-ISP companies running
> mission-critical applications on the Internet?
>
> So far, I only know of a couple, with PointCast being one of them.

We're multi-homed to BBN, Exodus (co-located too), and PBI.

netops writes:
>
> Does anyone know of any non-ISP companies that have decided to
> multi-home? Is this a major trend for non-ISP companies running
> mission-critical applications on the Internet?

We will be going multi-homed in about 2 weeks because the state of California
has mandated that all community colleges sign up with 4C.net, but we don't
want to give up our existing CERF.net connection.
--
Mark Bixby E-mail: markb@cccd.edu
Coast Community College Dist. Web: http://www.cccd.edu/~markb/
District Information Services 1370 Adams Ave, Costa Mesa, CA, USA 92626-5429
Technical Support +1 714 438-4647
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

This seems easy, so my answer is probably going to be lame.
If by "multi-home" you mean 2 connects, 2 providers, 2 POPs, then I can tell you
that Broderbund is doing this with out 2 DS-3s and 2 T1s. We are still layer 1
"Pac Bell Backhoe" fault intolerant, however (one fiber bundle to 1 Pac Bell
CO).

--->Steve

____________________Reply Separator____________________
Subject: Non-ISP companies multi-homing?
Author: netops <netops@flycast.com>
Date: 7/23/97 4:09 PM

Does anyone know of any non-ISP companies that have decided to
multi-home? Is this a major trend for non-ISP companies running
mission-critical applications on the Internet?

So far, I only know of a couple, with PointCast being one of them.

Thanks,
Lincoln Silver
FlyCast Communications

netops wrote:
>
> Does anyone know of any non-ISP companies that have decided to
> multi-home? Is this a major trend for non-ISP companies running
> mission-critical applications on the Internet?
>
> So far, I only know of a couple, with PointCast being one of them.
>
> Thanks,
> Lincoln Silver
> FlyCast Communications
What about iPass.com

On Wed, Jul 23, 1997 at 05:04:29PM -0700, Mark Bixby wrote:
> netops writes:
> > Does anyone know of any non-ISP companies that have decided to
> > multi-home? Is this a major trend for non-ISP companies running
> > mission-critical applications on the Internet?
>
> We will be going multi-homed in about 2 weeks because the state of California
> has mandated that all community colleges sign up with 4C.net, but we don't
> want to give up our existing CERF.net connection.

Here's an interesting question: is it considered multi-homing to have
connections between an internal backbone and a commercial provider's
backbone in more than one location -- if it's the same commercial
provider?

I have in mind, particularly, people like HP.

My instincts tell me that it probably is, but I wonder what the routing
management differences might be.

Cheers,
-- jr 'if this is off-topic, reply off-list' a
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "People propose, science studies, technology
Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592

Bruce,
I have several customer who are multi-homed, some of which are ISP"s but not
all. I am seeing this a coming trend for customers who wish to have
redundant internet access. A bit pricey i bet, but maybe easier on the
nerves :)

John Buxbaum
AT&T CBB

-----Original Message-----
From: Bruce Benda <bruce@clari.net>
To: netops <netops@flycast.com>
Cc: nanog@merit.edu <nanog@merit.edu>
Subject: Re: Non-ISP companies multi-homing?



>> Does anyone know of any non-ISP companies that have decided to
>> multi-home? Is this a major trend for non-ISP companies running
>> mission-critical applications on the Internet?
>>
>> So far, I only know of a couple, with PointCast being one of them.
>
>We're multi-homed to BBN, Exodus (co-located too), and PBI.
>

Mark,
You have been told by the State who you have to use as a provider?

-----Original Message-----
From: Mark Bixby <markb@spock.dis.cccd.edu>
To: netops <netops@flycast.com>
Cc: nanog@merit.edu <nanog@merit.edu>
Subject: Re: Non-ISP companies multi-homing?



>netops writes:
>>
>> Does anyone know of any non-ISP companies that have decided to
>> multi-home? Is this a major trend for non-ISP companies running
>> mission-critical applications on the Internet?
>
>We will be going multi-homed in about 2 weeks because the state of
California
>has mandated that all community colleges sign up with 4C.net, but we don't
>want to give up our existing CERF.net connection.
>--
>Mark Bixby E-mail: markb@cccd.edu
>Coast Community College Dist. Web: http://www.cccd.edu/~markb/
>District Information Services 1370 Adams Ave, Costa Mesa, CA, USA
92626-5429
>Technical Support +1 714 438-4647
>"You can tune a file system, but you can't tune a fish." - tunefs(1M)
>

netops writes:
>
> Does anyone know of any non-ISP companies that have decided to
> multi-home? Is this a major trend for non-ISP companies running
> mission-critical applications on the Internet?

Yes, several. As far as I can see, yes. The question I'd ask would
be why does it matter if an AS is "ISP" or "non-ISP"? The domain of
clueful people is far and away NOT limited to the domain of ISP
networkers. If an organization is sizeable enough and knows what
it is doing, or can hire or rent someone who does, more power to them.

Cheers,
Joe

(affiliation for identification, not endorsement; disclaim, disclaim)

--
Joe Provo, Network Architect 800.763.8111 x3006
Network Operations Center Fax 508.229.2375
UltraNet Communications, Inc. <jprovo@ultra.net>

On Jul 23, netops <netops@flycast.com> wrote:

> Does anyone know of any non-ISP companies that have decided to
> multi-home? Is this a major trend for non-ISP companies running
> mission-critical applications on the Internet?
>
> So far, I only know of a couple, with PointCast being one of them.

There's also Gannett (the folks who own USA Today and a lot
of other newspapers and radio and TV stations.) But, with
all the stuff they own & do, it wouldn't be too much of a
stretch to consider them a web hosting facility (with a very
limited clientele.)

*********************************************************
J.D. Falk voice: +1-415-482-2840
Supervisor, Network Operations fax: +1-415-482-2844
PRIORI NETWORKS, INC. http://www.priori.net
"The People You Know. The People You Trust."
*********************************************************

On Wed, 23 Jul 1997, netops wrote:

> Does anyone know of any non-ISP companies that have decided to
> multi-home? Is this a major trend for non-ISP companies running
> mission-critical applications on the Internet?
>
> So far, I only know of a couple, with PointCast being one of them.

The Eli Lilly pharmaceutical corporation based here in Indanapolis
(www.lilly.com) is multihomed. I would assume any corporation of this
scale which conducts worldwide research such as Lilly would place enough
value on their internet connectivity to obtain redundant connections.

Aaron Abelard / aaron@abelard.com / http://www.abelard.com/
"Nunc Lento Sunito Dicunt, Moreris" (Donne)
"Lasciate tutto speranza, voiche entrate" (Dante)
"kinda like a cloud i was up way up in the sky" (NIN)
"Once more unto the breech, dear friend" (Shakespeare)

netops@flycast.com (netops) writes:
> Does anyone know of any non-ISP companies that have decided to
> multi-home? Is this a major trend for non-ISP companies running
> mission-critical applications on the Internet?

Yes. I know some people in the UK that are multi-homed, too (though
there's probably not too many over here.)

James.

At 19:09 -0400 7/23/97, netops wrote:
>Does anyone know of any non-ISP companies that have decided to
>multi-home? Is this a major trend for non-ISP companies running
>mission-critical applications on the Internet?
>
>So far, I only know of a couple, with PointCast being one of them.
>
>Thanks,
>Lincoln Silver
>FlyCast Communications

Let me try to answer this somewhat broadly, and still stay within the NANOG
charter. I believe it is an operational issue to consider any
organization, whether ISP or not, that can affect internet routing. An
enterprise that generates BGP announcements can affect such routing just as
well as a service provider.

A simple answer: yes, I see some form of complex Internet connectivity
(I'm avoiding the term multi-homing due to ambiguity) in large enterprises
(Fortune 500 roughly) and in enterprises for which Internet access is
mission-critical, regardless of their overall size.

Mergers and acquisitions, where the joined enterprises each had their own
Internet access, often mean complex connectivity, at least for a transition
period. Consolidation of separate divisional networks also creates this
situation. I've found a very frequent case to be where a large enterprise
decides that Internet access should be available corporate-wide, but their
research labs have had Internet access for years -- and it works, as
opposed to the new corporate connection that at best is untried.

Different people use terms such as "multi-homing" in different ways. Let
me propose a taxonomy I use in teaching design classes. I have had real
networks that used all of these cases.

1. Single-homed. Enterprise generally does not have ASN; all its
advertisements are made through its ISP. Uses default routes to the ISP.
The customer is primarily concerned with protecting against link or router
failures, rather than failures in the ISP routing system.

1.1 Single-homed, single-link. A single path to the ISP.
1.2 Single-homed, balanced link. Multiple parallel paths from a single
customer router to an router. Protects against link failures. The single
customer router constraint allows this router to do round-robin
packet-level load balancing across the multiple links, for resiliency and
possibly additional bandwidth.
1.3 Single-homed, multi-link. Separate paths from multiple customer
routers to multiple ISP routers at different POPs. Default routes
generated at each of the customer gateways are injected into the enterprise
routing system, and the combination internal and external metrics are
considered by internal routers in selecting the external gateway. [.I
generally recommend this to a customer who wants resiliency but wishes to
avoid the complexity of BGP]
Special Case 1.1+, 1.2+, 1.3+. While the customer is still
single-homed, an AS upstream from the ISP has a routing policy that makes
it necessary to distinguish routes originating in the customer from those
originating in the ISP. In such cases, the enterprise may need to run BGP,
or have the ISP run it on its behalf, to generate advertisements of the
needed specificity.

2. Multi-homed. Enterprise connects to more than one ISP. May or may not
use BGP. Wishes to protect against problems in the ISP routing system, and
will accept additional complexity and router requirements to get this. May
also have differing service agreements for Internet access for different
divisions.

2.1 Multi-homed, primary/backup, single link. The enterprise connects
to two or more ISPs from a single router, but has a strict policy that only
one ISP at a time will be used for default. In an OSPF environment, this
would be done by advertising defaults to both ISPs, but with different Type
2 external metrics. The primary ISP would have the lower metric. BGP is
not necessary in this case. This easily can be extended to multi-link.
2.2 Multi-homed, differing internal policies. Assume OSPF interior
routing. The main default for the enterprise comes from one or more ASBRs
in Area 0, all routing to the same ISP. One or more organizations brought
into the corporate network have pre-existing Internet access agreements
with an ISP other than the corporate ISP, and wish to continue using this
for their "divisional" Internet access. [.I've seen this most often when a
corporation decides to have general Internet access, but its research arm
has long had its own Internet connectivity. Mergers and acquisitions also
produce this case.] In this situation, an additional ASBR(s) are placed in
the OSPF areas associated with the special-case, and this ASBR advertises
default. Filters at the Area Border Router block the divisional ASBR's
default from being advertised into Area 0, and the corporate default from
being advertised into the division.
2.3 Multi-homed, "load shared" with primary/backup. [.Thanks to Paul
Ferguson for the distinction between load balancing and load sharing.]
While there still is a primary/backup policy, there is an attempt to make
active use of both the primary and backup providers. The enterprise runs
BGP, but does not take full Internet routing. It takes partial routing
from the backup provider, and prefers the backup provider path for
destinations in the backup provider's AS, and perhaps directly connected to
that AS. For all other destinations, the primary provider is the preferred
default. A less preferred default is defined to the second ISP, but this
default is advertised generally only if connectivity is lost to the primary
ISP.
2.4 Multi-homed, global routing aware. Multiple customer router
receive a full routing table, and, using appropriate filtering and
aggregation, advertise different destinations (i.e., not just default)
internally. This requires BGP, and, unless dealing with a limited number
of special cases, requires significantly more resources inside the
organization.

3. Transit. While we usually think of this in terms of ISPs, some
enterprises may provide Internet connectivity to strategic partners. They
do not offer Internet connectivity on a general basis.

3.1 Full iBGP mesh. Connectivity and performance requirements are such
that a full iBGP mesh is practical.

3.2 Scalable IBGP required. The limits of iBGP full mesh have been
reached, and confederations, route reflectors, etc., are needed for growth.


--------

Howard Berkowitz
PSC International/Protocol Interface (Cisco/Bay/Digital training partners)
-- personal opinions, and other appropriate disclaimers

At 12:25 -0400 7/24/97, Jan Novak wrote:
>Nice lecture, thanks. But I saw always when thinking about multihoming
>some other problems also.

In the taxonomy I proposed, I tried to stay at the level of the customer
requirement, rather than the specific details of addressability. The cases
you cite are legitimate, but are in my mind at the next level of detail --
how one actually implements multihoming.

I'll make some general comments. I need to think a bit whether these would
be logically at a more detailed level of the taxonomy, or are in an
implementation taxonomy of their own.

Even beyond BGP capabiities (of either the enterprise or the ISP), your
examples are going to be affected by the particular ISPs' (and their
upstreams) aggregation and prefix filtering policies.

>
>2] Multihomed to different ISP without BGP, supposing I need only one /24.
>It will be PA or PI addressing space ??

From the taxonomy standpoint, it could be either. Current registry
policies from RFC 2050 would generally say PA.

>With respect to CIDR aggregation effort, make it sense to require /24 PI
>address block?? How will route the second ISP
>my PA from the other ISP (he will de-aggregate the block of the second
>provider to announce more specific prefix??) ??
>
>2] Multihomed to different ISP with BGP , supposing I need only one /24.
>Again, make it sense to have my own AS
>and /24 PI block ??

>Supposing to have IBGP to one ISP (to avoid assigning of independent AS)
>and EBGP to the second ISP, again will my router announce the /24 inside
>of the first ISP address block to the EBGP peer ??

Interesting approach. In general, the ISPs I know would be reluctant to
run iBGP with a customer, unless they had total control of all BGP
speakers. If I understand you correctly, the enterprise would have to tag
its advertisements to the second ISP with the ASN of the first, since the
enterprise doesn't have its own. Again, I think most ISPs would be
reluctant to give up this amount of control.
>
>
>2. Multi-homed. Enterprise connects to more than one ISP. May or may not
>use BGP. Wishes to protect against problems in the ISP routing system, and
>will accept additional complexity and router requirements to get this. May
>also have differing service agreements for Internet access for different
>divisions.
>
>

On Wed, 23 Jul 1997, netops wrote:

> Does anyone know of any non-ISP companies that have decided to
> multi-home? Is this a major trend for non-ISP companies running
> mission-critical applications on the Internet?

Yes, we announce our routes through two different providers with
connectivity through two different wireline carriers.

Paul
-------------------------------------------------------------------------
Paul D. Robertson
gatekeeper@gannett.com

On Thu, 24 Jul 1997, Howard C. Berkowitz wrote:

> Interesting approach. In general, the ISPs I know would be reluctant to
> run iBGP with a customer, unless they had total control of all BGP
> speakers. If I understand you correctly, the enterprise would have to tag
> its advertisements to the second ISP with the ASN of the first, since the
> enterprise doesn't have its own. Again, I think most ISPs would be
> reluctant to give up this amount of control.

I think most of the companies running redundant links now have their own
address space and ASN. We got our primary address blocks back when a
company could still do that. I think there's going to have to be some
way to address that with semi-portable AS' in the near future though, as
more criticality transitions to the Net.

That, or people will start buying up service providers to get address blocks,
then they'll own the routers, and work out their iBGP issues "internally".
Not that that works for smaller companies who want it, but if you're a
multi-billion dollar corporation, it's an option (yes, it should scare you).

I know at least one tier 1 has started offering seperate wireline into
different NAPs in the DC area, which is about as good as you can get without
going to two providers. They want a lot of money for it though, and the
gains of a second provider are much more cost-effective from a strict
redundancy standpoint.

I don't know how we can get a combination of aggragate routing and
multi-homing to scale correctly, but I think it's becomming more
important that we do so.

Paul
-------------------------------------------------------------------------
Paul D. Robertson
gatekeeper@gannett.com

>
> Without the ISP having total control over the customer
> router, a misconfiguration of filters on the customer side
> could easily cause the customer to be a valid (and 1 hop)
> path in the tables from ISP A to ISP B. Doesn't sound
> like a possibility I would be willing to have hanging over
> my head.

Well, since my bandwidth is necessary for my business, I think I'd be
much more concerned about becomming the valid route than my upstreams, if
they get better routing through me, it's not necessarily a bad thing
for them unless they're concerned about me snarfing traffic.

Plus, you can filter out what you send to me if you're my upstream. That
means you'll need a misconfigured router on your side *and* one on mine.
I don't know your competency, but I'm fairly certain of mine ;). I put a
lot more time, effort and care into choosing a provider than you do into
choosing a customer.

I don't think it's as big of an issue, other than the obvious
effects of router filtering performance, and the chance that the upstream
could hose his filters when he goes to listen for routes to me from
external sources if he's already got major paranoia filters. Hopefully,
he's got that filtered to only happen from my other peering points though.

It's not rocket science, but it does take some care in set-up. You have
as much chance of getting control of my gateway routers as you have of
turning into a purple poodle. I'd purchase Yet Another Service Provider
and route a tier lower before I'd play that game. I've got a lot more to
lose than my upstreams.

Paul
-------------------------------------------------------------------------
Paul D. Robertson
gatekeeper@gannett.com

At 09:20 PM 7/23/97 -0400, John J. Buxbaum wrote:
> Bruce,
>I have several customer who are multi-homed, some of which are ISP"s but not
>all. I am seeing this a coming trend for customers who wish to have
>redundant internet access. A bit pricey i bet, but maybe easier on the
>nerves :)
>

Here in the Bay Area, the BBN outage of last fall, among other outages, has
really shaken up the established Silicon Valley companies. A lot of network
managers had a lot of explaining to do and many of them said "I recommended
a backup connection, but it wasn't in the budget." Now it's in the budget.
Every major corporate site will multi-home if they haven't already, or else
move their servers into an ISP POP.

I do not in any way mean to cast aspersions on BBN/BARRNET. I used to work
at BBN before it bought BARRNET. I also was Exec Dir of CERFNET, a BARRNET
competitor in soCal.

It is the fact that a 24 hour outage could happen to the premium Bay Area
ISP that was the shocker. If it can happen to BBN/BARRNET, in the view of
corporate network managers and their executive managements, then it can
happen to anyone and there is no way that a major site can afford to rely
on just one ISP. It's too bad it was BBN, but it would have happened
eventually to UUNET or MCI or Sprint.

Multihoming is here to stay in the Bay Area.

--Kent


Kent W. England VP of Technology
GeoNet Communications, Inc. Direct: 415.596.6321
555 Twin Dolphin Drive Fax: 415.596.1701
Redwood City, CA 94065 Company: 415.596.1700
http://www.geo.net Email: kwe@geo.net

John J. Buxbaum writes:
>
> Mark,
> You have been told by the State who you have to use as a provider?

If not an outright mandate, the "auxiliary funding" provided to each campus
for information infrastructure upgrades was an offer too good to refuse.

CSUnet/4Cnet is a state-created and funded entity serving public educational
institutions within the state of California.

Quoting from http://www.4c.net/4CNet_mission.html:

In 1984, the California State University (CSU) system established "CSUnet",
a dedicated data network linking each of the campuses of the CSU. The
network was created as one of several efforts to meet the increasing
information technology demands of the University system and its campuses
throughout the State. CSUnet continually modified and expanded its
programmatic functions and technical resources to keep current with
state-of-the-art inter-network services and applications. CSUnet's purpose
has been to serve the University's academic and administrative mission,
goals and objectives in ways that exploit centralized and distributed
information resources.

The State of California authorized auxiliary funding in the 1996-97 fiscal
year to the California Community Colleges (CCC) "to assure that each of the
125 (campus and district office) sites have established necessary
infrastructure capability for teleconferencing, connections to CSUnet and
satellite downlink" capabilities.

In response to this funding allocation, the CSU and CCC have implemented a
working relationship to create the California State University and Community
College Network, 4Cnet. The role of 4CNet expands the role of CSUnet to
the Community College Environment. It is the purpose of 4Cnet to serve the
academic and administrative mission goals an objectves in ways that exploit
centralized and distributed information resources for the separate and
combined California State Universities and Community Colleges.

> -----Original Message-----
> From: Mark Bixby <markb@spock.dis.cccd.edu>
> To: netops <netops@flycast.com>
> Cc: nanog@merit.edu <nanog@merit.edu>
> Subject: Re: Non-ISP companies multi-homing?
>
>
>
> >netops writes:
> >>
> >> Does anyone know of any non-ISP companies that have decided to
> >> multi-home? Is this a major trend for non-ISP companies running
> >> mission-critical applications on the Internet?
> >
> >We will be going multi-homed in about 2 weeks because the state of
> California
> >has mandated that all community colleges sign up with 4C.net, but we don't
> >want to give up our existing CERF.net connection.
--
Mark Bixby E-mail: markb@cccd.edu
Coast Community College Dist. Web: http://www.cccd.edu/~markb/
District Information Services 1370 Adams Ave, Costa Mesa, CA, USA 92626-5429
Technical Support +1 714 438-4647
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

At 12:01 -0400 7/24/97, root@gannett.com wrote:
>>
>> Without the ISP having total control over the customer
>> router, a misconfiguration of filters on the customer side
>> could easily cause the customer to be a valid (and 1 hop)
>> path in the tables from ISP A to ISP B. Doesn't sound
>> like a possibility I would be willing to have hanging over
>> my head.
>
>Well, since my bandwidth is necessary for my business, I think I'd be
>much more concerned about becomming the valid route than my upstreams, if
>they get better routing through me, it's not necessarily a bad thing
>for them unless they're concerned about me snarfing traffic.
>
>Plus, you can filter out what you send to me if you're my upstream. That
>means you'll need a misconfigured router on your side *and* one on mine.
>I don't know your competency, but I'm fairly certain of mine ;). I put a
>lot more time, effort and care into choosing a provider than you do into
>choosing a customer.
>
>I don't think it's as big of an issue, other than the obvious
>effects of router filtering performance, and the chance that the upstream
>could hose his filters when he goes to listen for routes to me from
>external sources if he's already got major paranoia filters. Hopefully,
>he's got that filtered to only happen from my other peering points though.
>
>It's not rocket science, but it does take some care in set-up. You have
>as much chance of getting control of my gateway routers as you have of
>turning into a purple poodle. I'd purchase Yet Another Service Provider
>and route a tier lower before I'd play that game. I've got a lot more to
>lose than my upstreams.
>
Paul,

you clearly know what you are doing. But it's amazing how many
organizations don't understand fundamental global routing concepts, and
believe waving money at ISPs will make them do what they want even if that
makes no sense.

I've been doing design seminars for the pre-/post-sales tech support
organizations of several national-level carriers. In a recent class, the
students brought up a problem with one of their accounts, which I shall
call Major Clueless Bank (MCB).

Said bank wanted to offer consumer banking over the Internet. All their
direct connectivity came from my client, National Service Provider (NSP-1),
at several geographically dispersed points. By my taxonomy, single-homed,
multi-linked.

MCB desired to level the load over their various server farms and links to
NSP-1. They had fixated on BGP as the way to do what they thought they
wanted to do, which was to affect the MED passed to peers of NSP-1 based on
loading of their servers. They also wanted to affect NSP-1's interior
routing so they could advertise more specific routes to each of their
server farms, again based on _their_ load. Several million a year in
revenues were involved.

IMHO, on looking at what they were trying to do, it wasn't even a routing
problem. What they wanted was probably best done with DNS load control.
They simply did not realize that what they wanted in routing would have
marginal effect on the direct peers of NSP-1, and none on non-adjacent AS.
Their fundamental mental model was an enterprise network where they were in
control. And their next level of detail assumed everything could be
controlled with IP routing.

The concept that other traffic flowed in NSP-1, and that they could not
control the routing of other AS with whom they had no business
relationship, simply didn't penetrate.

So if the ISP has to set general policies,they need to protect themselves
against the NCBs of the world. Paranoid filtering isn't enough if the
customer is demanding something not possible. A part of making multihoming
practical is managing customer expectations and educating enterprise
network designers (or encouraging them to _have_ designers).

Howard

I see this again and again.

On Thu, 24 Jul 1997, Gordon Mercer wrote:

> You wrote:
> > >
> > > Without the ISP having total control over the customer
> > > router, a misconfiguration of filters on the customer
> > > side could easily cause the customer to be a valid (and
> > > 1 hop) path in the tables from ISP A to ISP B. Doesn't
> > > sound like a possibility I would be willing to have
> > > hanging over my head.
> >
> > Well, since my bandwidth is necessary for my business, I
> > think I'd be much more concerned about becomming the
> > valid route than my upstreams, if they get better routing
> > through me, it's not necessarily a bad thing for them
> > unless they're concerned about me snarfing traffic.
>
> They've also got to worry about your bandwidth, which
> could become a big issue depending on the size of the two
> providers involved.

If they've oversold their provisioning, then yes, they would, but I can't
see how other than that they would. Perhaps I'm missing something? In
my particular case, my upstreams are UUNet and BBN, and I've been
particularly happy with the current arrangement.


> In the particular scenario being discussed, which routes
> would you want from your upstream? You might want full
> routes for the ability to actually choose best path, and
> then the upstream providers loose control over what you
> are sending where.

I get full routes from my peers. That doesn't mean they send me traffic
based on destination addresses outside of those specifically linked to my
AS. Why would they route traffic destined to someone else through my
path if they were paranoid about me polluting things? I'd expect them to
no do that as much as I expect them to not accept routes advertised by
me that aren't in the address blocks I've specified. Maybe I'm missing
something here, but it seems pretty cut and dried, and other than the
filtering/CPU issues I don't see a major downside. Certainly my
upstreams didn't seem to have a problem implementing it, and it's saved
us bigtime a number of times since we started it.

> I'm sure you know exactly what you are doing, but not
> every Joe that a provider takes on does. My point is only
> that this is a situation that I would not want to bring
> upon myself.

I can understand that. In my case, it was a couple of years in coming,
but we'd planned for it at the start, and gotten agreements from the
providers to do it during circuit upgrades. I'd have dropped a provider
who wouldn't have agreed, since I had it as a critical need which it took
a while to get funded, and to get management to buy in to.

Long-term, I'm more concerned with the route aggragation problems once
other folks start jumping on the bandwagon than I am with any particular
application, mine included. Not just because I'm carrying full tables,
but because CIDR was a necessary evil, and we're basically moving towards
negating its advantages.

Paul
-------------------------------------------------------------------------
Paul D. Robertson
gatekeeper@gannett.com

>
> >Supposing to have IBGP to one ISP (to avoid assigning of
> >independent AS) and EBGP to the second ISP, again will
> >my router announce the /24 inside of the first ISP
> >address block to the EBGP peer ??
>
> Interesting approach. In general, the ISPs I know would
> be reluctant to run iBGP with a customer, unless they had
> total control of all BGP speakers. If I understand you
> correctly, the enterprise would have to tag its
> advertisements to the second ISP with the ASN of the
> first, since the enterprise doesn't have its own. Again,
> I think most ISPs would be reluctant to give up this
> amount of control.

Without the ISP having total control over the customer
router, a misconfiguration of filters on the customer side
could easily cause the customer to be a valid (and 1 hop)
path in the tables from ISP A to ISP B. Doesn't sound
like a possibility I would be willing to have hanging over
my head.



---
-=<:gEm:>=-

-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>--
Gordon Mercer -=<Dedicated>=-
[digitalNATION]
703 642 2800 -=<Servers>=- gmercer@dn.net
<::>=-=<::>=--=<::>=-=<::>=--=<::>=-=<::>=--=<::>=-=<::>

You wrote:
> >
> > Without the ISP having total control over the customer
> > router, a misconfiguration of filters on the customer
> > side could easily cause the customer to be a valid (and
> > 1 hop) path in the tables from ISP A to ISP B. Doesn't
> > sound like a possibility I would be willing to have
> > hanging over my head.
>
> Well, since my bandwidth is necessary for my business, I
> think I'd be much more concerned about becomming the
> valid route than my upstreams, if they get better routing
> through me, it's not necessarily a bad thing for them
> unless they're concerned about me snarfing traffic.

They've also got to worry about your bandwidth, which
could become a big issue depending on the size of the two
providers involved.

>
> Plus, you can filter out what you send to me if you're my
> upstream. That means you'll need a misconfigured router
> on your side *and* one on mine. I don't know your
> competency, but I'm fairly certain of mine ;). I put a
> lot more time, effort and care into choosing a provider
> than you do into choosing a customer.
> Paul

In the particular scenario being discussed, which routes
would you want from your upstream? You might want full
routes for the ability to actually choose best path, and
then the upstream providers loose control over what you
are sending where.

A and B can both filter what the customer sends to them
based on network, and then the problem is solved.
Unfortunately, this does not always give customers the
flexibility they are looking for.

I'm sure you know exactly what you are doing, but not
every Joe that a provider takes on does. My point is only
that this is a situation that I would not want to bring
upon myself.

---
-=<:gEm:>=-

-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>-<sMp>--
Gordon Mercer -=<Dedicated>=-
[digitalNATION]
703 642 2800 -=<Servers>=- gmercer@dn.net
<::>=-=<::>=--=<::>=-=<::>=--=<::>=-=<::>=--=<::>=-=<::>

On Thu, 24 Jul 1997, Howard C. Berkowitz wrote:

> MCB desired to level the load over their various server farms and links to
> NSP-1. They had fixated on BGP as the way to do what they thought they
> wanted to do, which was to affect the MED passed to peers of NSP-1 based on
> loading of their servers. They also wanted to affect NSP-1's interior
> routing so they could advertise more specific routes to each of their
> server farms, again based on _their_ load. Several million a year in
> revenues were involved.

We went through that phase with senior management in one or two of our
divisions. It's surprising how some folks interpret "It doesn't do that"
to mean "Ask me again".

>
> IMHO, on looking at what they were trying to do, it wasn't even a routing
> problem. What they wanted was probably best done with DNS load control.

Distributed Director is looking better all the time, if only they'd drop
the price down to semi-managable. *sigh*

> They simply did not realize that what they wanted in routing would have
> marginal effect on the direct peers of NSP-1, and none on non-adjacent AS.
> Their fundamental mental model was an enterprise network where they were in
> control. And their next level of detail assumed everything could be
> controlled with IP routing.

Bwaahahahah but I *do* control the Internet ;)

>
> The concept that other traffic flowed in NSP-1, and that they could not
> control the routing of other AS with whom they had no business
> relationship, simply didn't penetrate.
>
> So if the ISP has to set general policies,they need to protect themselves
> against the NCBs of the world. Paranoid filtering isn't enough if the
> customer is demanding something not possible. A part of making multihoming
> practical is managing customer expectations and educating enterprise
> network designers (or encouraging them to _have_ designers).
>

Good point. I really just wanted to get a combination of things across,
firstly that it's doable, and I think we probably are doing it in the most
logical way, second of all, the routing infrastructure needs to change or
routing aggragation will break, and lastly that even though it isn't
always true, it is possible that the ISP is the least "victimized" in an
incorrect set-up.

But then, I think you've all got the easy jobs, since I have to deal with
most of the same issues (over 130 business units will do that), as well
as Appletalk, IPX and all the st00pid MS network garbage ;) [1]

Paul "Arcserve backup is killing one of my internal 7513s" Robertson

[1] Yes, it's a troll, save the list follow-ups and flame directly
-------------------------------------------------------------------------
Paul D. Robertson
gatekeeper@gannett.com

Nice lecture, thanks. But I saw always when thinking about multihoming some other problems also.

2] Multihomed to different ISP without BGP, supposing I need only one /24. It will be PA or PI addressing space ??
With respect to CIDR aggregation effort, make it sense to require /24 PI address block?? How will route the second ISP
my PA from the other ISP (he will de-aggregate the block of the second provider to announce more specific prefix??) ??

2] Multihomed to different ISP with BGP , supposing I need only one /24. Again, make it sense to have my own AS
and /24 PI block ?? Supposing to have IBGP to one ISP (to avoid assigning of independent AS)
and EBGP to the second ISP, again will my router announce the /24 inside of the first ISP address block to the EBGP peer ??


2. Multi-homed. Enterprise connects to more than one ISP. May or may not
use BGP. Wishes to protect against problems in the ISP routing system, and
will accept additional complexity and router requirements to get this. May
also have differing service agreements for Internet access for different
divisions.