Драйвер протокола lldp майкрософт что это

Обновлено: 05.07.2024

Windows 10 has activated the "MsLldp" Service on Network Adapters. This "MsLldp" Service sends LLDP Ethernet-Frames to managed Switches so that they show up in the LLDP Neighbors Table.

I like to get Information how to Configure this Service.

Default configuration is, that it only sends the MAC-Address of the Ethernet-Adapter as "LLDP Chassis Subtype". How to Configure this Service to send for example "System name" or "Port Description" Information .

9 Answers

Unfortunately, using the registry to change the behaviour of Mslldp looks like a dead end.

This is what I have found: the driver always tries to read a REG_SZ value named ChassisId from the service's Parameters subkey; if this fails, the service reads the ComputerName value from the key HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName. The result of this process (i.e. either the ChassId or ComputerName value) is stored in a global variable which appears not to be used (apart from initialization and cleanup).

It is still possible that Mslldp is capable of more than we suspect (perhaps controlled via IOCTLs) but I doubt it.

Based on my research, it seems that Microsoft LLDP can only send the MAC-Address to managed switch.

The similar thread has discussed before, you could have a look:

Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Thanks for your pointer @CandyLuo-MSFT

I already tried WinLLDPservice as alternative which works fine, but sends wrong "System Capabilities / Auto Negotiation" (which is sent correct by MSLLDP).

If the only functionality of MSLLDP Service is to send the MAC-Address, why is this Service existing? MAC-Addresses could be even identified by Checking the SourceAddressTable of a switch, therefore no LLDP would be needed.

Since there are limited Microsoft documents talking about MSLLDP Service, I am not sure whether there is someplace in windows can configure this service to send for other Information.

If you want to get exact confirm, I would suggest you open a case with Microsoft where more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this. Here is the link:

Appreciate your understanding. :)

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Just like Candy, I could not find any information on the web. However looking at the strings inside mslldp.sys and the debug symbols, it might be possible to send the computer name. The strings include:

The symbols include:

It might take some trial and error or reverse engineering, but sending the computer name may well be possible.

Thanks @GaryNebbett for the hint,

I already tried to:
1. disable the MSLLDP Service
2. reboot the machine with disabled MSLLDP Service
3. Start ProcMon and watch all registry-Access filtering Path "MsLldp"
4. Now with running ProcMon I start MSLLDP Service and wait for first LLDP Frames sent on network (Wireshark running to check this)
5. Check ProcMon if there are any interesting Registry-request like e.g. Service Parameters with suspicious Names which could be helpful

=> but no luck with this so far, didn't see anything worth to check in detail

I can see one of the strings I mentioned earlier (ChassisId) being queried. What do you see?

93363-image.jpg

Your Screenshot is very interesting @GaryNebbett,
seems you have some "Agents" registered.

I have no entries in "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsLldp\Parameters\Agents" at all, this Key exists, but no SubKeys or Values there.
And of course I don't have this "ChassisId" entry nor can I see a request like this using ProcMon.

I did not have the Agents subkey initially - in my first capture I could see "open" requests for that key, so I created the key (the GUID is a network interface GUID) and repeated the test.

A quick look at the binary code of mmlldp.sys suggests that the ComputerName registry entry is only requested if the ChassisId value has been successfully read. It will take some more effort to work out exactly what values are needed where and what impact that has on the behaviour of the service.

Thanks @GaryNebbett for this instructions.

Can see the Request for "HKLM\System\CurrentControlSet\Services\MsLldp\Parameters\ChassisId" now.

Hint to myself: ProcMon Filter-Configuration: Remove Default Filter "System" to see Kernel-Activity! :-)

Please try to mark the replies which help you. It will encourage the person who help you.
Appreciate your understanding. :)

@CandyLuo-MSFT there is only a possibility to press "thumbs up" / upvote on those replies which are comments. But almost all Answers given are "Answers" which I can only "upvote" by pressing "Accept Answer", they do not have a "thumbs up" button. But it seems I can only accept ONE answer, trying to mark more than one just leads to error "We're sorry, but this question already has an accepted answer."

