Looking at the possiblity of deploying LISP VM Mobility between geographically disparate data centers with extended subnet mode via OTV. I've looked over the Cisco guide and it states that the ETR function needs to be L2 adjacent to the mobile nodes to detect the vm migration between sites.
Unfortunately, we need firewalling and traditionally we would have the firewall separating the Core and WAN modules of the network design. Placing the xTRs at the distribution layer would tunnel through the firewalls. Anyone dealt with something to this effect? Unless someone knows of a firewall that is LISP aware and can inspect the inner headers and payload, I am thinking the only way to get proper security would be to put the firewalls in transparent mode between the mobile nodes and the default gateway (ITR). Alternatively would be to use host based, hypervisor based security, or ASA 1000v which in our case seems unlikely due to needing a mix of virtual and physical hosts with a large mix of OSes.
Am hoping that the mobility event generated by the detection of the VM migration can be separated from the xTR function. This way we could place the xTR function in the WAN block on the ASRs and have the dynamic EIDs defined on the 7K. When the 7K detects the migration, it can either register the EID with the MS on behalf of the ITRs or it can notify the ITR to do the same. This way the xTR encap/decap can happen outside the firewall while the mobility occurs inside the firewall and these functions can be L3 separated. Is this currently possible and just not mentioned in the guide?
Would love to get some feedback.
Have you been able get any more information regarding this configuration? I have been looking at this for a potential deployment and a firewall in front of the servers is under consideration. The ability to place the firewall in the network with OTV/LISP will be be important consideration.
One additional question I have is what happens when a server moves from one location with active sessions to remote users. What happens to this traffic as LISP redirects traffic in mid-session.
Sent from Cisco Technical Support iPad App
No, I have not been able to secure a meeting with anyone deeply familiar with the development of the protocol or anyone deploying it. As for the active session question, my understanding is that the traffic can flow through the existing path during the transition and be routed over the site to site link internally, via the OTV. This is until the xTRs are fully synched with the new location information at which point traffic will be rerouted to the new site optimally. Whether or not packet loss is observed is still a question in my book.
I think this feature could solve your problem:
With the feature "Configuring TCP State Bypass" two ASA could be active at both datacenters.
Of course the ASAs must be deployed between the servers and the ITR/ETR in layer-2-modus (transparent mode) so that the ITR/ETR can see the ARP requests from te servers.
Would this solve your problem?
Hi Eneudenberger, thanks for the feedback, I appreciate it. I have thought of this as a solution and here are my thoughts. This will certainly work with a small number of VLANs. I am trying to serve a large number of VLANs so this solution becomes less desireable as the number of VLANS increase and therefore increases the number of firewall instances required to support the solution. I am also trying to limit the traffic that goes through the firewalls. This would force all off subnet traffic to flow through the firewall which is not a requirement for our solution and would increase the hardware requirements for the firewall itself, forcing us into a very large FW platform. Besides all of that, I have used TCP state bypass to allow failover and failback between geographically disparate sites. TCP state bypass comes with its own set of downsides,
1. (obvious) no TCP state maintenance.
1a. TCP timers need to be tweaked because connections are not removed from the firewall tables on FIN ACK. In some environments with lots of transient short lived connections, this can cause connection count exhaustion.
1b. Service policy inspections for tcp don't work. Loss of FTP inspection will turn your firewall into swiss cheese.
1c. Each firewall rule you may now needs a reverse rule allowing the reverse connection i.e. create a firewall rule on inside interface allowing machines to "any" on tcp destination port 80 and now you need a rule on the outside interface allowing tcp source port 80 from "any" to your machines.
TCP State bypass isn't fun!
All that aside, I have been told by someone on another forum that Cisco is adding the ability to have the VM move detection separated from the xTR function so that we can put the firewalls between the WAN and the Server Distribution, which would be fantastic. I haven't seen anything as of yet but let me know if you come across it or have any other ideas, Thanks!
Thanks for the update. I agree TCP State Bypass is not the final answer.
I haven’t found anything else that address this issue however.
Hi Carlo, Hi Bill.
We are doing east-west DC moves today where east-west moves south of the firewalls are detected and trigger the event on the north side of the firewalls with LISP. Its really cool!
I need to spend some time next week documenting the solution next week.
I'd be glad to talk to you about it further.