Clarification on OCS Edge Interface Support

A question that comes up almost weekly in the TechNet discussion forums is: "Can I use only one network card in my Edge server?"

Background

A definitive answer has always been difficult to nail down as my testing, other user’s experiences, different Microsoft documents, and some other sources all seem to slightly contradict each other. Let’s start with the documentation; the OCS 2007 Supportability Guide states the following:

“Edge server roles can be collocated, but each server role must have a separate IP address. Each server role can use a separate physical network adapter, or all server roles can use a single multihomed network adapter.”

“Two network adapters, one for the internal interface of the Access Edge Server and one for the external interface, are supported and recommended. A single multihomed network adapter for both the internal and external edge is also supported.”

So my first thought is: what exactly is a “single multihomed network adapter” in those contexts? That term can mean a couple different things. According to the Microsoft KB article 157025 a multihomed computer is "one that has multiple network interfaces" but another TechNet article for TCP/IP in Windows Professional 2000 states that a multihomed computer is when "a computer can access multiple subnets that are logically separated, but bound to a single network adapter.”

To further complicate things, Wikipedia defines four different variants for a multihomed computer as:

1. Single interface connected to multiple IP subnetworks
2. Multiple interfaces with a single IP address for interface
3. Multiple interfaces connected to the same IP subnetwork
4. Multiple interfaces connected to separate IP subnetworks

Confused yet? So basically, a single multihomed network interface could mean one of several different scenarios, and I did not believe that all of these situations are supported or even possible based on network configuration limitation within OCS and Windows Server itself.

In the past I tried to deploy a simple Access Edge server with a single Interface for the internal and external network, which were both in the same IP subnet (connected back to a switch routed to a single third-leg ISA server for the Perimeter Network) and it simply would not work. SIP traffic wasn’t passing back to the Front-End server; it just would not leave the Edge server. External connections authenticated, but traffic just died ‘inside’ the Edge server. Once I installed a second NIC everything worked fine. Yet I have heard about some people getting an Edge Server to operate correctly with a single interface, but I was unaware of what the exact configuration was were the working and non-working scenario’s failed.

So thanks to input from Neil Deason at Microsoft, I was able to come up with what I hope to be a pretty clear definition to this common question.

Supported Configurations

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

The documented, recommended, and unquestionably supported configuration is simply to deploy separate physical network interface cards which are connected to separate IP subnetworks. (This includes a single physical card with multiple ports; whatever physical configuration that allows you to plug two cables into the server and the host sees separate interfaces. Let’s not get silly here.) By definition this means that the internal and external subnetworks need to be uniquely different, which is typically found in a standard Perimeter Network located between separate firewalls.

A simple Access Edge deployment utilizing NAT:

Or a consolidated Edge deployment with all three external roles assigned publicly routable IP addresses:

The above configuration only works for a consolidated Edge Server when all external IP addresses are on a public IP subnetwork, otherwise separate adapters connected to separate IP subnetworks would need to be used. The Access Edge and Web Conferencing roles can be co-located on the same same external interface using the same IP private subnetwork.

Here’s a consolidated Edge deployment using the least amount of public IP addresses:

This can be expanded up to separate physical adapters for each external role in a consolidated Edge server, as shown repeatedly in the documentation, for enhanced performance and security. And if plenty of public IP addresses are available, then assigning each role a public address simplifies the configuration further:

Unsupported Configurations

A Consolidated Edge or dedicated A/V Authentication Edge server will clearly not operate on a single network interface due to the A/V role’s requirement for a publicly routable IP address, which would conflict with the requirement of separate IP Addresses spaces for the internal and external networks. So, a single multihomed network adapter connected to a same IP subnetwork for both internal and external routes is not supported for the A/V Edge role specifically.

The ‘Fuzzy’ Configurations

There are a few scenarios that fall into this category which technically ‘can’ function but it depends on the layout of the existing networks, the deployment of the OCS servers, and maybe what color shirt you are wearing that day. Basically, it might work but it’s not recommended and the supportability is not 100% clear. Contacting PSS may result in a resolution or a request to reconfigure the server to match recommended guidelines.

1. A single physical network interface with multiple IP addresses in different subnetworks, for a dedicated Access Edge server. Technically this works, but the documentation states that it only applies to the Access Edge role, and probably is not supported for the Web Conferencing and A/V Authentication roles.
2. Multiple physical network interfaces with multiple IP addresses in the same subnetwork. This configuration works and is supported, but is highly discouraged as to accommodate the need for separate interfaces you would have to configure gateways on both network adapters. This is not recommended due to the Dead Gateway Detection feature of Windows Server. By design, only one of the two gateways can be used by default and there is no load balancing or logic used for routing, Windows simply becomes a non-opportunistic router and traffic flow could be very spotty. Networks with a single firewall appliance (e.g an ISA Server deployed in 3-leg Perimeter mode) fall into this category and the recommended configuration is discussed on page 18 of the Designing Your Perimeter Network for Office Communications Server 2007 White Paper from Microsoft.
3. A single physical network interface with multiple IP addresses in the same subnetwork. I’ve already stated this an impossible configuration for the A/V Authentication role, but may work for the Access Edge and Web Conferencing roles. I personally have not gotten this to work the one time I attempted it for the Access Edge role, but I have heard vague references of it working although I haven’t seen any documented proof. This is even less desirable than the configuration above.

So the moral of the story continues to be: use at least two NICs! In a full-feature deployment OCS can get complicated quite quickly and I still don’t understand the desire to cut corners in this area. And if you are working in Perimeter network with only a single IP subnetwork, then you’re already twice-removed from the optimal configuration by attempting to use a single NIC in the Edge server. But if you don’t want to follow the deployment shown in the Perimeter Network white paper, at least use separate NICs in the Edge server to more closely match Microsoft’s recommendations and hedge your bets towards a better level of supportability.