L2 Услуга EPL: Ethernet Private Line

Это урок-звезда всего пути. EPL сбивает с толку почти каждого новичка одним вопросом: «а где тут IP-адреса?!». Правильный ответ — их тут и не должно быть. Сейчас разберём, почему, и научимся смотреть то, что тут действительно важно — MAC-адреса. Медленно, по полочкам, с большой наглядной схемой.

Что под капотом этой услуги

EPL — это название на прайс-листе. Внутри сети оператора её обычно везёт pseudowire поверх MPLS: «виртуальный провод» между двумя портами, построенный на метках. Знать эту начинку для сдачи услуги не обязательно, но без неё непонятно, почему часть вопросов клиента решается за минуты, а часть требует работ по всей магистрали. Если хочется понять механику — сходи туда после этого урока, а не вместо него.

Заявка из очереди

«Заявка #50122. Клиент „Ромашка“: между головным офисом (Москва) и резервным ЦОД (Новосибирск) заказан канал L2 100 Мбит/с (услуга EPL). Требование клиента: оба сегмента — в одной подсети, трафик шифруем сами. Организовать канал, сдать с протоколом измерений».

Первая реакция новичка: «одна подсеть на два города? так не бывает». Бывает — и заказывают это постоянно. К концу урока ты будешь понимать, зачем клиенту такой канал, почему в нём нет ни одного IP-адреса оператора, как проверить его по MAC-таблицам и что за «протокол измерений» требуется при сдаче.

Что узнаешь — после урока ты сможешь
Вспомни из прошлых уроков

Урок 2 — сегодня главный: кадр (L2, MAC-адреса) — внешний конверт, пакет (L3, IP) — внутренний; коммутатор читает только MAC и учит таблицу «MAC ↔ порт»; broadcast не выходит за пределы L2-сети; VLAN — изолированные «дворы» внутри свитча, и метка 802.1Q в кадре говорит, чей это двор. Если это подзабылось — вернись и освежи, иначе EPL будет казаться магией.

1. Что такое EPL простыми словами

EPL = Ethernet Private Line, «частная линия Ethernet». Это услуга, в которой оператор соединяет две точки клиента (например, два офиса в разных городах) прозрачным каналом L2. «Прозрачный» — значит оператор не вмешивается в то, что внутри: он просто берёт Ethernet-кадры, которые клиент отправил с одной стороны, и в неизменном виде выдаёт с другой.

Ключевые свойства EPL:

Точка-точка (point-to-point)
Ровно две стороны: офис A ↔ офис B. Никого лишнего в этом канале нет.
Уровень L2 (Ethernet), не L3
Оператор возит кадры по MAC-адресам, а не пакеты по IP. Для клиента это выглядит как один большой коммутатор между офисами.
Полная прозрачность
Что клиент отправил (любые VLAN, любые протоколы) — то и приедет. Оператор не разбирает содержимое.
Выделенная полоса
Например, 100 Мбит/с только для этого клиента — не делится ни с кем.
Аналогия №1

EPL = один очень длинный патч-корд между офисами

Представь, что ты взял сетевой кабель и протянул его из офиса A в Москве прямо в офис B в Новосибирске — воткнул одним концом в свитч там, другим тут. Для твоих устройств это одна и та же локальная сеть, будто они в соседних комнатах. EPL — ровно это, только «кабель» реализован через сеть оператора. Внутри этого кабеля оператору незачем иметь IP — кабель не имеет адреса, он просто провод.

Зачем бизнес покупает «провод», если есть интернет и VPN

Вопрос, который стоит задать до конфигов: у клиента есть интернет в обоих офисах — почему бы не соединить их VPN-туннелем? Зачем платить за отдельный L2-канал? Реальные причины из заявок:

Потребность клиентаПочему именно L2-канал
Репликация СХД / резервный ЦОДСистемы хранения и кластеры часто требуют «один L2-сегмент» между площадками: миграция виртуалок и отказоустойчивость работают внутри одной подсети
Собственное шифрованиеБанки и госструктуры шифруют трафик своими устройствами. Им нужен «чистый провод», в который оператор не заглядывает — EPL идеальна: она и не умеет заглядывать
Не-IP протоколыСтарые АТС, промышленные протоколы, чужие туннели — по L2-каналу едет что угодно, а не только IP
Гарантированная полоса и задержкаVPN через интернет — «как повезёт»; EPL — выделенные мегабиты с SLA, критично для синхронной репликации
Простота на стороне клиентаНикакой маршрутизации настраивать не надо: воткнул свитч — работает

