North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Confussion over multi-homing
> -----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.
|