North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Confussion over multi-homing

  • From: Dmitri Krioukov
  • Date: Fri Sep 15 18:26:13 2000

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Alex Pilosov
> Sent: Friday, September 15, 2000 5:30 PM
> To: David Lott
> Cc: Dmitri Krioukov; [email protected]
> Subject: Re: Confussion over multi-homing
>
>
>
> On Fri, 15 Sep 2000, David Lott wrote:
>
> (for some reason RFC2260 refers to RFC1773 as describing encapsulation
> over non-direct-ebgp-learned-routes, I assume that they meant GRE,
> RFC1701/2)
>
> > RFC2260 essentially states how routers using BGP can be
> configured to detect
> > failure of connectivity to a particular ISP and then advertise
> that address
> > out to another ISP.  However, if the ISP that is still up
> filters at a /20
> > you still end up with the same problem.
> That's not a problem, since you have a contractual relationship with this
> ISP, you can thwack them with the money-stick, and tell them to blow a
> hole in the filter for you.
>
> The real problems I see with it are following:
> 1. You need to get both upstreams to agree to run GRE on their edge
> router. That requires bigger money-stick than fixing their filtering :)

:)

> 2. It only protects you from failure of a link from you to upstream, not
> from upstream losing their connectivity, power, or flapping like crazy and
> getting dampened. In my experience, latter happened more often than first.
> :)

note that "non-direct ebgp" peering on the picture can actually be between
e-br-a and *any* router in isp-b, not necessarily isp-br-b. this way your
real problem 2 is solved.

> > Actually the are two issues that must be addressed by any multi-homing
> > solution.
> > 1) How does someone get to me? (outside connectivity in)
> > 2) If I use more than one address pool, how do I NAT with the correct
> > (meaning up) ip address (inside connectivity out)
> >
> > While RFC 2260 does not solve these problems, it does lead me
> to think that
> > a solution is possible - give me a few days to work on this and
> I'll report
> > back.
> This RFC doesn't address cases where you use NAT. See this if you do:
> http://www.ieng.com/warp/public/cc/pd/iosw/ioft/ionetn/tech/emios_wp.htm
> It uses DNS trickery to accomplish it. You CAN use RFC2260 trickery with
> it (half of RFC2260 is included there), but you don't have to, if you
> don't care about broken connections when one of links fails.
>
>
> --
> Alex Pilosov            | http://www.acecape.com/dsl
> CTO - Acecape, Inc.     | AceDSL:The best ADSL in Bell Atlantic area
> 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :)
> New York, NY 10018      |
--
dima.