Теперь требование из заявки #50122 «оба сегмента в одной подсети, шифруем сами» читается легко: это классический резервный ЦОД — клиенту нужен прозрачный L2 под репликацию, с шифрованием его собственными средствами.

2. Почему в EPL нет IP-адресов оператора — полный разбор

Это главный вопрос урока. Разложим на три «почему», чтобы стало кристально ясно.

Причина 1: EPL работает на L2, а IP — это L3

Вспомним «этажи» сети (модель OSI). IP-адрес живёт на уровне L3 (сетевом). EPL же целиком работает на уровне L2 (канальном), где адресация идёт по MAC. Оператор в EPL не поднимается до L3 — он читает у кадра только L2-заголовок (MAC-адреса) и везёт кадр дальше. До IP-заголовка внутри кадра ему нет никакого дела — он его даже не смотрит.

MAC назначения
6 байт · читает оператор
MAC источника
6 байт · читает оператор
Тип/VLAN
802.1Q
Данные (внутри — IP-пакет клиента)
оператор НЕ смотрит
FCS
контроль

Ethernet-кадр глазами оператора: он работает с фиолетовыми MAC-полями. IP-адреса лежат внутри «Данных» — и это личное дело клиента.

Причина 2: IP-адресация — это забота клиента, и она сквозная

Раз оператор отдаёт кадры в неизменном виде, то оба офиса клиента оказываются в одной L2-сети. А значит, устройства обоих офисов сидят в одной IP-подсети — например, 10.10.10.0/24: офис A — адреса из начала блока, офис B — из конца, но подсеть общая. IP тут есть — но это IP клиента, не оператора. Оператор к этой адресации вообще не прикасается.

Главный вывод

В EPL у оператора нет IP на этом сервисе, потому что оператору незачем участвовать в L3. Он — «провод». IP-адреса, которые ты увидишь в трафике EPL, — это адреса клиента с обоих концов, из одной подсети. Если тебя спрашивают «какой IP на EPL со стороны оператора» — правильный ответ: «никакого, это L2-сервис».

Причина 3: так работает технология (pseudowire поверх MPLS)

Технически EPL строится как псевдопровод (pseudowire) — виртуальный L2-туннель через магистраль оператора (обычно MPLS). Кадр клиента на входном роутере (PE) заворачивается в служебные метки, «телепортируется» через сеть и на выходном PE разворачивается обратно в исходный кадр. Клиентский кадр внутри туннеля не меняется — поэтому и адресация клиента остаётся сквозной, а оператор остаётся на L2.

Забегая в следующий урок

Узнаёшь слово MPLS? Да, это та же магистраль, что повезёт IPVPN в уроке 7. Разница в том, что заворачивают в метки: в EPL — целый Ethernet-кадр клиента (L2), в IPVPN — IP-пакет (L3). Одна магистраль, два типа груза. Поэтому обе услуги часто живут на одних и тех же PE.

3. Разбор схемы: два офиса, одна подсеть

Вот та самая наглядная схема. Клиент «Ромашка» соединил два офиса услугой EPL. Смотри, как это выглядит и где какие адреса.

EPL: для клиента два офиса — как один коммутатор
Офис A (Москва) 💻 ПК-A1 10.10.10.11 MAC …:A1 Офис B (Новосиб) 💻 ПК-B1 10.10.10.22 MAC …:B1 EPL — прозрачный L2-канал оператор возит кадры, IP не трогает Оба офиса — в ОДНОЙ подсети 10.10.10.0/24 это адреса КЛИЕНТА. У оператора на EPL адреса нет вообще.
ПК-A1 и ПК-B1 «думают», что они в одной локальной сети — хотя между ними тысячи километров. Так и задумано.

Проверь понимание на пути одного пинга: ПК-A1 (10.10.10.11) пингует ПК-B1 (10.10.10.22). По маске ПК-A1 решает: «сосед по подсети» → шлёт ARP-запрос (broadcast) → EPL прозрачно доносит broadcast до Новосибирска → ПК-B1 отвечает своим MAC → дальше кадры летают напрямую MAC↔MAC. Ни одного маршрутизатора, ни одного шлюза на пути — всё ровно как в уроке 2, только «провод» длиной в полстраны.

Аналогия №2

