This was a question from a national vocational university. They wanted to know if they needed multiple NICs/VLANs and a Perimeter for OCS R2 Edge since they didn’t have one already.
One or two NICS?
The answer is two NICs are now required for OCS R2 Edge where you could get away with a single NIC in R1.
Multiple VLANs or Perimeter needed?
With two NICs, you also need multiple VLANs to accommodate this. Placing the Edge in a firewalled Perimeter is strongly recommended.
Two sample Edge VLAN configurations
Single Consolidated Edge server:
Sample Load Balanced Consolidated Edge VLAN:
What are the Edge roles I need to deploy again and what do they do?
Do I need a unique IP for each role in consolidated Edge?
Yes, a unique IP is required per role (3 per External NIC).
Can I NAT the A/V Edge role?
If you are deploying a single consolidated Edge server you can NAT the A/V Edge role IP however it is not the recommended method of deployment. The sample VLANs above show the recommended method.
If you are deploying a load balanced consolidated Edge array NAT is not supported and an external routed IP is required. See VLAN sample above.
How many certificates do I need for Edge?
Internal NICs need one cert:
Go here for more info.
External NICs need two certificates:
Note: I heard these could be combined by adding the FQDN of Access and Web Conf roles to the same SAN cert.
Other certificates for Edge:
With load balanced Edge consolidated servers can I use software load balancers?
No, a hardware load balancer is required.
What firewall ports do I need to open with Edge?
More info go here.
Other Edge Best Practices
•Have 2 NICs in both your Edge and ISA servers
•Put them on completely different networks
•Have the default GW on the external facing NIC only (and pointed outside)
•Use 3 IP addresses associated with the external facing Edge NIC
•Create a persistent static route between the DMZ and corpnet if the internal facing Edge NIC is not on the same network as the Pool FE
•If you use a split zone DNS make sure there is no overlap in how names resolve internally and externally when dealing with Edge interfaces
•Confirm that firewall rules allow contact with the correct set of devices internally and externally, that they are open in the correct direction and associated with the correct protocols
•Make sure you assign a dedicated AV Auth cert
•Make sure the Edge server knows about the pool and the pool knows about each of the Edge roles and that AV didn’t accidentally default to 443
This was a question from a national vocational university. They wanted to know if they needed multiple
The diagram w/ the load balancers in the picture with no natting involved seems to have natting? Goes from 18.104.22.168 to .31/.32? What is the actual requirement here? And how does NAT break the transaction?
The diagram depicts a hardware load balancer virtual IP (VIP) of .16.30 which balances between .16.31 and .16.32 IPs.
You can NAT the web conf and access edge roles in the load balanced design however the AV cannot be NATed as remote audio and video do not work in this design.
There is an excellent step by step guide for deploying OCS R2 Edge that just became available here:
Isn't that Natting to go from .16.30 to .31/.32, regardless of the device doing it(lb)? The destination ip is actually changing, correct?
Load balancers inherently implement a network address translation (NAT) function as they attempt to make a single virtual IP address distribute across multiple physical servers. There are two obvious ways to do NAT: based on the destination address/port (DNAT) or based on the source address/port (SNAT). In OCS 2007, we supported either mode. In R2, we no longer support DNAT.
Why? Because DNAT has some peculiarities when one of those physical OCS servers behind the load balancer wants to communicate with different OCS server in the same pool and wants to load balance that communication as well. There’s no good way to make this work with DNAT. With SNAT, this works just fine.
Thanks for the reply - you seem to have done some homework on this - still trying to understand these requirements for the implementation our messaging team is working on currently.
Just a couple more if you are willing >
1. If I get your last statement correctly, you are saying that if another physical server in the lb pool of servers needs to make a request to another physical server in the pool (probably a load balanced request to the vip i'm guessing from your snat/dnat explaination), the connection is never established (asymetric request, client->vip, server->client)?
Can you work around this issue, by source natting only the server in the pool when they need to make a request to one of the vips that load balance to physical servers on the same network/subnet or even same pool?
2. Just to make sure, I worked with the messaging team on their ocs 2007 environment and needed to due a double nat to "bridge" the connection using public -> this was to make the stun protocol work - This is not the same protocol/requirement we are looking at here right? Haven't had a chance to take a packet capture on this traffic yet, so didn't know if the client side ip is being inserted in the payload like the STUN was.
For question 1, yes if you use DNAT. This is why we no longer support DNAT for a HW LB config in OCS R2.
For question 2, not sure about the double NAT. You can NAT the Access Edge IP and Edge Web Conferening IP but not the A/V Conferencing Edge IP per the diagram above.
Love the Visio diagram to visually show an OCS config end to end.
Any way to get a copy of the Visio template used to create that to same me some time documenting our environment? Great article.
Let me check on the visio. I believe all I have is the static image. If find it I will post a SkyDrive link in here.
Is it possible to have a link to download the visio schemas please ?
Thanks in advance.
Sorry, I only have the images as I pulled them from an R2 training slide deck. There was no author listed for the content.
For a consolidated edge server with one physical interface per role (no load balancing), how do you make sure that the server replies to access packets on the access interface, and not the AV interface? (And is this important?) It looks as if the strong-host model is not available on Windows Server 2003.
For consolidated Edge single server (no LB), you only need two physical NICs (external and internal). You can then bind a unique IP per role. Traffic is routed based on IP and FQDN.
There is a useful Edge planning tool if you haven't see it that lays it all out for you: