Рутер (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 или не на рутера няма значение.

Наздраве!

Конкретно на мен това ми беше необходимо, за да поддържа установен site-to-site VPN, понеже, ако няма трафик през тунела – той се самоизключва, а включването му след това може да отнеме няколко ценни секунди или да провали опит за телефонен разговор (Call Manager Express).

При не-установен тунел и опит за телефонно (VoIP) обаждане от едната мрежа до другата, UDP трафикът който се генерира понякога е недостатъчен да “събуди” и установи VPN тунела. В резултат на което – провален разговор.

Ето и самият пример:

ip sla 1
 icmp-echo 192.168.10.1 source-ip 192.168.11.1
 frequency 30
ip sla schedule 1 life forever start-time now

Тук пингваме през 30 секунди ИП адреса 192.168.10.1 от името на 192.168.11.1 (интерфейса на рутера към вътрешната мрежа), като задачата ще се изпълнява до безкрайност – forever. Можете да си поиграете с параметрите спрямо вашите нужди.

Примерът е от IOS 15.1.

1. Закачате се към конзолата със сериен кабел.
2. Рестартирате/включвате рутера и натискате CTRL+BREAK или CTRL+B докато зареждането спре в rommon.
3. confreg 0×2142
4. reset или рестартиране от тока.
5. За да запазите конфигурацията: copy start run
6. Сега сменяте enable паролата с:

conf t
enable secret newpassword
exit

conf t
clock timezone gmt +2
clock summer-time CDT recurring

Така дори ще поддържа и лятното време

conf t
service dhcp
ip dhcp pool 192.168.1.0/24
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 217.10.240.2 217.10.240.242
exit
ip dhcp excluded-address 192.168.1.1 192.168.1.100

Така конфигуриран ще раздава динамични адреси от 192.168.1.101 нагоре (включително).

Твърдото рестартиране ще прекъсне връзката за няколко минути:
#clear ip bgp *

Това понякога решава доста проблеми и би помогнало на много хора