D link discovery protocol что это

Обновлено: 30.06.2024

Задача: базовая настройка управляемого коммутатора, с использованием "интерфейса командной строки" (CLI). Под "базовой" я понимаю настройку минимально необходимого функционала с попутным явным отключением всего не задействованного и могущего внести смущение в умах.

На свежеиспечённый коммутатор можно зайти как минимум тремя способами:

подключившись к любому клиентскому Ethernet-порту, обращаясь по IP-адресу 10.90.90.90/8;
подключившись к специальному Ethernet-порту, предназначенному для управления устройством, обращаясь по IP-адресу 192.168.0.1/24;
подключившись к "консольному" порту RS-232 специальным кабелем DB-9 имеющим на сторону устройства разъём типа RJ-45.

Мне ближе последний вариант, подключение к "консольному" порту - он работает вне зависимости от текущей сетевой конфигурации устройства.

Рекомендованные производителем параметры подключения к "консольному" порту следующие:

terminal - "VT 100+";
speed - 115200 baud;
parity - none;
data bits - 8;
stop bit - 1;
sofware flow control - none;
hardware flow control - none.

Запускаем программу "терминального" клиента:

DGS-3620-28TC Gigabit Ethernet Switch
Command Line Interface

Просто нажимаем пару раз "Enter", проходя этапы ввода логина и пароля, и вот, мы можем просмотреть текущую конфигурацию устройства:

Device Type : DGS-3620-28TC Gigabit Ethernet Switch
MAC Address : MAC
IP Address : 10.90.90.90 (Manual)
VLAN Name : default
Subnet Mask : 255.0.0.0
Default Gateway : 0.0.0.0
Boot PROM Version : Build 1.00.016
Firmware Version : Build 1.00.040
Hardware Version : A1
Firmware Type : EI
Serial Number : Serial
System Name :
System Location :
System Uptime : 0 days, 0 hours, 42 minutes, 50 seconds
System Contact :
Spanning Tree : Disabled
GVRP : Disabled
IGMP Snooping : Disabled
MLD Snooping : Disabled
RIP : Disabled
RIPng : Disabled
DVMRP : Disabled
PIM : Disabled
PIM6 : Disabled
OSPF : Disabled
OSPFv3 : Disabled
BGP : Disabled
VLAN Trunk : Disabled
Telnet : Enabled (TCP 23)
Web : Enabled (TCP 80)
SNMP : Disabled
SSL Status : Disabled
SSH Status : Disabled
802.1X : Disabled
Jumbo Frame : Off
CLI Paging : Enabled
MAC Notification : Disabled
Port Mirror : Disabled
SNTP : Disabled
DHCP Relay : Disabled
DNSR Status : Disabled
VRRP : Disabled
HOL Prevention State : Enabled
Syslog Global State : Disabled
Single IP Management : Disabled
Password Encryption Status : Disabled
DNS Resolver : Disabled

Приступим к конфигурированию как таковому.

На всякий случай явно отключаем автоматическую настройку с помощью DHCP и получение конфигурации с TFPD-сервера:

Назначим свой IP-адрес:

Отключим ненужный нам пока функционал поддержки протокола IPv6:

Удостоверимся в том, что изменения приняты:

IP Interface : System
VLAN Name : default
Interface Admin State : Enabled
DHCPv6 Client State : Disabled
IPv4 Address : 192.168.1.2/24 (Manual) Primary
Proxy ARP : Disabled (Local : Disabled)
IP Directed Broadcast : Disabled
IPv4 State : Enabled
IPv6 State : Disabled
IP MTU : 1500

IP Interface : mgmt_ipif
Status : Enabled
IP Address : 192.168.0.1
Subnet Mask : 255.255.255.0
Gateway : 0.0.0.0
Link Status : Link Down

Total Entries: 2

Обратите внимание на то, что "shell" устройства регистро-чувствительный, в частности, имя интерфейса "System" так и вводится, с большой буквы, в то время как другие операнды и операторы - с маленькой.

Задаём маршрут по умолчанию, необходимый для обеспечения доступности управляющего функционала коммутатора:

Удостоверимся, что маршрут верно задан:

Проверим, достижим ли с коммутатора какой-нибудь удалённый ресурс:

Reply from 192.168.12.12, time<10ms
Reply from 192.168.12.12, time<10ms
Reply from 192.168.12.12, time<10ms
Ping Statistics for 192.168.12.12
Packets: Sent =4, Received =4, Lost =0

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

Отключаем расширенную систему авторизации на устройстве, оставляя локальную базу:

Задаём пароль для повышения уровня привилегий, перехода "enable":

Создаём парочку административных аккаунтов:

Enter a case-sensitive new password:********
Enter the new password again for confirmation:********
Success.

Когда придёт в голову сменить пароль, делаем это так:

Удостоверимся, что аккаунты созданы в том виде, как нам было угодно:

Username Access Level
------------ ------------
superadmin Admin
trivialadmin Admin

Велим коммутатору шифровать сохранённые в энергонезависимой памяти пароли:

Включаем поддержку доступа к устройству по протоколу SSH:

Отключаем поддержку небезопасного протокола доступа к устройству Telnet:

Явно указываем, каким образом мы будем проходить проверку подлинности:

Задаём параметры подключения клиента SSH к серверу:

Вводим заранее созданных пользователей в список допущенных для работы с SSH:

Отдельно явно разрешаем использование протокола шифрования трафика SSH:

Сохраняем всё, и настройки и журнал событий, в энергонезависимую память:

Теперь идём на своё рабочее место и подключаемся к устройству используя для этого протокол SSH.

Первым делом стоит подкорректировать настройки портов. Такие "железки", как стекируемые гигибитные коммутаторы обычно не на тривиальный клиентский доступ берутся. Например, у нас они применяются на связке пула серверов виртуализации и пачки серверов распределённой сетевой файловой системы оптической магистралью в 20Gbps. Подключаемое оборудование оснащено сетевыми интерфейсами поддерживающими всё и даже гораздо более того, на что способны эти коммутаторы; потому конфигурация портов фиксировано задаётся пиковой. Например таким образом:

Здесь мы предписали портам навязывать свою конфигурацию клиенту, задав скоростные характеристики в 1Gbps с полным дуплексом, предлагая аппаратный контроль потока передаваемых данных и выделили четыре "оптических" SFP-порта для связи с другими коммутаторами.

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

Следует иметь в виду, что у D-Link при конфигурировании "гигабитных" "медных" портов нужно явно указывать, какая сторона ведущая, а какая ведомая. В частности, если этот коммутатор "ведущий" (master), что на втором "гигабитные" порты должны быть инициированы как "ведомые" (slave), например:

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

Далее следует чуть подкорректировать общие настройки, имеющие отношение к обеспечению условий коммутации.

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

Для отлова "петель" в сети коммутации используем специализированный функционал коммутатора, регулярно посылающий тестовый пакет обнаружения "loopback" (это работает независимо от протокола STP):

recover_timer - время (в секундах), в течение которого порты будут отключены;
interval - период (в секундах) между отправкой пакетов обнаружения петли.

В качестве дополнительной меры обеспечения доступности сервисов, представляемых коммутатором, включим поддержку "Safeguard engine", режима, в котором отбрасываются или отправляются в конец очереди (с пониженным приоритетом) все ARP и "широковещательные" пакеты тогда, когда загрузка процессора возрастёт выше установленного порога:

rising 90 - процент загрузки процессора, выше которого включается режим "Safeguard engine";
falling 30 - процент загрузки, ниже которого выключается "Safeguard engine";
mode fuzzy - выбираем режим мягкого противодействия нагрузке, когда широковещательные и ARP пакеты не откидываются полностью, а лишь понижаются в приоритете при обработке.

Считаю полезным воспользоваться функциональностью отслеживания и обхода состояния HOL (Head-of-line blocking), блокировки FIFO буфера исходящей очереди интерфейса пакетами входящей очереди "медленного" или просто сбоящего интерфейса при том, что в ту же исходящую очередь направляются пакеты входящей очереди гораздо более "быстрого" интерфейса. Активируем механизм, справляющийся с проблемами HOL:

