Есть универсальное решение для подключения нескольких провайдеров, ip sla + track. Решение легкое для понимания и простое в управлении. Но когда дело доходит до одновременного использования двух и более каналов связи, данная технология в чистом виде не подходит.
Хочу поделится своим опытом. На узлах с несколькими провайдерами я использую конфигурацию содержащую виртуальные роутеры – VRF. Эта конфигурация взята из моей практики и хорошо себя зарекомендовала.
Предположим у нас есть 2 провайдера с параметрами:
ISP1 1.1.1.1 шлюз 1.1.1.2
ISP2 2.2.2.1 шлюз 2.2.2.2
И локальная сеть:
LAN 192.168.1.1/24
Приступим к конфигурации. Для начала нужно создать эти самые виртуальные маршрутизаторы, а будет их 3. Два на провайдеров и один на локальную сеть.
Сразу же настроим правила экспорта маршрутов, что бы не возвращается в раздел ip vrf. Логика следующая – нельзя обменивается маршрутами между VRF провайдеров (на самом деле можно, но при таких вариантах настройка усложнится). На пальцах: VRF провайдеров могут получать и отправлять маршруты только в/от VRF локальной сети. VRF локальной сети может отправлять свои маршруты и получать маршруты от любых других VRF.
ip vrf isp1
rd 65000:1
route-target export 65000:1
route-target import 65000:99
ip vrf isp2
rd 65000:2
route-target export 65000:2
route-target import 65000:99
ip vrf lan
rd 65000:99
route-target export 65000:99
route-target import 65000:1
route-target import 65000:2
Вводим данные о сетях в наш маршрутизатор, не забываем сразу включить NAT и назначить интерфейсам нужные VRF. Один интерфейс не может принадлежать сразу нескольким VRF. Представьте себе, что вы решили сделать из одного маршрутизатора несколько, распилив его на части и в каждой части остались свои интерфейсы.
interface GigabitEthernet0/0/0
description === ISP 1 ===
ip vrf forwarding isp1
ip address 1.1.1.1 255.255.255.252
ip nat outside
interface GigabitEthernet0/0/1
description === ISP 2 ===
ip vrf forwarding isp2
ip address 2.2.2.1 255.255.255.252
ip nat outside
interface GigabitEthernet0/0/2
description === LAN ===
ip vrf forwarding lan
ip address 192.168.1.1 255.255.255.0
ip nat inside
Все, теперь у нас есть 3 маленьких, но гордых независимых маршрутизатора. Перед тем как сделать главное – прописать шлюзы провайдеров, надо настроить ip sla тест. Делается это так же, как и в стандартном решении, но с указанием VFR’а из которого предполагается проводит ip sla тест.
ip sla auto discovery
ip sla 1
icmp-echo 4.2.2.1
vrf isp1
frequency 15
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 8.8.8.8
vrf isp1
frequency 15
ip sla schedule 2 life forever start-time now
track 11 ip sla 1 reachability
track 12 ip sla 2 reachability
track 123 list boolean or
object 11
object 12
Добавляем маршруты в наши виртуальные маршрутизаторы, которые отвечают за связь с провайдерами. Обратите внимание на значения метрики, на резервном канале метрика выше и далее вы поймете почему.
ip route vrf isp1 0.0.0.0 0.0.0.0 1.1.1.2 100 track 123
ip route vrf isp2 0.0.0.0 0.0.0.0 2.2.2.2 120
В принципе этого уже достаточно, для того что бы к маршрутизатору можно было подключится из вне по публичному адресу любого из провайдеров (если, конечно, настроен SSH или telnet доступ).
Далее приготовим NAT, все делаем практически так же, как мы привыкли настраивать в стандартном решении без VRF. Делаем access-list который запрещает транслировать локальные адреса в локальные адреса:
ip access-list extended NO_NAT
deny ip any 192.168.0.0 0.0.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 10.0.0.0 0.255.255.255
permit ip any any
Делаем карты маршрутизации для каждого провайдера:
route-map ISP1 permit 10
match ip address NO_NAT
match interface GigabitEthernet0/0/0
route-map ISP2 permit 10
match ip address NO_NAT
match interface GigabitEthernet0/0/1
И включаем NAT overload (обратите внимание, что правило настраивается на виртуальный маршрутизатор vrf lan):
ip nat inside source route-map ISP1 interface GigabitEthernet0/0/0 vrf lan overload
ip nat inside source route-map ISP2 interface GigabitEthernet0/0/1 vrf lan overload
Наше элегантное решение практически готово, но нужен финальный штрих, это BGP процесс который будет заниматься перераспределением маршрутов между VRF учитывая правила импорта\экспорта которые мы настроили в каждом VRF.
router bgp 65000
bgp log-neighbor-changes
address-family ipv4 vrf isp1
redistribute connected
default-information originate
exit-address-family
address-family ipv4 vrf isp2
redistribute connected
default-information originate
exit-address-family
address-family ipv4 vrf lan
redistribute connected
exit-address-family
Команда default-information originate позволяет передавать через bgp маршрут по умолчанию. В результате, в кандидаты на маршрут по умолчанию для vrf lan попадут два маршрута до шлюзов разных провайдеров, но с помощью bgp будет выбран тот, у которого метрика меньше. Соответственно если вдруг надо переключить NAT с одного провайдера на другой, достаточно будет поменять метрику в таблице маршрутизации одного из VRF.
Заключение. Данная конфигурация позволяет организовать подключение к двум провайдерам связи одновременно. Конфигурация очень гибкая, используя PBR, можно разделять трафик между провайдерами, и даже в случае падения одно из них, продолжать предоставлять сервис. Особенность VRF, позволяет даже во время сложных манипуляций с конфигурацией не потерять связь с устройством (нельзя одновременно править две таблицы маршрутизации, хотя…). Конфигурация легко расширяется и позволяет без заморочек добавить новых провайдеров.
Из недостатков, хочу отметить необходимость почти в любую команду вставлять дополнительный текст vrf <название>. Так просмотр таблицы маршрутизации виртуального роутера локальной сети вызывается командой:
show ip route vrf lan
Пинг из-за NAT:
ping vrf lan 8.8.8.8
Пинг из vrf первого провайдера:
ping vrf isp1 8.8.8.8
Спасибо за внимание. Подготовлено на роутере Cisco 881 IOS version 15.5
Комментарии (17)
Rel1cto
06.11.2015 09:34Не вижу ни одного преимущества перед стандартным решением без vrf. Только ненужное усложнение конфигурации.
HunterXXI
06.11.2015 10:17+1Добрый день.
Мне нравится, что я всегда могу мониторить и имею доступ к своему оборудованию по публичным адресам из любой точки мира. В стандарном решении одноммоментно доступен толкьо один првайдер, с тем который не активен вы не можете провести полноценный icmp тест, что бы оценить качество канала или подлючится удаленно без включения специфических правил в таблицу маршрутизации.
Ох, знали бы Вы как классно стоить отказоустойчивые VPN туннели с данным решением. Full Mesh FlexVPN? Раз плюнуть!
PbIPXA
06.11.2015 10:43как классно стоить отказоустойчивые VPN туннели с данным решением, Full Mesh FlexVPN
поподробнее можно- в чем прелести вашего варианта? Чем он лучше- удобнее хорошо разжеванного Dual Hub DMVPN например?HunterXXI
06.11.2015 11:46я не говорил, что он лучше)) просто реализовано по-другому. Коротко мы держим 4 открытых туннеля и балансируем их с помощью eigrp:
Spoke ISP1 – HUB01
Spoke ISP2 – HUB01
Spoke ISP1 – HUB02
Spoke ISP2 – HUB02
Есть вариант для экономных с 2-одновременными туннелями
Spoke ISP1 – HUB01
Spoke ISP1 – HUB02
Остальные поднимаются по мере пропадания связи
Rel1cto
08.11.2015 13:08+1Доступность второго адреса при живом первом можно сделать с помощью одного единственного route-map.
ip access-list standard Prov2
10 permit host <Router_IP_address_ISP2>
route-map MakeProv2Alive
match ip address Prov2
set ip next-hop <ISP2_gateway>
ip local route-map MakeProv2Alive
Тогда пакеты, которые роутер захочет отправить от source IP, принадлежащего 2 провайдеру, будут завёрнуты на соответствующий шлюз.
bebebe
06.11.2015 10:56Вероятно, что прелесть в NAT внутри VRF. Таким образом при падении одного аплинка не надо ждать таймаутов NAT или делать clear ip nat tr *
Но нужно проверять.
PbIPXA
06.11.2015 10:48А так да, идея постоянной доступности по двум каналам- полезная.
Еще вопрос: если нужно сделать ip nat inside source static 192.168.x.x 91.8.2.3 как быть в вашем варианте (в случае с sla просто меням правила с помощью скрипта- старое выбрасываем, для работающего канала прописываем)bebebe
06.11.2015 11:05Что-нибудь вида
ip nat inside source static 192.168.x.x 91.8.2.3 vrf isp1 extendable match-in-vrf ip nat inside source static 192.168.x.x 91.8.2.3 vrf isp2 extendable match-in-vrf
но нужно проверять.
Karroplan
06.11.2015 11:15мне кажется, что track 123 list boolean or надо менять на track 123 list boolean and.
Далее, в этом трекинге нужно настроить соответсвующие delay up/down — очень часто встречается ситуация когда «восьмерки» выпадают на секундочку и трекинг туда-сюда переключаться начинает, что приводит к потере связи на ровном месте.HunterXXI
06.11.2015 11:51-1это не так. с xgu
track list boolean <and | or>
and:
комбинированный трек в UP, если все объекты внутри UP
комбинированный трек в DOWN, если один или более объектов внутри DOWN
or:
комбинированный трек в UP, если хотя бы один объект внутри UP
комбинированный трек в DOWN, если все объекты внутри DOWN
Karroplan
06.11.2015 14:40так я и говорю, что нужен «and», потому как часто бывает такое, что что-то упало в сети провайдера и их гейт доступен, а вот интернета нема… соотвественно, доступность == гейт && восьмерки, а не гейт || восьмерки.
HunterXXI
06.11.2015 15:16В текущем случае and ничуть не лучше or и погоды не сделает, т.к. будет срабатывать если не проходит ping на восьмерки.
но признаю ошибку… моя невнимательность. в продакшене мы никогда не тестируем шлюз провайдера. только внешние ресурсы в количестве.
bebebe
06.11.2015 11:15+2Кстати, на схеме с VRF можно сделать и двух одновременно работающих провайдеров.
Если интересно, могу вспомнить детали.
bebebe
Появилось несколько вопросов.
1) как при такой схеме работает сбор Netflow?
2) не уверен, что директива log в ACL это хорошая идея. Роутер умрет на реальной загрузке.
3) в обоих sla у вас используется vrf isp1. Это ошибка?
4) почему в ip route vrf isp2 0.0.0.0 0.0.0.0 9.9.9.2 120 нет трекинга sla?
HunterXXI
Спасибо за замечания.
1. Так же, как всегда. Что конкретно смущает Вас в отношении совместной работы netflow и vrf?
2. Конкретно это правило ваш роутер не «нагнет», хотя все же убрал log из конфига, здесь он лишний.
3. Нет, все правильно. Хорошим тоном считается тестировать несколько адресов. Т.к. ходят слухи будто бы шлюз провайдера может отклонить icmp запросы к самому себе, что приведет к незаслуженному удалению маршрута из таблицы. Хотя на практике с такой ситуацией не встречался, привык использовать по два ip sla правила.
4. Добавить трекинг второго провайдера можно, но я посчитал это избыточным. В данной конфигурации если упадут оба ISP, в таблице маршрутизации lan vrf все равно будет маршрут шлюза второго провайдера. Если добавить трекинг, в такой ситуации она будет пустая.
P.S. Исправил опечатку с неверным шлюзом ip route vrf isp2 0.0.0.0 0.0.0.0 9.9.9.2 120
bebebe
1) проблема может быть в том, что если снимать netflow с «внешнего» интерфейса при том, что он является nat outside, то в show ip ca flow будут видны адреса, в которые занатился пакет (адрес на интерфейсе isp1), что делает практически бесполезным сбор netflow, так как в нем нет необходимой информации. Покажите, как вы снимате netflow (конфигурация на интерфейсах) и вывод show ip ca flow
HunterXXI
да в sh ip cache flow лажа.
надо будет поискать возможности решить эту проблему. :*(