On 10/08/2010, at 5:43 PM, David Freedman wrote: > Can't seem to find anything suggesting a feature which could quite easily be > a superb alternative to bridging is even remotely vrf aware. > > Any advice/pointers appreciated.
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> the former is where we (cisco) have put a lot of effort when it comes to solving real world issues for enterprise data centers. there is a flash demo on the above url that shows details of how it works. the configuration is incredibly straight forward and removes a lot of the pitfalls of alternative approaches. > http://blogs.cisco.com/datacenter/comments/cisco_and_vmware_validated_archit > ecture_for_long_distance_vmotion/ > > This is a terrible thing IMHO as you are still left to pick up the pieces as > to who owns the subnet for routing purposes, you have a few options. 1. deaggregate / announce host routes (may work ok for an enterprise, less so for other environments) 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. since they probably aren't palatable to you, we also have another way on the way. 3. LISP. <http://lisp4.cisco.com/index.html> > 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. cheers, lincoln. _______________________________________________ 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/