Далее - общесистемные мелочи.

Велим коммутатору отправлять на удалённый сервер данные своего журнала событий:

Научим наш коммутатор выспрашивать точное время у соответствующих серверов.

Задаём "часовой пояс":

Отключим перевод на "летнее время":

Укажем наши сервера точного времени:

Отключим поддержку протокола PTP (Precision Time Protocol), протокола сверхточной синхронизации времени для промышленных сетей:

Далее отключим то, что не подпадает под понятие базовой настройки.

Отключаем перенаправление DHCP запросов на целевой сервер и функционал встроенного DHCP-сервера как такового:

Отключаем подсистему разрешения доменных имён DNS, как невостребованную на уровне коммутации:

Отключаем систему уведомления SNMP сервера о изменении MAC клиента на портах:

Отключим поддержку рассылки "самопроизвольного ARP" (Gratuitous ARP) (применяется для определения конфликтов IP-адресов в сегменте сети: как только интерфейс инициирует адрес, рассылается ARP-ответ без запроса):

Отключим функционал IMPB (IP-MAC-Port Binding), позволяющий контролировать доступ в сеть на основе связки IP, MAC и порта подключения:

Явно отключим поддержку контроля трафика на основе MAC-адресов (MAC-based ACL):

Отключаем поддержку протокола STP и вспомогательного протокола PDU (Bridge Protocol Data Unit) управления сетевыми мостами:

Отключаем поддержку протокола ERPS (Ethernet Ring Protection Switching), использующегося для исключения образования колец в топологии (может применяться как замена семейству протоколов STP):

Отключаем протокол оповещения и сбора информации о соседнем оборудовании LLDP (Link Layer Discovery Protocol) (свободная замена таким протоколам, как: Cisco Discovery Protocol, Extreme Discovery Protocol, Foundry Discovery Protocol или Nortel Discovery Protocol). Вещь полезная, но не особо нужная до понимания целесообразности применения:

Отключаем богатый и полезный, но не нужным нам пока, функционал CFM (Connectivity Fault Management, 802.1ag) предоставляющий возможности наблюдения, поиска и устранения неисправностей в сетях Ethernet, позволяя контролировать соединение, изолировать проблемные участки сети и идентифицировать клиентов, к которым применялись ограничения в сети:

Отключаем функционал единого адреса для стека коммутаторов:

Отключаем функционал объединения нескольких коммутаторов в "стек" (Stacking):

Отключаем авторизацию клиентов на портах:

Отключаем инкапсуляцию тегов VLAN в теги VLAN второго уровня:

Если к коммутатору не подключены VoIP-телефоны Cisco со встроенным мини-свичём, изолирующим VoIP-трафик путём тегирования с помощью 802.1q, то отключим функционал распознавания вторичного VoiceVLAN на портах:

Явно отключаем управление "мульткастом", если он не используется:

Отключаем поддержку "независимого от протокола мультикаста" PIM (Protocol Independent Multicast) (называется протоколо-независимым, потому что базируется на традиционных маршрутных протоколах, вроде BGP, вместо того, чтобы создавать собственную сетевую топологию):

Отключаем поддержку ещё одного специфичного протокола "мультикаста" DVMRP (Distance Vector Multicast Routing Protocol - протокол дистанционно-векторной многоадресной маршрутизации):

Раз уж мы занялись искоренением ненужной нам функциональности маршрутизации - погасим поддержку динамической маршрутизации и для "Layer 3".

Отключим поддержку BGP (Border Gateway Protocol):

Отключим поддержку OSPF (Open Shortest Path First):

Отключим поддержку RIP (Routing Information Protocol):

Отключаем поддержку протокола ECMP (Equal-Cost Multi-Path). ECMP работает совместно с протоколами маршрутизации, такими как RIP и OSPF, и позволяет установить несколько равноценных маршрутов для передачи данных:

