J3qx

information archive

Типовые проблемы с WAN.

Posted by j3qx на Июль 27, 2013

Типовые проблемы с WAN.

 

1)     Проверка работы филиалов:

  1. Очень часто на SERVER1 сбоит RAdmin server, что приводит к невозможности доступа по RAdmin на филиалы. В таком случае можно порекомендовать или перезапустить сервис RAdmin на SERVER1, или ходить через другой метафрейм.
  2. На SERVER1 есть WUG с картой TDWAN.WUP – там все филиалы (Новосиб – не работает). На SERVER1 на диске C: есть три скрипта:
    1.                                                     i.     C:\VPN.CMD – пингер для всех VPN последовательно.
    2.                                                   ii.     C:\PVC.CMD – пингер для всех PVC от Совинтела последовательно.
    3.                                                 iii.     C:\LL.CMD – пингер для всех выделенок последовательно.
  3. На СУС есть скрипт FILIALS.CMD:
    1.                                                     i.     «4» – позволяет посмотреть состояние всех VPN.
    2.                                                   ii.     «5» – позволяет сбросить все VPN. Для обратного подъема VPN нужно на SERVER1 запустить скрипт VPN.CMD.
    3.                                                 iii.     «6» – позволяет перезапустить VPN со стороны филиала (доступно только в том случае, если на филиале установлен Cisco831).
    4.                                                 iv.     «3» – позволяет пинговать любой VPN-филиал снаружи. Может быть полезно для определения есть ли вообще соединение с Интернет на филиале.
  4. На СУС есть скрипт PING_OUTSIDE.BAT – позволяет пинговать любой хост в интернет.

 

Типовая проблема: Отвалился иногородний филиал. Запускаем FILIALS.CMD. Выбираем «3» и номер филиала. Если ответ успешен, то:

  1. Если филиала на базе Cisco831:
    1. То выбираем «6» и номер этого филиала.
    2. Проверяем доступность филиала с SERVER1.
    3. Если VPN не поднимается:
      1.                                                                         i.     То выбираем «5» и отвечаем «Да».
      2.                                                                       ii.     Запускаем на SERVER1 скрипт VPN.CMD.
      3.                                                                     iii.     Проверяем доступность филиала с SERVER1.
      4.                                                                     iv.     Если и это не помогает, то выбираем «1» и проверяем конфигурацию маршрутизатора (команда «sho run») с эталонной.
  2. Если филиала на базе DLink :
    1. То выбираем «5» и отвечаем «Да».
    2. Запускаем на SERVER1 скрипт VPN.CMD.
    3. Проверяем доступность филиала с SERVER1.
  3. Если ситуация не попадает в описанные рамки, то необходимо любым доступным способом связаться с инженером филиала и, возможно, с  провайдером филиала. Далее необходимо решать проблему совместно.  Основная идея в том, что имеется эталонная конфигурация маршрутизатора, описание сети филиала и неизмененные настройки в Центральном офисе. Нужно просто найти различия и соответствующим образом их нивелировать путем:
    1. Внесения корректировок в настройки со стороны Центрального офиса.
    2. Внесения корректировок  в настройки маршрутизатора филиала. В данном случае обязательно помнить, что нужно сохранять успешную конфигурацию в энергонезависимую память маршрутизатора (командой «wr mem»).
    3. Удаления привнесенных изменений со стороны провайдера.
  4. Часто канал не поднимается в результате больших задержек на канале и/или нестабильном канале. В этом случае, к сожалению, сделать ничего нельзя – придется подождать стабилизации канала. Временного прогноза на этот случай не существует – от нескольких минут, до нескольких дней.
  5. В любом случае – об инциденте должно быть доложено непосредственному руководителю исполнителя, куратору филиала и в список рассылки alert@example.com:

 

Редко, но бывает, что отваливаются все VPN – необходимо проверить доступность Интернета из Центрального Офиса (например, с помощью PING_OUTSIDE.BAT):

  1. Если Интернет недоступен, то необходимо связаться с КомКором и передать им сообщение о сбое на канале. После восстановления работоспособности канала в Интернет необходимо выполнить FILIALS.CMD «5» и с SERVER1 и VPN.CMD.
  2. Если Интернет недоступен, а провайдер утверждает, что с его каналом и оборудованием все в порядке, то необходимо убедиться в работоспособности активного оборудования PIX, 2651XM, 2621XM и A5-2-WANSW (telnet/SSH с СУС, WUG на СУС, подключение через консольные порты). В том числе необходимо убедиться в их правильном электропитании (все указанное оборудование запитано через устройства гарантированного электропитания – UPS). В крайнем случае, НЕ СОХРАНЯЯ конфиги, перегрузить устройства. На восстановление работоспособности устройств требуется время:
    1. PIX                 – ~5-10 минут,
    2. 2621               – ~6-8 минут,
    3. 2651               – ~4-6 минут,
    4. WANSW        – ~4-6 минут.

Итого: 10-20 минут (с учетом восстановления Линков между устройствами)

 

.

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: