Cisco router dual ISP

Конкретен пример как да се направи автоматично прехвърляне към втори Интернет доставчик (или трасе) при пропадане на главната линия.

Рутер (IOS 12.4):
fe0 – 192.168.0.1/24 – вътрешна мрежа
fe1 – 100.100.100.123/24, GW: 100.100.100.1 – трасе1
fe2 – 200.200.200.123/24, GW: 200.200.200.1 – трасе2

Приемаме трасе1 за главна линия, а трасе2 за резервна, която ще се ползва единствено, когато трасе1 не работи. За диагностика дали трасето работи ще ползвам ping.
И двете трасета са за предоставяне на достъп до Интернет, така че за диагностика ще се пингва адрес някъде в Интернет. Избрах един от DNS сървърите на OpenDNS – 208.67.222.222.

Превключването между трасетата ще става като бива сменян шлюзът по подразбиране за рутера (default gateway). За тази цел трябва статично да рутираме заявките до 208.67.222.222 през трасе1 (главното трасе).

ip route 208.67.222.222 255.255.255.255 100.100.100.1

От предишната ми статия вече знаете как се правят пингващи роботчета в Cisco IOS, сега ще разширим малко възможностите на едно такова роботче:

ip sla 1
 icmp-echo 208.67.222.222 source-ip 192.168.0.1
 frequency 30
ip sla schedule 1 life forever start-time now
ip sla reaction-configuration 1 react timeout action-type triggerOnly

Бързо стават ясни фактите:
– пингва 208.67.222.222, като изпраща заявките от името на 192.168.0.1
– пингва през 30 секунди
– цикълът продължава вечно
– когато имаме timeout, това ще предизвика trigger събитие, което сега ще уловим:

track 1 ip sla 1

Пингачката вече трябва да работи, а това можете да проверите с:

debug ip icmp
term mon

Сега е момента да нагласим и самата маршрутизираща таблица на рутера така, че да се съобразява с пингачката и събитията генерирани от нея:

ip route 0.0.0.0 0.0.0.0 100.100.100.1 track 1
ip route 0.0.0.0 0.0.0.0 200.200.200.1 10

Сега какво означава това – първият ред ни дава шлюзът по подразбиране на главното трасе, но „track 1“ означава, че този route ще е валиден само, ако „спусъкът“ track 1 разрешава, т.е. ако пингачката работи и пингвания IP адрес отговаря.
Вторият ред ни дава втори шлюз по подразбиране – този на резервното трасе. Но този route е с по-нисък приоритет (по-голяма метрика – 10), т.е. ще работи, само ако няма route с по-висок приоритет от него (по-ниска метрика).

Можете да видите статуса на track-а в рутиращата таблица ето така:

sh ip route track-table
 ip route 0.0.0.0 0.0.0.0 100.100.100.1 track 1 state is [down]

Когато е down (т.е. пингачката получава таймаути от пингвания адрес) – този route изобщо не съществува в таблицата за рутиране и рутера подхваща следващото налично трасе – през 200.200.200.1.

Дали има NAT или не на рутера няма значение.

Наздраве! 🙂