MAC-адреса, OUI и цифровая подстанция: что к чему?

Когда инженер открывает pcap-файл с цифровой подстанции, основное внимание обычно уходит на прикладные данные различных видов коммуникаций: GOOSE, Sampled Values, MMS, PTP, SNMP, LLDP и др.. Это логично: именно в прикладных данных кадров Ethernet находится информация о работе РЗА, АСУ ТП, синхронизации времени и служебная информация сетевой инфраструктуры.

Но иногда полезная диагностическая информация находится и на уровне Ethernet-кадров. В частности, в MAC-адресах устройств.

Один из таких признаков — OUI, или Organizationally Unique Identifier. По нему часто можно предположить, какой организации принадлежит диапазон MAC-адресов, а значит — какой производитель или поставщик может быть связан с сетевым интерфейсом устройства.

Для эксплуатации цифровой подстанции это не просто теоретическая деталь. OUI помогает быстрее разобраться, какие устройства реально присутствуют в технологической сети, найти неожиданные подключения, сопоставить фактический трафик с проектной документацией и ускорить первичный анализ pcap-файлов.

Что такое MAC-адрес

MAC-адрес Ethernet-интерфейса обычно имеет длину 48 бит, то есть 6 октетов. Один октет — это 8 бит. В привычном виде MAC-адрес записывается как шесть пар шестнадцатеричных символов:

00:1B:19:AA:BB:CC

или так:

00-1B-19-AA-BB-CC

Такой адрес можно условно разделить на две части:

00:1B:19:AA:BB:CC
│──────│ │──────│
  OUI     индивидуальная часть адреса

Первые три октета, то есть первые 24 бита, — это OUI: Organizationally Unique Identifier. Оставшиеся три октета, ещё 24 бита, организация использует для назначения уникальных адресов конкретным сетевым интерфейсам.

Что такое OUI

OUI — это уникальный идентификатор организации, назначаемый через IEEE Registration Authority.

Упрощённо часто говорят так: OUI — это первые три октета MAC-адреса, по которым можно определить производителя устройства.

Для практического анализа трафика такое объяснение обычно удобно. Но формально корректнее говорить немного точнее:

OUI указывает организацию, которой IEEE выделила соответствующее адресное пространство.

Эта организация может быть производителем сетевой карты, промышленного коммутатора, ИЭУ, контроллера, коммуникационного модуля, встроенной платы, серверного оборудования или виртуализационной платформы.

Поэтому OUI не всегда однозначно означает бренд устройства, который написан на лицевой панели. Иногда он показывает производителя сетевого интерфейса, модуля или чипа, установленного внутри оборудования.

Как из OUI получается MAC-адрес

Если организации выделен OUI, она может использовать оставшиеся 24 бита для формирования уникальных MAC-адресов.

Например, если организации выделен OUI:

00:1B:19

то она может назначать своим устройствам адреса вида:

00:1B:19:00:00:01
00:1B:19:00:00:02
00:1B:19:00:00:03
...
00:1B:19:FF:FF:FF

Оставшиеся 24 бита дают:

2^24 = 16 777 216

То есть один большой блок позволяет сформировать примерно 16,7 млн уникальных 48-битных адресов.

Именно поэтому крупные производители сетевого оборудования, серверных плат, промышленных устройств, Wi-Fi-модулей и Ethernet-контроллеров могут иметь не один, а десятки или сотни выделенных блоков.

Как организация получает OUI

OUI не выбирается производителем самостоятельно. Его назначает IEEE Registration Authority — регистрационный орган IEEE, который ведёт глобальные реестры идентификаторов.

Процесс можно описать в несколько шагов.

Компания определяет, какой адресный блок ей нужен

Если организация выпускает устройства с Ethernet-интерфейсами, ей нужны уникальные MAC-адреса.

Это может быть производитель:

• ИЭУ;
• промышленных коммутаторов;
• контроллеров;
• шлюзов;
• серверов;
• плат связи;
• встраиваемых модулей;
• испытательного оборудования;
• устройств для АСУ ТП и РЗА;
• и др.

В зависимости от масштаба производства компания выбирает подходящий тип регистрационного блока IEEE: большой, средний или малый.

Классический случай, который чаще всего связывают с OUI, — это MA-L, или MAC Address Block Large.

Организация подаёт заявку в IEEE Registration Authority

Компания подаёт заявку через IEEE RA. В заявке указываются сведения об организации, контактные данные, тип требуемого блока и формат публикации информации.

Данные могут быть публичными или конфиденциальными. Если регистрация публичная, информация об организации попадает в открытые базы, которые затем используют инструменты OUI lookup, в том числе Wireshark и другие базы производителей.

