Selective Q-in-Q с профилями и без

Продолжаем серию заметок о Q-in-Q. В прошлый раз коснулись темы Selective Q-in-Q на примере модели DGS-3420-28SC. Сегодня попробуем разобраться с этим еще раз. :)

Описанная в прошлой заметке задача очень проста, потому давайте усложним ее. Представим, что нам надо завернуть во внешний тег (SP-VLAN) не выборочные VLAN, а целый диапазон.

Итак, задача: завернуть непрерывный диапазон VLAN с уровня доступа в одну общую VLAN на уровне агрегации, при этом протащив управляющую VLAN транзитом.

Схема сети:

На доступе используется коммутатор DES-3200-28. В портах с 1 по 24-й находятся клиенты, каждый в своей VLAN. Номера VLAN начинаются с 401 и в дальнейшем соответствуют номеру порта, т.е. продолжаются до 424.

На агрегации как и раньше используется коммутатор DGS-3420-28SC. Управляющий интерфейс также находится в VLAN 7. В качестве SP-VLAN используется VLAN с ID 101.

Как обычно, не забудем поменять outer_tpid, чтобы не потерять управление коммутатором:
config qinq ports 1-28 outer_tpid 0x8100

Теперь можно безопасно включить Q-in-Q:
enable qinq

Разрешим кадры большого размера:
enable jumbo_frame

Создадим VLAN, которая будет использоваться в качестве SP-VLAN:
create vlan 101 tag 101
config vlan 101 add tagged 20,28

Дальше у нас есть выбор - использовать профили или нет. Профили поддерживаются далеко не всеми моделями (DGS-3420-28SC поддерживает). Рассмотрим оба варианта.

Вариант с использованием профилей

Создадим профиль для Q-in-Q с номером 1:
create vlan_translation_profile 1

Добавим в профиль правило, согласно которому внешние VID в диапазоне 401-424 относятся к SP-VLAN 101
config vlan_translation_profile 1 add rule_id add svid 101 classify outer_vid 401-424

На самом деле профили позволяются классифицировать фреймы по многим признакам (source_mac, destination_mac, source_ipv4, destination_ipv4, outer_vid, 802.1p, ip_protocol, l4_src_port, l4_dest_port), но в данном случае мы будем классифицировать их по outer_vid.

Добавим правило* для трансляции управляющей VLAN в VLAN с тем же самым ID, т.е. без добавления внешнего тега SP-VLAN:
config vlan_translation_profile 1 add rule_id replace svid 7 classify outer_vid 7

Применим профиль для порта №20:
config qinq ports 20 add vlan_translation_profile 1

Сменим порту №20 в роль на UNI:
config qinq ports 20 role uni missdrop enable

Справочная информация из презентации D-Link:

• Параметр «missdrop enable» означает, что добавление внешнего тега (SP-VLAN) будет осуществляться только согласно правилам vlan_translation.
• Параметр «missdrop disable» означает, что добавление внешнего тега (SP-VLAN) будет осуществляться согласно правилам vlan_translation, а к трафику не попавшему под правила vlan_translation будет добавлятся внешний тег (SP-VLAN) равный PVID порта, т.е. SP-VID = PVID.

* В реальных условиях мне не доводилось протаскивать управляющую VLAN через UNI порт в случае использования профилей, но теоретически это должно работать. :)

Вариант без использования профилей (подходит и для других моделей D-Link)

Создадим правило трансляции для диапазона VLAN:
create vlan_translation ports 20 add cvid 401-424 svid 101

Добавим правило для трансляции управляющей VLAN без добавления внешнего тега:
create vlan_translation ports 20 replace outer_vid 7 svid 7

Изменим роль порту №20 на UNI:
config qinq ports 20 role uni missdrop enable

Как видно, основное отличие от прошлого примера состоит в использовании диапазона вместо единичного номера VLAN. Ну и в этот раз мы включили missdrop enable, чтобы ограничить применение Q-in-Q только для явно заданных правил трансляции.

Проверка DGS-3000-28SC предмет хеш-коллизий

Коллизии MAC-адресов до сих пор больной вопрос в сетях с плохим дизайном. Вслед за DGS-3420-28SC пришел черед испытаний DGS-3000-28SC.

Методика тестирования та же самая, что и с предыдущем посте на эту тему. Заливаем 7466 MAC-адреса с Brocade SX-800, выступающего в качестве поставщика реальных MAC'ов, и смотрим на результат.

Внимательный читатель заметит, что MAC-адресов на 2 больше, чем мы залили. Объясняется это просто - в вилане присутствует MAC моей сетевой карты и самого коммутатора. В прошлом тесте я был подключен через консоль, а интерфейс коммутатора был в отдельной вилан, потому количество адресов в выводе совпадало с тем, что было отправлено на коммутатор.

Таким образом, DGS-3000-28SC успешно проходит проверку на хеш-коллизии.

Группа D-Link Ru в Telegram

Про мессенджер Telegram слышали, наверное, все. И если простить ему привязку к телефонному номеру, то пользоваться им определенно можно. Групповые чаты достаточно удобны и используются многими сообществами, в том числе сетевыми инженерами.

Однако, после того, как уютненьком Nag.Ru начала преобладать "политота", все большую популярность стали набирать тематические сообщества со специфичной технической направленностью. И в самом деле, как можно обсуждать что-то важное, когда в интернете кто-то не прав? Так и появились Pro Telecom, Я люблю АС "Ревизор" и другие интересные группы.