EPL = телефонная «прямая линия» без коммутатора

Старая «прямая линия» между двумя кабинетами: снял трубку — сразу другой кабинет, без набора номера, без АТС посередине, которая «знает адреса». Провод просто соединяет две точки. EPL — то же самое для Ethernet: два офиса напрямую, а «АТС» (маршрутизация по IP) тут не нужна.

4. Как правильно смотреть MAC-адреса в EPL

Раз в EPL главные — MAC-адреса, то и диагностика идёт по ним. Вопрос «а куда смотреть?» зависит от того, на чьём оборудовании ты стоишь.

На стороне клиента — show mac address-table

Коммутатор клиента учит MAC-адреса, как обычно (мы это разбирали в теме ARP — свитч запоминает, за каким портом какой MAC). Фокус в том, что MAC-адреса удалённого офиса он видит будто они подключены к локальному порту (тому, что смотрит в EPL). Это и есть доказательство, что EPL — прозрачный L2.

SwitchA# show mac address-table Vlan Mac Address Type Ports 10 0011.2222.00a1 DYNAMIC Gi0/1 ← локальный ПК-A1 (свой порт) 10 0011.2222.00b1 DYNAMIC Gi0/24 ← ПК-B1 из ДРУГОГО города! виден через порт EPL

Видишь? MAC …00b1 — это устройство в Новосибирске, но локальный свитч в Москве считает, что оно «за портом Gi0/24». Потому что Gi0/24 воткнут в EPL, а EPL прозрачно приносит кадры удалённого офиса. Для свитча удалённый офис = «ещё один сосед на проводе».

На стороне оператора — MAC в псевдопроводе

Оператор обычно EPL-сервис делает «port-based» и не изучает клиентские MAC (просто прокидывает кадры). Но при диагностике на PE можно посмотреть, что за MAC-и «пролетают» через сервис, и живёт ли псевдопровод. Команды зависят от вендора, например:

! статус L2-сервиса (псевдопровода) — «поднят ли туннель» PE# show l2vpn service all Service ROMASHKA-EPL: UP AC(Gi0/2) UP PW(peer 10.255.0.9) UP ! MAC-адреса, замеченные в бридж-домене сервиса (если он MAC-learning) PE# show bridge-domain 100 mac-address 0011.2222.00a1 dynamic Gi0/2 ← MAC клиента со стороны офиса A 0011.2222.00b1 dynamic pseudowire ← MAC клиента, пришедший из офиса B
Как читать

Локальные MAC клиента видны «за физическим портом» (AC — Attachment Circuit), а удалённые — «за псевдопроводом» (PW — Pseudowire). Если MAC второго офиса вообще не появляется — трафик оттуда не доходит: проверяй статус PW (должен быть UP) и физику на дальней стороне. Это твой главный чек-лист при «EPL не работает».

Где стоишьЧто смотретьКоманда (пример)
Коммутатор клиентаУчтённые MAC, за каким портом удалённый офисshow mac address-table
PE оператораСтатус L2-сервиса и псевдопроводаshow l2vpn service all
PE оператораMAC в бридж-домене (если MAC-learning)show bridge-domain N mac-address
Любой узел«Пролетающие» MAC вживуюtcpdump -e / SPAN-порт + Wireshark

5. EPL, EVPL, E-LAN — и чем это не IPVPN

Чтобы не путаться в родственных услугах L2:

УслугаТопологияПростыми словами
EPLточка-точка, весь портОдин офис ↔ один офис, весь порт целиком отдан клиенту.
EVPLточка-точка, часть порта (по VLAN)То же, но один физический порт делят несколько сервисов/клиентов по VLAN.
E-LAN (VPLS)много-точекТри и больше офисов в одной L2-сети — «большой виртуальный свитч».
IPVPN (след. урок)L3, много офисовУже маршрутизация по IP — офисы в РАЗНЫХ подсетях, оператор участвует в L3.

EVPL поближе: VLAN клиента, VLAN оператора и QinQ

EVPL заслуживает отдельного разбора — это хлеб инженера СПД в городах. Ситуация: в бизнес-центре один оптический ввод, а клиентов — двадцать. Тянуть каждому свой кабель до PE дорого. Решение: один физический порт, а клиенты разделены по VLAN — каждому сервису своя метка 802.1Q (VLAN-ликбез был в уроке 2).

