North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Generally accepted announcement sizes
There are a few points worth reiterating with this model, most of which Tony has already touched on. To function properly: o This requires that one of your two providers allocate the space and announce the aggregate locally, as well as propagate the more-specific learned from the customer. o This requires that the owner of the aggregate accept the announcement of the more specific from the second provider as well. o This requires that the customer doesn't have a problem with traffic being routed solely via the primary provider when considering peer networks who reject the more-specific advertisement from the secondary provider. o This requires that the customer doesn't have a problem with suboptimal routing to the secondary provider via the primary provider when problems occur, and that the primary provider imposes no policies that would disallow this. o This model of redundancy also assumes that some type of Byzantine failure with routing internal to the primary providers network is not of concern (hrmm..). Of course, if any of these are problems, then the whole issues becomes, well, slightly more interesting... -danny > 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).