VMware, Cisco stretch virtual LANs across the heavens VMware and Cisco have teamed up with a quartet of fellow industry heavyweights to attack a vexing virtual-network configuration problem by proposing a solution that takes its inspiration from – of all places – cell phones. VMware has long since figured out how to teleport virtual machines around a network of servers using its …
yes and no. The point of this (and it sounds like it involves LISP) is that you shouldn't have to change the IGP database or cause any churn of your routing protocol to move a host around your network when you can just tunnel then shift the traffic to the host address.
The big change is that for years we have been told that tunnels are not the way but now it seems they are :)
The DMZ hopping problem is particular troubling for me in attaching physical machines from different DMZs to the same SAN. However I think virtualization, especially within a good cloud, helps to eliminate this problem, even in flat network designs. Think of this: your physical hosts/node machines are connected to the private management net, the SAN net and the public net. If anyone could get access to the host machine then all sorts of nefariousness is possible. But the host itself doesn't have an IP on the public side and the SAN/management side is protected by your firewall. From the VM perspective, there is only one network connection and it's to the public network. Even though the VM is attached to the private SAN and you can console into the VM from the management side, the VM only knows about the public side and can't move data through the private interfaces. Since the danger comes from the public side, the risk is safely mitigated.
Or not. I must admit coming to this revelation while I was falling asleep last night so it may be suspect. I look forward to any corrections smarter people may have.
Kosh: I'm guessing you haven't actually read the specification then. Less tunnelling and more encapsulation and while the concept is very simple it does solve a big problem very cheaply, efficiently and intelligently. Dynamic routing just doesn't do what this is intended to do unless you have a lot of physical interfaces and plenty of memory for VRFs = unnecessary complexity. Oh but there's MPLS/VPLS - similar yes but I can reap all the benefits of VXLANs even using a basic Netgear/D-Link/cheap switch (not that I would but I could).
Not only have I read the specification but by referring to it as "tunneling" I am quoting it. You can't split the difference between tunnels and encapsulation; the latter is simply the wire format of the former concept.
The truth of the matter is, a man was once faced with problem. A network that wasn't quite numbered how he liked it for a clean topological separation. "I know," he said, "I'll use a dynamic mesh of self-discovering tunnels". Now he had two problems.
VMware have been purveyors of braindead networking "protocols" for years and it's no surprise they're still at it.
The shocker is Cisco being so desperate to get back with the cool kids it is throwing away the whole "How to design large networks that don't suck" rulebook and actively encouraging poor practices.
Spanning Layer2 networks accross multiple sites is a cardinal sin FOR GOOD REASON - now instead of a broadcast storm, or multicast flood ruining the day for a single location the whole global network is at risk...
Long before that there will be un-expected behaviors showing up when LAN protocols start experiencing WAN latencies and performance issues when WAN links give up trying to be LAN links.
Yes.
Spanning tree should have been killed years ago - but it helped sell switch ports because STP keeps turning off and stopping yopu using redundant links...
Most of my clients want to get rid of STP to improve throughput and decrease latency.
Sometimes "tried and tested" is not enough and this is what drives innovation.
I'd learn the new stuff if I were you...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
