Меню

Настройка cisco резервный канал



Резервирование каналов в CISCO ­ Дневник ­ Максим Боголепов

Резервирование каналов в CISCO

В дополнение к недавней заметке про резервирование каналов на сервере под управлением FreeBSD, выкладываю решение такой же задачи с использованием одного пограничного маршрутизатора (cisco 2821) с двумя каналами, подключённого к различным провайдерам без балансировки нагрузки (без PBR – policy based routing).

Схема коммутации предельно проста. На ней видны все исходные данные:

Шлюз по умолчанию, выданный нам основным провайдером: 172.16.0.2, вспомогательным — 10.10.0.2.

Сперва настроим трансляцию адресов (nat) внутренней сети в выданный адрес каждого из провайдеров:

В списке доступа для трансляции адресов будет фигурировать только наша локальная сеть:

Теперь необходимо настроить роутинги. Сперва – route-map для правил трансляции через каждого из провайдеров:

И два статических роутинга до нескольких постоянно работающих в сети интернет хостов (мной выбраны два – dns Google и Яндекса) через шлюз по умолчанию основного провайдера:

Мы будем проверять доступность этих выбранных хостов через канал основного провайдера.

Теперь настраиваем правила динамической трансляции адресов внутренней сети через каждый из внешних адресов:

Впоследствии вам может понадобится настройка статической трансляции (например — для доступности почтового сервера с каждого из этих внешних ip). Делается это следующим образом:

Где 192.168.0.2 внутренний ip вашего почтового сервера.

Не забудьте при этом прописать во внешнем dns эти два адреса примерно следующим образом (в части касающейся):

Время жизни (ttl) лучше выставить поменьше, чтобы после переключения на вспомогательного провайдера почта к вам не терялась — $TTL 600 ; 10 min .

Теперь воспользуемся инструментом IP SLA (IP Service Level Agreements) для мониторинга доступности выбранных нами хостов в сети интернет посредством обычного ping:

  • threshold — устанавливает верхнее пороговое значение для измерения RTT (round-trip time), в ms;
  • timeout — период времени, который cisco ожидает ответ на пакеты icmp, в ms;
  • frequency — частота отправки тестовых пакетов, в сек.

Рекомендации Cisco по настройке данных параметров: (frequency seconds) > (timeout milliseconds) > (threshold milliseconds).

Командой ip sla schedule мы запускаем каждый из этих двух тестов.

Теперь необходимо настроить track — enhanced object tracking, очень удобная функция IOS , позволяющая отслуживать состояние выбранного объекта, в нашем случае — результатом iсmp ответа от хостов в интернете. Делается это следующим образом:

Каждый из track отслеживает свой ping тест. Для принятия окончательного решения о “падении” канала связи основного провайдера настроим суммарный track, который будет UP в случае, если хотя бы один из track 10 и track 20 будет находится в состоянии UP:

Параметр delay необходим для того, чтобы суммарный track 50 переходил в состояние DOWN с задержкой. Иначе, как только пропадет хотя бы один пакет icmp в двух тестах одновременно, track 50 перейдет в состояние DOWN . Параметр delay необходимо настраивать в соответствии с частотой отправки icmp-запросов (эту частоту мы обозначили в 3 секунды при настройке ip sla — параметр frequency). Задержка на переход в состояние DOWN мы выставили в 10 секунд. Иначе говоря, track 50 перейдет в состояние DOWN только если все тесты перестали получать ответы. Аналогично с переходом в состояние UP.

Наконец, нам осталось прописать статические маршруты. Первый — через основного провайдера с проверкой доступности через суммарный track 50. Второй — через вспомогательного провайдера:

Теперь, чтобы всё было “красиво”, необходимо решить проблему с подвисшими сессиями трансляции адресов при переключении между провайдерами. Конечно мы можем изменить значения по умолчанию время жизни трансляций (tcp, udp, dns и т.д.) (которые равны 24 часам), но это может привести к лишним разрывам сессий. Просто для примера (все значения в секундах):

