Недавно обратился заказчик, который эксплуатирует стек из S5720-52X-PWR-SI и дюжину IP телефонов Avaya и Grandstream. С Avaya проблем не было, а вот Grandstream периодически отключались, при этом отключались спонтанно и выборочно. Зависимостей не было обнаружено: в отдельные дни могло быть до 30 отключений, в другие 1-2. Некоторые аппараты отключались чаще, другие – реже. C PoE и с кабельной трассой проблем не было. Больше подозрений вызвала именно конфигурация портов в режиме hybrid...
08:42:25+03:00 SW-HUAWEI POE/4/POWEROFF:OID 1.3.6.1.4.1.2011.5.25.195.40.2 PD powered off.
08:42:23+03:00 SW-HUAWEI POE/4/POWERON:OID 1.3.6.1.4.1.2011.5.25.195.40.3 PD powered on.
Сначала мы рекомендовали включить на портах LLDP (lldp enable), если подключенные к ним устройства работают по стандарту 802.3at: LLDP нужен для согласования PoE сигнала. Но клиент уточнил, что использует Grandstream GXP 2560. Спецификация по Grandstream GXP 2560 утверждает, что телефон работает по стандарту 802.3af. LLDP нужен для согласования PoE сигнала при работе по стандарту 802.3at, но не 802.3af. Мы проверили командой display poe power slot X - да, с порта коммутатора отдавалось 15,4 Вт (стандарт 802.3at PoE обеспечивает 25,5 Вт, а 802.3af - 15,4 Вт):
GigabitEthernet5/0/15 3 15400 30000 2968 2968 2915
После мы обратили внимание на другой лог, который указывал на то, что поддерживаемый ток используемого PD (Powered Device – IP телефон в нашем случае) недостаточен в момент включения, поэтому коммутатор PoE считал, что PD отключился, и выключал PoE на порту. Стандарты IEEE требуют, чтобы PD поддерживал значение тока более 10 мА в течение не менее 75 мс в течение каждых 325 мс. В противном случае коммутатор PoE считает, что PD отсоединен. Вот этот лог:
%%01POE/6/PDPOWEROFF(l)[]:Slot=X;PD on the interface GigabitEthernet5/0/15 is powered off. (Reason=The PD was disconnected, the inrush current exceeded the PD threshold, or MPS current was too low.)
Мы прошлись по официальному траблшутингу и сначала жестко прописали указание на стандарт 802.3af: poe af-inrush enable (в представлении интерфейса). Далее установили задержку в 3 секунды poe power-on delay 3 (в представлении интерфейса). Поскольку время флапов указанных линков составляло меньше 3 секунд, мы полагали, что может иметь место деградация физического соединения между коммутатором и телефонами. Чтобы нивелировать этот флап, мы предложили установить задержку сохранения соединения выше этого значения (значение по умолчанию – 0 секунд). В результате это дало только субъективный эффект: по ощущениям телефоны стали отключаться реже. Проверка СКС не выявила изъянов.
Мы продолжили копаться в логах и нашли, что каждому отключению телефона предшествовало сообщение в логах об изменении статуса MSTP порта без изменения физического статуса порта: порт переходил в состояние discarding, а затем тут же в forwarding. После этого сервис прекращался и в логи начинало валиться сообщение - Not hit the user-bind table.
Входящий пакет мачился командой arp anti-attack check user-bind enable прописанной на VLAN 7 для голосового трафика. Поскольку VLAN 7 явно прописан не был на порту, то по умолчанию разрешался VLAN 1 и трафик, который мачился user-bind таблицей, то есть voice-vlan:
interface GigabitEthernet0/0/1
description ==
port link-type hybrid
stp edged-port enable
dot1x domain 8021x
poe af-inrush enable
poe power-on delay 3
dot1x enable
dot1x reauthenticate
undo lldp enable
vlan 7
name voice-vlan
dhcp snooping enable
arp anti-attack check user-bind enable
Интересно то, что после того, как телефон "дергали по питанию", чтобы его перезагрузить и восстановить сервис, то в логах было сообщение о переходе этого порта в состояние forwarding, но для разных MSTP instance: для 0-го по умолчанию, и сконфигурированного 1-го:
23:49:55+03:00 SW-HUAWEI MSTP/4/PFWD:OID 1.3.6.1.4.1.2011.5.25.42.4.2.1 The port has been set to forwarding state. (InstanceID=0, PortInstanceID=0, PortID=224, IfIndex=124, PortName=GigabitEthernet5/0/15)
23:49:55+03:00 SW-HUAWEI MSTP/4/PFWD:OID 1.3.6.1.4.1.2011.5.25.42.4.2.1 The port has been set to forwarding state. (InstanceID=1, PortInstanceID=1, PortID=224, IfIndex=124, PortName=GigabitEthernet5/0/15)
stp region-configuration
instance 1 vlan 2 to 4000
active region-configuration
То есть порт работал с двумя VLAN: 1-ым и 7-ым voice-vlan, которые принадлежали разным instance. И когда по какой-то причине MSTP статус порта флапался, то получалось, то пакет с тем же MAC адресом поступал с другого VLAN (с 1-го), а в user-bind таблице уже была запись, что этот MAC ассоциирован с 7-ым VLAN. В результате коммутатор отбросывал пакет.
Нам не удалось пока установить, почему порт менял MSTP состояния - явных причин на то не было. Однако ясно, что несмотря на то, что на порту был настроен edged-port, или portfast (команда на Huawei - stp edged-port enable) порт продолжал участвовать в STP: он продолжал принимать и рассылать BPDU. По концепции, edged-port не отключает STP на порту, он делает переход из состояния discarding в forwarding за какие-то 0,0001 секунды: он пропускает learning фазу (15 секунд), и не отправляет конфигурационного BPDU - Topology Change Notification (TCN). При этом все три фазы на коммутаторе Huawei отражаются в логах:
23:49:55+03:00 SW-HUAWEI %%01MSTP/4/SET_PORT_DISCARDING(l)[-]:In MSTP process 0 instance 0, MSTP set port GigabitEthernet5/0/15 state as discarding.
23:49:55+03:00 SW-HUAWEI %%01MSTP/4/SET_PORT_LEARNING(l)[1]:In MSTP process 0 instance 0, MSTP set port GigabitEthernet5/0/15 state as learning.
23:49:55+03:00 SW-HUAWEI %%01MSTP/4/SET_PORT_FORWARDING(l)[2]:In MSTP process 0 instance 0, MSTP set port GigabitEthernet5/0/15 state as forwarding.
Мы рекомендовали клиенту выпилить VLAN 1 из конфигурации интерфейсов (команда undo port hybrid vlan 1), и жестко прописать vlan 7 на порту (voice-vlan 7 enable include-untagged и port hybrid untagged vlan 7). Есть три правила работы с voice VLAN на коммутаторах Huawei:
1.VLAN 1 не может быть сконфигурирован как voice VLAN.
2.Voice VLAN и VLAN по умолчанию должны быть разными.
3.Только один voice VLAN может быть сконфигурирован на интерфейсе как voice VLAN.
P.S.
Поскольку нам пока не удалось установить причину флапов портов, мы и назвали пост "нераскрытым инцидентом", но собранной информации посчитали достаточной, чтобы поделиться ею с вами.
--
Разве stp edged-port не отключает STP протокол на интерфейсе?
--
