|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Confussion over multi-homing
On Thu, 14 Sep 2000, Roeland M.J. Meyer wrote: > > David Lott: Thursday, September 14, 2000 10:34 AM wrote: > > > First, allow me to state the assumptions that I'm under. I understand > > the policy to state that if a business needs to multi-home > > and requires > > less space than a /20, then they should request this space from their > > ISP. I also understand that there are filters at the /20 > > boundaries in > > order to minimize the size of the routing table. Not *all* boundaries, see below. > > > > Question: Doesn't this break multi-homing for end users that > > need less > > than a /20? > > Yep, this has been a topic here before...no real resolution. You didn't > really need to prove the case, it has already been proven. No. From a post I made to this list on 6/22/2000: ++> Here's the deal. If you number out of Provider1's CIDR block ++> but advertise your more-specific to Provider2 and the two Providers ++> touch and Provider1 accepts the more-specific route from Provider2, ++> you should have no problem reaching anyone. ++> ++> Here's the reason: Everyone accepts Provider1's announcement of the block. ++> When your link to P1 is up, any traffic they recieve for your prefix ++> gets routed over that link since they carry your more-specific internally. ++> However, if other providers here the more-specific from P2, they'll ++> send directly via P2 who sends it over the link to you. ++> If your link to P1 goes down, P1 won't see the direct route to you ++> but should see the route via P2 if P1 is accepting it. (Some ++> may either block the announcement or have anti-spoofing packet filters ++> at their borders that block the traffic itself). ++> As long as Provider1 sees the more-specific from Provider2, the length is irrelevant. Does someone disagree? ++> There are many misconceptions about this topic. ++> Hopefully this explanation has helped someone. Tony
|