We've been having problems with link state table updates flooding our network. These updates seem to be caused by an unreliable link between two offices that act as bridgeheads for different regions of our Exchange Server organization. How can we put a stop to this maddening problem?
The idea behind link state routing is that when a server notices that another server is unavailable, the first server sends an update to its routing group master, which then sends out notifications to all the other servers in the routing group. This design works wonderfully about 99 percent of the time. The other 1 percent of the time, you end up with problems like the one you describe. Your link state update floods are almost certainly caused by the intermittent failure of your interoffice link—when one bridgehead sees that the link to the other side has failed, it triggers a link state table update, and the same thing happens on the other side of the link. When the link comes back up, each side tries to flood the other with updates. This problem is even worse in hub-and-spoke networks because link state changes from one spoke can flood all the other spokes.
The best way to fix the problem is to fix whatever's wrong with your network link. In the meantime, you can add the SuppressStateChanges REG_DWORD entry to the HKEY_LOCAL_MACHINE\SYSTEM\Current
ControlSet\Services\RESvc\Parameters registry subkey on your bridgehead servers, then set the entry's value to 1. After you restart the Routing Engine, the SMTP service, and the Exchange MTA Stacks service, this registry change will prevent the servers from sending any link state updates. Of course, suppressing link state updates isn't a good long-term solution because it prevents you from getting good routing data throughout the organization, but it can help while you fix the root problem.47369