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<[email protected]>
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 [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
