I previously discussed using LISP to optimize your client-server traffic so today I’ll discuss the reverse direction: Egress Path Optimization from the Server to the Client. Let’s go over the need for Path Optimization in the direction from Server-to-Client with some pictures and explanations.
The Virtual Machine (VM) server is configured with a default gateway IP address, 192.168.1.1, which is the next hop IP address that the VM will forward packets towards as the traffic returns to the client outside the data center. In this data center environment, we’ve deployed the default gateway using the First Hop Redundancy Protocol (FHRP). In reality, FHRP is an umbrella technology term that includes Hot Standby Routing Protcol (HSRP) and Virtual Router Redundancy Protocol (VRRP), two main technologies that provide transparent failover and redundancy at the first hop IP router. Please see info on FHRP here.
Also notice that the VM default gateway is the same as the HSRP Virtual IP Address (VIP). The HSRP VIP binds itself to one of the physical HSRP Routers via an HSRP election process using Layer 2 control packets between the two physical HSRP Routers and this means that the VM default gateway, since it points to a VIP, may move between physical HSRP Routers, and of course which is then intent and design when using any type of FHRP.
In the above picture, the Path is Optimized from Server to Client, so now let’s take a look at what happens when we migrate the VM to the new data center.
You can see from the above picture that we’ve migrated the VM to the second data center, Data Center Beta (notice the neat arrows going from left to right). The configuration settings of the VM have not changed, the default gateway is still 192.168.1.1 and it still points to an HSRP VIP on Nexus 7000 Routers, but now all these components are in data center 2. All Server to Client traffic returns via the path in data center 2 and HSRP will elect a physical HSRP Router to bind the HSRP VIP and the path from Server to Client in data center 2 is optimized because it takes the direct path…
The live migration of the VM implies that we have a Layer 2 extension between the data centers (OTV, VPLS, VPC, FabricPath, TRILL, etc.) . This Layer 2 extension means that there are Layer 2 adjacencies between the HSRP Routers in Data Center Alpha and Data Center Beta and since the HSRP Routers talk Layer 2 to each other to elect the HSRP primary and standby routers and associated HSRP functionality, there is a great potential (IE near certainty) that the HSRP Routers in Data Center Alpha will send and receive HSRP control plane packets with the HSRP Routers in Data Center Beta.
Ultimately, what could happen is that the VM in Data Center Beta may use the HSRP VIP in Data Center Alpha as the default gateway IP next hop. Clearly, the picture below shows a suboptimal, non-optimized path from server to client since it starts in Data Center Beta but has to go through Data Center Alpha to get back to the client. We want it to go directly and only through Data Center Beta.
You have a choice here, you can create a manual or automated process to change the default gateway setting on the VM after it has migrated. However, changing the VM IP configuration will of course drop existing sessions and then require system wide updates to propagate (DNS, Management, Security Policies, etc.) associated with the new IP scheme to ensure re-acquiring desired system policies. Argh !
Another option, which may alleviate that headache, is to use FHRP to our advantage. We continue using FHRP in data center 1 and FHRP in data center 2 (specifically and in our case: HSRP in Data Center Alpha and HSRP in Data Center Beta). We continue as is and then we “filter” the FHRP messages from being processed by the remote FHRP Routers. For example, when using HSRP, you would create HSRP message filters at your DCI edge to prevent HSRP messages in data center 1 from being processed by HSRP routers in data center 2. You might see this referred to as FHRP filtering and since we’re using HSRP, also referred to as HSRP localization.
Luckily, our team developed a Cisco Validated Design (CVD) that provides details in how to do FHRP filtering (ie HSRP Localization) on two different DCI Layer 2 extension technologies. We provide configuration examples for FHRP filtering over OTV and another set of configuration examples for FHRP filtering over VPC because there is a slight difference between how to filter them. To complete our example, once we filter the HSRP messages, we now have the optimized path in Data Center Beta. Final picture below.
Here’s the CVD with FHRP Filtering examples in the “Egress Path Optimization” section.
Check them out feel free to reach out to me here or via linkedin with any question, comments. etc..
I think in another post I’ll tie both LISP and FHRP together in one discussion to complete the picture…stay tuned..