Yes, Q&A platform can only accept ONE answer. It doesn't matter, just choose the one you prefer as the answer. It will be very beneficial for other community members who have similar questions to find answers quickly.

Link Layer Discovery Protocol (LLDP) — протокол канального уровня, который позволяет сетевым устройствам анонсировать в сеть информацию о себе и о своих возможностях, а также собирать эту информацию о соседних устройствах.

LLDP это стандартный протокол, который описан в IEEE 802.1AB.

Содержание

Устройство, использующее LLDP, хранит информацию о соседях, но не перенаправляет её дальше (независимо от того поддерживает ли устройство протокол LLDP).

Каждое устройство хранит информацию о соседях в MIB. Поэтому эта информация может использоваться различными управляющими хостами с помощью протокола SNMP.

Например, ProCurve Manager использует информацию LLDP для построения топологии сети и сбора инвентарной информации.

Информация об устройстве, которая может передаваться с помощью LLDP:

  • Имя устройства (System Name),
  • Описание устройства (System Description),
  • Идентификатор порта (Port ID),
  • Описание порта (Port Description),
  • Возможности устройства (System Capabilities),
  • Управляющий адрес (Management Address),
  • и др.



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

  • Коммутатор sw4 получит LLDP-информацию от двух соседей core_sw (через два порта) и sw5400;
  • Коммутатор core_sw получит LLDP-информацию только от sw4 (но через оба порта);
  • Коммутатор sw5400 получит LLDP-информацию только от sw4.

Для LLDP зарезервирован multicast MAC-адрес — 01:80:C2:00:00:0E. Это специальный зарезервированный MAC-адрес, который предполагает, что коммутаторы, получившие кадр с таким адресом получателя, не будут его передавать дальше.

LLDPDU состоит как минимум из четырёх обязательных TLV полей:



  • Chassis ID TLV (Type = 1);
  • Port ID TLV (Type = 2);
  • Time To Live TLV (Type = 3);
  • End of LLDPDU TLV (Type = 0).

Между обязательными TLV (после первых трёх и перед последним) могут размещаться другие (опциональные) TLV, например:

  • Port Description TLV (Type = 4);
  • System Name TLV (Type = 5);
  • System Description TLV (Type = 6);
  • System Capabilities TLV (Type = 7).

В коммутаторах ProCurve таблицы LLDP и CDP взаимно пополняют друг друга. То есть, командами просмотра соседей обнаруженных по LLDP, можно увидеть и CDP-соседей. И наоборот.

По умолчанию на коммутаторах ProCurve включен LLDP, с такими параметрами:

Информация об устройстве на котором выполняется команда:

Пример топологии (команды выполняются на коммутаторе sw4):

LLDP procurve2.jpg

Информация о соседях:

Более подробная информация о соседе на 1 интерфейсе (коммутатор 3 уровня, но в данный момент работает как коммутатор 2 уровня):

Более подробная информация о соседе на 24 интерфейсе (коммутатор 3 уровня):

По умолчанию на коммутаторе включен LLDP.

Если после отключения LLDP, необходимо его снова включить:

Настройка transmit interval (из-за используемой команды называется также refresh interval):

Для изменения delay-interval необходимо использовать команду setmib lldpTxDelay.0 -i <1-8192>. По умолчанию delay-interval равен 2 секундам.

Значение TTL получается по формуле:

Изменение holdtime multiplier (по умолчанию 4):

Delay Interval — коммутатор использует этот интервал для задержки отправки объявлений LLDP, которые отправляются из-за изменений в LLDP MIB. По умолчанию delay-interval равен 2 секундам.

Интервал может быть изменен с помощью управляющего хоста SNMP (NMS) или с помощью команды setmib.

Изменение delay interval:

Изменение reinit interval:

Изменение notification interval:

Просмотр информации о текущих значениях интервалов на коммутаторе:

Пример перевода порта 3 в режим txonly:

Просмотр информации о текущем режиме портов:


