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



    Добрый день! На написание этого материала меня вдохновил HunterXXI в своей статье Два провайдера одновременно или Dual ISP with VRF на Cisco. Я заинтересовался, изучил вопрос и применил на практике. Хотел бы поделится своим опытом в реализации Dual ISP на Cisco с реальным использованием одновременно двух ISP и, даже, балансировкой нагрузки.

    Демо схема:




    Описание:


    Все действия выполняются на Cisco 1921 IOS Version 15.5(3)M3 с установленным модулем EHWIC-4ESG.

    • Порты GigabitEthernet0/0 и GigabitEthernet0/1 задействованы для подключения ISP.
    • Порты GigabitEthernet0/0/0 и GigabitEthernet0/0/1 сконфигурированы в TRUNK и подключены к коммутаторам.
    • Для работы с локальной сетью используются VLAN интерфейсы.
    • В данной схеме предусматривается три локальных IP сети 192.168.100.0/24 для VLAN 100, 192.168.101.0/24 VLAN 101 и 192.168.102.0/24 VLAN 102.
    • В данном примере VLAN 100 и 101 будут иметь связь между собой но 101 будет без доступа к Интернету, а VLAN 102 будет иметь выход только в интернет.

    Так задумано что бы показать возможности импорта/экспорта между VRF.

    Оставшиеся физические порты не задействованы, но Вам ничто не мешает их использовать по собственному усмотрению.
    Настройка Gi0/0/0 и Gi0/0/1
    interface GigabitEthernet0/0/0
     description TRUNK=>sw-access-1
     switchport mode trunk
     no ip address
    end
    
    interface GigabitEthernet0/0/1
     description TRUNK=>sw-access-2
     switchport mode trunk
     no ip address
    end

    Конфигурация VRF


    Технология Cisco Express Forwarding (CEF) — должна быть включена для работы VRF.

    Настройка VRF для ISP


    ip vrf isp1
     description ISP1
     rd 65000:1
     route-target export 65000:1
     route-target import 65000:100
     route-target import 65000:102
    
    ip vrf isp2
     description ISP2
     rd 65000:2
     route-target export 65000:2
     route-target import 65000:100
     route-target import 65000:102
    

    Обратите внимание, что в конфигурации нет импорта 65000:101 который будет закреплен за VLAN 101. Таким образом виртуальные маршрутизаторы isp1 и isp2 не будут иметь маршрутов в сеть 192.168.101.0/24

    Настройка VRF для VLAN


    ip vrf 100
     description VLAN_Desktop
     rd 65000:100
     route-target export 65000:100
     route-target import 65000:1
     route-target import 65000:2
     route-target import 65000:101
    
    ip vrf 101
     description VLAN_Voice
     rd 65000:101
     route-target export 65000:101
     route-target import 65000:100
    
    ip vrf 102
     description VLAN_Wireless
     rd 65000:102
     route-target export 65000:102
     route-target import 65000:1
     route-target import 65000:2
    

    Снова обратите внимание на VRF 101, который не обменивается маршрутами c ISP но обменивается с VRF 100.
    На своём опыте я убедился, что название VRF для ISP удобно использовать как isp1 и isp2, название VRF для VLAN должно соответствовать номеру VLAN, всё что идентифицирует VRF — description. Это связано с тем, что если, например, у Вас поменяется один из провайдеров то вся реконфигурация сведется к изменению IP адреса интерфейса и description-а.

    Конфигурация интерфейсов


    Применять команду ip vrf forwarding на интерфейсе нужно до назначения IP адреса. В противном случае IP адрес будет удалён и его придётся назначать заново.

    WAN


    interface GigabitEthernet0/0
     description ISP1
      ip vrf forwarding isp1
      ip address 198.51.100.1 255.255.255.252
      ip nat outside
    
    interface GigabitEthernet0/1
     description ISP2
      ip vrf forwarding isp2
      ip address 203.0.113.1 255.255.255.252
      ip nat outside
    

    LAN


    interface Vlan100
     description VLAN_Desktop
     ip vrf forwarding 100
     ip address 192.168.100.254 255.255.255.0
     ip nat inside
    
    interface Vlan101
     description VLAN_Voice
     ip vrf forwarding 101
     ip address 192.168.101.254 255.255.255.0
     ip nat inside
    
    interface Vlan102
     description VLAN_Wireless
     ip vrf forwarding 102
     ip address 192.168.102.254 255.255.255.0
     ip nat inside
    

    Не забудьте создать соответствующие VLAN-ы
    vlan 100
     name Desktop
     exit
    
    vlan 101
     name Voice
     exit
    
    vlan 102
     name Wireless
     exit
    
    show vlan-switch
     VLAN Name                             Status    Ports
    ---- -------------------------------- --------- -------------------------------
    1    default                           active    
    100  Desktop                           active    
    101  Voice                             active    
    102  Wireless                          active    
    
    Vlan1 не используется, интерфейс имеет смысл отключить.
    interface Vlan1
     shutdown

    Конфигурация BGP


    router bgp 65000
    bgp log-neighbor-changes
     
    address-family ipv4 vrf 100
     redistribute connected
     maximum-paths 2
     exit-address-family
     
    address-family ipv4 vrf 101
     redistribute connected
     exit-address-family
     
    address-family ipv4 vrf 102
     redistribute connected
     maximum-paths 2
     exit-address-family
     
    address-family ipv4 vrf isp1
     redistribute connected
     redistribute static route-map BGP_Filter
     default-information originate
     exit-address-family
     
    address-family ipv4 vrf isp2
     redistribute connected
     redistribute static route-map BGP_Filter
     default-information originate
     exit-address-family
    

    Каждый из BGP address-family настраивается отдельно для VRF и перераспределяет подключенные маршруты (redistribute connected). У нас будет два маршрута по умолчанию, один через VRF isp1 и второй через isp2. Параметр maximum-paths 2 позволит импортировать в VRF 100 и 102 оба маршрута по умолчанию.

    Это будет выглядеть так:

    show ip route vrf 100
    
    B*    0.0.0.0/0 [20/0] via 203.0.112.2 (isp2), 0d01h
                    [20/0] via 198.51.100.2 (isp1), 0d01h

    Маршрутизаторы Cisco автоматически балансируют трафик по маршрутам в одном направлении с одинаковой стоимостью.

    В VRF isp1 и isp2 необходимо, помимо redistribute connected, разрешить redistribute static и default-information originate, что позволит передать шлюз по умолчанию в другие VRF. Вы можете заметить, что redistribute static делается через route-map BGP_Filter. Это происходит исключительно из соображений эстетического вида таблиц маршрутизации VRF определенных в локальную сеть, что бы маршруты к 8.8.8.8 и 80.80.80.80 не попадали в таблицы маршрутизации VRF 100 и 102.

    Настройка маршрутизации


    Приступим к настройке маршрутизации. Одной из особенностей работы с VRF, которая усложняет конфигурацию, является необходимость всё определять в конкретный VRF.

    ip route vrf isp1 0.0.0.0 0.0.0.0 198.51.100.2 tag 100 track 100
    ip route vrf isp2 0.0.0.0 0.0.0.0 203.0.112.2 tag 100 track 200

    • tag — поможет нам отфильтровать для передачи в локальные VRF только эти маршруты
    • track — указывает какой объект отвечает за работоспособность маршрута

    route-map BGP_Filter permit 10
     description Fix BGP static redistribution
     match tag 100

    Используя этот route-map и применяя его в VRF для ISP перераспределяться будут только маршруты с тэгом, а остальные останутся только внутри ISP VRF.

    ip route vrf isp1 8.8.8.8 255.255.255.255 198.51.100.2
    ip route vrf isp1 80.80.80.80 255.255.255.255 198.51.100.2
    ip route vrf isp2 8.8.8.8 255.255.255.255 203.0.112.2
    ip route vrf isp2 80.80.80.80 255.255.255.255 203.0.112.2

    Отдельные маршруты к хостам 8.8.8.8 и 80.80.80.80 необходимы для того, что когда сработает track и отключит шлюз по умолчанию у нас осталась возможность совершать проверку доступности этих адресов. Так как мы не присваиваем им тэг они не будут подпадать под route-map и перераспределяться.

    Настройка NAT


    Для работы NAT необходимо обозначить inside, outside интерфейсы. В качестве outside мы определяем интерфейсы в которые подключены ISP, командой ip nat outside. Все остальные интерфейсы, которые относятся к LAN обозначаем как inside командой ip nat inside.

    Необходимо создать два route-map-а в которых определяются интерфейсы isp1 и isp2

    route-map isp1 permit 10
     match interface GigabitEthernet0/0
     
    route-map isp2 permit 10
     match interface GigabitEthernet0/1

    Правила NAT необходимо указывать для каждого VRF через каждый ISP. Так как в нашем условии Vlan 101 не имеет доступа к сети Интернет то правила для него указывать нет необходимости, а даже если их указать — работать не будет, потому что нет маршрутизации.

    ip nat inside source route-map isp1 interface GigabitEthernet0/0 vrf 100 overload
    ip nat inside source route-map isp2 interface GigabitEthernet0/1 vrf 100 overload
    ip nat inside source route-map isp1 interface GigabitEthernet0/0 vrf 102 overload
    ip nat inside source route-map isp2 interface GigabitEthernet0/1 vrf 102 overload

    Немного теории NAT
    У Cisco есть много разновидностей NAT. В терминологии Cisco, то что мы используем называется Dynamic NAT with Overload или PAT.

    Что нужно для того что бы NAT работал?

    1. Определить внутренний и внешний интерфейсы
    2. Указать, что мы хотим транслировать
    3. Указать, во что мы хотим транслировать
    4. Включить трансляцию

    В простой конфигурации NAT достаточно создать access-list в котором определить локальную сеть и применить правило трансляции.

    ip access-list extended NAT
     permit ip 192.168.0.0 0.0.0.255 any
     
    ip nat inside source list NAT interface GigabitEthernet0/0 overload

    Таким образом мы указываем, что/во что и включаем трансляцию, то есть выполняем все необходимые требования.

    Это настройка простой конфигурации, она очевидна и понятна без дополнительных подробностей.

    Правило которое мы применяем в нашей конфигурации уже не так очевидно. Как мы помним, route-map isp1 определяет интерфейс GigabitEthernet0/0. Перефразируя команду получается нечто подобное

    ip nat inside source GigabitEthernet0/0 interface GigabitEthernet0/0 overload in vrf 100

    Получается нужно транслировать трафик source которого GigabitEthernet0/0?

    Для того что бы это понять необходимо погрузится в механизм прохождения пакета внутри маршрутизатора.

    • Трафик который приходит на интерфейс который помечен как inside не подвергается трансляции. Он маркируется как возможно транслируемый.
    • Следующим шагом обработки этого трафика является его маршрутизация согласно таблице маршрутизации или PBR.
    • Если согласно таблице трафик попадает на интерфейс который отмечен как outside происходит его трансляция.
    • Если трафик попадает на не outside интерфейс трансляции не происходит.

    Ошибочно можно подумать, что можно делать route-map LAN match interface Vlan100. Применять этот как ip nat inside source route-map LAN и т.д.

    Во избежание этой мысли нужно понять, что это правило трансляции срабатывает тогда, когда трафик уже находится на outside интерфейсе и match интерфейса где этого трафика уже нет ни к чему не приведет.
    Спасибо IlyaPodkopaev NAT на Cisco. Часть 1

    Настройка SLA


    ip sla auto discovery
    
    ip sla 10
     icmp-echo 198.51.100.2
     vrf isp1
     frequency 5
    ip sla schedule 10 life forever start-time now
    
    ip sla 11
     icmp-echo 8.8.8.8
     vrf isp1
     frequency 5
    ip sla schedule 11 life forever start-time now
    
    ip sla 12
     icmp-echo 80.80.80.80
     vrf isp1
     frequency 5
    ip sla schedule 12 life forever start-time now
    
    
    ip sla 20
     icmp-echo 203.0.112.2
     vrf isp2
     frequency 5
    ip sla schedule 20 life forever start-time now
    
    ip sla 21
     icmp-echo 8.8.8.8
     vrf isp2
     frequency 5
    ip sla schedule 21 life forever start-time now
    
    ip sla 22
     icmp-echo 80.80.80.80
     vrf isp2
     frequency 5
    ip sla schedule 22 life forever start-time now

    Ничего особенного в конфигурации нет, проверятся доступность по ICMP узлов 8.8.8.8 80.80.80.80 и маршрутизаторов провайдера из каждого ISP VRF.

    Настройка track


    track 100 list boolean and
     object 101
     object 110
     
    track 101 ip sla 10 reachability
     delay down 20 up 180
     
    track 102 ip sla 11 reachability
     delay down 20 up 180
     
    track 103 ip sla 12 reachability
     delay down 20 up 180
     
    track 110 list boolean or
     object 102
     object 103
     
    track 200 list boolean and
     object 201
     object 210
     
    track 201 ip sla 20 reachability
     delay down 20 up 180
     
    track 202 ip sla 21 reachability
     delay down 20 up 180
     
    track 203 ip sla 22 reachability
     delay down 20 up 180
     
    track 210 list boolean or
     object 202
     object 203
     
    track 1000 stub-object

    Логика работы:

    В таблице маршрутизации есть маршрут ip route vrf isp1 0.0.0.0 0.0.0.0 198.51.100.2 tag 100 track 100 который завязан на track 100.

    • Если track 100 в состоянии UP то маршрут в таблице есть.
    • Объект 100 это boolean and, что означает, что UP он будет считаться если все его объекты в состоянии UP.
    • Если любой из объектов 100 DOWN то весть объект 100 будет DOWN.
    • Он содержит объекты 101 и 110.
    • Объект 101 соответствует SLA 10 — проверяет шлюз провайдера.
    • Объект 110 объединяет 102 и 103 как boolean or, что означает, что он будет UP если хотя бы один из его объектов UP.
    • Объекты 102 и 103 проверяют 8.8.8.8 и 80.80.80.80 соответственно, их нужно два для исключения ложных срабатываний.

    Таким образом получается, что если отвечает шлюз по умолчанию провайдера и хотя бы один из внешних адресов то связь считается рабочей.

    track 1000


    track 1000 stub-object
     default-state down

    Этот объект умолчанию имеет состояние DOWN.
    В данной конфигурации этот объект необходим для того, что бы принудительно отключить одного из ISP и не подключать его. Для этого track 1000 нужно добавить в объект 100 или 200. Исходя из boolean and, если один из объектов DOWN то весь объект считается DOWN.

    Настройка EEM


    EEM — Embedded Event Manager позволяет автоматизировать действия в соответствии с определенными событиями.

    В нашем случае, когда один из ISP перестанет работать, он будет исключен из таблицы маршрутизации. Но правила трансляции NAT будут оставаться. Из-за этого, уже установленные пользовательские соединения зависнут до того момента пока трансляции NAT не очистится по тайм-ауту.

    Для того, что бы ускорить этот процесс нам необходимо очистить таблицу NAT командой clear ip nat translation * и лучше всего сделать это автоматически.

    event manager applet CLEANNAT-100
     event track 100 state down
     action 10 cli command "enable"
     action 20 cli command "clean ip nat translation *"
    event manager applet CLEANNAT-200
     event track 200 state down
     action 10 cli command "enable"
     action 20 cli command "clean ip nat translation *"

    Если объекты 100 или 200 перейдут в состояние DOWN то будут выполнены команды action по порядку.

    tips and tricks


    Хочу отметить ещё несколько особенностей работы с VRF.

    Например конфигурация NTP:

    ntp server vrf isp1 132.163.4.103

    Из-за использования VRF любые сетевые операции нужно относить к виртуальному маршрутизатору, это связано с тем, что когда Вы настроите эту конфигурацию и выполните show ip route вы не увидите ни одной записи в таблице маршрутизации.

    ping vrf isp1 8.8.8.8

    Будьте внимательны.

    К преимуществам этой конфигурации я хотел бы отнести её гибкость. Можно с легкостью вывести один VLAN через одного ISP, а другой через второго.

    К недостаткам, и это вопрос к уважаемой публике, когда отваливается один из ISP то команда clear ip nat translations * обрывает все соединения, включительно с работающим ISP. Как показала практика, в тех случаях когда отваливается провайдер — пользователи не замечают этот «обрыв» или он не является критичным.

    Если кто-то знает как очищать таблицу трансляций частично — буду благодарен.

    P.S>


    Не забудьте запретить NAT трансляцию в приватные подсети.

    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
    • +17
    • 16.6k
    • 8
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 8

      0
      спасибо за статью
      но мне не понятно, зачем для работы vrf cef?
      (или это фигура речи такая?)
      я понимаю что cef нужен для sla,track но не для vrf
      если я не прав, поясните пожалуйста
        0
        Попробую объяснить так:
        no ip cef
        
        R1(config-if)#ip vrf forwarding test
        % Enable CEF globally before configuring VRF on any interface
          +1
          Для полноценных VRF (с использованием BGP и MPLS) CEF нужен, потому что MPLS циска (насколько мне известно) умеет только через CEF. Насчет VRF-lite не уверен.
          Тут вопрос в другом: зачем вообще VRF в этом случае? На мой взгляд, получается наркоманско-шизофренический конфиг, который никто кроме автора поддерживать не сможет. Хотя job-security, да, хороший.
          Единственное, что этот конфиг дает — разграничение доступа, но в лоб, с использованием ACL, получится проще и понятнее.
            0
            Насчет «кроме автора никто не сможет поддерживать» не согласен. Я основывался на статье автора которую указал. Я разобрался — ничего сложного. По поводу ACL — вы правы, но статья не о том, и то что в данном случае, в определенных ситуациях ACL не нужен это скорее фича.
            0
            Как раз для IP SLA технология CEF не нужна. Пакеты генерирует само устройство (используется process switching).

            А вот VRF в качестве пререквизита требует CEF. Изначально VRF появился для работы MPLS VPN. При этом MPLS опирается на логику CEF и обязательно требует его включения. VRF обеспечивает изоляцию за счёт разных таблиц RIB и FIB для каждого инстанса.
            +1
            Если кто-то знает как очищать таблицу трансляций частично — буду благодарен.

            Можно поробовать так: clear ip nat translation vrf isp1 *

            Из-за этого, уже установленные пользовательские соединения зависнут до того момента пока трансляции NAT не очистится по тайм-ауту.

            Я бы не согласился с этим утверждением. Действительно, соединения подвисают, так как пакеты в рамках открытой сессии используют текущие записи NAT, которые ссылаются на адреса отказавшего провайдера. Но таймаут NAT для TCP равен 24 часа. Ждать его окончания было бы слишком долго.

            Обычно клиентская сторона намного раньше разрывает соединение. Например, может использоваться механизм TCP Keep-alive. Или пользователь самостоятельно инициирует установку нового соединения (например, принудительно обновив страницу в браузере).

            Магия «clear ip nat translation» заключается в том, что как только вы вводите эту команду, маршрутизатор отправляет пакет с флагом RST для всех TCP сессий. Из-за чего внутренние ПК завершают текущую сессию и при необходимости открывают новую. А новая уже прекрасно работает, так как создаются новые NAT записи, использующие адреса второго провайдера.
              0
              В голове не укладывается, зачем в дизайне SMB нужна такая сложная конфигурация…
                0
                для дизайна SMB, есть решения из коробки-простые и легкие?

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