Skip to main content
 
Go Search
Home
Categories
Bloggers
Clarification on OCS Edge Interface Support
By: Jeff Schertz | Posted: August 12, 2008 at 9:05 AM

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 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:

image

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

image

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:

image

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:

image

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.


  Comments   Add Comment   Share It  
  Your Name:
  Your Email: **will not be displayed
  Comment Title:
* Comments:
  If you cannot read the code, please
click here to get a new one. You won't
lose your comments by doing so.
* Security Code:
   
  
  
* Your Name:
* Your Email: **will not be displayed
* Recipient's Email:
* Subject:
  If you cannot read the code, please
click here to get a new one. You won't
lose your comments by doing so.
* Security Code:
  
  
  
Re: Do I need more than one public IP?
By: Wael Sherif | Posted: December 8, 2009 at 6:09 AM
so you mean one public IP is enough, then use three internal virtual IPs on the Edge? I'm that but getting Cookie errors on the server.
Re: Do I need more than one public IP?
By: Jeff Schertz | Posted: December 3, 2009 at 10:07 AM
If you are using NAT then you can put private addresses on all three roles. this article was written before R2 was released which added the ability to use NAT on the A/V Edge role. Regarding the certificate, take a look at this newer article for a deeper explanation on the topic: http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=79
Do I need more than one public IP?
By: Wsherif | Posted: December 3, 2009 at 9:50 AM
I can understand that we need at least two NICs and three IPs on the external NIC for each role, but the question is if NAT is enabled do I still need three public IPs. the second question is why can't I install one certificate with SAN (subject alternative names) for all roles, one of Microsoft team said we can't do this we have to get normal different certificate for each role(SAN is not supported).
Re: NAT or A/V Edge
By: Jordan | Posted: July 27, 2009 at 12:48 AM
Basically, ONE-to-ONE NAT is SUPPORTED. To all others, one-to-one means your internal server with internal ip address looks like it has a static public ip address (set / configured by Firewall). This maybe elementary concept, but reading the MS docs and concept of supported NAT and terminology is different from standards. The concept of Edge and NAT is obviously a confusing one - evidence on all Internet postings on subject. Hope this clears up one concept for someone.
Re: NAT or A/V Edge
By: Jeff Schertz | Posted: July 27, 2009 at 11:46 AM
Jordan, Basically it's supported if the public IP address is assigned directly to the interface on the server in Windows. Performing ANY NAT on the External roles (Windows has private IP addresses assigned)is supported on the AE and WC roles, but not the AV role. R2 now support NAT on the AV Edge role as well, but there are specific requirements which are documented in other blogs. This was written a year ago and doesn't address R2.
Re: NAT or A/V Edge
By: Jordan | Posted: July 27, 2009 at 11:39 AM
Ok, if I put the public ip on my FW then I will be performing a ONE-to-ONE NAT. I just thought, ANY NAT of any type is not supported; particularly on A/V Edge. If a ONE-to-ONE NAT is okay, then alot of documentations needs to be clarified from various resources. Can you please clarify?
Re: NAT or A/V Edge
By: Jeff Schertz | Posted: July 21, 2009 at 3:00 PM
If you put the IP address on the firewall and configure NAT then you'll need a private IP address on the Edge external interface to route that traffic to. If you want to use public IP addresses for Edge they need to be assigned to the server NIC(s) directly and then configured the firewall to Route (and not NAT) that traffic to the Edge server.
NAT or A/V Edge
By: Jordan | Posted: July 19, 2009 at 10:18 PM
We only have one FW for our perimeter. I have 15 routable / public ip addresses. Do I actually put a public ip address on my external interface? On my FW I will be using, but question is, the ip is set on the FW AND now on the external interface - will it route from FW to the external interface (same ip)?
Re: OCS Edge with NAT?
By: Jeff Schertz | Posted: November 5, 2008 at 10:32 AM
Andy, only the external IP address for the A/V Conferencing Edge roles must be publicly routable, the Access Edge and Web conferencing Edge roles can use either a routed public IP or NAT.
OCS Edge with NAT?
By: Andy | Posted: November 5, 2008 at 8:39 AM
I've been looking around as to the reason our Edge server hasn't been working, and thought i had it until i read this. Most sites seem to indicate that the external NIC for the edge server must have a directly routable internet IP, with no NAT. Fig 1 however suggests that Edge can work with a NAT'd IP, can anyone clarify??
By: zinid | Posted: November 4, 2008 at 6:12 AM
> If you are saying that your 'internal' AD-connected OCS server is on a public IP address then your configuration is very far-removed from best practices. Firewalls are deprecated now? ;) BTW, Edge server also needs AD connection, so I don't see the difference. Furthermore, I think that a network administrator must decide what exactly to put into DMZ. Well, nevermind :) > The Edge server is still needed for things like Federation and PIC connectivity as those components are in the Edge Access role Yes, and I can't understand why. The Edge server looks like a transaction stateless SIP proxy. What if I don't need it? I think that MS OCS is not flexible at all: it forces system administrators to reconfigure their networks and to buy (pretty expensive) ad-hoc servers.
Re:
By: Jeff Schertz | Posted: November 1, 2008 at 8:26 AM
The Edge server is used to protect the internal server's when external connectivity is needed. If you are saying that your 'internal' AD-connected OCS server is on a public IP address then your configuration is very far-removed from best practices. The Edge server is still needed for things like Federation and PIC connectivity as those components are in the Edge Access role.
By: zinid | Posted: November 1, 2008 at 4:36 AM
The only thing I can't understand is why the Edge server is actually needed. What if i don't have a private network and all IPs in my network are public?
Nevermind...
By: Doug Drewry | Posted: October 20, 2008 at 9:03 PM
I unbound the gateway address from all 3 interfaces and traffic began flowing correctly. Thanks anyway.
Interfaces
By: Doug Drewry | Posted: October 17, 2008 at 1:59 PM
I have 3 interfaces on the same subnet, 1 access edge, 1 web conferencing, and 1 for internal communication. The default gateway address is the same for all 3 interfaces, yet it never shows up for the access edge interface in an ipconfig. Thought on this? Thanks.
By: Jeff Schertz | Posted: September 11, 2008 at 8:54 PM
Certainly there is more than one way to skin a cat. This blog simply serves as a guideline to what may or may not be SUPPORTED so that administrators planning to deviate from the recommendation may know what they have in store for themselves. Feel free to link back to your own articles detailing these configuration so that others may experiment.
Valid design
By: Rich Siegel | Posted: September 9, 2008 at 12:25 AM
I should be able to use 2 IP's on the same adapter on the same subnet for these roles (AV, Conf, & SIP). There are valid good designs for this IMHO. I use a Cisco firewall as my true edge device, and deployed ISA in the Cisco's DMZ (ISA's external) and want to put the OCS Edge role on the internal network completely. I shouldn't have to make another VLAN DMZ on the ISA or run a design that positions the ISA/Edge next to each other as this link points out. If Edge is internalized and behind an application level firewall, I get both manageability and maximum security. http://www.isaserver.org/tutorials/OCS-2007-ISA-2006-Firewall-Design-Architecture.html As far as default gateways only 1 interface needs a default gateway, static routes can be created, no?
I use one NIC with multiple IPs in the same subnet
By: Scott Bueffel | Posted: August 26, 2008 at 3:14 PM
My production Edge environment uses a single NIC with multiple IP addresses in the same subnet. Since I am load balancing, I have two servers set up this way. I am not running A/V Edge on these servers; I use scaled single-site topology with AE and WC on one server. If you are interested in how I have it configured to work, let me know.
 

 About Jeff Schertz

Senior ConsultantJeff Schertz is a senior consultant for PointBridge, focused on unified communications. He has over 10 years of experience in the IT industry ranging from family-owned businesses to global product dev... [more]

View Jeff Schertz's profile on LinkedIn
Microsoft Certified IT Professional

 Tag Cloud

 External Links

 ‭(Hidden)‬ Admin Links