Отключаем поддержку VRRP (Virtual Router Redundancy Protocol) - сетевого протокола, предназначенного для увеличения доступности маршрутизаторов выполняющих роль шлюза по умолчанию путём объединения группы маршрутизаторов в один виртуальный маршрутизатор:

Если коммутатор только коммутирует, а не занимается туннелированием, то отключаем поддержку L2PT (Layer 2 Protocol Tunneling). L2PT позволяет передавать инкапсулированные блоки данных протокола (PDU) "Layer 2", таких, как STP (Spanning Tree Protocol), CDP (Cisco Discovery Protocol), VTP (VLAN Trunking Protocol), PAgP (Port Aggregation Protocol), LACP или UDLD (UniDirectional Link Detection):

Отключаем зеркалирование портов (применяется для мониторинга и сбора статистики). Различают две технологии SPAN (Switch Port Analyzer в терминологии Cisco). SPAN работает в пределах одного коммутатора, а RSPAN (Remote Switch Port Analyzer) может зеркалировать и передавать трафик между коммутаторами. Если я верно понял, D-Link называет SPAN как "mirror";

Отключаем поддержку sFlow (стандарт для мониторинга компьютерных сетей). Насколько я понял, sFlow является открытым отраслевым стандартом и продвигается в качестве замены "цисковского" NetFlow:

Явно отключаем поддержку "Jumbo Frame", "сверхдлинных Ethernet-кадров", до понимания сферы применения:

Напоследок рекомендую отключить "web"-интерфейс и связанные с ним подсистемы контроля доступа WAC (Web-based Access Control):

CLI предоставляет достаточно инструментария для контроля и мониторинга устройства, например:

В общем, все. Теперь можете приступать к чтению руководства администратора от разработчиков коммутатора, чтобы осмыслить, как освоить оставшиеся здесь неосвещёнными 90% функционала устройства.