IEEE рассматривает заявку

IEEE проверяет заявку и назначает организации адресный блок.

Важно, что IEEE не назначает каждый MAC-адрес отдельно. Она выделяет организации диапазон, а дальше сама организация распределяет конкретные адреса между своими устройствами.

То есть производитель получает право использовать определённый адресный блок, а затем внутри своей производственной системы назначает индивидуальные MAC-адреса конкретным сетевым интерфейсам.

Для получения дополнительного OUI организация должна подтвердить, что не начнёт использовать новый блок в продукции до тех пор, пока не будет использовано не менее 95% предыдущего блока в контексте соответствующего стандарта. Это правило нужно, чтобы большие адресные пространства не оставались неиспользованными.

Данные попадают в реестр

Если регистрация публичная, сведения о блоке становятся доступными в регистрационных базах IEEE и производных базах производителей.

Именно поэтому Wireshark может показывать не только MAC-адрес, но и название организации, которой принадлежит соответствующий диапазон.

Например, вместо полностью «голого» адреса инженер может увидеть более понятное представление с указанием производителя или организации.

Какие бывают регистрационные блоки IEEE

Важно понимать, что OUI — это не единственный тип регистрационного блока IEEE. Существуют разные варианты, рассчитанные на разные масштабы производства и разные задачи идентификации.

В части MAC-адресов полезно различать четыре понятия:

MA-L — большой блок MAC-адресов, включает OUI
MA-M — средний блок MAC-адресов
MA-S — малый блок MAC-адресов, включает OUI-36
CID  — Company ID, но не для формирования универсальных MAC-адресов

MA-L — большой блок, классический случай с OUI

MA-L расшифровывается как MAC Address Block Large.

Это тот самый вариант, который чаще всего в прикладной литературе называют «получить OUI».

В случае MA-L организация получает 24-битный OUI и может формировать на его основе 48-битные идентификаторы EUI-48, которые используются как MAC-адреса Ethernet-интерфейсов.

Структура для EUI-48 выглядит так:

OUI, выданный IEEE:       24 бита
Часть производителя:      24 бита
Итого EUI-48 / MAC:       48 бит

Пример:

00:1B:19:AA:BB:CC
│──────│ │──────│
  OUI     часть, назначенная производителем

Один MA-L-блок даёт:

2^24 = 16 777 216

уникальных EUI-48-адресов.

Такой блок подходит крупным производителям оборудования, которые выпускают большие серии устройств с сетевыми интерфейсами.

Для инженера, анализирующего pcap-файл в Wireshark, именно MA-L/OUI чаще всего и даёт привычную расшифровку производителя по первым трём октетам MAC-адреса.

MA-M — средний блок

MA-M — это MAC Address Block Medium.

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

Для EUI-48 это можно представить так:

MA-M, выданный IEEE:      28 бит
Часть организации:        20 бит
Итого EUI-48 / MAC:       48 бит

Количество EUI-48-адресов в таком блоке:

2^20 = 1 048 576

То есть MA-M даёт примерно 1 млн 48-битных адресов.

Это может быть удобным вариантом для производителя среднего масштаба, которому не нужен диапазон на 16,7 млн адресов, но требуется достаточно большое адресное пространство для серийного выпуска оборудования.

Важная особенность: MA-M не является классическим OUI в привычном смысле первых 24 бит. Поэтому не всегда корректно сводить всю систему IEEE-регистрации только к фразе «первые три октета — это производитель».

MA-S — малый блок и OUI-36

MA-S — это MAC Address Block Small.

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

MA-S связан с понятием OUI-36. Для EUI-48 это можно представить так:

MA-S / OUI-36, выданный IEEE:  36 бит
Часть организации:            12 бит
Итого EUI-48 / MAC:           48 бит

Количество EUI-48-адресов:

2^12 = 4096

То есть MA-S даёт всего 4096 уникальных 48-битных адресов.

Такой вариант может быть достаточен для небольших производителей, опытных партий оборудования, специализированных устройств, лабораторных приборов или малосерийных промышленных решений.

Для цифровой подстанции это тоже может быть актуально. Например, небольшая компания может выпускать специализированные шлюзы, модули сопряжения, тестовые устройства или сервисное оборудование для МЭК 61850. Для таких продуктов огромный блок MA-L может быть избыточен, а MA-S — достаточен.

CID — Company ID

Отдельно существует CID, или Company ID.

По размеру он похож на OUI: это тоже уникальный 24-битный идентификатор организации. Но его назначение другое.

Ключевое отличие:

CID нельзя использовать для формирования универсальных MAC-адресов EUI-48 или EUI-64.

