Recently we replaced our old 4-leg ISA 2006/SP1 with a new 5-leg TMG 2010 on 2008 R2. On both the DHCP Relay Agent is configured to serve clients on one network adapter [a wireless network]. On the new TMG 2010, after every restart the DHCP Relay agent is not working as long as the adapter it's bound to, is in state "Identifying..." network. For 3 of the adapters the NLA [Network Location Awareness] is stuck in the "Identifying..." network state. If we succeed to bring the adapter into the "Unidentified network" state the DHCP Relay is working perfectly up to the next restart.
The trick used to switch state on the adapter from "Identifying..." to "Unidentified network" is to disconnect network cable from the switch and plug it into a spare switch and move all distribution cables over. Not very admin friendly though.
I've tried nail down this for a week now.
Is there anyone else seeing this, and found a working solution?
Can NLA be configured to quick get out of "Identifying..." state?
Rune Flo.Tuesday, April 27, 2010 9:34 AM
Disbale the DHCPMediaSensing and see if that helps you.
Value Name: DisableDHCPMediaSense
Data Type: DWORD
Value Data Range: 0, 1 (False, True)
Take a trace on DHCP Server, the Relay Agent and teh client and check for the communication. Clean the arp cach of all three before taking data.
Now, filter the traffic with "ARP or DHCP" and see where is it failing.
Thursday, April 29, 2010 4:17 PM
- Proposed as answer by Nick Gu - MSFTMicrosoft contingent staff, Moderator Friday, April 30, 2010 3:21 AM
- Unproposed as answer by James KilnerMicrosoft contingent staff, Owner Sunday, August 01, 2010 9:07 AM
Thanks for for your suggestion, I really appreciate your help on this one.
I'll set off a maintenance window this weekend to try it out and report back.
I'll like you to know that RRAS LAN routing works on the interface, even in "Identifying..." network state. But only from clients with permanent IP address or with not expired DHCP address leases. Another thing I noticed when this happens, in RRAS on the IPv4 node "General" the interface where the DHCP Relay Agent is bound does NOT list its IP address [10.20.254.1]. I don't remember exact wording, but the IP Address was "unknown" or "Not available" something like that. I'll record on next reboot :)
Rune Flo.Friday, April 30, 2010 8:53 AM
While I'm reading me up on "DisableDHCPMediaSense" I came across this one:
"windows 7 DisableDHCPMediaSense and routing table"
As our TMG 2010 server runs on 2008 R2, what will you anticipate happens to the IPv4 routing tables if I set DisableDHCPMediaSense=1 and reboot the TMG server?
As of current [after reboot], in the RRAS/IPv4/DHCP Relay Agent node, the counters [Requests received, Replies received,...] for the added interface adapter shows all zero as long as the interface is in "Identifying..." state. [Netmon 3.3] trace on clients on this segment shows DHCP Request going out, but TMG doesn't pick them up and pass on to the DHCP servers on the internal network.
Just some thought in advance...
Rune.Friday, April 30, 2010 2:37 PM
Thanks for the article. I tried contacting Arthur Xie but he seems to be out of office. I'll speak to him on Monday to ask if there is any issue.
As far as I know, this should not cuase any issue. We can simply test by creating the key in our lab and compare the change in routing table. I"ll do that and update you.
Regards.Friday, April 30, 2010 6:18 PM
Thanks for your effort on this issues and your offer to test in yours lab. I'll await the outcome of your test, before applying it to my production environment.
While you are at it, is it possible to arrange a 5-leg TMG 2010 setup to nail down why the NLA service is stuck in "Indentifying..." network state for other adapters [without a IPv4 default gateway set]. Both the Internal (Domain network) and External (Public Network) are identified just fine.
And a last note, I shouldn't doubt your advice, but in reading up about "DHCP Media Sence" most are related to feed events to the DHCP Client Service to act upon (Renew lease, remove routes,...). Is this events applicable for the RRAS "DHCP Relay Agent" too, and now if the events disappears, what will then happen to solve the issue. My trick to get the adapter from "Identifying..." to "Unidentified network" state will probably be lost by disable media sensing, or?
Deep thoughts on this issue now. Need to stabilize TMG before moving on...
Rune.Saturday, May 01, 2010 12:27 PM
My 2008 R2 made no difference to its routing table when i created that key. NLA and NLS are used for the determination of the connectivity combinely.
Check these for the info:
I think our focus here is to make the Relay Agent work. I am sure if you make the change, it should help, without any change in the routing table.
Take a snapshot of Routing table, make the key, reboot, compare the routing table. You should be fine.
Regards.Saturday, May 01, 2010 5:51 PM
I've just set the registry parameter DisableDHCPMediaSense=1 and rebooted the TMG 2010 server. The setting didn't make any difference to DHCP Relay Agent behaviour. After reboot in the RRAS/IPv4/General, the actual interface [Wireless and Lab Network] show IP Address = Not available, Operational Status=Non-operational. LAN routing works on the interface, plenty incoming/outgoing bytes. But no DHCP Requests are picked up and passed on.
I then disconnect the adapter cable [fiber] put it into a spare network switch and back to the original switch everything start working. Strange?
In RRAS the interface now has got it's IP Address=10.20.254.1 and Operational Status=Operational
The adapter on this interface is an "Intel(R) PRO/1000 PF Dual Port Server Adapter" (driver version: 188.8.131.52, driver date: 26.03.2010, provider: Intel). There are plenty advanced properties available, but default settings are used. The other fiber port on this adapter is used for the external network (Internet). The server is a generous equipped Dell R610.
This interface and 2 others is still in "Identifying... No network access", so NLA has probably nothing to do with this :)
Just to satisfy my curiosity and probably narrow in, I rebooted TMG once more. I now looked at the routing tables, and noticed that the adapter route [route print] didn't show up right away. After some time (minutes ?) they appeared still:
No Manual 256 10.20.0.0/16 11 Wireless and Lab Network
No Manual 256 10.20.254.1/32 11 Wireless and Lab Network
No Manual 256 10.20.255.255/32 11 Wireless and Lab Network
But no DHCP Relay until the cable was disconnected/reconnected (no spare switch was actually needed either).
Should I keep the DisableDHCPMediaSense=1 registry setting?
Any futher suggestions of what to try?
Thanks for all help.
Sunday, May 02, 2010 10:12 AM
- Edited by RuneFlo Wednesday, May 05, 2010 1:49 PM
Please do this:
1. Install Netmon on the client and the DHCP Server
2. Install TMG DataPackager on TMG.
3. Clean the arp cache from all the three mahcines.
4. Run TMG DataPackager in Basic Repro Mode.
5. Run Netmon on all interfaces on client and DHCP.
6. Do a ipconfig/release & ipconfig/renew from the client.
7. Stop the traces after the client fails to get the IP
Share the all the data with me.
Regards.Sunday, May 02, 2010 6:57 PM
Thanks for further advices.
I'll try to get a maintenance window this evening or tomorrow, capture the data and have it uploaded to you. I assume all to be taken right after reboot while the DHCP Relay Agent is not working.
No netmon trace on the TMG itself?
Do you have an upload link or other way to share the data?
Rune Flo.Monday, May 03, 2010 11:42 AM
I'm ready to upload. The Netmon captures was taken with capture filter = "ARP or DHCP", capture period lasted until client give up on DHCP. The TMG DataPackager implicit capture resulted in 78,5 MB (82 398 011 bytes) cab file.
In Sendspace, what email to use for "Recipient's email" ?
Rune Flo.Tuesday, May 04, 2010 9:21 AM
Sorry If this is not what you have expected, but here is the [ARP or DHCP] filtered Netmon captures ((-2)after I realized that TMGDP captured too).
Is it smart to paste link to TMGDP .cab file here?
Thursday, May 06, 2010 1:45 PM
Did this get solved? I am having what appears to be the exact same issue and it is really irritating. I'm hoping you guys have found a solution.
I can fix the problem temporarily by disabling the Adapter from Network Connections and then re-enabling it.Tuesday, May 11, 2010 10:13 AM
No further info, and no solution so far. All communication going on has been within this thread.
I'm reluctant tweaking TMG config before getting this solved, but one thing I plan to test is if this could be an adapter/driver issue. The current DHCP Relay adapter is an "Intel(R) PRO/1000 PF Dual Port Server Adapter", but I have a spare "Broadcom BCM5709C NetXtreme II GigE" adapter port available. Both with up-to date drivers. What kind of adapters are you experiencing this issue with?
My workaround is disconnect/connect network plug. Do you see any issue with firewall [like hangup, timeout] when disabling/enabling adapter?
Hopefully Amit will return to this thread. No call to PSS yet.
Rune Flo.Tuesday, May 11, 2010 2:33 PM
I am running TMG 2010 as a virtual machine on VMware ESX4. The NIC that is being emulated is a Intel(R) PRO/1000 MT Adapter.
Like you I am running Windows Server 2008 R2 on the TMG 2010 server and have the same behaviour as you in RRAS (Non-operational adapter for my Wireless network leg and no DHCP Relay traffic being seen until I Disable and Re-enable the adapter in Network Connections).
I hope this is identified as a bug and fixed in a patch or service pack. Like you say though it could be something to do with Intel NIC settings?
Disabling and Re-enabling the adapter in Network Connections didn't seem to cause any other issues on the firewall and I only waited about 10 secs before re-enabling it.
BTW, none of my NICS are in identifying state when this problem occurs for me.
BradTuesday, May 11, 2010 11:35 PM
Thanks for your update. As so few seems to run into this issue, the cause may be NIC driver/config related.
As soon as I'm able to get a service window for the TMG, i'll test DHCP relay with a Broadcom NIC.
BTW, What is the driver version of your emulated Intel(R) PRO/1000 MT Adapter ?
Rune.Wednesday, May 19, 2010 10:40 AM
Changing adapter from "Intel(R) PRO/1000 PF Dual Port Server Adapter" (fiber) to "Broadcom BCM5709C NetXtreme II GigE" (cobber) fixed the "DHCP Relay Agent" issue. Both adapters have up-to date drivers, although Windows Update this month offered an update for the Intel adapter. It failed to install when selected (tried once). Not selected for update afterwards.
Still curious why this advanced (and expensive) adapter fails with the DHCP Relay Agent. The other fiber port serves our 100Mbps internet connection without any issues (as far as I can see). I'll keep the current TMG configuration for some time, but will look for updated drivers from Intel and eventually test to see if the issue remains.
Brad, Do you have a choice of other emulated adapters available?
Rune Flo.Friday, May 21, 2010 8:07 PM