Балансировка траффика между двумя NAT на разных провайдерах на одном физическом роутере cisco

    При классической схеме подключения двух ISP к одному роутеру, есть возможность использовать сразу два канала для NATирования внутренних клиентов с балансировкой нагрузки, а не только для фейловера при отказе одного из провайдеров.

    Осуществляется это следующим образом:
    c использованием vrf:
    описание vrf для первого провайдера:
    экспортируем нашу метку «100:0»,
    импортируем метку из vrf второго провайдера «100:1»

    ip vrf ISPA
     rd 100:0
     route-target export 100:0
     route-target import 100:1
    

    описание vrf для второго провайдера:
    экспортируем нашу метку «100:1»,
    импортируем метку из vrf первого провайдера «100:0»

    ip vrf ISPB
     rd 100:1
     route-target export 100:1
     route-target import 100:0
    

    описание vrf для клиентской сети:
    импортируем обе метки из vrf двух провайдеров «100:0» и «100:1»

    ip vrf LAN
     rd 100:100
     route-target import 100:0
     route-target import 100:1
    


    Настройка интерфейсов:
    к первому провайдеру:
    настраиваем правильный vrf
    ip vrf forwarding ISPA

    включаем нат
    ip nat outside


    interface FastEthernet0/0
     ip vrf forwarding ISPA
     ip address 50.0.0.1 255.0.0.0
     ip nat outside
    

    ко второму провайдеру:
    настраиваем правильный vrf
    ip vrf forwarding ISPB

    включаем нат
    ip nat outside


    interface FastEthernet1/0
     ip vrf forwarding ISPB
     ip address 60.0.0.1 255.0.0.0
     ip nat outside
    

    интерфейс смотрящий в локальную сеть:
    настраиваем правильный vrf
    ip vrf forwarding LAN

    включаем нат
     ip nat inside


    interface FastEthernet1/1
     ip vrf forwarding LAN
     ip address 192.168.0.1 255.255.255.0
     ip nat inside
    


    Маршруты по умолчанию к провайдерам:
    с указанием vrf для каждого маршрута

    ip route vrf ISPA 0.0.0.0 0.0.0.0 50.0.0.2
    ip route vrf ISPB 0.0.0.0 0.0.0.0 60.0.0.2
    


    Настройка BGP для взаимной редистрибьюции маршрутов между vrf:
    распространяем подключенные сети с интерфейсов:
    redistribute connected

    распространяем статические дефолтные маршруты к провайдерам:
      redistribute static
      default-information originate

    в клиентском vrf разрешаем распределение нагрузки:
    maximum-paths 2


    router bgp 65000
     address-family ipv4 vrf ISPA
      redistribute connected
      redistribute static
      default-information originate
    
     address-family ipv4 vrf ISPB
      redistribute connected
      redistribute static
      default-information originate
    
     address-family ipv4 vrf LAN
      redistribute connected
      maximum-paths 2
    


    Правила для NAT:
    включаем NAT на оба внешних интерфейса в клиентском vrf

    ip nat inside source route-map A interface FastEthernet0/0 vrf LAN overload
    ip nat inside source route-map B interface FastEthernet1/0 vrf LAN overload
    


    Access list и route-map для правил NATирования:
    используем route-map для двух целей:
    — IOS не дал бы создать два разных правила NAT для одного access-list
    — идентификация по исходяшему интерфейсу

    route-map A permit 10
     match ip address 1
     match interface FastEthernet0/0
    
    route-map B permit 10
     match ip address 1
     match interface FastEthernet1/0
    
    access-list 1 permit 192.168.0.0 0.0.0.255
    


    Для проверки что балансировка маршрутов случилась, будем использовать команду traceroute:
    R1#traceroute vrf  LAN 8.8.8.8 source fa 1/1
    Type escape sequence to abort.
    Tracing the route to 8.8.8.8
    VRF info: (vrf in name/id, vrf out name/id)
      1 50.0.0.2 132 msec
        60.0.0.2 44 msec
        50.0.0.2 24 msec
    

    как видно из приходящих ответов отвечают два провайдера.

    Таблица NAT после этих ответов подтверждает созданные соответствия:
    R1#show ip nat translations
    Pro Inside global      Inside local       Outside local      Outside global
    udp 50.0.0.1:49162     192.168.0.1:49162  8.8.8.8:33434      8.8.8.8:33434
    udp 60.0.0.1:49163     192.168.0.1:49163  8.8.8.8:33435      8.8.8.8:33435
    udp 50.0.0.1:49164     192.168.0.1:49164  8.8.8.8:33436      8.8.8.8:33436
    


    Таблица маршрутизации для клиентского vrf выглядит следующим образом:
    R1#show ip route vrf LAN
    
    B*    0.0.0.0/0 [20/0] via 60.0.0.2 (ISPB), 00:00:20
                    [20/0] via 50.0.0.2 (ISPA), 00:00:20
          50.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    B        50.0.0.0/8 is directly connected (ISPA), 00:00:22, FastEthernet0/0
    L        50.0.0.1/32 is directly connected, FastEthernet0/0
          60.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    B        60.0.0.0/8 is directly connected (ISPB), 00:00:20, FastEthernet1/0
    L        60.0.0.1/32 is directly connected, FastEthernet1/0
          192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
    C        192.168.0.0/24 is directly connected, FastEthernet1/1
    L        192.168.0.1/32 is directly connected, FastEthernet1/1
    


    без использования vrf:
    #интерфейс к первому провайдеру
    interface FastEthernet0/0
     ip address 50.0.0.1 255.0.0.0
     ip nat outside
    
    #интерфейс ко второму провайдеру
    interface FastEthernet1/0
     ip address 60.0.0.1 255.0.0.0
     ip nat outside
    
    #интерфейс к клиентской сети
    interface FastEthernet1/1
     ip address 192.168.0.1 255.255.255.0
     ip nat inside
    
    #PBR для того чтобы при запросах снаружи наш роутер не путался куда отдавать пакеты
    ip local policy route-map PBR
    
    #NAT правила и маршруты по умолчанию с одинаковыми метриками
    ip nat inside source route-map A interface FastEthernet0/0 overload
    ip nat inside source route-map B interface FastEthernet1/0 overload
    ip route 0.0.0.0 0.0.0.0 50.0.0.2
    ip route 0.0.0.0 0.0.0.0 60.0.0.2
    
    #PBR если пакеты должны уйти через первый провайдер
    route-map PBR permit 10
     match ip address 10
     set ip next-hop 50.0.0.2
    
    #PBR если пакеты должны уйти через второй провайдер
    route-map PBR permit 20
     match ip address 11
     set ip next-hop 60.0.0.2
    
    #для NAT через первого провайдера
    route-map A permit 10
     match ip address 1
     match interface FastEthernet0/0
    
    #для NAT через второго провайдера
    route-map B permit 10
     match ip address 1
     match interface FastEthernet1/0
    
    #сопутствующие acl
    access-list 1 permit 192.168.0.0 0.0.0.255
    access-list 10 permit 50.0.0.1
    access-list 11 permit 60.0.0.1
    


    !
    ip cef обязателен в обоих случаях

    Всем спасибо за внимание, жду ваших комментариев.

    P.S.
    ecmp фейл (спасибо vasilevkirill что обратил внимание) не случается благодаря алгоритму хеширования используемому в cef,
    подробно об этом на официальном сайте
    циско www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/116376-technote-cef-00.html
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 15

      +1
      Правильно ли я понял, в итоге получается обычный ECMP.
      B*    0.0.0.0/0 [20/0] via 60.0.0.2 (ISPB), 00:00:20
                      [20/0] via 50.0.0.2 (ISPA), 00:00:20
      

      Первый же сайт, типо одноклассников, который учитывает в сессии ip адрес, и тут же вы получите факап. в виде разъяренных пользователей, которые должны будут каждые N минут вводить логин и пароль.
        0
        Скорее работает как обычный PAT, только в пуле неупорядоченные адреса из некоторого диапазона.
        Часто разъяренные пользователи приходят ругаться на обычный PAT?
          0
          на PAT, конечно же нет, но я говорю о другом нюансе.

          мой хост 192.168.0.100/24 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100->60.0.0.1))->Хост назначения(8.8.8.8)
          хост 8.8.8.8 с учётом моего IP адреса создал cookie.
          вопрос в следующем, если я через некоторое время (но меньшее жизни куки), обращусь к хосту 8.8.8.8, каков шанс, что мой трафик уйдёт с адрес 60.0.0.1, а не 50.0.0.1??
            0
            ну, официальный гайд говорит следующее о TCP сессиях:

            When port translation is configured .. .. TCP translations time out after 24 hours, unless a RST or FIN is seen on the stream, in which case it times out in 1 minute.

            Но давайте предположим что провайдер выдал сетку вам 50.0.0.0/29,
            и вы настроили PAT на все доступные вам адреса 50.0.0.2 — 50.0.0.6,
            тот же эффект что и при дуал нате.
              0
              =))) вы же понимаете, к чему я виду =)
              давайте по другому
              1) запрос
              мой хост 192.168.0.100:45555 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:45555->60.0.0.1:45555))->Хост назначения(8.8.8.8:80)
              2) запрос ajax или полученеи картинок и т.п.д
              мой хост 192.168.0.100:41111 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:41111->???.???.???.???:41111))->Хост назначения(8.8.8.8:80)

              в итоге получим два соединения, и не факт что, второе выйдет с адреса 60.0.0.1
                0
                я не уверен как работает в таких случаях дуал НАТ, но уверен так же как и классика
                  0
                  а тут нат не при делах будет, вначале отработает маршрутизация и выберется один из исходящих интерфесов, а потом уже применется соответствующий нат. В отличии от случая с сеткой /29 на одном интерфейсе, тут да, будут помниться нат трансляции и всё будет ок
                    0
                    Сделал тесты, я не знаю почему но он всегда выпускает клиента с тем же IP адресом для определенного source, если пакет приходит снаружи клиентского интерфейса. С самого роутера идет шафл.
                    Не могу объяснить почему. По логике ECMP действительно должен был произойти шафл, но он происходит только с разными source IP. Может быть по дефолту на тестовой системе стоит ecmp per destination. Это единственное объяснение которое у меня пока есть. Так что все ок.
                    Тестировалось на следующем софте:
                    7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.3(3)XB12, RELEASE SOFTWARE (fc2)
                  0
                  сделаю тесты напишу вам здесь
                    0
                    ну даже если в этом месте может возникнуть проблема, мы можем всегда включить тюнинг ecmp на cisco
                    через per-destination а не per-packet
                      0
                      Сделал тесты, я не знаю почему но он всегда выпускает клиента с тем же IP адресом для определенного source, если пакет приходит снаружи клиентского интерфейса. С самого роутера идет шафл.
                      Не могу объяснить почему. По логике ECMP действительно должен был произойти шафл, но он происходит только с разными source IP. Может быть по дефолту на тестовой системе стоит ecmp per destination. Это единственное объяснение которое у меня пока есть. Так что все ок.
                      Тестировалось на следующем софте:
                      7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.3(3)XB12, RELEASE SOFTWARE (fc2)
                        0
                        нашел объяснение в ecmp хеше, дописал объяснение в конец статьи, спасибо вам за замечание
                          0
                          я бы всё таки добавил, что необходимо включить cef.
                          ip cef distributed
                          

                          так как в RFC по ecmp явным образом не сказано учитывается ли порты src и dst при расчёте хеша
                0
                Вы одно слово в заголовке забыли написать — название вендора. «Балансировка траффика между двумя NAT на разных провайдерах на одном физическом роутере _Cisco_». Потому что название в том виде, как есть, выглядит обещанием статьи с теорией балансировки, а на практике начинается с места в карьер прямо с варианта с vrf. Так что как быстрый howto — неплохо (хотя впервые в публичном howto вижу балансировку с, ни много ни мало, BGP внутри роутера для балансировки!), но это все равно очень cisco-only.

                А что с определением живости интернета через конкретных аплинков? У вас прописана логика загрузки обоих каналов, но что делать, если один из них упадет?

                P.S. Кстати, навскидку не скажу, но, если аплинки не в виде интерфейсов со статическими IP, а в виде, скажем, pppoe- или l2tp-соединений (а сегодня все больше провайдеров стараются сделать именно так, ибо для них так удобнее; шлюзы по умолчанию в этом случае могут, скажем, меняться от «дозвона» к дозвону), там, вроде бы, могут быть «моменты» в настройке.
                  0
                  исправил название спасибо.
                  определение живости по sla я опустил в статье.
                  моменты могут быть вы правы

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое