Здравствуйте.
Есть универсальное решение для подключения нескольких провайдеров, 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 1.1.1.2 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 9.9.9.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 log deny ip any 172.16.0.0 0.15.255.255 log deny ip any 10.0.0.0 0.255.255.255 log permit ip any any log Делаем карты маршрутизации для каждого провайдера:
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
ссылка на оригинал статьи http://habrahabr.ru/post/270261/
Добавить комментарий