EPL: весь порт — одному клиенту
Порт PE отдан целиком: что бы клиент ни прислал (с метками, без меток, любые VLAN) — всё уезжает в псевдопровод. Максимальная прозрачность.
EVPL: на порту живут несколько сервисов
Кадры клиента «Ромашка» приходят с меткой VLAN 100 — уезжают в её псевдопровод; кадры «Кактуса» с VLAN 200 — в его. Один порт, много изолированных каналов.
А если клиенту нужны СВОИ VLAN внутри канала? QinQ
Клиент хочет прозрачно возить свои VLAN 10, 20, 30 через EVPL. Оператор надевает на клиентский кадр вторую метку — свою, внешнюю (S-VLAN), не трогая метку клиента (C-VLAN). Это QinQ (802.1ad): «метка на метке». На выходе внешняя метка снимается — клиент получает свои VLAN нетронутыми.
MAC-адреса
как обычно
S-VLAN 3005
метка ОПЕРАТОРА · снимется на выходе
C-VLAN 10
метка КЛИЕНТА · едет насквозь
Данные клиента
не трогаем

QinQ: кадр клиента с его меткой C-VLAN 10 завёрнут в операторскую S-VLAN 3005 — как конверт в конверте.

Как EVPL выглядит в конфиге PE (Cisco-стиль, EVC):

! На порту к бизнес-центру: сервис для кадров с VLAN 100 = клиент Ромашка PE(config)# interface Gig0/2 PE(config-if)# service instance 100 ethernet PE(config-if-srv)# encapsulation dot1q 100 ! ловим кадры с меткой 100 PE(config-if-srv)# rewrite ingress tag pop 1 symmetric ! снять метку на входе, вернуть на выходе PE(config-if-srv)# xconnect 10.255.0.9 100 encapsulation mpls ! псевдопровод до дальнего PE
Классика заявок по EVPL

«Канал поднялся, а трафика нет» — в восьми случаях из десяти это несовпадение VLAN на стыке: оператор ждёт кадры с меткой 100, а клиент шлёт без метки (или с меткой 10). Симптом на PE: счётчики input по сервису — нули, при этом порт up и общие счётчики порта растут. Первый вопрос клиенту: «с какой VLAN-меткой вы отдаёте нам трафик?»

Не перепутай на собеседовании

EPL — это L2 (возим кадры, у оператора нет IP, офисы в одной подсети). IPVPN — это L3 (маршрутизируем пакеты, VRF+BGP, офисы в разных подсетях). Классический вопрос джуну: «Клиент говорит, что офисы в одной подсети и всё работает как локалка — какая это услуга?» Ответ: EPL (или E-LAN, если офисов больше двух).

6. Как сдают канал клиенту: заворот и Y.1564

Вернёмся к заявке #50122: «сдать с протоколом измерений». Канал мало собрать — надо доказать, что он держит обещанные 100 Мбит/с без потерь. Пинги для этого слишком слабы. Стандартная процедура приёмо-сдаточных испытаний:

Заворот на дальнем конце (loopback)
На дальней стороне канала включают «зеркало» — порт или тестер, который отправляет всё пришедшее обратно отправителю. Теперь с ближней стороны можно гонять трафик «туда-обратно» и мерить весь канал одним прибором. Заворот делают тестером, специальной функцией порта (loopback) или даже физической петлёй на оптике.
Нагрузочный тест Y.1564
Тестер генерирует поток на полную полосу договора и измеряет четыре показателя: пропускную способность (все 100 Мбит проходят?), потери кадров (0%?), задержку и джиттер (дрожание задержки — критично для голоса). Y.1564 умеет проверять сразу несколько сервисов и «перегруз» (что канал честно режет сверх полосы, а в полосе — не теряет).
Протокол измерений
Результаты оформляются документом: полоса, потери, задержка, джиттер, длительность теста. Подпись с двух сторон — и канал в эксплуатации. При будущих спорах («ваш канал теряет пакеты!») этот протокол — точка отсчёта.
Почему тест гоняют на РАЗНЫХ размерах кадра

Приёмку прогоняют на кадрах от 64 до 1518+ байт. Маленькие кадры — стресс для производительности оборудования (миллионы кадров в секунду), большие — проверка MTU по всему пути. Канал, сданный только на «удобных» кадрах 512 байт, может развалиться на больших — привет, авария 2 из следующего раздела.

Важно: RFC 2544 — не для боевой сети