Мы же этого воспользуемся EEM (embedded event manager). Им мы привяжем некоторые действия к изменению состояния наших track. А именно: каждый раз будем очищать динамические трансляции и записывать в syslog сообщения об этих изменениях:

Проверка наших настроек осуществляется следующими способами:

Проверка работы nat:

Проверка ip sla:

Вот, в принципе, и всё. В заключении привожу листинг проделанной работы:

Rating: 4.7/5(6 votes cast)

Источник

Настройка cisco резервный канал

в случае с пат всё очень просто, там проблема в обратном пакете :

Читайте также:  Триколор настройка каналов оператор

1. просто работа того или другого (всё выше сказаное по переключению должно работать)

ip nat inside source static tcp х.х.х.х 25 х1.х1.х1.х1 25 route-map имямэпа1 extendable no-alias
ip nat inside source static tcp y.y.y.y 25 y1.y1.y1.y1 25 route-map имямэпа2 extendable no-alias

route map имямэпа1 permit 10
match interface имяфейса(x.x.x.x)

route map имямэпа2 permit 10
match interface имяфейса(y.y.y.y)

2. если нуна балансировка:
пункт 1 + :
подымаете service ещё на одном порту и полисироутингом рулите

2.37, Tpoxa ( ? ), 11:22, 07/05/2013 [^] [^^] [^^^] [ответить] + / –
если 2 прова, то надо вместо
ip nat inside source list 100 interface FastEthernet0/1 overload,
потому что одна команда перебивает другую.
Надо:
ip nat inside source route-map interface FastEthernet0/1 overload
ip nat inside source route-map interface FastEthernet0/1 overload

роут мапы уже приписываешь кого и как ты выпускаешь, но часто они одинаковые.

> А как быть в случае с PAT? Ситуация — 2 провайдера, моя
> cisco, за ней серверы, на cisco настроен проброс определённых портов на
> сервера. Проблема в изменении параметров проброса при переключении между провами.
> Проброс настроен так:
> ip nat inside source list 100 interface FastEthernet0/1 overload
> ip nat inside source static tcp 210.10.0.2 21 xx.xx.xx.xx 21 extendable
> ip nat inside source static tcp 210.10.0.2 22 xx.xx.xx.xx 22 extendable
> Подскажите если кто знает как это победить!

1.20 , Dev ( ? ), 22:55, 21/01/2008 [ответить] [﹢﹢﹢] [ · · · ] + / –
Вопрос первый: у меня Cisco 3640 с таким ИОСом: c3640-i-mz.124-16.bin.. Это не 12,4Т, но 12,4 же, первый вариант должен прокатывать. А вот «ip sla» нету? Вернее «ip sla monitor 1» можно ввести, но дальше затык (я думаю, что это просто не совсем то). Как быть?

Второй вопрос: Если первый пров через сериал, а второй через езернет — разницы нет? Как я понимаю source-ip — это ip интерфейса, который смотри в сторону прова?

Третий вопрос: первый айпи в строках проверки доступности — это любой хост в инете, который будет показателем доступности провайдера? просто у нас часто бывает, что пров доступен, а в середине маршрута — обломс. придется брать хост инета, а не шлюз прова, т.е. что-то типа www.ru [194.87.0.50]. Я правильно понимаю?

Заранее благодарен.

2.21 , crazycool ( ? ), 10:05, 22/01/2008 [^] [^^] [^^^] [ответить] + / –
>Вопрос первый: у меня Cisco 3640 с таким ИОСом: c3640-i-mz.124-16.bin.. Это не
>12,4Т, но 12,4 же, первый вариант должен прокатывать. А вот «ip
>sla» нету? Вернее «ip sla monitor 1» можно ввести, но дальше
>затык (я думаю, что это просто не совсем то). Как быть?