CID нужен для случаев, когда организации требуется уникальный идентификатор, но не требуется выпускать универсально уникальные MAC-адреса.

Иначе говоря:

CID можно использовать как идентификатор организации.
CID нельзя использовать как основу для универсальных MAC-адресов.

Если производитель выпускает устройство с Ethernet-интерфейсом и хочет назначать ему универсально уникальные MAC-адреса, ему нужен не CID, а один из адресных блоков MA-L, MA-M или MA-S.

Сравнение MA-L, MA-M, MA-S и CID

Если упростить, IEEE выдаёт организациям не отдельные MAC-адреса, а адресные блоки разного размера. Крупному производителю нужен MA-L, производителю среднего масштаба может быть достаточно MA-M, небольшой компании — MA-S. А CID нужен не для MAC-адресов, а для других задач идентификации организации.

Как Wireshark использует OUI

Wireshark умеет сопоставлять MAC-адреса с базой производителей.

Когда в pcap-файле встречается Ethernet-кадр, Wireshark может посмотреть первые октеты MAC-адреса и попытаться найти соответствующую запись в базе производителей.

Например, есть MAC-адрес:

00:30:A7:12:34:56

OUI здесь:

00:30:A7

Это OUI компании Schweitzer Engineering Laboratories.

То есть уже на первом этапе анализа можно предположить, что данный Ethernet-кадр отправлен устройством или сетевым интерфейсом, связанным с оборудованием SEL.

Для инженера цифровой подстанции это полезная подсказка. Если на объекте действительно установлены устройства SEL, такой Source MAC может быть ожидаемым. Дальше его нужно сопоставить с проектной документацией, SCD-файлом, IP-адресом, VLAN, портом коммутатора и конкретным ИЭУ.

Например:

Source MAC:      00:30:A7:12:34:56
OUI:             00:30:A7
Vendor:          Schweitzer Engineering Laboratories
Traffic type:    GOOSE / MMS / служебный Ethernet-трафик

Логика анализа может быть такой:

00:30:A7:12:34:56
        ↓
OUI: Schweitzer Engineering Laboratories
        ↓
проверяем:
- есть ли устройства SEL на объекте;
- какой порт коммутатора видит этот MAC;
- какой IP-адрес соответствует этому MAC;
- публикует ли устройство GOOSE;
- устанавливает ли оно MMS-сессию;
- есть ли соответствующий IEDName в SCD-файле.

Но результат нужно читать аккуратно. OUI lookup показывает владельца адресного блока или организацию, связанную с сетевым интерфейсом. Это не всегда означает, что конечное устройство целиком выпущено именно этой организацией.

Зачем OUI инженеру цифровой подстанции

На цифровой подстанции Ethernet-сеть — это не просто вспомогательная ИТ-инфраструктура. Через неё передаются критичные технологические данные:

• GOOSE-сообщения;
• потоки Sampled Values;
• MMS-обмен с ИЭУ;
• PTP-синхронизация времени;
• служебный трафик коммутаторов;
• инженерный доступ;
• данные АСУ ТП и РЗА.

Поэтому понимание состава участников сети имеет прямое эксплуатационное значение.

OUI может помочь в нескольких практических задачах.

Быстро понять состав оборудования в pcap-файле

Представим, что инженер получил pcap-файл с цифровой подстанции. В нём десятки или сотни MAC-адресов. Часть относится к ИЭУ, часть — к коммутаторам, часть — к серверам, часть — к инженерным рабочим местам.

Без дополнительной расшифровки это выглядит как набор адресов:

00:30:A7:12:34:56
00:1B:19:AA:BB:CC
00:80:63:11:22:33
E8:9F:80:77:88:99

После OUI lookup инженер может увидеть, что разные адреса относятся к разным производителям сетевых интерфейсов или оборудования.

Например:

На реальном объекте это помогает быстро задать правильные вопросы:

• почему такой адрес присутствует в технологической сети;
• соответствует ли он ожидаемому составу оборудования;
• есть ли этот участник в схеме ЛВС, SCD-файле и таблице подключений;
• с какого порта коммутатора приходит этот Source MAC;
• какой трафик он передаёт: GOOSE, SV, MMS, PTP, ARP, служебные протоколы.

Например, если на подстанции действительно применяются устройства SEL, то Source MAC с OUI 00:30:A7 может быть ожидаемым. Но если таких устройств на объекте нет, это уже повод проверить, откуда появился данный MAC-адрес и какое оборудование фактически подключено к сети.

Найти неожиданное устройство в технологической сети

Если в технологической сети цифровой подстанции должны быть только определённые устройства, появление неожиданного OUI может быть поводом для проверки.

