Comments for Jim Raymond's Weblog http://jimraymond.wordpress.com Technology Thoughts Thu, 12 Feb 2009 14:48:35 +0000 http://wordpress.com/ hourly 1 Comment on Always Check the Routing by doulouz http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-10 doulouz Thu, 12 Feb 2009 14:48:35 +0000 http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-10 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 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

]]> Comment on Always Check the Routing by doulouz http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-9 doulouz Thu, 12 Feb 2009 11:52:58 +0000 http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-9 hi jim, i'd be glad to send you the whole net diagram @ your personal email thank you! doulouz hi jim,
i’d be glad to send you the whole net diagram @ your personal email
thank you! doulouz

]]> Comment on Always Check the Routing by jimraymond http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-8 jimraymond Wed, 11 Feb 2009 18:03:56 +0000 http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-8 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. 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.

]]> Comment on Always Check the Routing by doulouz http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-7 doulouz Wed, 11 Feb 2009 12:21:40 +0000 http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-7 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 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

]]> Comment on Always Check the Routing by jimraymond http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-6 jimraymond Tue, 10 Feb 2009 18:27:36 +0000 http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-6 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. 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.

]]> Comment on Always Check the Routing by doulouz http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-5 doulouz Tue, 10 Feb 2009 14:04:51 +0000 http://jimraymond.wordpress.com/2009/01/30/always-check-the-routing/#comment-5 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 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

]]> Comment on Exchange 2007 UM – Can’t get to voice mail by Mino http://jimraymond.wordpress.com/2008/04/17/exchange-2007-um-cant-get-to-voice-mail/#comment-4 Mino Mon, 13 Oct 2008 12:54:08 +0000 http://jimraymond.wordpress.com/2008/04/17/exchange-2007-um-cant-get-to-voice-mail/#comment-4 Great article man , i faced the same problem and it appeared to me that the exchange was using the self signed certificate and when replaced it with the one from CA and amde sure that the certificate request done by comman includes the FQDM of the UM servers as the first record then after it i can include any other names like autodiscover or anything else , but u have to make sure that the FQDN of the UM server is the first name so that the SN of the certificate would be the FQDN of the UM server , or else it will fail when communicating with the OCS. by the way i mentioned ur gr8 post about striping the + on my blog http://theucguy.wordpress.com/ Great article man , i faced the same problem and it appeared to me that the exchange was using the self signed certificate and when replaced it with the one from CA and amde sure that the certificate request done by comman includes the FQDM of the UM servers as the first record then after it i can include any other names like autodiscover or anything else , but u have to make sure that the FQDN of the UM server is the first name so that the SN of the certificate would be the FQDN of the UM server , or else it will fail when communicating with the OCS.

by the way i mentioned ur gr8 post about striping the + on my blog
http://theucguy.wordpress.com/

]]>