«IP SLAs — ICMP Echo Operation» для вашей платформы есть в IOS’ах IP версии 12.3 и 12.3T. Может, конечно, в 12.4 он уже называется как-то по другому, :(( но врядли.
>
>
>Второй вопрос: Если первый пров через сериал, а второй через езернет —
>разницы нет? Как я понимаю source-ip — это ip интерфейса, который
>смотри в сторону прова?

да. тут тип интерфейса не имеет значения.
>
>Третий вопрос: первый айпи в строках проверки доступности — это любой хост
>в инете, который будет показателем доступности провайдера? просто у нас часто
>бывает, что пров доступен, а в середине маршрута — обломс. придется
>брать хост инета, а не шлюз прова, т.е. что-то типа
>www.ru [194.87.0.50]. Я правильно понимаю?

правильно вы все понимаете. только в этом случае, обязательно использование route-map’ов, чтобы пинги уходили с нужного интерфейса.
>
>Заранее благодарен.

3.25 , Dev ( ? ), 07:24, 08/02/2008 [^] [^^] [^^^] [ответить] + / –
> «IP SLAs — ICMP Echo Operation» для вашей платформы есть в IOS’ах IP версии 12.3 и 12.3T. Может, конечно, в 12.4 он уже называется как-то по другому, :(( но врядли.

Есть в моей, но там команда ip sla 1 не проходит, т.к. заменена на ip sla monitor 1. Остальное так же все.

Вопрос: Все ввел, пинги пошли, но почему-то пишет такую статистику:

Round trip time (RTT) Index 1
Latest RTT: 184 ms
Latest operation start time: .09:16:41.419 PST Fri Feb 8 2008
Latest operation return code: Over threshold
Number of successes: 0
Number of failures: 114
Operation time to live: Forever

Что значит — Latest operation return code: Over threshold?
и как я понимаю — Number of successes: 0
Number of failures: 114
это значит ошибки. Но пинг то проходит — Latest RTT: 184 ms
или так и должно быть?

4.26 , Dev ( ok ), 08:42, 08/02/2008 [^] [^^] [^^^] [ответить] + / –
>
>Что значит — Latest operation return code: Over threshold?

в случае с пат всё очень просто, там проблема в обратном пакете :

1. просто работа того или другого (всё выше сказаное по переключению должно работать)

ip nat inside source static tcp х.х.х.х 25 х1.х1.х1.х1 25 route-map имямэпа1 extendable no-alias
ip nat inside source static tcp y.y.y.y 25 y1.y1.y1.y1 25 route-map имямэпа2 extendable no-alias

route map имямэпа1 permit 10
match interface имяфейса(x.x.x.x)

route map имямэпа2 permit 10
match interface имяфейса(y.y.y.y)

2. если нуна балансировка:
пункт 1 + :
подымаете service ещё на одном порту и полисироутингом рулите

2.29 , Max ( ?? ), 09:53, 01/08/2008 [^] [^^] [^^^] [ответить] + / –
Господа, а как быть если проблемы с каналом не от провайдера до вас, а у самого провайдера. Если сделать что бы проверялась связь от вас до маршрутизатора провайдера, то при пропадании канала у самого провайдера, маршрутизатор провайдера будет пинговаться а вот переключения не получиться потому как ответ от маршрутизатор провайдера приходит! Может целесообразнее ставить проверку пинга канала на внешние устройства например www.ru
1.30 , rincho ( ? ), 17:44, 18/08/2008 [ответить] [﹢﹢﹢] [ · · · ] + / –
вопрос: а как привязать PAT к двум или трём провайдерам? Ситуация такая что от каждого из провайдеров получаем статик дефолт маршрут. А задача получать инет на внутреннем интерфейсе с частной адресацией. используется cisco 2811 , на ней подняты сабинтерфейсы. на сабинтерфейсы на выход поставлено ip nat outside. на сабинт внутренний ip nat inside. ip nat inside source list X.X.X.X x.x.x.x а overload делать куда?
2.31 , Max ( ?? ), 17:53, 02/09/2008 [^] [^^] [^^^] [ответить] + / –
Товарищи а почему никто не пишет, что для того что бы заработал jitter надо что бы было ещё оборудование которое поддерживало бы эту технологию.
«Весьма важный момент: jitter тест возможен только между двумя устройствами Cisco поддерживающими IP SLA тесты. Вы не сможете запустить данный тест между маршрутизатором Cisco и, например, компьютером или маршрутизатором другого производителя.»
потом в моей версии IOS нпример необходимо установить ещё и порт по которому конектиться! «Router(config-sla-monitor)# type jitter dest-ipaddr 172.29.139.134 dest-port 5000» что за порт здесь этого не написанно! но без него никак!
1.32 , www_tank ( ok ), 11:55, 22/12/2008 [ответить] [﹢﹢﹢] [ · · · ] + / –
у меня проблема как у Ивана Жукова с той лишь разницей, что BGP поднять не реально.
и вообще оба провайдера не будут никак учавствовать в моей беде.

проблема с2801 со sla на двух каналах от двух провайдеров.
на резервный канал кроме прочего трафика приходит Ipsec туннель. вот он и не поднимается, потому что первый же ответный пакет идет по дефолтовому маршруту в основной канал. статик на другой конец туннеля прописать не представляется возможным,т.е. там динамически выдаваемый Ip.

1.33 , tpoxa ( ? ), 17:33, 24/12/2012 [ответить] [﹢﹢﹢] [ · · · ] + / –
можно было бы добавить инфу о том, как при этом сделать nat. обычный nat в этом случае работать не будет, точнее, будет работать только на 1 ифейс, а в данном случае надо чтобы на оба. надо сделать ip nat inside source route-map бла-бла. Но в качестве идеи автор молодец.
1.34 , tpoxa ( ? ), 17:41, 24/12/2012 [ответить] [﹢﹢﹢] [ · · · ] + / –
вот все просто и понятно http://www.cisco.com/en/US/tech/tk364/technologies_configuration_example09186
1.35 , костя ( ?? ), 19:16, 29/04/2013 [ответить] [﹢﹢﹢] [ · · · ] + / –
Всем привет, меня интересует как/что сделать так чтобы впн мог передавать на выходе только данные, те которые меня интересуют, а все остальное отсеивал??

2.36 , crazycool ( ? ), 19:28, 05/05/2013 [^] [^^] [^^^] [ответить] + / –
> Всем привет, меня интересует как/что сделать так чтобы впн мог передавать на
> выходе только данные, те которые меня интересуют, а все остальное отсеивал??
> Заранее спасибо!

Что ты имеешь в виду под словами «на выходе»? Все зависит от того, какую технологию ты используешь для построения VPN туннелей.
— Legacy IPSec
— IPsec using VTI
— DMVPN
— GETVPN

1.38, subbotin ( ? ), 17:24, 18/06/2015 [ответить] [﹢﹢﹢] [ · · · ] + / –
Здравствуйте, есть роутер:
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9_NPE-M), Version 15.3(3)M2, RELEASE SOFTWARE (fc1)
ROM: System Bootstrap, Version 15.0(1r)M16, RELEASE SOFTWARE (fc1)
Не могу дать команду ip sla 1
Есть только варинты ip sla
key-chain
responder
server
Подскажите что делать, менять IOS? Если да, на какой?
2.39, subbotin ( ? ), 16:50, 26/06/2015 [^] [^^] [^^^] [ответить] + / –
Если кому интересно, решилось все заменой IOS на:
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.4(3)M2, RELEASE SOFTWARE (fc2) и активацией лицензии securityk9.
1.40, Konstantin ( ?? ), 15:15, 28/03/2018 [ответить] [﹢﹢﹢] [ · · · ] + / –
приветствую.
route-map 115 permit 10
match ip address 115
set ip next-hop verify-availability 80.91.170.13 10 track 1
set ip next-hop verify-availability 83.218.239.13 20 track 2

указывем в acl внутренних хостов

access-list 115 permit ip host 192.168.0.15 any
access-list 115 permit ip host 192.168.10.2 any
access-list 115 permit ip host 192.168.0.161 any

ip policy route-map 115
Сделал.работает но так как ip компа и днс моей конторы находяться в разных подсетях,и как только я вешаю на внутренний интерфейс этот route-map

Источник

Залозный Александр

Автоматическое переключение на резервный канал при падении основного.

В этой заметке рассмотрим автоматическое переключение на резервный канал при падении основного на примере роутера Cisco 2801 c IOS c2801-advsecurityk9-mz.124-20.T1.bin который используется в одном из филиалов.

Имеем подключение к двум провайдерам по Ethernet.
FastEthernet0/0 — ISP1
FastEthernet0/1 — ISP2
vlan1 — внутренняя сеть 192.168.64.0/24

Требуется чтобы при падении основного канала трафик автоматически шел через резервный.
При востановлении работоспособности основного автоматически шел через основной.

Для проверки работоспособности будем пинговать внешний ресурс.
В примере указан DNS гугла (8.8.8.8), я же использую IP маршрутизатора в главном офисе с которым строятся IPsec тоннели, так как были ситуации когда пинг на 8.8.8.8 работает и интернет у пользователей есть, но связи с главным офисом через конкретного провайтера нет.

Создаем IP SLA которые будут пинговать 8.8.8.8 через интерфейсы подключенные к провайдерам.
И запускаем их.

ip sla monitor 10 type echo protocol ipIcmpEcho 8.8.8.8 source-interface FastEthernet0/0 ip sla monitor schedule 10 life forever start-time now ! ip sla monitor 11 type echo protocol ipIcmpEcho 8.8.8.8 source-interface FastEthernet0/1 ip sla monitor schedule 11 life forever start-time now

Настроим tracking process которые будут отслеживать состояние наших IP SLA.
Устанавливаем задержку 5 секунд на переход tracking process в состояние Up/Down на случай кратковременного пропадания пинга.

track 10 rtr 10 reachability delay down 5 up 5 ! track 11 rtr 11 reachability delay down 5 up 5

Добавим маршруты по умолчанию с разными административными дистанциями через наших провайдеров.
Логика работы следующая:
Если Track 10 и Track 11 в состоянии UP — в таблицу маршрутизации попадает маршрут с наименьшей административной дистанцией (через ISP1).
Если Track 10 в состоянии DOWN — этот маршрут удаляется из таблицы маршрутизации и работает маршрут через ISP2.
Если Track 10 и Track 11 в состоянии DOWN — предполагаем что не работает сам внешний ресурс которым мы пингуем и работаем через ISP1.

ip route 0.0.0.0 0.0.0.0 IP_ISP1 track 10 ip route 0.0.0.0 0.0.0.0 IP_ISP2 2 track 11 ip route 0.0.0.0 0.0.0.0 IP_ISP1 3

Существуем небольшая вероятность что одновременно не будет работать и удаленный ресурс и ISP1, в этом случаем автоматического переключения не произойдет.

На этом настройка собственно автоматического переключения закончена.

access-list 100 remark ACL-for-nat access-list 100 permit ip 192.168.64.0 0.0.0.255 any ! route-map ISP1_NAT_RMAP permit 10 match ip address 100 match interface FastEthernet0/0 ! route-map ISP2_NAT_RMAP permit 10 match ip address 100 match interface FastEthernet0/1 ! ip nat inside source route-map ISP1_NAT_RMAP interface FastEthernet0/0 overload ip nat inside source route-map ISP2_NAT_RMAP interface FastEthernet0/1 overload ! interface FastEthernet0/0 ip nat outside ! interface FastEthernet0/1 ip nat outside ! interface Vlan1 ip nat inside

Источник

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Настройка техники © 2021
Внимание! Информация, опубликованная на сайте, носит исключительно ознакомительный характер и не является рекомендацией к применению.

Adblock
detector