Cisco EVC

Как известно, сети второго уровня делят на виртуальные сети VLAN-ы. Для этого используется протокол 802.1q. Поддерживается 4096 VLAN-ов на одном устройстве, в одном широковещательном домене. Однако для некоторых сетей такого количества не хватает. Одно из решений проблемы - разделение такой сети на сегменты, которые соединены между собой через L3-устройства. В каждом сегменте теперь может существовать до 4096 VLAN-ов, и номера VLAN в разных сегментах могут совпадать.
Трафик между сегментами ходит теперь используя маршрутизацию. Однако маршрутизация на сегодняшний день медленнее коммутации. Здесь поможет EVC. Также через EVC возможно подключить два компьютера к разным интерфейсам маршрутизатора так, чтобы оба компьютера были в одном широковещательном домене.
Существует такая технология виртуальных сетей как Ethernet Virtual Connections (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 и быть переданными далее.

Итак:

EVC (Ethernet Virtual Connections) - технология виртуальных соединений, которая позволяет организовать внутри одного физического коммутатора несколько виртуальных коммутаторов (широковещательных доменов). Домен EVC состоит из bridge-domain и подключенными к нему EFP.

Bridge domain – это виртуальный коммутатор, который передаёт кадры в соответствии с mac таблицей. У каждого bridge-domain-а существует экземпляр таблицы mac-адресов. Отдельных настроек для bridge-domain-а в конфиге Cisco нет, кроме номера в настройке Service instance, хотя на старых IOS bridge-domain необходимо было

Ethernet Flow Point (EFP) - это логический интерфейс на котором настроены правила пересылки пакетов в bridge-domain. В Cisco он называется Service instance. Внутри service instance настраиваются правила,  например (encapsulation, rewrite, привязка к bridge-domain и т.д.). К одному bridge-domain можно подключить сразу несколько EFP на одном физическом интерфейсе.

Encapsulation (Flexible Service Mapping) – этот параметр в настройках Service instance задает правила выбора пакетов. Например настройка encapsulation dot1q 351 говорит что будут обработаны только кадры с тегом равным 351 (VLAN 351).

Настройка

Простая настройка EVC:

interface GigabitEthernet0/0/2
 no ip address
 negotiation auto
 service instance 10 ethernet
  encapsulation dot1q 762
  bridge-domain 351

На физическом интерфейсе настраивается логический интерфейс Service instance, внутри которого указывается encapsulation dot1q 762 и принадлежность к bridge-domain 351. То есть пакеты с тегом 762, приходящие на физический порт GigabitEthernet0/0/2, будут попадать в Bridge domain 351.
На физическом порту можно настроить несколько Service instance, которые могут принадлежать как к одному и тому же Bridge domain, так и к разным.
В encapsulation можно указать несколько тэгов, а также диапазон, 762, 315 и с 700 по 722.
Если нужно принимать не тэгированный трафик, то в encapsulation указываем untagged:

interface GigabitEthernet0/0/2
 no ip address
 negotiation auto
 service instance 10 ethernet
  encapsulation dot1q 762
  bridge-domain 351
 service instance 20 ethernet
  encapsulation dot1q 315,762,700-722
  bridge-domain 300
 service instance 40 ethernet
  encapsulation untagged
  bridge-domain 400

К плюсам технологии EVC относится прежде всего гибкость, позволяющая направлять кадры с разных vlan (или из одного vlan-a) в нужный нам bridge-domain. Делается это при помои команды rewrite:

service instance 20 ethernet
  encapsulation dot1q 315
  rewrite ingress tag pop 1 symmetric
  bridge-domain 300

В данном примере со всех входящих кадров с тэгом 315 будет сниматься перед отправкой в bridge-domain 300 и наоборот, всем исходящим кадрам от bridge-domain 300 будет добавлен тэг 315.
Что будет происходить в случае следующей записи?

 service instance 20 ethernet
  encapsulation dot1q 315,762,700-722
  rewrite ingress tag pop 1 symmetric
  bridge-domain 300

В данном случае все тэги будут вырезаны и все кадры попадут в bridge-domain 300. Чтобы не перемешать все кадры, в данном случае команду rewrite лучше не использовать.
Тогда возможны два варианта:

• настроить так чтобы каждому bridge-domain соответствовал бы свой EVP (Service instance). Но тут придется много настраивать руками.
• применить команду, что каждый bridge-domain соответствует тэгу:

 service instance 20 ethernet
  encapsulation dot1q 315,762,700-722
  rewrite ingress tag pop 1 symmetric
  bridge-domain from encapsulation

L3 интерфейсы. Маршрутизация. 

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

 service instance 20 ethernet
  encapsulation dot1q 315
  rewrite ingress tag pop 1 symmetric
  bridge-domain 300

Для маршрутизации пакетов с них обязательно нужно снять метки. Так что команда rewrite на EVC (Service instance) в данном случае обязательна.
Конфигурирование SVI для bridge-domain не отличается от конфигурирования SVI для vlan.

interface BDI300
 ip address 10.0.0.1 255.255.255.0

QoS для EVC

На bridge-domain интерфейсе можно настроить QoS только для ВХОДЯЩЕГО трафика. То есть "разметить" трафик на interface BDI можно, а вот приоритизировать исходящий трафик не удастся.

interface BDI760
 ip address 10.10.0.15 255.255.255.254
 service-policy input QoS_in