Просмотр информации о текущем режиме порта 2:

По умолчанию коммутатор анонсирует управляющий адрес по таким правилам:

  • если порт принадлежит только одному VLAN и в нем есть IP-адрес(а) — он анонсирует наименьший IP-адрес,
  • если порт принадлежит только одному VLAN и в нем нет IP-адреса — он анонсирует 127.0.0.1,
  • если порт принадлежит нескольким VLAN — он анонсирует наименьший IP-адрес из VLAN с наименьшим VID.

Однако, адрес может быть назначен административно.

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

Эта команда не позволяет назначить адрес полученный по DHCP или адрес, который не назначен статически в VLAN на коммутаторе.

Если, например, попытаться назначить несуществующий адрес как управляющий, то коммутатор выдаст такую ошибку:

Просмотр информации о том, какой адрес этот коммутатор анонсирует как управляющий:


Просмотр информации о том, какой адрес сосед анонсирует как управляющий:

Настройки LLDP на коммутаторе:

Информация о настройках LLDP на интерфейсе, в том числе какие TLV отправляются (на коммутаторе с поддержкой LLDP-MED):

Информация о настройках LLDP на интерфейсе, в том числе какие TLV отправляются (на коммутаторе без поддержки LLDP-MED):

Статистика LLDP (на 23 интерфейсе сейчас соседа нет, но статистика о пакетах осталась):

Информация о статистике на конкретном интерфейсе:

Вообще, lldpd поддерживает не только LLDP, но также и CDP, EDP, SONMP и AgentX SNMP.

Активация соответствующих протоколов выполняется ключами:

Установка lldpd осуществляется принятым в дистрибутиве способом:

Ключи демону в Debian передаются через /etc/default/lldpd:

Запуск демона осуществляется командой:

Просмотреть информацию о LLDP-соседях:

На коммутаторе Linux-машина при этом видна так:

Виден её MAC-адрес, имя хоста, а также интерфейс, которым хост подключен к коммутатору.

Среди расширенных сведений можно увидеть версию ядра и IP-адрес системы.

Поддержка LLDP в FreeBSD осуществляется при помощи программы openlldp, доступной в виде порта. Демон openlldpd отправляет по указанному ему сетевому интерфейсу информацию о системе, пользуясь протоколом LLDP.

Домашний сайт проекта: OpenLLDP (англ.)

Для того чтобы хосты Windows также могли использовать LLDP, необходимо установить LLDP-агент. Например, haneWIN LLDP Agent. Этот агент платный, однако в течении 30дневного периода его можно потестировать бесплатно.

Теперь хост по LLDP получил информацию о коммутаторе, к которому он подключен:

HANEWIN info.jpg

Более подробная информация о коммутаторе:

HANEWIN detail.jpg

На коммутаторе Windows-машины с установленным LLDP-агентом видны так:

Более подробная информация:

Информацию о множестве устройств, обменивающихся информацией по LLDP, можно собрать и представить в виде карты сети.

Вот пример простого скрипта, который обходит коммутаторы по SSH, узнает у них информацию о соседях, полученную по LLDP, и на её основе генерирует описание представления сети в виде graphviz-файла, который после дальнейшей обработки превращается в графическую схему:


В результате получаем схему соединения:

Lldp2dot.jpg

Вручную разобраться в хитросплетениях патчкордов было бы значительно сложнее.



Программа wiremaps пользуясь информацией, которую она может получить через протоколы LLDP, EDP, CDP и SONMP, а также из таблиц FDB и ARP, составляет описание сети и предоставляет его пользователю.

Подробнее о программе:

Нечто похожее делает программа NetDisco. Эта информация доступна через web-интерфейс.



Программа NeDi (Network Discovery and Inventory) собирает информацию с управляемых сетевых устройств и ведет учет и статистику как самих устройств, так и абонентских нод. Использует LLDP, CDP и ARP таблицы для построения наглядной топологии в растровом и векторном виде, а также для автоматического поиска новый управлемых устройств.

Подробнее о программе:

Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED) — расширение стандарта LLDP, которое позволяет:

Описан в стандарте ANSI/TIA-1057.

LLDP-MED определяет такие TIA Organizationally Specific TLV:

  • LLDP-MED Capabilities TLV (OUI = 00-12-BB, Subtype = 1)
  • Network Policy TLV (OUI = 00-12-BB, Subtype = 2)
  • Location Identification TLV (OUI = 00-12-BB, Subtype = 3)
  • Extended Power-via-MDI TLV (OUI = 00-12-BB, Subtype = 4)
  • Inventory - Hardware Revision TLV (OUI = 00-12-BB, Subtype = 5)
  • Inventory - Firmware Revision TLV (OUI = 00-12-BB, Subtype = 6)
  • Inventory - Software Revision TLV (OUI = 00-12-BB, Subtype = 7)
  • Inventory - Serial Number TLV (OUI = 00-12-BB, Subtype = 8)
  • Inventory - Manufacturer Name TLV (OUI = 00-12-BB, Subtype = 9)
  • Inventory - Model Name TLV (OUI = 00-12-BB, Subtype = 10)
  • Inventory - Asset ID TLV (OUI = 00-12-BB, Subtype = 11)

Устройства которые поддерживают LLDP-MED разбиты на три класса:

  • Class 1 (generic endpoint devices): Эти устройства поддерживают базовые возможности обнаружения по LLDP, анонсирование сетевых политик (VLAN ID, приоритеты 802.1p и DSCP), управление PoE. Этот класс включает такие устройства как IP call controllers и communication-related сервера.
  • Class 2 (media endpoint devices): Эти устройства поддерживают все возможности первого класса, плюс возможности media streaming. Это такие устройства как voice/media gateways, conference bridges, и media servers.
  • Class 3 (communication devices): Эти устройства поддерживают все возможности первого и второго классов, плюс идентификацию местоположения, emergency 911 capability, поддержку коммутатора 2го уровня, управление информацией об устройстве. Как правило это IP телефоны или софт-телефоны.

Для того чтобы LLDP-MED анонсировал в TLV информацию о VLAN, должен быть создан voice VLAN и порт, на котором находится IP-телефон должен быть тегированным в этом VLAN.

Создание voice VLAN:

Просмотр информации о VLAN (метка voice выставлена у VLAN 10):

Для работы LLDP-MED на коммутаторе обязательно должны быть включены такие TVL (они включены по умолчанию):

  • capabilities — позволяет коммутатору определить тип подключенного устройства и какие TLV устройство поддерживает;
  • network_policy — используется для информирования устройства о номере VLAN (VLAN ID) и настройках QoS, которые ему присвоены. Подключенное устройство использует эту информацию для того чтобы настроить себя для работы в соответствующем VLAN. Если порт принадлежит нескольким voice VLAN, то коммутатор поместит в TLV VLAN с наименьшим VLAN ID.
  • location_id — анонсирует настроенную информацию о местоположении устройства;
  • poe — коммутатор использует это TLV для того чтобы анонсировать возможности и настройки приоритета PoE для порта. Подключенное устройство использует аналогичное TLV для того чтобы сообщить свои требования к PoE.
  • macphy_config — коммутатор и подключенное устройство используют это TLV для того чтобы договариваться о скорости и режиме дуплекса. Поддерживается и в LLDP, но является обязательным только для LLDP-MED.

Информация о TLV на интерфейсе:

Если какие-либо из LLDP-MED TLV были отключены на интерфейсе, то можно их включить с помощью команды:

TLV macphy_config включается так:

Включение/отключение возможности контроля и выделения PoE с помощью LLDP-MED (по умолчанию отключено):

Включить обнаружение PoE с помощью LLDP TLV advertisement:

Существуют аналогичные LLDP проприетарные протоколы обнаружения (discovery protocols):