Например, в сети должны находиться:

• ИЭУ РЗА;
• контроллеры присоединений;
• промышленные коммутаторы;
• серверы АСУ ТП;
• серверы РС ВАПС;
• рабочие станции инженера;
• оборудование синхронизации времени.

А в pcap-файле внезапно появляется MAC-адрес, OUI которого относится к производителю бытового роутера, офисной точки доступа, камеры или USB-Ethernet-адаптера.

Это не доказывает нарушение само по себе. Возможны разные объяснения:

• временно подключили ноутбук наладчика;
• использовался USB-Ethernet-адаптер;
• подключали сервисный маршрутизатор;
• проводились испытания;
• использовалось временное оборудование подрядчика;
• MAC-адрес был назначен виртуальной машиной;
• устройство было подключено ошибочно.

Но это уже повод задать правильные вопросы:

• что это за устройство;
• кто его подключил;
• к какому порту коммутатора оно было подключено;
• было ли оно указано в проектной документации;
• участвовало ли оно в технологическом обмене;
• могло ли оно повлиять на работу GOOSE, SV, MMS или PTP.

Сопоставить фактическую сеть с проектной документацией

В проектной документации, SCD-файлах, схемах ЛВС и таблицах портов обычно указано, какие устройства должны находиться в сети.

Но фактическая картина на действующем объекте иногда отличается от проектной.

Например:

• заменили коммутатор;
• поставили другую ревизию оборудования;
• добавили временное устройство;
• подключили инженерную станцию;
• изменили схему зеркалирования трафика;
• заменили сетевой модуль в устройстве;
• часть оборудования была модернизирована без отражения в документации.

OUI lookup помогает быстро увидеть, соответствует ли фактический состав участников сети ожидаемому.

Конечно, OUI не заменяет полноценную проверку. Но он может быть хорошим первичным индикатором несоответствия.

Ускорить расследование проблем GOOSE, SV и MMS

При анализе нештатной ситуации важно быстро понять, кто именно участвует в обмене.

Например:

• какое устройство публикует GOOSE;
• откуда идут Sampled Values;
• кто устанавливает MMS-сессию;
• какой MAC-адрес принадлежит серверу АСУ ТП;
• какой адрес относится к инженерной станции;
• какое устройство отправляет неожиданный broadcast или multicast;
• кто генерирует лишний служебный трафик.

OUI помогает быстрее ориентироваться в Ethernet-адресах.

Особенно это полезно, когда в pcap-файле нет полной контекстной информации, а инженер анализирует запись уже после события. Например, при расследовании инцидента, проверке корректности наладки, анализе работы РС ВАПС или разборе проблем на действующей цифровой подстанции.

Проверить сетевую гигиену объекта

На технологической сети цифровой подстанции не должно быть случайных устройств.

OUI lookup может использоваться как часть простой проверки сетевой гигиены:

• какие производители сетевых интерфейсов видны в технологической сети;
• есть ли неожиданные бытовые или офисные устройства;
• присутствуют ли виртуальные сетевые интерфейсы;
• есть ли признаки временного оборудования;
• совпадает ли фактический состав устройств с ожидаемым;
• нет ли в сети устройств, не относящихся к РЗА, АСУ ТП или сетевой инфраструктуре.

Это особенно актуально для сетей, где передаются GOOSE и Sampled Values. Такие сети должны быть предсказуемыми, управляемыми и хорошо документированными.

Одинаковые Source MAC на объекте: может ли такое встретиться

Отдельный важный вопрос: могут ли на реальном объекте встретиться одинаковые MAC-адреса источника?

Да, могут. Но для обычной Ethernet-сети это нештатная ситуация.

Важно говорить именно про Source MAC, то есть MAC-адрес источника Ethernet-кадра. Это адрес устройства, которое отправило кадр в сеть.

Source MAC = от кого пришёл кадр

В нормальной ситуации два разных устройства в одной VLAN не должны одновременно отправлять кадры с одним и тем же Source MAC.

Если это происходит, коммутатору становится трудно понять, где на самом деле находится устройство с таким MAC-адресом.

Как коммутатор использует Source MAC

Коммутатор Ethernet строит таблицу коммутации на основе MAC-адресов источника.

Он работает примерно так:

1. На порт приходит Ethernet-кадр.
2. Коммутатор смотрит поле Source MAC.
3. Запоминает: этот MAC-адрес находится за этим портом.
4. Когда потом нужно отправить кадр на этот MAC-адрес, коммутатор отправляет его в соответствующий порт.

Например:

Порт 3 → пришёл кадр с Source MAC 00:30:A7:12:34:56

