Design Reference
Table Of Contents
- Contents
- Chapter 1: Introduction
- Chapter 2: New in Release 4.0.50
- Chapter 3: New in Release 4.0.40
- Chapter 4: New in Release 4.0
- Chapter 5: Network design fundamentals
- Chapter 6: Hardware fundamentals and guidelines
- Chapter 7: Optical routing design
- Chapter 8: Platform redundancy
- Chapter 9: Link redundancy
- Chapter 10: Layer 2 loop prevention
- Chapter 11: Spanning tree
- Chapter 12: Layer 3 network design
- Chapter 13: SPBM design guidelines
- Chapter 14: IP multicast network design
- Multicast and VRF-Lite
- Multicast and MultiLink Trunking considerations
- Multicast scalability design rules
- IP multicast address range restrictions
- Multicast MAC address mapping considerations
- Dynamic multicast configuration changes
- IGMPv3 backward compatibility
- IGMP Layer 2 Querier
- TTL in IP multicast packets
- Multicast MAC filtering
- Guidelines for multicast access policies
- Multicast for multimedia
- Chapter 15: System and network stability and security
- Chapter 16: QoS design guidelines
- Chapter 17: Layer 1, 2, and 3 design examples
- Chapter 18: Software scaling capabilities
- Chapter 19: Supported standards, RFCs, and MIBs
- Glossary
Figure 43: Traditional routing before moving VMs
A VM is a virtual server. When you move a VM, the virtual server is moved as is. This action means
that the IP addresses of that server remain the same after the server is moved from one data center
to the other. This in turn dictates that the same IP subnet (and hence VLAN) exist in both data
centers.
In the following figure, the VM moved from the data center on the left to the data center on the right.
To ensure a seamless transition that is transparent to the user, the VM retains its network
connections through the default gateway. This method works, but it adds more hops to all traffic. As
you can see in the figure, one VM move results in a complicated traffic path. Multiply this with many
moves and soon the network look like a tangled mess that is very inefficient, difficult to maintain,
and almost impossible to troubleshoot.
Reference architectures
December 2014 Network Design Reference for Avaya VSP 4000 Series 91
Comments? infodev@avaya.com










