So this blog is sort of a follow-up to Matt McGillen’s original article on the same subject. During a recent OCS deployment I was configuring a Mediation Server against a IP-PBX system that is to be tested for eventual certification. In doing so I made sure to configure all aspects of OCS to strict best practice recommendations, including this specific one from the OCS 2007 Enterprise Voice Planning and Deployment Guide
Configure Dual Interface Cards for Mediation Server
To help ensure the physical as well as logical separation of your Enterprise Voice infrastructure from the media gateways, you should install Mediation Server on a computer that is equipped with two network interface cards (NICs). One card faces the gateway; the second card faces the Communications Server 2007 server that acts as the Mediation Server’s internal next hop.
But what is not included in the guide is a clear statement as to how the multiple interfaces should be configured. What is inferred in other documentation and covered in materials like the Voice Ignite classes is that this dual NIC scenario assumes that both interfaces are connected to different subnetworks. This topology coincides with a ‘secure’ internal network where OCS client-to-server communications are encrypted over TLS, while the other network in which the Mediation Server and Media Gateway talk is considered an ‘unsafe’ network as standard SIP and media traffic flows over the wire unencrypted.
What we learned long ago was that multiple IP addresses on a Mediation server (whether on the same or separate NICs) was always a big headache as SIP invites would physically leave the Mediation Server over the defined ‘Gateway Listening’ interface but would sometimes include the other interface’s IP address in the Session Description Protocol details. So an IP-PBX might look at these packets coming from the IP address it was configured to trunk across but see in the packet’s SDP that the origin of the packet is actually recorded as the other IP address. You can see in the Network Monitor capture below how traffic from the Source address of 192.168.131.232 actually shows the origin of 192.168.131.222:
This is not cool, as the voice endpoints on the IP-PBX system can be referred the wrong IP address to send media traffic to, or have other weirdness like voice communications working in only one direction. Now this isn’t a problem specifically with OCS, but more to do with how Windows Server handles multiple network interfaces in the same subnetwork. Since the first interface’s IP address (which is also the FQDN-resolvable IP) is treated as the ‘primary’ IP it appears that some traffic is just ‘stamped’ with that overriding IP address.
Now the general consensus is that in this scenario simply moving to a single interface with a single IP address will resolve the issue. And it does. There are also a coupld of other workarounds, but they are simply masking the behavior and not resolving it. But if dual NICs are configured across separate subnetworks, as the Mediation Server was envisioned to be deployed, then the behavior shown above goes away, as Windows Server will correctly stamp the origin with the only valid IP address for that subnet.
Having separate subnetworks on both ‘sides’ of the Mediation Server makes it more clear why the documentation calls for two dedicated interfaces:
So, in environments where the Mediation Server and Media Gateway or IP-PBX are in the same subnet, then a single interface on the Mediation Server is still the recommended approach. And then leave the confusing dual interface setups for environments where separate subnets are in use and they are actually needed.
