[i had replied to David off list but it seems his reply to me was bcc'd here. so to keep things relevant i'm posting the reply here too]
On 10/08/2010, at 6:53 PM, David Freedman wrote: > I should have mentioned that my target trains are 12.2SX and 12.2SR :) 6500/7600 are capable of MPLS/VPLS/EoMPLS/EoMPLSoGRE i believe, so certainly you have some mechanisms available to you for transporting L2 between your physical sites across your infrastructure, be it over IP or MPLS as the underlying transport. >> 1. OTV >> <http://www.ciscosistemi.net/en/US/prod/switches/ps9441/nexus7000_promo.html> >> 2. EoMPLSoGRE >> <http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_ >> c11_493718.pdf> > > Great, but both layer 2 solutions and both suffering from the same l3 > symmetry issue. correct, these are technologies around how you make a single L2 subnet available at multiple location(s) when they are not necessarily L2 connected. > This is an MPLS network and as such the VPLS sledgehammer could be > brandished, I'm just trying to avoid it. a wise move (i think) - but since you already have a MPLS network, there is no reason why you should not perhaps use it for a L2 transport, e.g. EoMPLS (e.g. xconnect), A-VPLS or VPLS. again - this gets you the span-L2-betwen sites -- but to acheve the 'optimal L3->L2' you still need a mechanism to achieve that. >> you have a few options. >> 1. deaggregate / announce host routes (may work ok for an enterprise, less so >> for other environments) > > Don't see this as being a problem in a well managed SP network. there ya go then. do that. you mentioned in email that this was for vMotion, you can have a 'script' run on a vMotion event, you could have that trigger some backend system to advertise a host route. i would not necessarily recommend this approach. it only really works if its you guys that control the "hosts". if this is a 3rd party then caveat emptor having all your routes deaggregated. :) >> 2. announce the server subnet out both/multiple locations with same metric, >> return traffic will arrive at closest site or loadbalance across them with >> ECMP. > > Similar problems as with layer 2, return traffic has to come back to a deagg > of some sort or be bridged across to where it needs to go somehow my experience is that most folks have a LOT of bandwidth between their data centers, less so to the internet or branch offices if in an enterprise environment. so some traffic statistically arriving in the "wrong" physical data center generally is not an issue. if it is, then your solutions are: (1) deaggregate, (2) LISP >> since they probably aren't palatable to you, we also have another way on the >> way. >> >> 3. LISP. <http://lisp4.cisco.com/index.html> > > LISP/HIP is great, but quite far from production use, especially in this > scenario (but I have been following your LISP efforts with great interest) > >> >> >>> I personally think LAM and >>> sufficiently convergence tuned network should be almost if not as good. >> >> LAM is for unicast traffic only and IP unicast traffic to be precise. there >> are many protocols / use-cases where that is not sufficient. >> i think its widely acknowledged that it doesn't really scale. > > Disagree, we are only talking about host route deaggregation for hosts which > need to migrate for some reason or another, it doesn't appear to be a > complicated or dangerous thing to do providing active number of deaggregates > is managed, granted point about the multicast but don't think it will hamper > the product much (inter-datacenter multicast isn't a problem anyway) thing about LAM is its intended for "IP traffic" and "unicast IP" at that. once you have things like hosts and vMotion hapenning you really don't have control over what the hosts and apps themselves running on these virtual servers are doing. my experience is that things that you THINK don't require multicast often does. and often hosts and apps that expect L2 connectivity also have requirements for non-IP traffic too. i don't think LAM will accomodate either scenario as it was not intended to, and predates a lot of the virtual-machine-mobility brave new world. > > I note from > http://www.cisco.com/en/US/docs/ios/ipmobility/command/reference/imo_01.html > it seems to have made it into XE, quite why this was chosen (and not SX/SR) > is beyond me! probably because ASR1K is targeted primarily where things like the 7200 router workhorse was traditionally used. just for the same reasons that things like Nexus 7000 don't have features that cause the box to drop to software forwarding, i'd say that LAM on 6500/7600 fits the same category. or maybe it is there and just not talked about, because its not a wise thing to do. cheers, lincoln. > > > Appreciate the advice. > > > Dave. > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
