Redundancy & Summarization

Sat Aug 22 17:52:32 UTC 2009

Sent from my iPhone, please excuse any errors.

On Aug 22, 2009, at 9:52, Adam Greene <maillist at webjogger.net> wrote:

> Another option could be to announce one /17 to each upstream  
> provider and use conditional BGP to announce the other /17 to the  
> provider that's still active in the event that one provider goes down.

Good idea.  Still uses just two prefixes and allows for backup  
connectivity.

Just be careful that the internal routing table does not stop the  
conditional announcement.

-- 
TTFN,
patrick

> On 8/21/2009 4:08 PM, Patrick W. Gilmore wrote:
>> On Aug 21, 2009, at 3:47 PM, Brian Dickson wrote:
>>
>>>> My institution has a single /16 spread across 2 sites: the lower / 
>>>> 17 is
>>>> used at site A, the upper /17 at site B.  Sites A & B are connected
>>>> internally.  Currently both sites have their own ISPs and only  
>>>> advertise
>>>> their own /17's.  For redundancy we proposed that each site  
>>>> advertise
>>>> both their own /17 and the whole /16, so that an ISP failure at  
>>>> either
>>>> site would trigger traffic from both /17s to reconverge towards the
>>>> unaffected location.
>>>
>>> There are two different ways to achieve almost-identical results.
>>
>> As much as I like Brian, I am going to have to respectfully disagree.
>>
>>
>>> However, one is a 50%  more "green" than the other, i.e. friendly  
>>> to other network operators.
>>>
>>> These two choices are functionally equivalent, and possible, only  
>>> because things currently work for both your /17's.
>>>
>>> Here are the two ways to do this:
>>>
>>> One is:
>>> - announce /17 "A" and /16 from uplink ISP-A
>>> - announce /17 "B" and /16 from uplink ISP-B
>>> - This results in 3 prefixes globally: A, B, and /16.
>>>
>>> The other is:
>>> - announce /17 "A" and /17 "B", with different policies (i.e.  
>>> prepend your AS once or twice), at *both* ISPs.
>>> - This results in 2 prefixes globally: A and B.
>>>
>>> In all cases, as long as one ISP link is up, there is a path to  
>>> both A and B.
>>> In most cases, the best path to A or B, is *mostly*, but not  
>>> completely, under your influence.
>>
>> This is highly dependent on variables not in evidence.  If your  
>> upstreams are, for instance, Sprint & Level 3, then a large  
>> percentage of the Internet will be traveling through one or the  
>> other.  And once it hits your upstream, prepends are irrelevant.   
>> Every upstream (for values of "every" == "100%" to at least one  
>> decimal place) localprefs their downstreams' prefixes.
>>
>> In this case, anyone downstream of either L3 or Sprint will send  
>> _all_ traffic through that upstream's link.  While not the whole  
>> Internet, it's still quite a bit.  Moreover, many people do things  
>> like localpref Sprint _down_ because they are more expensive.  So  
>> even someone multi-homed to both may send all traffic through L3.   
>> Etc., etc.
>>
>> A slight twist on Brian's idea would be to use communities and tell  
>> Upstream A to localpref Prefix B below that of peer routes.  Then  
>> you only need two prefixes, and each site only receives its own  
>> traffic except when the other site fails.  If Upstream B goes down,  
>> Upstream A will accept Prefix B and propagate it.
>>
>> Again, dependent upon your upstreams having communities able to do  
>> this.  Or if they are "nimble", maybe a call to their operations  
>> department?
>>
>
>
>