Forum Discussion
Chris_103447
Altocumulus
AltocumulusIssues with Exchange 2013 load balancing through LTM (v11.6)
I have a support case open for this as well, but since no one has truly engaged in spite of a Sev1 classification, I'm hoping someone in the community can help. Thank you ahead of time.
We have an Exchange 2013 (latest CU) cluster with two CAS servers and two DAG servers. We've been load-balanced through Kemp VLMs for a couple years without issues, though only w/ transparent SSL pass-through. Sunday night we migrated to BIG-IP LTM VE running 11.6 HF4 using the latest Exchange iApp. All services are co-located on the same CAS servers and we are using SSL bridging. The Exchange servers are on the internal VLAN by themselves and use the LTM internal self IP as their default gateway. Routing outside of that VLAN is configured to use the LTM external self IP as the route into the internal/Exchange VLAN.
After changing routes, DNS, gateways, etc from Kemp to F5, most things worked but clients on the "external" VLAN have difficulty connecting to Exchange. It is intermittent (about 50/50) and appears to be a mix of routing and autodiscover issues as it is slow to create new profiles and to reconnect using Outlook's "Connection Status" tool. After 30-45 seconds typically, it would connect and pass mail fine, but it won't failover if the CAS servers flip (i.e. reboots) and reconnect or fresh opening lags. We can reproduce it readily. Additionally, we show errors with our Lync servers on that same "external" VLAN updating presence/contact subscriptions from Exchange.
Of additional note, I have a forwarding virtual server setup to pass all traffic for all VLANs/IPs so that Exchange can be managed, contacted, etc for services other than those in the iApp (the LTM-VE is fully inside, so no interfaces on the internet). That seems to work fine.
The challenges have been: 1. The Exchange iApp doesn't cover SMTP, so we had to pull the community RC for that. 2. The Exchange iApp and deployment guide doesn't speak to routing/forwarding, so we had to reference an F5 KB on the IP forwarding virtual server.
Main item to troubleshoot: hosts/servers on the "external" VLAN have major connectivity issues to Exchange through the iApp (SSL/443). Lync, in particular, is having presence and contact update issues w/ Exchange.
Thanks again for any help.
Hi Chris,
I guess you were using the iApp to build your Exchange service configuration, right?
Recently I faced a similar issue after a client migrated to v11.6. Immediately issues were reported about clients not able to auto discover.
It turned out changing the clientside TCP profile to default TCP profile (the iApp deploys a WAN-optimized TCP profile) solved the problem.
Thanks, Stephan
Chris_103447Just discovered that we actually have issues accessing all virtual servers from clients on the "external" VLAN. If clients are a hop beyond that, no issues, but they can't be on the same L2 network and work consistently.
External VLAN: 192.168.50.x/24
Internal VLAN: 192.168.60.x/24
Other VLANs: 192.168.100.x, .200.x, etcIntermittently broken: Client50 --> VIP50 (arp)
Consistently works: Client200 --> VIP50 (route: 200 --> 5)Seems like something fishy with how ARP is working. Just never had this issue with Kemp...
Hi Chris-
I'm sorry you're having issues with your Exchange deployment.
Off the top of my head, without looking at your case notes directly (which I'll do), it sounds to me like there's a strong possibility that you have a duplicate IP address on your "external" VLAN--meaning, your virtual server shares an IP address with something that already exists. That would explain a lot of things: the intermittent connectivity on the same L2 network, the ARP issues, the working connectivity from remote networks (because the intervening router already has a good ARP table entry, or hides the problem by trying repeatedly to get a good connection), etc. Can you move your Exchange virtual server(s) to an entirely new IP address on the same VLAN/subnet and let us know what happens?
On a separate note, we've made a conscious decision to keep SMTP as a separate entity/iApp for now, in part for reasons of not complicating the iApp any more, and in part because many/most of our customers use a 3rd-party SMTP relay or appliance on their DMZ to send and receive SMTP messages, and don't rely on Exchange itself for that. Yes, eventually there needs to be a Send and Receive connector somewhere in the Exchange environment, but BIG-IP doesn't necessarily sit in front of those connectors. In the future, we may incorporate SMTP directly into the Exchange CAS iApp, or allow the two iApps to be optionally "chained", but we haven't made a final decision on that yet.
- Chris_103447Dayne, thanks for your reply. I don't think that we're dealing with a duplicate IP address, since we see this on all of the virtual servers. I can verify that all of them were/are available and assigned only to the LTM virtual servers. Additionally, when I attempted the L4 pass-through test virtual server, it also was an unused IP and exhibited the same behavior. I'm fine with F5's decision to separate CAS from SMTP iApps, but there should be better documentation linking them as solutions. We use Cisco ESAs (IronPort) as our perimeter endpoint for SMTP, but mail gateways still have to deliver that mail back to Exchange over SMTP, so it has to be serviced somewhere.
Chris, I should mention that although there is a community-contributed SMTP iApp, there's also an F5-contributed SMTP iApp. I'm not sure which you're using. The F5-contributed iApp comes from the same group that posts the supported iApps on downloads.f5.com, and will be moved to that location once we receive a little more feedback and complete full QA testing on it.
- Chris_103447I'm using the F5-contributed SMTP iApp (1.0.0rc2). I just called it "community" since it isn't in the downloads list.
- Chris_103447
The issue here was a conflict between Auto Last Hop and our virtual environment. For some reason, traffic through our QLogic converged network adapters would carry the host MAC rather than the virtual NIC MAC, and Auto Last Hop would try to return traffic to the host rather than the guest.
We suspect that this may be related to the QLogic CNAs, as they have exhibited strange behavior in other situations and are renowned for bad driver issues (on both Hyper-V and vSphere). For now, we've worked around it by disabling Auto Last Hop globally. We aren't losing anything by that action compared to our prior setup on Kemp VLMs, which didn't have an Auto Last Hop feature.
Thanks,
Chris
