Технология TCP/IP Dead Gateway Detection – причина “странной” маршрутизации.

Раз уж мы начали обсуждать стек TCP/IP и его реализацию в Microsoft Windows Server 2003, то я хотел бы этот ряд продолжить описанием еще одной очень полезной технологии TCP/IP Dead Gateway Detection. Это технология довольно старая, описанная в RFC 816, и поддерживается Microsoft начиная еще с версии Windows 95. Однако, как показывает практика мало кто понимает как она работает и соответственно мало кто умеет ее корректно применять на практике.

Суть алгоритма очень проста. Известно, что после передачи по протоколу TCP определенной порции данных (или истечения определенного таймаута) хост-получатель отправляет хосту-отправителю подтверждение (ACK) о получении этой порции данных. Хост отправитель ожидает переодического получения таких подтверждений, прежде чем отправить следующую порцию данных. В случае если такое подтверждение не получено, хост-тправитель попопытается отправить эту порцию данных еще раз. И так хост-отправитель будет делать несколько раз, после чего сочтет TCP-соединение разоравнным и закроет соответствующий сокет. Число попыток такой передачи задается в реестре Windows в параметре TcpMaxDataRetransmissions. По умолчанию это значение принимается равным 5-и. Все описанное ранее верно, если настроен всего один шлюз по умолчанию. В том случае если в таблице маршрутизации указано несколько шлюзов по умолчанию (Default Gateways), то передача даных будет работать несколько иначе.

Если при передаче данных нет подтверждения (ACK) от хоста-получателя, то как и раньше выполняется попытка повторной передачи данных. Однако, если по истечении более половины попыток (в нашем случае это 3-и попытки) передача все же оказалась неудачной, то в КЕШ-записи (Route Cached Entry – RCE) маршрута к этому хосту-получателю изменятется адрес шлюза на следующий по списку адрес шлюза по умолчанию и процедура повторяется заново. Если все перечисленные в таблице маршрутизации шюзы по умолчанию опробованы и подтверждения от хоста-получателя все же нет, то TCP-соединение разрывается.

Если более 25% от всех TCP соединений в записях RCE уже использут следующий шлюз по умолчанию, то все остальные TCP-соединений тоже переводятся на новый шлюз по умолчанию, а так же делается отметка в таблице маршрутизации, что основным шлюзом по умолчанию теперь является новый хост.

Следует заметить, что работа данного алгоритма возможна ТОЛЬКО при следующих условиях:

1. В настройках TCP/IP указано более одного шлюза по умолчанию.
2. Через неработающий шлюз по умолчанию уже установлены TCP соединения или устанавливаются TCP-соединения с внешними хостами.
3. Через альтернативные шлюзы по умолчанию возможна маршрутизация до хоста-назначения.

Очевидно, что переключение с одного шлюза по умолчанию на другой не возможно без TCP соединений. Например выполнение команды PING не приведет к переключению шлюзов, т.к. PING использует ICMP протокол.

В Windows Server 2003 и в Windows XP данный алгоритм по умолчанию включен. Есть два параметра реестра в разделе HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 

DWORD DeadGWDetectDefault

DWORD Interfaces\{int-guid}\EnableDeadGWDetect

отвечающие за работу этого алгоритма. Первый из них (DeadGWDetectDefault) позволяет включить или выключить алгоритм на всех интерфейсах сразу, а второй (EnableDeadGWDetect), позволяет контролировать работу алгоритма на уровне каждого интерфейса по отдельности.

Для того, что бы узнать о многих других особенностях работы стека TCP/IP и его скрытых настройках скачайте документ Microsoft Windows Server 2003 TCP/IP Implementation Details.