23.12.2015 11:58
Lennotoecom 15 8500 Источник
При классической схеме подключения двух 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

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


  1. vasilevkirill
    23.12.2015 23:05
    #8714333
    +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 минут вводить логин и пароль.


    1. Lennotoecom
      23.12.2015 23:39
      #8714369

      Скорее работает как обычный PAT, только в пуле неупорядоченные адреса из некоторого диапазона.
      Часто разъяренные пользователи приходят ругаться на обычный PAT?


      1. vasilevkirill
        23.12.2015 23:55
        #8714397

        на 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??


        1. Lennotoecom
          24.12.2015 00:10
          #8714409

          ну, официальный гайд говорит следующее о 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,
          тот же эффект что и при дуал нате.


          1. vasilevkirill
            24.12.2015 00:26
            #8714429

            =))) вы же понимаете, к чему я виду =)
            давайте по другому
            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


            1. Lennotoecom
              24.12.2015 03:36
              #8714545

              я не уверен как работает в таких случаях дуал НАТ, но уверен так же как и классика


              1. vanyas
                24.12.2015 08:35
                #8714637

                а тут нат не при делах будет, вначале отработает маршрутизация и выберется один из исходящих интерфесов, а потом уже применется соответствующий нат. В отличии от случая с сеткой /29 на одном интерфейсе, тут да, будут помниться нат трансляции и всё будет ок


                1. Lennotoecom
                  24.12.2015 09:25
                  #8714663

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


            1. Lennotoecom
              24.12.2015 03:39
              #8714547

              сделаю тесты напишу вам здесь


            1. Lennotoecom
              24.12.2015 04:15
              #8714559

              ну даже если в этом месте может возникнуть проблема, мы можем всегда включить тюнинг ecmp на cisco
              через per-destination а не per-packet


            1. Lennotoecom
              24.12.2015 09:25
              #8714665

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


            1. Lennotoecom
              24.12.2015 09:58
              #8714691

              нашел объяснение в ecmp хеше, дописал объяснение в конец статьи, спасибо вам за замечание


              1. vasilevkirill
                24.12.2015 15:40
                #8715485

                я бы всё таки добавил, что необходимо включить cef.

                ip cef distributed

                так как в RFC по ecmp явным образом не сказано учитывается ли порты src и dst при расчёте хеша


  1. achekalin
    24.12.2015 09:32
    #8714671

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

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

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


    1. Lennotoecom
      24.12.2015 09:45
      #8714679

      исправил название спасибо.
      определение живости по sla я опустил в статье.
      моменты могут быть вы правы