Это - политика, сохраненная Вашим поставщиком услуг. Так как возможно, что база данных была присоединена к другому экземпляру и изменила, они не хотят повторно прикрепленный к их экземпляру. Я не знаю Вашу установку, но если Вы находитесь на экземпляре черепка, это может быть то, почему. Если у Вас есть специализированный экземпляр MSSQL, они не должны заботиться что.
Можно ли всегда просить говорить с их супервизором?
Мое предположение - то, что это из-за набора опции Automatic Metric на NIC. Автоматическая метрика основана на скорости канала, таким образом, я предполагаю, что Ваш хост подключен к порту коммутатора на 100 Мбит/с. DG присвоят метрика на основе одной только скорости канала. Любому статически присвоенному маршруту присвоят метрика на основе скорости канала ПЛЮС метрика, которую Вы присваиваете. Если Вы хотите присвоить более низкую метрику своей записи в таблице статической маршрутизации, чем метрика, это присвоено DG, то отключите опцию Automatic Metric на NIC.
Соответствующая часть route /?
текст справки:
> route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2 destination^ ^mask ^gateway metric^ ^ Interface^
Вы видите здесь установку этого через METRIC
опция, когда Вы добавляете маршрут. Более низкие числа берут приоритет над более высокими числами.
На основе информации Вы отправили, похоже, что это присваивает метрику относительно диаграммы, найденной в этой ссылке: http://support.microsoft.com/kb/299540, или относительно шлюза по умолчанию. Вы могли бы видеть, позволяет ли это Вам использовать отрицательную величину там для принуждения более низкой метрики, стоившей за желаемый маршрут.
На основе моего опыта использование нескольких идентичных маршрутов с различными метриками в Windows хитро в лучшем случае и часто ненадежно, особенно в Windows Vista/7. Можно работать вокруг этого при помощи двух маршрутов вместо одного, таким образом вынуждая Windows использовать уточненные маршруты. Так, следование Вашему примеру:
route ADD 0.0.0.0 MASK 128.0.0.0 192.168.76.2 IF 11
route ADD 128.0.0.0 MASK 128.0.0.0 192.168.76.2 IF 11
Это выполнит Вашу цель надежно. На самом деле это - решение, используемое программным обеспечением OpenVPN для установления маршрута по умолчанию по VPN.
Я знаю, что это поздно, но я столкнулся с этим сегодня - я хотел подключиться к Gmail, но он был заблокирован веб-фильтром локальной сети домена. Я подключил Wi-Fi USB, чтобы попасть в сеть без домена, и смог попасть в Gmail, изменив приоритет трафика. Это по-прежнему позволяло мне получить доступ к сети домена.
Чтобы узнать номер интерфейса
Route Print
Используйте Netsh, чтобы установить меньшее значение на интерфейсе устройства USB Wi-Fi. Меньшее значение означает более высокий приоритет. Это также приведет к удалению автоматической настройки.
netsh interface ipv4 set interface 25 metric=2
Используйте Route Print
для проверки
Если вы допустили ошибку, вы можете вернуть интерфейс обратно в автоматический режим
netsh interface ipv4 set interface 25 metric=automatic
Подробнее о netsh см. http://www.colorconsole.de/cmd/en/Windows_Vista/netsh/interface/ipv4/set/interface.htm
Это старый вопрос, но если вы наткнулись на него, как и я, попробуйте следующее (подтверждено на Win10):
откройте свойства адаптера, настройки IPv4, Advanced, затем ...
Снимите флажок " Автоматическая метрика
", как упоминалось ранее, И
установите метрику интерфейса
некоторого значения (в этом примере я использовал « 10
»)
Нажимайте OK / Применить, пока не вернетесь к сетевым соединениям. Отключите и снова включите адаптер, чтобы все сбросить и включить новую настройку.
route print
...
Теперь вы заметите, что метрика по умолчанию для адаптера увеличилась с 10 до 20.
добавьте новый маршрут по умолчанию с метрикой « 5
», как упоминалось ранее
route print
. ..
он будет создан как « 15
» по сравнению с « 20
» существующего значения по умолчанию.
route CHANGE 0.0.0.0 MASK 0.0.0.0 192.168.76.1 METRIC 2 IF 11
. route ADD 0.0.0.0 MASK 0.0.0.0 192.168.76.2 METRIC 1 IF 11
. Примечание. Я не тестировал его.