Home page logo

nanog logo nanog mailing list archives

Re: Non-ISP companies multi-homing?
From: "Howard C. Berkowitz" <hcb () clark net>
Date: Thu, 24 Jul 1997 13:32:17 -0400

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.


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,

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).


I see this again and again.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]