[c-nsp] BGP Multipath and unequal IGP metrics

[Rubens Kuhl]

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/
>