I had a question regarding a datacenter move we have coming up at our company. Currently we have a 6500 with an FWSM with about 10-15 virtual contexts. There are about 15-20 VLANS which are used over ESX hosts through virtual machines.
We will be reconstructing the datacenter using two new 6500s with VSS, and my question is, is there a way I can use the exact same inside IP's and VLAN schema for this cloned infrstructure, but still communicate back to the old 6500 or do I need to use a new IP block? Basically, I would like to be able to turnk a few ports from the current to the new environment, so I can do data transfers as needed. The new 6500s will have a different ISP as well, so the only thing im thinking about is if I can keep the same internal VLANs and scopes or do I need to change. Can you please advise on the best route to take for this? If you need more info please feel free to ask, and thanks in advance to all who contribute.
Basically have BGP with two ISPs configured and 12-15 virtual contexts inside of the FWSM on the 6500. Static routes route the public IPs to the approriate virtual context. In total about 30-35 VLANs in production, and all run thrugh the 6500 and ann access-layer 4500. There are bridge-groups on the 6500, and all the contexts are routed not transparent.
In a perfect world, I can build a side by side infrastructure identical to the current, with the same VLANs, and same internal IPs. The public IPs will change, and I realize that, but I would like to keep the internal infrastructure as identical as possible, as the virtual machines wil be getting closed from the current to the new infrasturcture.
You can make use of Same IP address for internal LAN , Intially (until your migration completed ) you can have MAN link between datacenter connecting between 6500 of both location . Same VLAN can be extended between both location . On new location you can create appropriate L2 VLAN , Do VMotion for your VM . Then you can change gateway for those VM machine pointing to your new datacenter firewall .
B) To avoid service outage , you can do FQDN registeration with both old & Public IP address for NATED server .
vMotion is a vCenter operation, therefor you can only vMotion between two hosts that are managed by the same vCenter.
However within the vCenter a few limitations also exists. A virtual datacenter object is a vMotion boundary, therefor the two hosts must belong to the same datacenter within vCenter.
If you use a virtual distributed switch, both hosts must have their vMotion and VM networks connected to the same vDS. That means both hosts must connect to the same VDS with their vMotion network and the VM network on the source host must belong to the same distributed virtual switch as the destination host.
By default WAN connections with latency of 5ms or less are supported by the licenses, the enterprise plus license features Metro vMotion that has a mechanism that can sustain up to 10ms of latency. We officially do not list a minimum bandwidth requirement. I'm currently involved in getting a public statement out of the minimum required bandwidth for vMotion across WAN.
I apoligize if I wasn't too clear. I will be cloning this infrastructure within the same data-center. So I can run trunk cables local between the 6500's. Also these hosts will not be V-Motioned. We will be cloning these machines and bringing them online in the new infrastructure, so both will be online at the same time. Current and New. We will modify the new servers, and test the entire infrastructure before modifying public dns to port the names over to the new public IPs
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...