Ethernet Virtual Circuits

Всем привет. В этой статье поговорим еще об одном инструменте виртуальных сетей. Речь пойдет о такой технологии как Ethernet Virtual Circuits (EVC).

Как вам уже должно быть известно, сети второго уровня очень удобно  делить на  виртуальные подсети — VLAN’ы. Как правило, для этого используется стандарт IEEE 802.1q. Он позволяет организовать до 4096 VLAN’ов в одном широковещательном сегменте. Число немаленькое и даже для больших организаций его обычно достаточно. Но сети бывают всякие разные, и встречаются такие, в которых этого количества уже не хватает. Очевидное решение – разделение такой сети на два и более сегмента, которые объединяются между собой устройствами третьего уровня, маршрутизаторами. Как показано на рисунке.

evc1

В такой сети в каждом отдельном сегменте мы можем назначать любые ID VLAN’ов, даже если они повторяются в разных сегментах.

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

EVC работает на основе такого понятия как bridge domain. Bridge domain – определяет широковещательный сегмент внутри одного устройства и имеет значение только внутри этого устройства. По сути это виртуальный коммутатор, на который подключаются определенные VLAN’ы с различных портов. Сам Bridge Domain только передает пакеты в соответствии с таблицей MAC-адресов, не производя более никаких действий. В отличие от VLAN на Catalyst, в Bridge Domain мапятся не порты целиком, а L2 сабинтерфейсы, называемые Ethernet Flow Point (EFP). К каждому Bridge Domain может быть отнесено несколько VLAN’ов. В свою очередь один и тот же тег VLAN может встречаться в разных Bridge Domain. Однако эти VLAN’ы хоть и имеют одинаковый тег, относясь к разным Bridge Domain, не смогут соединяться в данном коммутаторе. EFP конфигурируются на физическом интерфейсе и определяют к какому Bridge Domain отнести приходящие на порт пакеты.

Порядок обработки пакетов приходящих на порт строится следующим образом:

- на порт принимается тегированный или нетегированный пакет.

- в зависимости от  тега (или его отсутствия) пакет обрабатывается соответствующим EFP. В процессе обработки пакета на интерфейсе тег может быть либо оставлен у пакета, либо отброшен, а сам пакет попадает в прописанный для этого EFP Bridge Domain

- в соответствии с таблицей MAC-адресов, пакет направляется к исходящему порту, где, в зависимости от bridge-domain, он попадает на обработку соответствующему EFP. Этот EFP присваивает пакету новый тег, если старый был отброшен, или отправляется без изменений, со старым тегом, или нетегированный.

Обратите внимание, что даже нетегированные пакеты должны быть обработаны EFP, чтобы попасть в нужный Bridge Domain и быть переданными далее.

 

evc2

В результате мы имеем возможность управлять всеми соединениями в L2 сети, вплоть до построения виртуальных каналов от одного порта к другому, и использовать одинаковые dot1q теги повторно в разных частях L2 сети не разделяя эти сети . Таким образом VLAN перестает привязан к конкретному dot1q тегу, и может быть протянут через несколько сетей с повторяющимися тегами.

Теперь, прежде чем переходить к конфигурированию EVC, давайте уточним терминологию.

Bridge domain – определяет широковещательный сегмент внутри одного устройства и имеет значение только внутри этого устройтва. По сути это виртуальный коммутатор, на который подключаются определенные VLAN’ы с различных портов. Сам Bridge Domain только передает пакеты в соответствии с таблицей MAC-адресов, не производя более никаких действий. Причем таблица эта одна для одного конкретного bridge domain, в отличие от традиционного подхода, когда таблицы были отдельными для каждого VLAN.  Какие VLAN’ы будут подключены, определятся в настройках каждого порта отдельно.

Ethernet Flow Point (EFP) – это L2-сабинтерфейс  на физическом порту, которая определяет в какой Bridge Domain должен попасть пакет, должен ли быть удален тег и т.п. К EFP могут быть также применены политики, списки доступа, установлен L2 туннель. Каждый отдельный EFP может быть включен или выключен как интерфейс, а кроме предоставить статистическую информацию.

Encapsulation (Flexible Service Mapping) – задает критерии для отнесения тегированных пакетов к конкретному EFP.

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

Device#configure terminal

В некоторых старых версиях софта требуется, прежде всего, создать Bridge Domain (причем предупреждения об этом нет)

Device(config)#bridge-domain 5

В режиме конфигурирования  bridge-domain ничего особо и нет, поэтому переходим в режим конфигурирования интерфейса.

Device(config)#interface gigabitethernet0/1

Теперь нам нужно создать EFP. Для этого вводим команду

Device(config-if)#service instance 1 ethernet

и входим в режим конфигурирования EFP. Теперь нам нужно определить, какие теги будут относиться к данному EFP. Пишем:

Device(config-if-srv)#encapsulation dot1q 20,30-40

Здесь мы определили, что к Service instance 1 будут относиться пакеты с тегом 20 и с 30-го по 40-й. Следующим действием мы должны определить, что нам делать с тегами. Мы можем их не трогать, а можем вырезать. Чтобы вырезать, нужно ввести следующую команду:

