[c-nsp] BGP Multipath and unequal IGP metrics

[David Hughes]

Hi

By "layers" are your suggesting building tunnels to match the iBGP  
topology so the peers all think they are directly connected?   
Interesting thought but not sure how it'd scale with gre etc.  There  
is mpls configured on the core (just for inter-DC EoMPLS at present)  
so perhaps mpls-te could provide an answer.   I've no experience with  
mpls-te but I'll go off and have a read.

Thanks for your thoughts.



David
...



On 03/08/2009, at 12:14 PM, Rubens Kuhl wrote:

> I would consider using a layered-session approach.
> The first layer would be used only to provide the path to the BGP
> loopback, both to your core routers and to your transit providers, and
> would be used to equalize the metric of the alternate paths. A likely
> scenario would consist of 4 BGP sessions among your own routers and 2
> or 4 sessions to your transit provider, but might be more; it would
> require BGP support, but no 1 milion routes support.
>
> The second layer would use the first one to exchange provider
> announcements, both yours to transit and full routes from the transit
> providers.
>
> Disclaimer: haven't tested this exact scenario, ended up having
> full-route capable routers on all hops.
>
>
> Rubens
>
>
> On Mon, Jul 27, 2009 at 9:11 PM, David Hughes<david at hughes.com.au>  
> wrote:
>> Hi
>>
>> I have a situation that looks like a problem in the making.  In a  
>> subset of
>> our network there's a pair of well connected datacentres (eg dual  
>> 10GE paths
>> etc).  One of our upstreams will shortly be presenting a transit  
>> path at
>> both of these 2 locations.  No problems I think to myself - we'll  
>> just
>> multi-path from our core and load share over both paths.
>>
>> Problem.  Seeing as the 2 border routers in question are at different
>> locations, the core routers see different IGP metrics to the  
>> nexthop of the
>> BGP table entry.  As a result they are excluded from use with BGP  
>> multipath
>> and I'm left with the core routers at each DC only using the paths  
>> to the
>> border router at the local site.
>>
>> I don't want to mess around with tweaking the OSPF metrics as I'm  
>> sure
>> that's just a disaster waiting to happen for some poor network  
>> engineer in a
>> year or two.  I thought I'd found a nice clean solution with Cisco's
>> "multipath unequal-cost" feature but for some reason I can't even  
>> start to
>> understand you can only use it in a VRF, not in the default table.
>>
>> So the only solution I can see is to reconfigure the core devices  
>> and move
>> all interfaces and routing processes into a VRF so that I can  
>> effectively
>> get this feature on our entire table.
>>
>> What am I missing here?  Surely I'm not Robinson Crusoe - someone  
>> must have
>> done this before.  Platform is Cat6k / Sup720.
>>
>>
>> Thanks
>>
>> David
>> ...
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>