Согласованная работа различных узлов в локальной сети (LAN) требует корректной конфигурации протоколов и приложений, которые выполняются и поддерживаются ими. По мере того как число различных типов устройств в сети растет, сетевым администраторам все труднее становится отслеживать правильность конфигурации каждого из них, одновременно все большее количество времени тратится на то, чтобы обнаружить и устранить проблемы. Стандарт 802.1AB, или Link Layer Discovery Protocol (LLDP), обеспечит решение проблем конфигурации, вызванных расширением LAN.

Общие положения

LLDP-пакеты передаются периодически и сохраняются в течение определенного времени. Рекомендованная IEEE частота передачи составляет 30 с, но она может регулироваться. Устройства хранят полученные от соседей данные в информационной базе MIB (Management Information Base), которая предусматривается протоколом SNMP. Она актуальна в течение отрезка времени, определяемого значением поля Time to Live (TTL), содержащегося внутри полученного пакета. Рекомендуемое IEEE значение – 120 с, однако допустимый диапазон – от 0 до 65 000 с. Каждый раз, когда устройство получает пакет, оно сохраняет данные и включает таймер, который сравнивается со значением TTL. При совпадении значений устройство удаляет хранимую информацию. Таким образом сетевые системы управления получают только актуальные данные.

Протокол применим для всех сред, предусмотренных стандартом 802. А поскольку он работает только на канальном уровне, то позволяет системам, использующим различные протоколы сетевого уровня, получать информацию друг о друге. Когда два устройства обнаруживают, что они неправильно сконфигурированы, ошибка может быть исправлена с помощью соответствующего приложения. Метод, используемый приложением для разрешения проблемы, протоколом не определяется. Рассмотрим теперь LLDP более детально, не избегая при этом полезных повторений.

Агент LLDP

На сетевом устройстве, которое поддерживает LLDP, должен быть установлен соответствующий агент. Его архитектура просто описывается в терминах SNMP MIB (см. рис.) Информация о локальных (не удаленных) устройствах LAN, передаваемая агентом, сохраняется в базе локальных устройств LLDP local system MIB. В случае, если локальное устройство передает информацию более высокого уровня иерархии – организационного (organization specific information) в формате TLV, она сохраняется в организационной базе локального устройства Organizationally defined local device LLDP. Информация, относящаяся к удаленным устройствам, определяется как удаленная системная информация и хранится в LLDP remote system MIB, а для данных организационного уровня от удаленных устройств предназначается база Organizationally defined remote device LLDP MIB. Следует заметить, что базы организационного уровня не являются обязательными в спецификации протокола.

Как работает агент LLDP

Агент LLDP может оперировать в трех режимах:

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

В типичном случае операции агента реализуются двумя модулями: передающим и приемным. Правда, двухмодульный подход только рекомендуется стандартом, но не является обязательным. При наличии передающего модуля он посылает информацию о локальных устройствах через регулярные отрезки времени. Данные посылаются в формате соответствующих TLV. При запрещении работы модуль передает TLV со значением TTL 0 в информационном поле. Это позволяет удаленным устройствам изъять из своих баз данных информацию, связанную с этим локальным устройством.

Приемный модуль, если он существует, получает информацию от удаленных устройств и обновляет соответствующую базу LLDP MIB. После приема данных запускается таймер для отсчета их времени актуальности, которое определено значением TTL TLV. Информация об удаленных системах стирается из базы при значении TTL 0 в информационном поле TLV.

Протоколом предусматривается передача данных только в одном направлении. То есть LLDP-устройства не обмениваются информацией в режиме запрос–ответ, а также не подтверждают ее получение. Каждый LLDP-пакет должен содержать четыре обязательных TLV:

  • chassis ID TLV: идентифицирует шасси устройств LAN 802;
  • port ID TLV: идентифицирует порт, через который передается LLDP-пакет;
  • TTL TLV: указывает отрезок времени в секундах, в течение которого полученная информация актуальна;
  • end of TLV: определяет конец TLV.

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

Таким образом, сам по себе LLDP не конфигурирует устройства и не управляет трафиком – он только распространяет информацию, относящуюся к конфигурации на уровне 2. И хотя сами устройства не могут запросить данные друг у друга, но приложения по управлению сетью имеют возможность запросить информацию, хранящуюся в базе SNMP MIB, построить текущую физическую топологию сети, а также определить несоответствия в имеющейся конфигурации.

