Разбор QinQ на Juniper MX и изящный бриджинг

Posted: 2017-10-11 in IT, Networks
Метки:,

Всем привет !
Я очень давно хотел поразбираться с двойным тегированием на домашнем роутере Juniper MX-серий, и вот этот момент настал. В отличие от EX, где настройки QinQ относительно немногочисленны, МХ-серия обладает просто огромным количеством настроек свитчинга, а поддержка виртуализованных инстансов и целой пачки технологий позволяет городить очень сложные конфигурации.
Задача этой заметки — разобрать средствами самого МХ-80 дважды тегированный траффик, пришедший в общем аплинке вместе с другими одиночно тегированными вланами и нетегированным траффиком, и после снятия верхнего тега сбриджить эти вланы с уже существующими вланами на МХ. Не забыть про native само собой. Если интересно — просим под кат.

Представим себе такую ситуацию: у нас есть физлинк к вышележащему провайдеру, и там есть какие-то свои вланы для инета, пиринга, пачечка вланов для всяких юриков. И вот там у вас появляется ещё один влан, в котором под неким сервисным тегом приходят вланы другой части нашей же сети. И этот верхний тег надо снять, а вланы сбриджить с теми вланами, что уже есть на МХ. На старых цисках и прочей классике это решалось диким способом — выделялись два отдельных физических порта, соединялись патчкордом, после чего один порт настраивался как обычный транк с нашими вланами, а второй — как dot1q-tunnel с vlan-id, равным сервисному от аплинка. Либо все эти вланы (и QinQ, и наши) прокидывались до отдельной небольшой железки типа 3750, где и совершалось непотребство с помощью QinQ-Loop. Такое встречается часто до сих пор, и массово применяется при разборе QinQ на дешевом железе.
Любуемся на схемку:

разбор QinQ на Juniper MX БЕЗ QinQ-Loop

Самый простой вариант — получить отдельный QinQ порт — оказался неприемлим тупо в силу отсутствия дополнительных оптических волокон в трассе, да и стоил бы не только лишних денег, но и дополнительных усилий по настройке, причём сразу с двух сторон, что требует согласования работ. Перевести же текущий транковый порт аплинка со стороны главной сети в dot1q-tunnel не выйдет — там ходит траффик других сетей, ничуть не менее важных (на картинке — VLAN 17 и 115).

Я же хотел разобраться, можно ли это сделать на джунипере МХ-80, не занимая дополнительные порты и желательно — не создавая излишне переусложненной конфигурации. Сложность в том, что на МХ есть сразу несколько разных опций, имеющих отношение к QinQ, и потребовалось прочитать изрядно документации.
Первое — документация на оф-сайте. Но она не особо детальная, без примеров и описывает несколько иной сценарий.

Вторая заметка — http://blog.sbolshakov.ru/10-3-q-in-q-config/ тоже затрагивает более классические случаи.

Третья заметка — http://security-corp.org/administration/network_technologies/37908-bridge-domains-and-virtual-switch-in-junos.html оказалась самой толковой, там разъяснены многие важные тонкости работы свитчинга в JunOS, и именно она позволила мне лучше понять и решить сию задачу максимально простой, понятной и читабельной конфигурацией.

При курении всех этих мануалов может легко потянуть на тёмную сторону силы ко всяким input-vlan-mapping-ам, виртуальным свитчам, ручному бриджеванию, L2-фильтрам и прочим силам зла.

Решение оказалось простым — суть в том, каким способом сконфигурировать юнит типа vlan-bridge. Если просто указать encapsulation vlan-bridge; + vlan-id 587; (Тип юнита «Service Provider» из третьей заметки) , то такой юнит надо указывать в секции bridge-domain, а при отказе от указания vlan-id в бридже и ручном маппинге есть все шансы застрелиться в процессе настройки даже без всякого QinQ. Если же использовать тип «Enterprise» (указать в юните family bridge), то после непродолжительного чтения манов, подсказок cli и экспериментов на тестовом стенде можно получить вот такую приятную конфигурацию Trunk-интерфейса на нашем Juniper MX:

# edit interfaces
xe-1/1/2 {
    description "10G-MAIN to Uplink-ISP";
    flexible-vlan-tagging;
    encapsulation flexible-ethernet-services;

    native-vlan-id 115;

    unit 115 {
        encapsulation vlan-bridge;
        vlan-id 115;
    }

    unit 17 {
        encapsulation vlan-bridge;
        vlan-id 17;
    }

    unit 587 {
        description "Strip QinQ-SVID-587 and BRIDGE CVIDs to my vlans !";
        encapsulation vlan-bridge;
        vlan-id 587;
        native-inner-vlan-id 1;
        family bridge {
            interface-mode trunk;
            inner-vlan-id-list [ 1-4 55 82 ];
        }
    }
}

То есть у нас в линке будет гремучая смесь разных видов траффика — нативный вообще нетегированный влан 115, с которого этот линк и начинался; одиночно тегированный влан 17 для L2-клиента; и собственно QinQ-влан 587, внутри которого будут упакованы наши вланы 1-4, а также 55 и 82. Что прекрасно — при такой настройке нам не придётся вообще ничего делать в секции bridge-domain. Посмотрим её:

# edit bridge-domains
VLAN1 {
    description "Mgmt VLAN";
    domain-type bridge;
    vlan-id 1;
    interface ae0.1;
    routing-interface irb.1;
}
VLAN2 {
    description "Servers VLAN;";
    domain-type bridge;
    vlan-id 2;
    interface ae0.2;
    routing-interface irb.2;
}
...
VLAN17 {
    description "L2-Client";
    domain-type bridge;
    vlan-id 17;
    interface xe-1/1/2.17;
    interface ae0.17;
}
VLAN115 {
    description "Uplink-ISP-Peering";
    domain-type bridge;
    vlan-id 115;
    interface xe-1/1/2.115;
    routing-interface irb.115;
}

Обратите внимание — строки interface xe-1/1/2.xx прописаны только для «Service-Provider» бриджей, тогда как для 587-го юнита нет ни строчек interface, ни даже самого брижд-домена 587 — поскольку мы внешную метку снимаем прямо на интерфейсе, то и отдельный бридж-домен нам не понадобился, что очень удобно.

Каждая строчка конфигурации юнита тут очень важна, поэтому рассмотрю подробнее:

unit 587 {   # Номер юнита может быть любым, но лучше - равным внешнему тегу SVID
        description "Описания помогут вспомнить через год, что это за фигня";
        encapsulation vlan-bridge;   # тип инкапсуляции такой же !
        vlan-id 587;    # внешний тег, он будет навешен на исходящий/снят с входящего.
        native-inner-vlan-id 1; # нетегированный траффик в туннеле отнести к 1-му влану
         # Без native-inner-vlan-id нетегированный траффик не будет принят из туннеля
        family bridge { 
            interface-mode trunk;  # собственно режим QinQ
            inner-vlan-id-list [ 1-4 55 82 ];   # какие вланы бриджить по внутренним vlan-id
        }
    }

В итоге получилось очень просто и понятно. Вообще тема свитчинга на Juniper MX-серий необычайно обширна, там есть ещё масса всего интересного. Сегодня мы избавились от уродского QinQ-Loop, в следующей заметке ещё может чего расскажу интересного.

Всем счастья.

Реклама
- комментарии
  1. Не пройдет.Смотрим,влан на юзера,есно QinQ, динамические профили создают эти вланы при авторизации по дшсп запросу.

  2. Виктор:

    А если такая же конструкция, но с QFX3500? 🙂
    т.е. имеем qfx3500, в него приходят-уходят вланы клиентов, также имеем в аплинке несколько вланов, и туда же хотелось подать qinq влан, в который собрать некоторые вланы летающие по qfx… других железок нету.. только qfx, так как в мануалах CE — PE — PE — CE — не получится, нету 2х коммутаторов..

  3. В теории изящней будет, если влан на пользователя ака qnq. Svlanы будут на обеих брасах кто первый затерменировал пациента тот и папа, аля пппое. С опт82 мне кажеться изящества не получиться. Но это теория, практика пока в процессе.

  4. Amin:

    1). В моём примере сложный бриджинг используется не для vlan-per-user, а для отказа от петлевого интерфейса при разборе ку-н-ку туннеля на Juniper-MX.

    2). С QFX дел не имел, но если там есть такие же гибко конфигурируемые бридж-домены, как на MX — то скорее всего, конфиг такой применить можно. Если же там работа с двойным тегированием как на EX — то вряд-ли, придётся придумывать что-то другое.