Коммутатор записывает:

00:30:A7:12:34:56 → порт 3

Теперь, если сервер АСУ ТП, инженерная станция или другое ИЭУ отправит unicast-трафик на этот MAC-адрес, коммутатор направит кадр в порт 3.

Что происходит при конфликте Source MAC

Представим, что на объекте есть два устройства:

IED-1 подключён к порту 3
IED-2 подключён к порту 8

Но у них одинаковый MAC-адрес:

00:30:A7:12:34:56

Сначала IED-1 отправляет кадр:

Source MAC: 00:30:A7:12:34:56
Порт:       3

Коммутатор запоминает:

00:30:A7:12:34:56 → порт 3

Потом IED-2 отправляет кадр:

Source MAC: 00:30:A7:12:34:56
Порт:       8

Коммутатор перезаписывает запись:

00:30:A7:12:34:56 → порт 8

Потом снова приходит кадр от IED-1 — и запись снова меняется:

00:30:A7:12:34:56 → порт 3

Такой эффект часто называют MAC flapping: один и тот же MAC-адрес «прыгает» между портами.

sequenceDiagram
    autonumber
    participant I1 as IED-1<br/>(порт 3)
    participant SW as Коммутатор
    participant I2 as IED-2<br/>(порт 8)

    Note over I1,I2: оба отправляют кадры с одинаковым Source MAC<br/>00:30:A7:12:34:56

    I1->>SW: кадр, Source MAC = 00:30:A7:12:34:56
    Note right of SW: запоминает:<br/>MAC → порт 3

    I2->>SW: кадр, Source MAC = 00:30:A7:12:34:56
    Note right of SW: перезаписывает:<br/>MAC → порт 8

    I1->>SW: кадр, Source MAC = 00:30:A7:12:34:56
    Note right of SW: снова перезаписывает:<br/>MAC → порт 3

    I2->>SW: кадр, Source MAC = 00:30:A7:12:34:56
    Note right of SW: и снова:<br/>MAC → порт 8

    Note over I1,I2: ⚠️ MAC flapping —<br/>unicast-трафик уходит то на порт 3, то на порт 8

Чем опасны одинаковые Source MAC

Главная проблема — коммутатор начинает нестабильно принимать решение, куда отправлять трафик на этот MAC-адрес.

Например, сервер АСУ ТП отправляет MMS-запрос устройству с MAC:

00:30:A7:12:34:56

Но в этот момент таблица коммутатора показывает:

00:30:A7:12:34:56 → порт 8

Значит кадр уйдёт на порт 8. Через секунду таблица может переучиться на порт 3 — и следующий кадр уйдёт уже туда.

В результате возможны:

• нестабильные MMS-сессии;
• периодические потери связи;
• «плавающие» ошибки диагностики;
• странные обрывы TCP-соединений;
• ошибки в журналах коммутаторов;
• неправильная привязка устройства к порту;
• затруднённый анализ pcap-файлов;
• ложное ощущение, что «то работает, то не работает».

Для цифровой подстанции это особенно неприятно, потому что такие проблемы могут выглядеть как неисправность ИЭУ, ошибка настройки MMS, проблема VLAN, неисправность коммутатора или нестабильность сервера. А реальная причина будет находиться ниже — на уровне конфликтующих Source MAC.

Откуда на объекте берутся одинаковые Source MAC

Есть несколько реальных сценариев.

Клонирование виртуальных машин

Это один из самых частых практических сценариев.

Например, сервер АСУ ТП, РС ВАПС, инженерная станция или тестовый стенд работает в виртуализации. Виртуальную машину склонировали, но не изменили MAC-адрес сетевого адаптера.

В итоге две виртуальные машины могут выйти в одну VLAN с одинаковым Source MAC.

Особенно это вероятно при быстрых пусконаладочных работах, переносе образов, развёртывании резервных серверов или создании копий стендов.

Ручная настройка MAC-адреса

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

Это может делаться для тестирования, резервирования, миграции, обхода привязки лицензии или по ошибке. Если такой адрес совпал с уже существующим устройством, возникнет конфликт.

Копирование конфигурации устройства

При наладке иногда копируют конфигурацию с одного устройства на другое.

Если в конфигурации присутствует MAC-адрес или параметры сетевого интерфейса, можно случайно перенести один и тот же адрес на два устройства.

Для большинства ИЭУ заводской MAC обычно жёстко задан, но для шлюзов, промышленных контроллеров, серверов, виртуальных машин и некоторых embedded-устройств такой риск реальнее.

Резервирование с виртуальным MAC

Некоторые системы резервирования используют общий виртуальный MAC-адрес.