Подключение к Интернету требует бесперебойной работы DNS. К сожалению, проблемы с DNS на Windows 10 распространены достаточно широко. Ниже мы расскажем о нескольких способах их устранения.


Содержание:

Командная строка

Нажмите кнопки «Windows + X» и зайдите в командную строку (администратор).


Последовательно введите следующие команды:

  • ipconfig /flushdns;
  • ipconfig /registerdns;
  • ipconfig /release;
  • ipconfig /renew;
  • NETSH winsock reset catalog;
  • NETSH int ipv4 reset reset.log;
  • NETSH int ipv6 reset reset.log;
  • Exit.

Проверьте, устранена ли неполадка.

Отключение пиринговой загрузки обновлений

Апдейты ОС очень важны для беспроблемного функционирования компьютера, но иногда обновление системы может привести к ошибкам DNS. Одним из вариантов решения такого рода проблем является отключение пиринговой загрузки. Для этого откройте «Настройки» и зайдите в «Update & Security». Выберите «Расширенные настройки», затем кликните на «How updates are delivered». Выберите «PCs on my local network» и отключите обновления из более чем одного источника (Updates from more than one place).


Изменение настроек энергопотребления


Переустановка драйвера сетевого адаптера

В «Менеджере устройств» следует найти сетевой адаптер, кликнуть по нему правой кнопкой и выбрать «Деинсталляция». После завершения удаления снова найдите то же устройство и нажмите на «Обновить драйвер». Выберите опцию автоматического поиска и установки ПО.


Убедитесь, что драйвер протокола Microsoft LLDP включен

Чтобы сделать это, нажмите «Windows + X» и выберите «Сетевые подключения». В открывшемся окне выберите свое подключение и кликните на него правой кнопкой, затем выйдите в «Свойства». Убедитесь, что в перечне напротив драйвера протокола Microsoft LLDP стоит галочка (если нет – поставьте ее).


Чистая загрузка

Некоторые пользователи утверждают, что они исправили проблемы с DNS, выполнив чистую загрузку. По их мнению, определенные сторонние службы мешали DNS, и после их обнаружения и отключения ошибка была устранена. Для выполнения чистой загрузки сделайте следующее:

  • Нажмите «Windows + R» и введите «msconfig».
  • Когда откроется окно «Настройки системы», зайдите в закладку «Services».
  • Выберите «Скрыть все службы Майкрософт» и кликните на «Отключить все».
  • Нажмите «Применить» и «ОК».

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


Смена настроек роутера

Существует мнение, что Windows 10 имеет проблемы при работе с сетями 2,4 ГГц. Поэтому, если ваш роутер поддерживает сеть 5 ГГц, убедитесь, что он использует именно ее. О том, как правильно перенастроить устройство, должно быть написано в инструкции к нему.

Используйте DNS-сервер Google

Если проблема возникла с DNS-сервером вашего провайдера, попробуйте воспользоваться общедоступным сервером Google. Зайдите в «Сетевые подключения», кликните правой кнопкой мышки по вашему соединению и выберите «Свойства». Введите адреса предпочтительного и альтернативного DNS-серверов 8.8.8.8 и 8.8.4.4 соответственно (также иногда используют адреса 208.67.222.222 и 208.67.222.220).


Измените MAC-адрес адаптера

Откройте командную строку как администратор и введите «ipconfig /all». Зайдите в «Physical Address», там вы увидите свой MAC-адрес. Затем откройте «Сетевые подключения» и в них свойства адаптера. Перейдите в «Настроить», далее в закладку «Расширенные». Выделите «Адрес сети», сюда нужно скопировать найденный ранее MAC-адрес. После всех манипуляций перезагрузите компьютер.


Удалите ключи Winsock из реестра

