Архитектура Router-on-a-Stick в сети передачи данных

Если вы испытываете нехватку физических портов на оборудовании сети передачи данных, в то время как перед вами встала острая необходимость завести второго интернет-провайдера или вывести часть серверов в ДМЗ используя оборудование Cisco Systems, тогда эта статья должна помочь с решением многим начинающим системным администраторам, а также тем, кто недавно приступил к работе с сетями передачи данных и с оборудованием Cisco в частности. Речь пойдет об архитекторе под названием Router-on-a-Stick.

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

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



Как мы видим, для решения поставленной задачи требуется коммутатор, желательно 3-го уровня. Коммутатор должен обладать достаточной пропускной способностью, чтобы снизить потенциальные задержки передачи пакетов в случае возникновения больших объемов трафика. Если это модульный коммутатор, тогда желательно обзавестись резервным блоком питания и резервным управляющим процессором для него.

Кроме очевидных преимуществ подобной архитектуры, есть также некоторые недостатки, одним из которых является увеличенная в несколько раз нагрузка на отдельно взятый физический порт устройства. Но бывают ситуации, когда обойтись без виртуальных интерфейсов нельзя. Так, например, если немного отвлечься от темы, то невозможно выстроить отказоустойчивую связку двух межсетевых экранов в режиме Active/Passive, если не подключить каждый из них одним физическим линком к коммутатору, а вторым объединив их между собой для обмена служебными данными. В случае выхода из строя одного межсетевого экрана, его место займет второй с идентичной конфигурацией.

Чтобы не оставаться голословным, я приведу пример реализации простейшей модели архитектуры Router-on-a-Stick.

Возьмем упрощенную схему, на которой представлен маршрутизатор, подключенный к коммутатору 2-го уровня. В свою очередь к коммутатору подключены линки от двух интернет-провайдеров и одна внутренняя сеть компании с рабочими станциями и серверами.

Для реализации задуманного, подключим линк от Провайдера #1 к порту Gi0/1 и определим его в VLAN 100, а линк от Провайдера #2 к порту Gi0/2 в VLAN 200. Рабочие станции и сервера будут находиться на портах Gi0/3 — 23 в VLAN 50. Аплинк между коммутатором и маршрутизатором будет на порту Gi0/24, он будет помещен в транк. Схема подключения приведена на рисунке далее:



Конфигурация коммутатора сводится к следующим командам:

telecombook_ru#conf t

telecombook_ru(config)#vlan 50
telecombook_ru(config-vlan)#name DATA
telecombook_ru(config-vlan)#exit

telecombook_ru(config)#vlan 100
telecombook_ru(config-vlan)#name ISP1
telecombook_ru(config-vlan)#exit

telecombook_ru(config)#vlan 200
telecombook_ru(config-vlan)#name ISP2
telecombook_ru(config-vlan)#exit

telecombook_ru(config)#interface Gi0/1
telecombook_ru(config-if)#switchport mode access
telecombook_ru(config-if)#switchport access vlan 100

telecombook_ru(config)#interface Gi0/2
telecombook_ru(config-if)#switchport mode access
telecombook_ru(config-if)#switchport access vlan 200

telecombook_ru(config)#interface range Gi0/3 – 23
telecombook_ru(config-if)#switchport mode access
telecombook_ru(config-if)#switchport access vlan 50

telecombook_ru(config)#interface Gi0/24
telecombook_ru(config-if)#switchport mode trunk
telecombook_ru(config-if)#switchport trunk encapsulation dot1q


Теперь, когда коммутатор настроен, необходимо указать IP адреса, предоставленные интернет-провайдерами и адрес шлюза для хостов в VLAN 50. Указывать их будем на маршрутизаторе для каждого VLAN с помощью виртуальных интерфейсов. Так, мы разделим один физический интерфейс Gi0/0 на три виртуальных Gi0/0.50, Gi0/0.100, Gi0/0.200 под каждый VLAN и настроим так, как приведено на схеме не забыв про NAT:



Для настройки маршрутизатора применим следующие команды:
telecombook_ru#conf t
telecombook_ru(config)#interface Gi0/0.50
telecombook_ru(config-if)#encapsulation dot1Q 50
telecombook_ru(config-if)#ip address 192.168.1.254 255.255.255.0
telecombook_ru(config-if)#ip nat inside

telecombook_ru(config)#interface Gi0/0.100
telecombook_ru(config-if)#encapsulation dot1Q 100
telecombook_ru(config-if)#ip address 100.50.50.1 255.255.255.252
telecombook_ru(config-if)#ip nat outside

telecombook_ru(config)#interface Gi0/0.200
telecombook_ru(config-if)#encapsulation dot1Q 200
telecombook_ru(config-if)#ip address 200.75.75.1 255.255.255.252
telecombook_ru(config-if)#ip nat outside

telecombook_ru(config)#ip access-list extended nat-traffic
telecombook_ru(config-acl)#10 permit ip 192.168.1.0 0.0.0.255 any
telecombook_ru(config-acl)#exit