Идея такая: для сети существует один «виртуальный» узел, а физически его могут обслуживать два устройства — основное и резервное. Но одновременно активным должен быть только один участник.

Если оба узла по ошибке становятся активными, возникает конфликт и MAC flapping.

Для цифровой подстанции это может быть актуально для серверов, шлюзов, маршрутизаторов, межсетевых экранов, кластеров АСУ ТП или систем верхнего уровня. Для двух независимых ИЭУ РЗА это не является нормальным сценарием.

Ошибка производителя или опытная партия оборудования

Редко, но теоретически возможно: оборудование поставлено с неуникальными MAC-адресами.

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

Локально администрируемые MAC-адреса

Если MAC-адрес не заводской, а локально назначенный, его уникальность зависит уже не от IEEE и производителя, а от того, кто его задал.

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

Как обнаружить одинаковые Source MAC в Wireshark

В pcap-файле признаком конфликта может быть ситуация, когда один и тот же Source MAC связан с разными сущностями:

один Source MAC → разные IP-адреса
один Source MAC → разные MMS-сессии
один Source MAC → разные svID

Например, в одном фрагменте трафика видно:

Source MAC: 00:30:A7:12:34:56
IP:         10.10.1.21
IEDName:    SEL_IED_Q01

А в другом фрагменте того же захвата:

Source MAC: 00:30:A7:12:34:56
IP:         10.10.1.22
IEDName:    SEL_IED_Q02

Это сильный признак, что нужно проверять конфликт MAC-адресов или особенности резервирования.

Для GOOSE можно смотреть не только Source MAC, но и поля уровня IEC 61850:

Source MAC один и тот же,
а GoCBRef/goID разные

Для SV:

Source MAC один и тот же,
а svID разные

Для MMS:

Source MAC один и тот же,
а IP-адреса или MMS-сессии разные

Такая картина не всегда автоматически означает аварию, но точно требует проверки.

Как обнаружить конфликт на коммутаторе

На коммутаторе нужно смотреть таблицу MAC-адресов и журналы событий.

Типовой симптом:

00:30:A7:12:34:56 → port 3
через несколько секунд:
00:30:A7:12:34:56 → port 8
потом снова:
00:30:A7:12:34:56 → port 3

В журналах это может называться по-разному:

MAC flapping
MAC address moved
Duplicate MAC address
MAC move detected

Формулировка зависит от производителя коммутатора.