Нажмите «Windows + R», введите «regedit». Перейдите по HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services. В списке выделите ключи Winsock и Winsock2, выберите «Экспорт». Сохраните их как winsock и winsock2. После того, как экспортируете ключи, удалите исходники. Перезагрузите компьютер и заново запустите редактор реестра. Выберите File>Import. Поочередно импортируйте winsock и winsock2, затем снов перезагрузите ПК.

Поделитесь в соцсетях:

Согласованная работа различных узлов в локальной сети (LAN) требует корректной конфигурации протоколов и приложений, которые выполняются и поддерживаются ими. По мере того как число различных типов устройств в сети растет, сетевым администраторам все труднее становится отслеживать правильность конфигурации каждого из них, одновременно все большее количество времени тратится на то, чтобы обнаружить и устранить проблемы. Стандарт 802.1AB, или Link Layer Discovery Protocol (LLDP), обеспечит решение проблем конфигурации, вызванных расширением LAN.

Общие положения

LLDP-пакеты передаются периодически и сохраняются в течение определенного времени. Рекомендованная IEEE частота передачи составляет 30 с, но она может регулироваться. Устройства хранят полученные от соседей данные в информационной базе MIB (Management Information Base), которая предусматривается протоколом SNMP. Она актуальна в течение отрезка времени, определяемого значением поля Time to Live (TTL), содержащегося внутри полученного пакета. Рекомендуемое IEEE значение – 120 с, однако допустимый диапазон – от 0 до 65 000 с. Каждый раз, когда устройство получает пакет, оно сохраняет данные и включает таймер, который сравнивается со значением TTL. При совпадении значений устройство удаляет хранимую информацию. Таким образом сетевые системы управления получают только актуальные данные.

Протокол применим для всех сред, предусмотренных стандартом 802. А поскольку он работает только на канальном уровне, то позволяет системам, использующим различные протоколы сетевого уровня, получать информацию друг о друге. Когда два устройства обнаруживают, что они неправильно сконфигурированы, ошибка может быть исправлена с помощью соответствующего приложения. Метод, используемый приложением для разрешения проблемы, протоколом не определяется. Рассмотрим теперь LLDP более детально, не избегая при этом полезных повторений.

Агент LLDP

На сетевом устройстве, которое поддерживает LLDP, должен быть установлен соответствующий агент. Его архитектура просто описывается в терминах SNMP MIB (см. рис.) Информация о локальных (не удаленных) устройствах LAN, передаваемая агентом, сохраняется в базе локальных устройств LLDP local system MIB. В случае, если локальное устройство передает информацию более высокого уровня иерархии – организационного (organization specific information) в формате TLV, она сохраняется в организационной базе локального устройства Organizationally defined local device LLDP. Информация, относящаяся к удаленным устройствам, определяется как удаленная системная информация и хранится в LLDP remote system MIB, а для данных организационного уровня от удаленных устройств предназначается база Organizationally defined remote device LLDP MIB. Следует заметить, что базы организационного уровня не являются обязательными в спецификации протокола.

Как работает агент LLDP

Агент LLDP может оперировать в трех режимах:

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

В типичном случае операции агента реализуются двумя модулями: передающим и приемным. Правда, двухмодульный подход только рекомендуется стандартом, но не является обязательным. При наличии передающего модуля он посылает информацию о локальных устройствах через регулярные отрезки времени. Данные посылаются в формате соответствующих TLV. При запрещении работы модуль передает TLV со значением TTL 0 в информационном поле. Это позволяет удаленным устройствам изъять из своих баз данных информацию, связанную с этим локальным устройством.

Приемный модуль, если он существует, получает информацию от удаленных устройств и обновляет соответствующую базу LLDP MIB. После приема данных запускается таймер для отсчета их времени актуальности, которое определено значением TTL TLV. Информация об удаленных системах стирается из базы при значении TTL 0 в информационном поле TLV.

Протоколом предусматривается передача данных только в одном направлении. То есть LLDP-устройства не обмениваются информацией в режиме запрос–ответ, а также не подтверждают ее получение. Каждый LLDP-пакет должен содержать четыре обязательных TLV:

  • chassis ID TLV: идентифицирует шасси устройств LAN 802;
  • port ID TLV: идентифицирует порт, через который передается LLDP-пакет;
  • TTL TLV: указывает отрезок времени в секундах, в течение которого полученная информация актуальна;
  • end of TLV: определяет конец TLV.

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

