antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 19 Январь , 2012

 

Подключение к двум провайдерам с помощью рутера Cisco и автопереключение каналов методом Cisco IP SLA ICMP Echo Operations

 

Часть 2: обеспечение функционирования DNS сервиса  и NAT при переключении на резервный канал.

Итак, основную задачу по обеспечению автоматического переключения с канала основного провайдера на канал резервного мы уже решили. Однако, при внедрении выведенного конфига у вас возникнут две дополнительные проблемы (это минимум, который я вам могу гарантировать ;-))

Первая проблема: если вы используете DNS сервера провайдеров для разрешения имен, то возникнет такая ситуация: канал переключается просто замечательно, но DNS запросы клиентов всё ещё отсылаются на DNS основного провайдера!

Вторая проблема: Интернет через резервного провайдера недоступен, ибо NAT делается не для адреса резервного провайдера.

 

Давайте решать.

 

Проблема 1. Переключение на DNS резервного провайдера.

Эту проблему решить можно несколькими способами. Например:

1) Самый легкий – на резолвере использовать общедоступные и бесплатные DNS сервера, а не сервера провайдеров. Например, Google Public DNS: 8.8.8.8 или 8.8.4.4.

2) Можно прописать статические маршруты до DNS серверов провайдеров через соответствующие шлюзы. Тогда, пакеты до DNS серверов каждого провайдера будут идти только через его канал (что правильно, и, IMHO, в любом случае, стоит так сделать).

Что это нам даст? — При недоступности самого провайдера, рутер будет сразу рапортовать о недоступности основной DNS и ваша прокси, кеширующая DNS, forwarder или что там ещё, начнет опрашивать резервный DNS. Однако, если до провайдера соединение есть, а уже у него нет подключения к Интернет (что у нас бывает частенько), тогда у вас начнутся проблемы. Решить их можно отключив интерфейс\выдернув кабель к основному провайдеру[1], либо сделав уход соответствующих пакетов на интерфейс Null0.

Так как у нас уже есть настроенный IP SLA для удаления маршрута по умолчанию, мы можем написать два статических маршрута до DNS сервера провайдера, один нормальный, второй на Null0, но с большей Admin distance, и использовать этот же IP SLA трекер для удаления нормального маршрута. Тогда, при “переключении канала” мы обеспечим ещё и “переключение DNS сервера”, ибо основной DNS сервер станет недоступен. Итого:

ip route DNS1 255.255.255.255 GW1 track 10 name To Primary DNS
ip route DNS1 255.255.255.255 Null0 254 name To Make Primary DNS Dead

 

Тут стоит оговориться, что если DNS сервер провайдера находится в одной подсети с нами (соответствующим внешним интерфейсом рутера), то надо немного поменять первый маршрут:

ip route DNS1 255.255.255.255 FastEthernet1 track 10 name To Primary DNS
ip route DNS1 255.255.255.255 Null0 254 name To Make Primary DNS Dead

 

Всегда могут появиться неожиданные нюансы…

 

 

Проблема 2. Настройка NAT при одновременном подключении к Интернет через двух провайдеров.

Итак, нам надо сделать настройки NAT таким образом, чтобы подмена происходила соответственно интерфейсу, через который выходит трафик. Сделать это можно с помощью рут-мапов. В нашем примере мы будем использовать PAT – организацию подключения к Интернет с использованием единственного публичного адреса: 

! Сначала необходимые ACL, чтобы выделить трафик, который надо NAT-ить
! Полагаем, что у нас ЛВС пользует подсеть 192.168.0.0 /24
ip access-list extended nat_FE1
 permit ip 192.168.0.0 0.0.0.255 any
 deny   ip any any
ip access-list extended nat_FE2
 permit ip 192.168.0.0 0.0.0.255 any
 deny   ip any any
!
! Искомые рут-мапы
route-map FE1 permit 10
 match ip address nat_FE1
 match interface FastEthernet1
!
route-map FE2 permit 10
 match ip address nat_FE2
 match interface FastEthernet2
!
! Сам NAT
ip nat inside source route-map FE1 interface FE1 overload
ip nat inside source route-map FE2 interface FE2 overload

 

Вот собственно и всё. Если возникнут вопросы после того, как вы честно постараетесь разобраться самостоятельно, заходите на http://anticisco.ru/forum , там вам обязательно помогут.

 

  

Ален Даниелян


 

[1] Вариант с отключением интерфейса также возможно автоматизировать, например, добавив к IP SLA ещё и EEM (Embedded Event Manager). Однако, если уж использовать EEM, то лучше менять всё решение и вместо удаления основного маршрута по умолчанию просто гасить интерфейс к основному провайдеру. Это отдельная история, возможно, её мы обсудим в отдельной статье (если, конечно, Fedia не вернет мне документы, что маловероятно).

 

Метки: , , ,
Опубликовано: Маршрутизаторы и коммутаторы

 

2 комментария “ISP Failover-Failback using IP SLA ICMP Echo Operations, p.2”

comment rss - Trackback

  1. DVD:

    Столкнулся с проблемой подвисших NAT-трансляций после переключения на резервный канал. Решилось при помощи EEM:
    ip sla reaction-configuration 1 react timeout threshold-type immediate action-type triggerOnly
    ip sla reaction-configuration 2 react timeout threshold-type immediate action-type triggerOnly
    ip sla enable reaction-alerts
    event manager applet nat_clear_isp1
    event ipsla operation-id 1
    action 1 wait 3
    action 2 cli command «enable»
    action 3 cli command «clear ip nat translation *»
    event manager applet nat_clear_isp2
    event ipsla operation-id 2
    action 1 wait 3
    action 2 cli command «enable»
    action 3 cli command «clear ip nat translation *»

  2. Alen:

    По правде, я с таким не сталкивался. Может от версии IOS зависит?..
    За код спасибо.

    Предлагаю открыть тему на форуме и разобраться с причиной.
    http://www.anticisco.ru/forum/viewforum.php

» Оставить комментарий

Вы должны войти чтобы прокомментировать.