[ уже посетило: 32950 / +16 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Агент 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. Следует заметить, что базы организационного уровня не являются обязательными в спецификации протокола.

D link discovery protocol что это

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

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

5.2. Конфигурация LLDP

Включить функцию LLDP и настроить статус порта;

Настроить отправку Trap;

Настроить информацию, передаваемую опционально;

Настроить таблицу соседей;

Вывод информации и отладка.

Включить функцию LLDP и настроить статус порта:

Команда

Описание

! В режиме глобальной конфигурации

Включить LLDP глобально. Команда no отключает эту функцию

! В режиме конфигурации порта

Включить LLDP на порту. Команда no отключает эту функцию

lldp mode (send|receive|both|disable)

! В режиме конфигурации порта

Настроить режим LLDP на порту, send - только отправка, receive - только прием, both - оба направления (по умолчанию)

2. Настроить таймеры:

Команда

Описание

lldp tx-interval <integer>

no lldp tx-interval

! В режиме глобальной конфигурации

no lldp msgTxHold

! В режиме глобальной конфигурации

Настроить количество интервалов tx-interval - время жизни информации о соседе LLDP с момента последнего обновления. Команда no восстанавливает конфигурацию по-умолчанию - 4.

lldp transmit delay <seconds>

no lldp transmit delay

! В режиме глобальной конфигурации

3. Настроить отправку Trap:

Команда

Описание

lldp trap <enable|disable>

! В режиме конфигурации порта

Включить LLDP trap для порта. Команда no отключает эту функцию.

lldp notification interval <seconds>

no lldp notification interval

! В режиме глобальной конфигурации

Задать время отправки trap после изменения LLDP таблицы. Команда no восстанавливает конфигурацию по-умолчанию - 5 секунд.

4.Настроить информацию, передаваемую опционально:

Команда

Описание

lldp transmit optional tlv [portDesc] [sysName] [sysDesc] [sysCap]

no lldp transmit optional tlv

! В режиме конфигурации порта

Задать LLDP TLV отправляемые опционально:

portDesc - description порта, sysName - имя коммутатора (hostname), sysDesc - описание коммутатора, sysCap - возможности системы. Команда no отключает опциональные tlv

lldp management-address tlv [A.B.C.D]

no lldp management-address tlv

! В режиме конфигурации порта

Передавать в качестве management-address tlv адрес [A.B.C.D]. Команда no отключает эту функцию.

5. Настроить таблицу соседей:

Команда

Описание

lldp neighbors max-num < value >

no lldp neighbors max-num

! В режиме конфигурации порта

Задать максимальное число соседей на порту. Команда no восстанавливает конфигурацию по-умолчанию - 100.

! В режиме конфигурации порта

Задать действие при получении информации от нового соседа при превышении максимального числа соседей. delete - удалить соседа с наименьшим временем жизни, discard - не записывать информацию о новом соседе (по-умолчанию).

6. Вывод информации и отладка:

Команда

Описание

! В Admin режиме

Вывести суммарную информацию о конфигурации LLDP на коммутаторе.

show lldp interface ethernet <IFNAME>

! В Admin режиме

Вывести информацию по конфигурации LLDP на порту коммутатора.

show lldp traffic

! В Admin режиме

Вывести суммарную информацию об отправленных и полученных пакетах LLDP.

show lldp neighbors interface ethernet < IFNAME >

! В Admin режиме

Вывести информацию о соседях LLDP на интерфейсе

! В Admin режиме

Выводить отладочную информацию о работе протокола LLDP на коммутаторе. Команда no останавливает вывод информации.

debug lldp packets interface ethernet <IFNAME>

no debug lldp packets interface ethernet <IFNAME>

! В Admin режиме

Выводить отладочную информацию о работе протокола LLDP на порту коммутатора. Команда no останавливает вывод информации.

show debugging lldp

! В Admin режиме

Вывести информацию о состоянии вывода отладки LLDP на коммутаторе.

clear lldp remote-table

! В режиме конфигурации порта

Очистить информацию о соседях LLDP на интерфейсе.

Протокол обнаружения сетевых устройств на канальном уровне

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

05. LLDP

LLDP (Link Layer Discovery Protocol, 802.1ab) - протокол канального уровня, позволяющий коммутатору оповещать оборудование, работающее в локальной сети, о своем существовании и передавать ему свои характеристики, а также получать от него аналогичные сведения. Каждое устройство LLDP может отправлять информацию о себе соседям независимо от того, отправляет ли сосед информацию о себе. Устройство хранит информацию о соседях, но не перенаправляет её. Коммутатор может передавать и принимать такую информацию, как: имя порта (Port name), идентификатор порта (PortID), аппаратный адрес (ChassisID), адрес управления (Management address), описание порта (PortDesc), описание устройства (SysDesc).

Полученная информация может быть запрошена с помощью стандартных SNMP MIB и использоваться в NMS для сбора информации и построения топологии сети.

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

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

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

Применение LLDP-MED на коммутаторах для назначения VOIP VLAN

Протокол 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, на вышестоящий сервер управления по протоколу SNMP. При этом на сервере управления может автоматически отображаться топология сети.

LLDP-MED (Media Endpoint Discovery) - это расширение стандарта LLDP, которое позволяет передавать информацию между сетевым оборудованием, например Ethernet коммутаторами, и конечными устройствами (такими как IP телефоны или шлюзы VoIP).

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

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

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)

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

Пример настройки LLDP-MED на оборудовании Raisecom

Протокол 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» :

5. Для просмотра настроек Voice VLAN и LLDP-MED можно использовать команды:

Пакет Yealink T26P LLDP-MED

Пакет Raisecom LLDP-MED:

Заключение

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

5.3. Пример конфигурации LLDP

Конфигурация коммутаторов будет выглядеть следующим образом:
Конфигурация коммутатора Switch A:

Содержание

Устройство, использующее 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):

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

Более подробная информация о соседе на 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 получил информацию о коммутаторе, к которому он подключен:

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

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

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

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

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

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

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

Программа 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):

Как работает агент 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, построить текущую физическую топологию сети, а также определить несоответствия в имеющейся конфигурации.

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