Пожалуй, пришло время сделать группу для обсуждения оборудования D-Link Ru. Такая попытка уже предпринималась однажды, но успехом не увенчалась. Оно и понятно, ведь Jabber - день позавчерашний. Посмотрим, что получится в случае с Telegram.

p.s. Спамить группой не хочу. Интересно посмотреть как она будет наполняться сама по себе.

DGS-3420-28SC Selective Q-in-Q

Тема сегодняшней заметки Selective Q-in-Q на DGS-3420-28SC. Модель коммутатора в данном случае не принципиальна, просто такой коммутатор есть под рукой и потому на стенде используем именно его.

Без лишних прелюдий обозначим задачу: завернуть несколько vlan с уровня доступа в одну общую vlan* на уровне агрегации, при этом протащив управляющую vlan транзитом.

Посмотрим на картинку:

На доступе у нас используется коммутатор DES-3200-28. В 1-м порту подключен клиент в vlan 444, а во втором - в vlan 555. Управляющий интерфейс коммутатора находится в vlan 7.

На агрегации используется коммутатор DGS-3420-28SC. Управляющий интерфейс также находится в vlan 7. На коммутаторе нет vlan 444 и 555, а вместо них есть общая vlan 101.

Таким образом, vlan 444 и 555, приходящие с уровня доступа, инкапсулируются в vlan 101 и отдаются в сеть через порт №28 коммутатора DGS-3420-28SC. И, наоборот, приходящий с сети трафик в vlan 101 разворачивается в vlan 444 и 555 соответственно и уходит через порт №20. Напомню, что Q-in-Q - это "двойное тегирование", т.е. за внешним тегом 101 идет внутренний тег (444 или 555) и коммутатор всегда может разобраться куда именно ему надо перенаправить трафик при "снятии" внешней метки.

Ладно, оставим теорию (о ней в другой раз) и перейдем непосредственно к настройкам.

ВНИМАНИЕ! При включении Q-in-Q все порты будут настроены как NNI и трафик от них пойдет с внешней меткой 0x88a8. Если вы этого не ожидали и не были к этому готовы, то доступ к коммутатору будет потерян. Поэтому, если на стыках с данным коммутатором вы используете "обычные" vlan 802.1q, то выполните следующую команду:

config qinq ports 1-28 outer_tpid 0x8100

После этого можно включить Q-in-Q без опасений потерять доступ:

enable qinq

Разрешим кадры большого размера:

enable jumbo_frame

Создадим "внешнюю" vlan и добавим ее на оба порта. Тут ничего сложного, все стандартно:

create vlan 101 tag 101
config vlan 101 add tagged 20,28

Создадим трансляции для каждой vlan уровня доступа. Здесь мы говорим коммутатору, какую клиентскую (cvid) vlan нужно поместить в какую провайдерскую (svid) vlan. В нашем примере мы помещаем vlan 444 и 555 в vlan 101:

create vlan_translation ports 20 add cvid 444 svid 101
create vlan_translation ports 20 add cvid 555 svid 101

Теперь нам надо позаботиться о том, чтобы не потерять управление коммутатором доступа. Мы предполагаем, что vlan 7 уже создана на обоих коммутаторах и добавлена на порты 20 и 28 коммутатора DGS-3420-28SC. Нам остается всего лишь сказать коммутатору, что клиентская vlan 7 не будет никуда заворачиваться, а будет "транслироваться" в vlan провайдера с номером... 7:

create vlan_translation ports 20 replace outer_vid 7 svid 7

Ну и, наконец, сменим роль порту №20 на UNI:

config qinq ports 20 role uni

После этого схема, изображенная на рисунке, станет рабочей.

P.S. Обратите внимание, что коммутатор доступа вообще никак не настраивается специально под Q-in-Q.

*Часто о VLAN говорят в мужском роде. Я же использую женский, т.к. VLAN - это "Виртуальная LAN". LAN - это сеть, "локалка", т.е. "она".

Тестирование DGS-3420-28SC на тему "конфликт hash"

Довольно долго у меня не было ни возможности ни повода для новой заметки. Теперь он появился). Назрела необходимость прогнать через DGS-3420-28SC большое число MAC-адресов и стало интересно, как железка справится с данной задачей. Отдельные посты на специализированных форумах заставили задуматься о проблеме hash и вопрос тестирования назрел сам собой.

Итак, в нашем тесте мы не будем флудить коммутатор сгенерированными MAC-адресами, мы поступим хитрее - затопим его реальными MAC'ами, взятыми с реальной железки. Получим от коллег по отрасли список MAC-адресов ("донором" выступил Brocade SX-800) и удалим дубликаты. В остатке получается список из 7466 уникальных адресов. Затем установим Ostinato и напишем скрипт для генерации трафика на Python. Этот скрипт использует simple-ostinato. В принципе, изначально я собирался использовать Scapy, но под Windows запустить его мне не так и удалось из-за различных зависимостей.

Когда все готово, подключаемся к коммутатору и заливаем туда все адреса, не забыв предварительно увеличить fdb aging_time. Минут через 10 проверяем результат.

Я просто оставлю здесь картинку и никак не буду ее комментировать. :)