Таким образом, сам по себе LLDP не конфигурирует устройства и не управляет трафиком – он только распространяет информацию, относящуюся к конфигурации на уровне 2. И хотя сами устройства не могут запросить данные друг у друга, но приложения по управлению сетью имеют возможность запросить информацию, хранящуюся в базе SNMP MIB, построить текущую физическую топологию сети, а также определить несоответствия в имеющейся конфигурации.

Протокол LLDP (Link Layer Discovery Protocol) позволяет сетевым устройствам передавать информацию о себе и своих возможностях, а также получать эту информацию о соседних устройствах, подключенных по Ethernet портам.

LLDP — это протокол канального уровня, который описан в стандарте IEEE802.1AB .

Оборудование передает кадры LLDP по сети Ethernet через определенные интервалы времени периодически. Каждый кадр LLDP имеет Multicast MAC адрес 01:80:C2:00:00:0E получателя и Ethertype поле 0x88CC по стандарту IEEE802.1AB .

Все Organizationally Specific TLV элементы имеют Type = 127 и используются для передачи TLV элементов различных компаний и организаций (например, информацию о VLAN Name и Link Aggregation и др.)

Пример кадра LLDP


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

Функционал LLDP-MED используется для:

  • определения типа подключенного устройства (IP-телефон или коммутатор и др.),
  • отображения информации о модели и серийном номере оборудования, версии программного обеспечения на оборудовании,
  • динамической настройки метки VLAN и QoS (Quality of Service) на порте для передачи трафика IP-телефонии,
  • динамической настройки электропитания PoE (Power over Ethernet) на порте.

В частности, элемент Network Policy TLV используется для передачи информации и метке VLAN и IP DSCP для QoS (Quality of Service) и элемент Extended Power-via-MDI TLV используется для передачи информации о настройке электропитания PoE (Power over Ethernet).

Протокол LLDP-MED часто используется в сетях при развертывании VoIP сервисов. Если оборудование IP телефонии поддерживает LLDP-MED, то оно может получать настройки Voice VLAN по протоколу LLDP-MED. На коммутаторах Raisecom можно настроить LLDP-MED таким образом, чтобы передавать информацию о Voice VLAN на подключенные IP-телефоны.


На схеме с примером топологии порт GE 1/1/1 коммутатора соединяет IP-телефон и компьютер с вышестоящей сетью. Требуется разделить голосовой трафик и передачу остальных данных по разным VLAN.

Для этого необходимо настроить GE 1/1/1 в режим Trunk, пустить передачу данных по Native VLAN (VLAN 100), а голосовой трафик по Voice VLAN (VLAN 200). Компьютер (ПК) отправляет untagged пакеты, которые передаются в Native VLAN интерфейса GE 1/1/1. IP телефон при этом будет получать LLDP пакеты, из которых сможет определить номер Voice VLAN. Этот VLAN используется телефоном для дальнейшей работы.

1. Создадим VLAN 100 и VLAN 200, активируем их, настроим VLAN 200 как Voice VLAN.

2. Включим глобально LLDP и LLDP на интерфейсе, чтобы передавать voice VLAN на IP телефон.

3. (Опциональный) по умолчанию интерфейс изменяет CoS и DSCP настройки QoS для голосовых пакетов на 6 и 46 соответственно. Для изменения настроек QoS можно использовать команду:

или доверять меткам CoS и DSCP от VoIP телефона на этом порте:

4. Для сохранения настроек команда «write» :

Пакет Yealink T26P LLDP-MED


Пакет Raisecom LLDP-MED:


Заключение

В статье описано назначение протокола LLDP и расширения LLDP-MED. Также приведены настройки LLDP-MED и Voice VLAN на Ethernet коммутаторах доступа Raisecom.

Читайте также: