Два провайдера одновременно или Dual ISP with VRF на Cisco

    image

    Есть универсальное решение для подключения нескольких провайдеров, 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
      redistribute static metric 100
      default-information originate
     exit-address-family
     
     address-family ipv4 vrf isp2
      redistribute static metric 120
      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
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 23

      +1
      Появилось несколько вопросов.
      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?
        0
        Спасибо за замечания.
        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
          0
          1) проблема может быть в том, что если снимать netflow с «внешнего» интерфейса при том, что он является nat outside, то в show ip ca flow будут видны адреса, в которые занатился пакет (адрес на интерфейсе isp1), что делает практически бесполезным сбор netflow, так как в нем нет необходимой информации. Покажите, как вы снимате netflow (конфигурация на интерфейсах) и вывод show ip ca flow
            0
            да в sh ip cache flow лажа.
            надо будет поискать возможности решить эту проблему. :*(

        0
        Не вижу ни одного преимущества перед стандартным решением без vrf. Только ненужное усложнение конфигурации.
          +1
          Добрый день.

          Мне нравится, что я всегда могу мониторить и имею доступ к своему оборудованию по публичным адресам из любой точки мира. В стандарном решении одноммоментно доступен толкьо один првайдер, с тем который не активен вы не можете провести полноценный icmp тест, что бы оценить качество канала или подлючится удаленно без включения специфических правил в таблицу маршрутизации.
          Ох, знали бы Вы как классно стоить отказоустойчивые VPN туннели с данным решением. Full Mesh FlexVPN? Раз плюнуть!
            0
            как классно стоить отказоустойчивые VPN туннели с данным решением, Full Mesh FlexVPN

            поподробнее можно- в чем прелести вашего варианта? Чем он лучше- удобнее хорошо разжеванного Dual Hub DMVPN например?
              0
              я не говорил, что он лучше)) просто реализовано по-другому. Коротко мы держим 4 открытых туннеля и балансируем их с помощью eigrp:
              Spoke ISP1 – HUB01
              Spoke ISP2 – HUB01
              Spoke ISP1 – HUB02
              Spoke ISP2 – HUB02

              image

              Есть вариант для экономных с 2-одновременными туннелями
              Spoke ISP1 – HUB01
              Spoke ISP1 – HUB02
              Остальные поднимаются по мере пропадания связи
              +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 провайдеру, будут завёрнуты на соответствующий шлюз.
                0
                для работы данноо решения, надо отключать на интерфейсе:
                ip verify unicast reverse-path
                или использовать его в щадящем режиме:
                ip verify unicast source reachable-via any allow-default
              0
              Вероятно, что прелесть в NAT внутри VRF. Таким образом при падении одного аплинка не надо ждать таймаутов NAT или делать clear ip nat tr *
              Но нужно проверять.
              0
              А так да, идея постоянной доступности по двум каналам- полезная.
              Еще вопрос: если нужно сделать ip nat inside source static 192.168.x.x 91.8.2.3 как быть в вашем варианте (в случае с sla просто меням правила с помощью скрипта- старое выбрасываем, для работающего канала прописываем)
                0
                Что-нибудь вида

                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 
                

                но нужно проверять.
                0
                мне кажется, что track 123 list boolean or надо менять на track 123 list boolean and.
                Далее, в этом трекинге нужно настроить соответсвующие delay up/down — очень часто встречается ситуация когда «восьмерки» выпадают на секундочку и трекинг туда-сюда переключаться начинает, что приводит к потере связи на ровном месте.
                  –1
                  это не так. с xgu

                  track list boolean <and | or>
                  and:
                  комбинированный трек в UP, если все объекты внутри UP
                  комбинированный трек в DOWN, если один или более объектов внутри DOWN
                  or:
                  комбинированный трек в UP, если хотя бы один объект внутри UP
                  комбинированный трек в DOWN, если все объекты внутри DOWN
                    0
                    так я и говорю, что нужен «and», потому как часто бывает такое, что что-то упало в сети провайдера и их гейт доступен, а вот интернета нема… соотвественно, доступность == гейт && восьмерки, а не гейт || восьмерки.
                      0
                      В текущем случае and ничуть не лучше or и погоды не сделает, т.к. будет срабатывать если не проходит ping на восьмерки.

                      но признаю ошибку… моя невнимательность. в продакшене мы никогда не тестируем шлюз провайдера. только внешние ресурсы в количестве.
                  +2
                  Кстати, на схеме с VRF можно сделать и двух одновременно работающих провайдеров.
                  Если интересно, могу вспомнить детали.
                    +1
                    Представленная схема работать не будет,
                    для того чтобы в vrf lan появились дефолтные маршруты этого кода недостаточно
                    address-family ipv4 vrf isp1
                      redistribute connected
                      default-information originate
                     exit-address-family
                    


                    требуется или там же дописать
                    redistribute static
                    или
                    дописывать ip route vrf lan 0.0.0.0 0.0.0.0 1.1.1.2 и ip route vrf lan 0.0.0.0 0.0.0.0 2.2.2.2

                    Пожалуйста, прежде чем оспаривать это сделайте лабу.
                      0
                      да вы правы
                      я почему то был уверен что этой комманды достаточно default-information originate

                      Router# sh run | section route
                       route-target export 65000:1
                       route-target import 65000:99
                       route-target export 65000:2
                       route-target import 65000:99
                       route-target export 65000:99
                       route-target import 65000:1
                       route-target import 65000:2
                      router bgp 65000
                       bgp router-id 1.1.1.1
                       bgp log-neighbor-changes
                       !
                       address-family ipv4 vrf isp1
                        redistribute connected
                        redistribute static metric 100
                        default-information originate
                       exit-address-family
                       !
                       address-family ipv4 vrf isp2
                        redistribute connected
                        redistribute static metric 120
                        default-information originate
                       exit-address-family
                       !
                       address-family ipv4 vrf lan
                        redistribute connected
                       exit-address-family
                      ip route vrf isp1 0.0.0.0 0.0.0.0 1.1.1.2 100
                      ip route vrf isp2 0.0.0.0 0.0.0.0 2.2.2.2 120
                      
                      
                        0
                        И раз уж вы тут, чтобы НАТ начал работать реально одновременно через два провайдера, автоматически через BGP балансируя трафик,
                        надо:
                        — убрать метрики с дефолтных маршрутов
                        — дописать в bgp в разделе address-family ipv4 vrf lan
                        строчку maximum-paths 2

                        тогда потом трейс traceroute vrf lan 8.8.8.8 source 192.168.1.1 покажет что два НАТА начали работать одновременно
                          0
                          вопрос балансировки я не пднимал в этой статье, но идея хорошая, надо проверить как проявит себя в реальных условиях.
                            0
                            напишите потом: )

                    Only users with full accounts can post comments. Log in, please.