Always Check the Routing
I just finished troubleshooting a problem that I should have solved sooner than I did!
A very simple installation of OCS 2007: a single standard pool and a single consolidated edge server. They didn’t have a PKI structure and oddly didn’t want one, so we used GoDaddy for the internal certs and Thawte for the public certs. After the implementation, everything seemed to work fine…
…until we tested one of the internal company users trying to make a Communicator call to another company user that was connected from the Internet. The invite was sent and the other client would ring, but the call would not connect. I began to narrow the scope of the failure by running the validation on pool and edge and taking Snooper traces of both servers. There were no errors and only this message in the Snooper trace, “Call terminated on media connectivity failure“, for the reason the call was terminated. As it turns out, inside to inside calls worked, outside to outside calls worked. The part that confused me, and still does to some degree, is that Federated calls succeeded.
Knowing that peer-to-peer calls don’t use the AVMCU, I decided to test LiveMeeting to ensure the MCU was OK…and it was. I was able to get full voice and video from a LiveMeeting hosted from the pool server.
Typically, I will install a consolidated edge with three public IPs on one NIC, an internal IP on a second NIC, and have the default gateway on the external NIC. Most smaller installation don’t have internal firewalls and have the edge installed directly on the internal LAN. I had overlooked the internal NIC configuration in assuming that communication was good to the internal network. It wasn’t until a ping from a workstation failing to the edge that reminded me to check the routing table on the edge server. Sure enough, the ping response was not able to be routed back since there were different subnets between the internal IP of the edge and the internal network. Once I added the internal persistent route, everything worked fine.
| route add 192.168.0.0 mask 255.255.0.0 192.168.251.1 if 0×10003 -p |
In this case the internal network was 192.168.11.0/24 and the internal interface of the edge was 192.168.251.0/24. The other office locations on the MPLS are other 24 bit masks of the 192.168 networks and are all reachable through the 192.168.251.1 gateway address. The funky part of the route add statement is getting the interface ID from the top of an ipconfig command and using the 0×1xxxx number. Lastly, the –p makes the route persistent (i.e.: after a reboot).
Now, back to the Federated call working when the route statement wasn’t there…
It appears that for Federated calls, the AVMCU is utilized. I’m researching that now. Someone please enlighten me.
Tags: calls, edge, ocs, OCS 2007, route add, voice
You can comment below, or link to this permanent URL from your own site.
February 10, 2009 at 6:04 am
hi there,
exactely same problem here.
can you elaborate a little bit about the need to specify the interface on the route add command?
i’ve got a similar static route (but withouth the IF thing) and still no luck to make 1-1 calls work.
thank you so much, doulouz
February 10, 2009 at 10:27 am
Thanks for the comment doulouz.
The interface specification enforces the NIC that will be used to reach the gateway IP on the route statement. This is especially important in the Mediation server. Frequently, I have setup a Mediation where both NICs are on the same subnet. In order to isoloate PBX vs. OCS traffic per NIC on the Mediation server the IF parameter becomes especially important! Also, be sure to use the -p to make the route persistent after a reboot.
February 11, 2009 at 4:21 am
jim,
thanks for explaining.
from what you’re saying, i understand that the internal client needs to contact the edge’s internal interface, because that’s where the media traffic gets out to the external client.
And, i confirmed that this is true. My internal clients are not on the same subnet as the internal edge NIC, but a tracert reveals that the internal client knows how to get there.
BUT
i’ve performed a tracert from the edge server TO the internal client and no luck! packets generated from my edge do not know how to go to the internal client. i believe that one of the routers doesn’t have proper tables to route the return traffic from edge to internal clients.
jim, in order to be 100% sure that i’m in the right direction, can you confirm that the media traffic coming from the external client flows to the external A/V edge nic, then to the internal edge NIC, then direct to the client via the edge IP routing table (no OCS proprietary routing involved and no front-end involved).
thanks so much, doulouz
February 11, 2009 at 10:03 am
doulouz,
Interesting. You are on the right track, but let’s look at it another way. Let’s use name resolution and ping. Can your Edge resolve and ping your front end? …how about the clients? In my case, the clients ping would reach the Edge, but the Edge couldn’t find its way back to the clients. It sounds like your clients can reach the Edge and with your route statement, the Edge should know the way back to the clients (at least the next hop or gateway).
I would need more specifics on your subnets and router config to be sure, but it sounds like you should check the internal routing.
February 12, 2009 at 3:52 am
hi jim,
i’d be glad to send you the whole net diagram @ your personal email
thank you! doulouz
February 12, 2009 at 6:48 am
jim,
my client can get to the edge. they can resolve, ping and tracert correctly to it.
the opposite, however, is not true. a tracert reveals that packets never get from the edge to the target client.
on my edge, there’s a static route pointing to the next hop for the internal interface (the road back to the clients). but packets get lost somewhere. that’s a customer’s site, and i don’t have a clear picture of what’s in between.
thank you so much, douloz