Методику RFC 2544 часто называют наравне с Y.1564, и в лаборатории она уместна. Но у неё есть отдельный документ-предупреждение — RFC 6815 с говорящим названием «Use on Production Networks Considered Harmful», и формулировка там жёсткая: «эти тесты НЕ ДОЛЖНЫ применяться в производственных сетях… они не дадут надёжного или точного результата измерений в производственной сети». Причина простая: RFC 2544 намеренно перегружает устройство и судит о ёмкости только по потерям кадров, а в живой сети потери возникают и по другим причинам. Поэтому в сдаче услуги действующему клиенту ориентир — Y.1564, а RFC 2544 остаётся лабораторным инструментом. Если в наряде на работы написано «прогнать RFC 2544 на действующем канале» — это повод уточнить задачу, а не молча выполнить.

7. Три классические аварии EPL

Авария 1 — петля и broadcast-шторм

EPL прозрачна — в том числе и для ошибок клиента. Если клиент случайно соединит свои свитчи в кольцо (например, воткнёт EPL вторым концом туда же или запараллелит с другим каналом), каждый broadcast-кадр начнёт крутиться по кругу и размножаться — broadcast-шторм. Симптом: канал загружен на 100% «из ниоткуда», сеть клиента лежит целиком. Диагностика: счётчики порта на PE растут одинаково бешено в обе стороны, в трафике — один и тот же broadcast. Лечение: найти и разорвать петлю (у клиента!), на будущее — storm-control на порту оператора.

Авария 2 — порезанный MTU

Клиентский кадр внутри сети оператора обрастает служебными заголовками (MPLS-метки, QinQ-метка — ещё +4 байта). Если где-то на пути MTU впритык, большие кадры молча умирают. Классический симптом: пинг ходит, а «тяжёлые» вещи не работают (RDP отваливается, файлы не копируются, репликация СХД сыпется). Проверка с клиентом: ping -f -l 1472 (Windows) / ping -M do -s 1472 (Linux) через канал. Не проходит — ищи, где по пути в транспорте зажат MTU. Именно поэтому при сдаче канал тестируют на максимальных кадрах.

Авария 3 — MAC-flapping: один MAC скачет между портами

В логах свитча клиента: %SW_MATM-4-MACFLAP_NOTIF: Host 0011.2222.00b1 is flapping between port Gi0/24 and port Gi0/23. Перевод: один и тот же MAC виден то за одним портом, то за другим, таблица свитча дёргается, трафик к этому MAC идёт с потерями. Причины: клиент подключил второй канал между офисами (резерв через другого оператора) и не настроил STP/агрегацию — кадры приходят с двух сторон одновременно; или где-то дублируется MAC (клонированные виртуалки!). Это близкий родственник петли: два пути в одном L2-домене без защиты. Лечение — резать один путь (STP), собирать оба в агрегат (LACP, если каналы позволяют) или уходить на L3-резервирование.

8. Плейбук: «EPL не работает»

Порты живы с обеих сторон?
На обоих PE: show interface порта клиента — up/up, ошибки не растут? Физика первична всегда. CRC-ошибки растут — кабель/оптика/SFP, дальше можно не ходить, пока физика грязная.
Псевдопровод поднят?
show l2vpn service all — и AC, и PW должны быть UP. PW down — смотри связность между PE (это уже внутренняя магистраль оператора: LDP, loopback-и PE). AC down — проблема на локальном стыке с клиентом.
Тот ли VLAN на стыке? (для EVPL)
Порт up, PW up, а счётчики сервиса по нулям — сверь VLAN: какую метку ждёт сервис (encapsulation dot1q …) и с какой меткой реально приходят кадры клиента. Несовпадение метки — самая частая причина «пустого» канала.
MAC-адреса ходят?
Появляется ли MAC дальнего офиса в бридж-домене / на свитче клиента? Виден только локальный MAC — трафик с той стороны не доезжает: иди на дальний PE и повторяй шаги 1–3 там.
Счётчики трафика растут в обе стороны?
На PE смотри input/output rate сервиса. Input есть, output нет (или наоборот) — односторонняя проблема, сверь VLAN-настройки на стыке с клиентом и загляни в логи на MAC-flapping.
Пинг ходит, «тяжёлое» нет?
MTU-тест из «Аварии 2»: ping -f -l 1472 и ниже. И спроси клиента, что менялось: половина «EPL сломалась» — это вчерашние изменения на стороне клиента.
Спорите о качестве? Меряй, а не спорь
Клиент говорит «канал теряет пакеты», счётчики чистые — организуй заворот на дальней стороне и прогони Y.1564. Цифры против ощущений: либо потери подтвердятся (и ты увидишь на каком плече), либо у клиента проблема внутри.

9. Мини-лаба: почувствуй L2 на своём компьютере

EPL дома не поднять, но её «физику» — кадры, MAC, broadcast-домен — можно потрогать за 15 минут. Понадобится Wireshark (бесплатный) или встроенные команды.

Посмотри на настоящие кадры
Поставь Wireshark, запусти захват на своём сетевом адаптере, открой любой сайт, останови захват. Кликни пакет и разверни слой Ethernet II: вот они, Destination MAC и Source MAC — те самые поля, по которым работает EPL. Заметь: MAC назначения у исходящих пакетов — это MAC твоего роутера, а не сайта (урок 2 в действии).
Найди broadcast-трафик своего «двора»
В фильтре Wireshark набери eth.dst == ff:ff:ff:ff:ff:ff. Увидишь ARP-запросы соседей по домашней сети («Who has 192.168.1.7?»). В EPL ровно такие кадры прозрачно летают между городами — потому два офиса и выглядят одной локалкой.
Собери «MAC-таблицу» своей сети
Пропингуй пару устройств дома (роутер, телефон, телевизор) и выполни arp -a: перед тобой карта «IP ↔ MAC» твоего L2-домена — та же информация, которой живёт свитч. Первые три байта MAC вбей в поиск «MAC vendor lookup» — узнаешь производителя каждой железки.
Проверь MTU своего канала (навык из аварии 2)
ping 8.8.8.8 -f -l 1472. Прошло — путь держит полные 1500. Нет — уменьшай и найди потолок. Это ровно тот тест, который ты будешь давать клиентам EPL при жалобах «пинг есть, файлы не копируются».

10. Словарик урока

ТерминПо-английскиСмысл в одну строку
EPLEthernet Private Lineпрозрачный L2-канал точка-точка, весь порт клиенту
EVPLEthernet Virtual Private Lineто же, но порт делится по VLAN между сервисами
E-LAN / VPLS—L2-сеть на три и более точек — «виртуальный свитч»
Псевдопроводpseudowire, PWвиртуальный L2-туннель через магистраль оператора
ACattachment circuitфизический порт/VLAN, которым клиент «прицеплен» к сервису
Бридж-доменbridge domainL2-мир сервиса внутри PE, где учатся MAC
QinQ802.1ad, Q-in-Qвторая VLAN-метка поверх клиентской: S-VLAN оператора снаружи, C-VLAN клиента внутри
S-VLAN / C-VLANservice / customer VLANметка оператора (снимется на выходе) / метка клиента (едет насквозь)
Broadcast-штормbroadcast stormлавина размножающихся кадров из-за петли L2
Storm-controlstorm controlограничитель broadcast-трафика на порту — страховка от шторма
MAC-flappingMAC flappingодин MAC «скачет» между портами: два пути в L2 без защиты или дубль MAC
Заворотloopback«зеркало» на дальнем конце канала для измерений туда-обратно
Y.1564—стандартная методика активации Ethernet-услуги: полоса, потери, задержка, джиттер (RFC 2544 — лабораторный аналог, в боевой сети запрещён RFC 6815)
Джиттерjitterдрожание задержки от кадра к кадру — враг голоса и видео
EPL — прозрачный L2-канал точка-точка: оператор возит Ethernet-кадры по MAC и не участвует в L3, поэтому своих IP-адресов у него на этом сервисе нет. Оба офиса клиента — в одной подсети, будто соединены одним патч-кордом; покупают это ради репликации ЦОД, своего шифрования и гарантированной полосы. EVPL делит порт по VLAN, QinQ прячет метки клиента внутрь метки оператора. Диагностика идёт по MAC: на клиенте — show mac address-table (удалённый офис виден «за портом EPL»), на PE — статус псевдопровода (PW UP) и совпадение VLAN на стыке. Сдача канала — заворот + Y.1564. Три вечные аварии: петля/шторм, порезанный MTU, MAC-flapping.
Задача 1. Через EPL пинг между офисами ходит, а копирование файлов зависает. Диагноз?

