Article ID: 205027 - View products that this article applies to.
This article was previously published under Q205027
This article describes in detail the operation of Dead Gateway Detection (DGD) and its interaction with the Routing and Remote Access Service (RRAS) Update.
The following list includes the 3 primary scenarios where fail-over may be expected, but does not occur:
In this scenario, it may be expected that if the local-area network (LAN) connection does not work for some reason, the Dial-On-Demand (DOD) connection will start. This is based on the idea that DGD should start once the first default gateway does not work. There are 2 static routes on RRAS-A:
DOD - - - - DOD / \ RRAS-A RRAS-B --- LAN 18.104.22.168 \ / LAN - - - - - - - - - - - - LAN 10.10.10.1 10.10.10.10
If a program on RRAS-A is running and is accessing 22.214.171.124, the path it takes is across 10.10.10.10 over the local area network (LAN) connection. With the preceding static routes, there is no problem as long as the LAN connection exists. However, if the LAN connection does not work, any further communication also does not work. Because of this, DGD is not activated and the DOD connection never dials.
destination net mask gateway interface metric 0.0.0.0 0.0.0.0 126.96.36.199 dod-test 4 0.0.0.0 0.0.0.0 10.10.10.10 NIC 2
In this scenario, it may be expected that if the dedicated Internet Service Provider (ISP) connection for some reason does not work on the external side of the proxy server, the DOD connection starts. This is also based on the idea that DGD should start once the first default gateway does not work. The static routes that might be attempted may look like the following table:
DOD - - - - - RAS / \ LAN - - - RRAS/Proxy ISP - - Internet non-valid \ / IP address LAN - - -T1/other - - - LAN
When multiple default gateways are specified on the external side of a Microsoft Proxy 2.0-based server, it might be expected to provide redundant connections to the Internet through the dialup device or devices. But if the LAN based ISP connection does not work, any further communication also does not work. Because of this, DGD is not activated and the DOD never dials.
destination net mask gateway interface metric 0.0.0.0 0.0.0.0 188.8.131.52 dod-isp 4 0.0.0.0 0.0.0.0 184.108.40.206 NIC 2
This scenario is very similar to scenario 2, but it does not work for a different reason. In this scenario, the LAN behind the RRAS server is using Internet-valid IP addresses. When clients are trying to pass outward through the RRAS server, if the LAN-based ISP connection does not work, the RRAS server never activates DGD and does not dial the DOD connection to the ISP. Note that this occurs even with the static routes in the following table:
DOD - - - - - RAS / \ LAN - - - RRAS ISP - - Internet valid \ / IP address LAN - - -T1/other - - - LAN
The reason for this inability to fail-over is that DGD relies on TCP transmission in order to activate it. When an RRAS server is behaving as a router, as it is in this case, it never parses the IP packet beyond the IP layer. Instead, it determines if the packet should be routed, and then either routes the packet or drops the packet.
destination net mask gateway interface metric 0.0.0.0 0.0.0.0 220.127.116.11 dod-isp b 4 0.0.0.0 0.0.0.0 18.104.22.168 NIC 2
Dead Gateway Detection only is activated by a server when it is the "initiator" of the TCP connection. In the preceding case, RRAS is not the source or initiator of the TCP session, and so is "unaware" that TCP sessions are not working correctly. Again, because the RRAS server does not "look" above the IP header when acting as a router, it never "sees" whether a packet is a UDP or TCP packet. That is why (in this scenario) RRAS will never fail-over to the second default gateway.
In all three of these scenarios, the behavior expected will not occur. Default gateway static routes added to RRAS that point to a DOD are not added to the list of available default gateways available to the router unless one of the 2 following conditions exists:
If you want to see the routes that the kernel of the OS is using at any one time, you can use "kernrout print" command at a command prompt. This is the routing table at the kernel level. This shows you the single best route that will be used by the operating system when making routing decisions.
Article ID: 205027 - Last Review: November 1, 2006 - Revision: 1.1
Contact us for more help
Connect with Answer Desk for expert help.