telecombook_ru(config)#route-map isp1 permit 10
telecombook_ru(config-route-map)#match ip address nat-traffic
telecombook_ru(config-route-map)#match interface GigabitEthernet0/0.100
telecombook_ru(config-route-map)#exit

telecombook_ru(config)#route-map isp2 permit 10
telecombook_ru(config-route-map)#match ip address nat-traffic
telecombook_ru(config-route-map)#match interface GigabitEthernet0/0.200
telecombook_ru(config-route-map)#exit

telecombook_ru(config)#ip nat inside source route-map isp1 interface GigabitEthernet0/0.100 overload
telecombook_ru(config)#ip nat inside source route-map isp2 interface GigabitEthernet0/0.200 overload


Завершим конфигурацию добавлением двух маршрутов по умолчанию:

telecombook_ru(config)#ip route 0.0.0.0 0.0.0.0 interface Gi0/0.100
telecombook_ru(config)#ip route 0.0.0.0 0.0.0.0 interface Gi0/0.200


Так как маршруты имеют одинаковую метрику, маршрутизатор будет балансировать нагрузку между ними.
Надеюсь, что данный материал когда-нибудь окажется для вас полезным. Спасибо!

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

    +1
    Спасибо большое! Никогда не знаешь, когда пригодится. Определённо в «закладки»
      0
      Да, действительно полезно, спасибо!
        +1
        вы саб интерфейсы в влан не посадили.
        пример:

        telecombook_ru#conf t
        telecombook_ru(config)#interface Gi0/0.50
        telecombook_ru(config-if)#enca do 50
        telecombook_ru(config-if)#ip address 192.168.1.254 255.255.255.0
        telecombook_ru(config-if)#ip nat inside


        p.s. коммутатора l3 не обязательно применять.
        и кому интересно почитайте, 3650-x 3750-x stack power

          0
          Спасибо, недоглядел! Поправил сабинтерфейсы.
          0
          «Router-on-a-Stick» иногда называют «lollipop» — «леденец на палочке» :)
            0
            Недавно настроил именно такую схему дома. D-Link DIR-825 плюс прошивка OpenWRT (родная прошивка не поддерживает VLan-ы). Два провайдера, основная локалка, гостевая локалка и гостевой WiFi — все в отдельных vlan-ах, все имеют доступ только к моему роутеру (на котором Hardened Gentoo Linux), а он уже решает кого куда пущать или не пущать.

            При кажущейся простоте настройки было несколько странных проблем. Например, встроенная ssh отзывалась на IP 192.168.x.x, но не отзывалась на 10.x.x.x — при этом судя по netstat она висела на 0.0.0.0:22 и не была привязана ни к какому интерфейсу. Другая похожая проблема — WAN интерфейс почему-то отказывался работать в мосте (bridge) с VLAN1, но работал нормально с любым другим номером VLAN (я в курсе про PVLAN, который как раз равен 1, но как это может мешать работе моста?).
              0
              s/PVLAN/PVID/
              0
              в качестве коммента:
              такую схему нельзя применять в условиях жестких требований:
              1) к отказоустойчивости. Т.к. свитч на котором живет куча виланов становится единой точкой отказа. Умер свитч — умерло всё.
              2) к безопасности. Особенно вторая схема, где и фаерволл-он-стик и роутер-он-стик. Потому как опять же данные из разных доменов безопасности проходят через одну и ту же железку. Трафик из пользовательских сетей в дмз идет через тот же свитч что и трафик из интернета. Достаточно подвергнуть свитч несложной атаке на переполнение fib/cam и вуаля…
                0
                Могу прокомментировать по первому случаю. Именно для этого я написал об использовании модульного коммутатора с двумя блоками питания и двумя супервизорами и возможно даже резервной линейной платой. С такой системой отказоустойчивости, шансы отказа коммутатора ничтожно малы, настолько, что это практически не реально, а если использовать два таких коммутатора, объединенных по технологии VSS, тогда скорее метеорит упадет, чем что-то откажет.

                А вот по безопасности интересно, я бы почитал об этом подробнее.
                  +1
                  Сейчас поразмыслил по поводу безопасности. Атаку на cam таблицу коммутатора можно реализовать только будучи в одном бродкастовом домене с коммутатором, по сути злоумышленник должен каким-то образом оказаться в том же VLAN, который проброшен, например, от коммутатора до маршрутизатора. А как он это может сделать? Только физически притащить свое оборудование и поставить его на участке подключения между коммутатором и провайдером. Это кажется уже фантастикой.

                  В любом случае можно защититься от такой атаки средствами port-security.

                  На счет переполнения FIB, на коммутаторе на данном VLAN отсутствуют IP адреса, а следовательно не выполняется маршрутизация, отсюда о FIB можно не беспокоиться, т.к. FIB попросту не будет работать.
                  0
                  Где можно подробнее прочитать про подобную атаку на свитч?
                    0
                    «стандартный» пример — VPN-концентратор с одним сетевым линком

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

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