Классика — MTU: маленькие пакеты (пинг) проходят, большие режутся где-то в транспорте. Проверь ping -f -l 1472 через канал; дальше ищи, где зажат MTU (у оператора запас под MPLS/QinQ-заголовки должен быть заложен).

Задача 2. Порт EPL внезапно загружен на 100% в обе стороны, клиент лежит. Что подозреваешь первым?

Петлю L2 и broadcast-шторм на стороне клиента: кадры крутятся по кругу и размножаются. Смотри трафик (один и тот же broadcast?), проси клиента проверить, что и куда воткнули. После разбора — предложи storm-control на порту.

Задача 3. EVPL включили, порт up, PW up, а трафика по сервису — ноль. Самая вероятная причина и первый вопрос клиенту?

Несовпадение VLAN на стыке: сервис ждёт метку 100, клиент шлёт с другой (или без метки). Первый вопрос: «с какой VLAN-меткой вы отдаёте трафик в наш порт?» Затем сверь с encapsulation dot1q в конфиге сервиса.

Задача 4. В логах свитча клиента: «Host 0011.2222.00b1 is flapping between Gi0/23 and Gi0/24». Что случилось?

MAC-flapping: один MAC виден с двух портов. У клиента два параллельных L2-пути между офисами (например, EPL + резервный канал) без STP/агрегации — или дубль MAC (клонированная виртуалка). Нужно оставить один активный путь (STP/LACP) или разнести резерв на L3.

Задача 5. Клиент при сдаче канала требует подтвердить «100 Мбит/с без потерь». Пингом докажешь?

Нет: пинг — это единичные маленькие пакеты, он не грузит канал и не меряет полосу. Нужен нагрузочный тест: заворот (loopback) на дальнем конце + Y.1564 — полоса, потери, задержка, джиттер на разных размерах кадра, с протоколом измерений.

Задача 6. Клиент репликацию СХД между площадками пустил через EPL, жалуется на «рваную» скорость вечером. Канал 100 Мбит, счётчики без ошибок, загрузка порта в полке. Что скажешь?

Канал честно занят на 100%: репликация упирается в купленную полосу (возможно, вечером к ней добавился другой трафик клиента). Это не авария — показывай график загрузки и предлагай расширение полосы или расписание репликации. Знакомо по IP access? Полка тарифа выглядит одинаково на любой услуге.

Клиент спрашивает: «какой IP-адрес у вас, оператора, на нашей EPL?» Что ответишь?

Никакого. EPL — это L2-сервис, оператор возит кадры по MAC и в IP-адресацию не вмешивается. IP-адреса на канале — это адреса самого клиента, из одной общей подсети на оба офиса.

Почему устройства двух удалённых офисов оказываются в одной IP-подсети?

Потому что EPL прозрачно соединяет их на L2 — для них это одна локальная сеть. А в одной L2-сети логично иметь одну IP-подсеть. ARP-broadcast свободно долетает до другого города.

На свитче офиса A ты видишь MAC устройства из офиса B «за портом Gi0/24». Это нормально?

Да, это норма и признак исправной EPL. Gi0/24 смотрит в EPL, а она прозрачно приносит кадры (и MAC) удалённого офиса — свитч воспринимает их как соседа на проводе.

«EPL не работает». Первое, что проверяешь на PE?

Физику порта (up/up, ошибки), затем статус псевдопровода (PW) и attachment circuit (AC): show l2vpn service all — оба должны быть UP. Если PW down — трафик между офисами не пойдёт.

Чем QinQ отличается от обычного 802.1Q — одной фразой?

802.1Q — одна VLAN-метка в кадре; QinQ — две: снаружи метка оператора (S-VLAN, снимается на выходе), внутри нетронутая метка клиента (C-VLAN). Конверт в конверте — клиентские VLAN едут через сеть оператора прозрачно.

Назови четыре показателя, которые меряет Y.1564 при сдаче канала.

Пропускная способность (throughput), потери кадров (frame loss), задержка (latency) и джиттер (дрожание задержки). Прогоняются на разных размерах кадра — от 64 байт до максимального.

Мост к следующему уроку

EPL идеальна для двух точек. Но что, если у клиента двадцать офисов? Тянуть двадцать «проводов» и держать всё в одной подсети — боль: один broadcast-шторм положит всю страну. Для этого есть услуга-конструктор из всего, что ты уже знаешь: VRF (урок 3) + BGP (урок 4) + транспорт оператора = IPVPN. Финальный урок соберёт весь путь воедино.

11. Источники

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