Device(config-if-srv)#rewrite ingress tag pop 1 symmetric

В результате этой команды все теги на входящих пакетах будут вырезаны и после этого пакеты будут переданы в соответствующий Bridge Domain, и наоборот пакетам из соответствующего Bridge Domain будет присвоен тег перед отправкой в линию.

Теперь осталось нам определить этот самый соответствующий Bridge Domain.

Для этого используется команда bridge-domain. Возможны следующие варианты:

— указать один конкретный bridge-domain

— указать, что bridge-domain должен быть равен тегу

В первом случае, так как мы определили несколько тегов и задали команду для их перезаписи, все пакеты свалятся в один bridge-domain. В таких случаях, чтобы их не перепутать, команду rewrite лучше не использовать.

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

Можно использовать вариант, когда для каждого тега создается отдельный EFP, но в этом случае приходится очень много конфигурировать.

В нашем случае, скорее всего, будет использована команда

Device(config-if-srv)#bridge-domain from-encapsulation

Здесь пакеты из различных VLAN не перепутаются, поэтому можно использовать и rewrite. Итак, что у нас получилось в целом.

interface GigabitEthernet0/1
service instance 3 ethernet
encapsulation dot1q 20,30-40
rewrite ingress tag pop 1 symmetric
bridge-domain from encapsulation

Если мы сконфигурируем все порты в такой же манере, все будет работать хорошо, но никаких преимуществ технологии EVC мы, конечно же, не увидим. Поэтому попробуем представить, что наш коммутатор (или маршрутизатор) разделяет зоны с одинаковыми наборами VLAN, и поменяем теги. Например так:

interface GigabitEthernet0/2
service instance 20 ethernet
encapsulation dot1q 20
rewrite ingress tag pop 1 symmetric
bridge-domain 30

Итак, что у нас получилось? Мы создали сабинтерфейс с номером 20 (этот номер ни к чему не относится, так же как и номер сабинтерфейса в маршрутизаторах и может быть любым), сказали, что этот сабинтерфейс работает с тегом 20 и подключили его к виртуальному коммутатору bridge domain 30. В результате пакеты приходящие на интерфейс GigabitEthernet0/1 с тегом 30 будут выходить из интерфейса GigabitEthernet0/2 с тегом 20 и наоборот.

Возможен также вариант, когда VLAN нужно прокинуть между разными устройствами, находящимися в разных частях сети провайдера. Тогда вместо команды bridge-domain нужно использовать xconnect. Например так:

 

Device 1
Interface loopback0
Ip address 1.1.1.1 255.255.255.255

— output omitted —

Interface gigabitethernet0/0
service instance 20 ethernet
encapsulation dot1q 20
rewrite ingress tag pop 1 symmetric
xconnect 2.2.2.2 20 encapsulation mpls

И второе устройство

Device 2
interface loopback0
Ip address 2.2.2.2 255.255.255.255

— Output omitted —

Interface gigabitethernet0/0
service instance 20 ethernet
encapsulation dot1q 30
rewrite ingress tag pop 1 symmetric
xconnect 1.1.1.1 20 encapsulation mpls

 

Ну и конечно же, статья была бы неполна, если я не расскажу, как настраивать L3 интерфейсы для маршрутизации пакетов проходящих через устройство. Основной момент здесь в следующем: так как основной элемент системы это Bridge Domain, то и привязка к SVI происходит именно через него. Что это значит? Это значит, что какой бы тег не был у приходящего пакета, SVI, которым будет обработан пакет, будет определен именно по номеру Bridge Domain сконфигурированного на EFP, а не по тегу.

Вспомним наш первый пример. У нас приходит на порт пакет с тегом 30, тег обрезается, пакет далее попадает в Bridge Domain  30, затем передается на исходящий интерфейс, там ему присваивается тег 20 и пакет передается через интерфейс. Для пакетов проходящих в обратном направлении все эти операции будут происходить в обратном направлении. Данный пример показывает, что если бы мы ориентировались на тег, то приходя с разных направлений, пакеты в одном и том же виртуальном канале попадали бы на разные SVI. Поэтому неизбежна привязка именно к каналу, а не к параметрам пакета. Ну а канал, в свою очередь, однозначно определяется номером Bridge Domain.

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

Конфигурирование SVI для Bridge Domain, в общем, ничем не отличается от конфигурирования SVI для обычных VLAN, но в зависимости от устройства он может иметь разные названия. Приведу пример для ASR903. Там интерфейс называется BDI – Bridge Domain Interface. В других устройствах это может быть просто Inteface Vlan.

Interface BDI30
ip address 10.10.10.1 255.255.255.0

Вот и все. Еще раз обращаю внимание, что номер интерфейса это не тег в пакете и не номер EFP – это номер Bridge Domain который сконфигурирован на EFP.

Итого: Ethernet Virtual Circuits – это технология, которая позволяет гибко управлять тегированным трафиком и обходить ограничение накладываемое стандартом 802.1q на количество VLAN в одном сегменте. Поскольку данная технология чаще всего востребована лишь в очень больших сетях, то и поддерживается она в основном оборудованием соответствующего класса. Это маршрутизаторы серии ASR, серия маршрутизаторов 7600 и другие.


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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me