Если на объекте установлен РС ВАПС (например, ПТК «Теквел Парк», подобное поведение также может быть видно как перемещение MAC-адреса, появление неизвестного устройства, изменение источника трафика или несоответствие ожидаемой модели обмена.

Что делать при обнаружении одинакового Source MAC

Практический порядок действий:

1. Убедиться, что речь именно об одинаковом Source MAC.
2. Проверить, с каких портов коммутатора приходит этот MAC-адрес.
3. Определить физические устройства, подключённые к этим портам.
4. Проверить, нет ли штатного механизма резервирования с виртуальным MAC.
5. Если резервирования нет — искать ошибку конфигурации.
6. Проверить виртуальные машины, клонированные образы, шлюзы, серверы и инженерные АРМ.
7. Проверить, не задан ли MAC вручную.
8. Проверить, не была ли скопирована конфигурация устройства.
9. Исправить адресацию или конфигурацию.
10. После исправления проверить таблицу MAC-адресов и повторный pcap.

Главное — не пытаться лечить только верхний уровень. При конфликте Source MAC можно долго искать ошибку в MMS, настройках ИЭУ, VLAN или серверном ПО, хотя причина будет заключаться в том, что коммутатор не может стабильно определить, за каким портом находится нужный MAC-адрес.

Практический пример для цифровой подстанции

Инженер анализирует pcap-файл с цифровой подстанции. В захвате есть MMS-трафик между сервером АСУ ТП и несколькими ИЭУ. Периодически MMS-сессия с одним устройством обрывается, но затем восстанавливается.

На первый взгляд можно предположить:

• проблемы с сетью;
• ошибки в настройке MMS;
• перегрузку ИЭУ;
• проблемы с сервером;
• ошибки VLAN;
• нестабильность коммутатора.

Но при анализе Ethernet-уровня выясняется, что один и тот же Source MAC появляется в кадрах с разными IP-адресами.

Например:

Кадры от первого устройства:
Source MAC: 00:30:A7:12:34:56
IP:         10.10.1.21
IEDName:    SEL_IED_Q01

и:

Кадры от второго устройства:
Source MAC: 00:30:A7:12:34:56
IP:         10.10.1.22
IEDName:    SEL_IED_Q02

Дальше инженер смотрит таблицу MAC-адресов коммутатора и видит:

00:30:A7:12:34:56 → port 5
00:30:A7:12:34:56 → port 12
00:30:A7:12:34:56 → port 5
00:30:A7:12:34:56 → port 12

То есть один и тот же MAC-адрес постоянно «переезжает» между двумя портами.

После проверки выясняется, что одно из устройств было заменено или сконфигурировано некорректно, либо на объекте использовалась копия конфигурации/виртуальной машины с тем же MAC-адресом.

После исправления MAC-адреса связь становится стабильной, а события MAC flapping в коммутаторе исчезают.

Этот пример хорошо показывает, почему при анализе цифровой подстанции важно смотреть не только на IEC 61850, но и на базовые механизмы Ethernet.

Важное ограничение: OUI — это не абсолютное доказательство

OUI полезен, но его нельзя воспринимать как стопроцентное доказательство происхождения устройства.

Есть несколько причин.

MAC-адрес может быть локально назначенным

Существуют два типа MAC-адресов:

UAA — Universally Administered Address
LAA — Locally Administered Address

UAA — универсально назначенный адрес. Обычно это заводской MAC-адрес, выделенный производителем из своего адресного диапазона.

LAA — локально администрируемый адрес. Его может назначить операционная система, гипервизор, сетевой администратор или программное обеспечение.

Локально назначенные MAC-адреса часто встречаются в виртуальных машинах, контейнерах, тестовых стендах и инженерных средах.

MAC-адрес может быть изменён программно

Во многих операционных системах MAC-адрес сетевого интерфейса можно изменить программно.

Это может использоваться в тестировании, виртуализации, резервировании, миграции виртуальных машин или при работе специализированного ПО.

Поэтому сам факт, что OUI указывает на определённую организацию, ещё не гарантирует, что физическое устройство действительно произведено этой организацией.

OUI может относиться к сетевому модулю, а не к конечному устройству

В промышленном оборудовании часто используются готовые Ethernet-модули, чипы, платы и коммуникационные процессоры.

Поэтому в pcap-файле OUI может указывать не на производителя ИЭУ, а на производителя сетевого контроллера или embedded-модуля внутри него.

Например, устройство на лицевой панели имеет один бренд, а OUI MAC-адреса относится к производителю сетевого чипа или встраиваемой платы.

Информация в базе может быть неполной

Инструменты lookup используют базы производителей, которые обновляются со временем.

Если локальная база Wireshark устарела, новый адресный блок может отображаться некорректно или не отображаться вовсе.

Кроме того, часть регистрационных данных может быть конфиденциальной.

Как правильно использовать OUI и Source MAC при анализе ЦПС

Правильный подход такой:

OUI — это полезный диагностический признак, а Source MAC — важный сетевой идентификатор отправителя. Но окончательные выводы нужно делать только после сопоставления нескольких источников данных.

При анализе цифровой подстанции стоит сопоставлять:

• SCD-файл;
• схему сети;
• таблицы коммутации;
• настройки VLAN;
• LLDP;
• IP-адреса;
• ARP-таблицы;
• настройки ИЭУ;
• журналы событий;
• порты коммутаторов;
• pcap-файлы;
• данные РС ВАПС (например, ПТК «Теквел Парк»).

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

Мини-чек-лист для инженера при анализе pcap-файла

При первичном анализе трафика цифровой подстанции полезно сделать несколько простых шагов.

flowchart TB
    START["<b>Source MAC в pcap-файле</b><br/>например, 00:30:A7:12:34:56"]
    Q1{"OUI совпадает с<br/>ожидаемым составом<br/>оборудования?"}
    Q2{"Source MAC уникален<br/>в своей VLAN?"}
    Q3{"Кадры приходят с<br/>одного и того же порта<br/>коммутатора?"}

    INV["<b>Проверить происхождение</b><br/>• что за устройство?<br/>• как попало в сеть?<br/>• есть ли в SCD / схеме ЛВС?<br/>• какой трафик передаёт?"]
    FLAP["<b>MAC flapping</b><br/>• таблица коммутатора<br/>• журналы (MAC moved / duplicate)<br/>• РС ВАПС / система мониторинга"]
    SRC["<b>Найти источник дубля</b><br/>• клон виртуальной машины<br/>• ручная настройка MAC<br/>• скопированная конфигурация<br/>• виртуальный MAC резервирования"]
    OK["<b>Норма</b><br/>сопоставить с SCD,<br/>проектной документацией,<br/>портами и VLAN"]

    START --> Q1
    Q1 -- "да" --> Q2
    Q1 -- "нет / неизвестен" --> INV
    INV --> Q2
    Q2 -- "да, уникален" --> Q3
    Q2 -- "нет, дубль" --> FLAP
    Q3 -- "да, с одного" --> OK
    Q3 -- "нет, с разных" --> FLAP
    FLAP --> SRC

    style START fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style Q1 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q2 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q3 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style INV fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style FLAP fill:#FDE8E8,stroke:#F56C6C,color:#B71C1C
    style SRC fill:#FBE9E7,stroke:#E64A19,color:#BF360C
    style OK fill:#E8F5E9,stroke:#67C23A,color:#1B5E20

Посмотреть список Source MAC

Выделить все уникальные MAC-адреса источника, которые встречаются в pcap-файле.

Проверить OUI

Посмотреть, каким организациям принадлежат первые октеты адресов.

Найти устройства, которых не ожидаем увидеть в структуре объекта

Сравнить найденные OUI с ожидаемым составом оборудования на объекте.

Например, если на объекте применяются устройства SEL, OUI 00:30:A7 может быть ожидаемым. Если устройств SEL на объекте нет, такой MAC-адрес требует дополнительной проверки.

Проверить уникальность Source MAC

Убедиться, что один Source MAC не используется разными IP-адресами, MMS-сессиями, IEDName, GoCBRef или svID.

Проверить таблицу MAC-адресов коммутатора

Если один MAC появляется на разных портах, проверить возможный MAC flapping.

Сопоставить с VLAN и типами трафика

Важно понять не только производителя, но и то, что устройство делает в сети:

• публикует GOOSE;
• передаёт Sampled Values;
• устанавливает MMS-соединение;
• участвует в PTP;
• отправляет ARP;
• генерирует broadcast;
• передаёт служебный трафик.

Сопоставить с документацией

Результаты нужно сравнить с SCD-файлом, схемой ЛВС, таблицами подключений, настройками коммутаторов и фактической конфигурацией объекта.

Что особенно важно для цифровой подстанции

На классической подстанции инженер часто видит цепь физически: кабель, клеммы, шкаф, устройство, дискретный сигнал.

На цифровой подстанции значительная часть взаимодействий переносится в Ethernet-сеть. Сигналы РЗА, измерения, команды, блокировки и телемеханики передаются в виде сообщений.

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

OUI и Source MAC — простые, но полезные элементы такого анализа.

OUI помогает ответить на вопрос:

какой организации принадлежит адресный блок?

Source MAC помогает ответить на вопрос:

кто отправляет кадры в сеть?

А анализ поведения Source MAC во времени помогает понять:

нет ли конфликта адресов, MAC flapping или некорректной работы резервирования?

Для цифровой подстанции это особенно важно, потому что один конфликтующий MAC-адрес может проявляться как нестабильная MMS-связь, странное поведение серверов, ошибки диагностики, сложности при анализе GOOSE/SV или непредсказуемая работа сетевой инфраструктуры.

Вывод

OUI — это первые октеты MAC-адреса, по которым часто можно определить организацию-владельца адресного блока. Для инженера цифровой подстанции это удобный инструмент первичной диагностики: он помогает понять, какие устройства присутствуют в технологической сети, найти неожиданные подключения и сопоставить фактический трафик с проектной документацией.

Например, Source MAC 00:30:A7:12:34:56 содержит OUI 00:30:A7, который относится к Schweitzer Engineering Laboratories. Если на объекте применяются устройства SEL, это может быть ожидаемым признаком. Если нет — такой адрес становится поводом для проверки фактического подключения и состава оборудования.

Но OUI нельзя воспринимать как абсолютное доказательство. MAC-адрес может быть локально назначенным, изменённым программно, относиться к сетевому модулю, а не к конечному устройству, или отсутствовать в локальной базе lookup.

Отдельно важно контролировать уникальность Source MAC. Если два разных устройства в одной VLAN одновременно отправляют кадры с одинаковым Source MAC, коммутатор будет постоянно переучивать таблицу коммутации. Возникает MAC flapping, unicast-трафик может уходить не туда, MMS-сессии становятся нестабильными, а диагностика превращается в поиск «плавающей» ошибки.

Поэтому при анализе цифровой подстанции важно смотреть не только на IEC 61850, IP-адреса и VLAN, но и на базовый Ethernet-уровень: Source MAC, OUI, таблицы коммутации и поведение MAC-адресов во времени.

В эксплуатации ЦПС умение читать такие сетевые признаки становится таким же важным, как умение читать схемы вторичных цепей. Потому что в цифровой подстанции значительная часть «проводов» уже находится внутри Ethernet-сети.