Что из себя представляют Keepalive сообщения на Cisco switch?
ISP->медиаконвертер->коммутатор
Интерфейс в сторону провайдера падает в errdisable:
%PM-4-ERR_DISABLE: loopback error detected on Gi0/2, putting Gi0/2 in err-disable state.
Проблема в том, что приходит обратно keepalive самого коммутатора, поэтому он лочит порт, как только делаю [no keepalive] на интерфейсе, проблема уходит(канал в норме, flood'a нет, петли у IPS нет)
Вот что пишет Cisco:
A loopback error occurs when the keepalive packet is looped back to the port that sent the keepalive. The switch sends keepalives out all the interfaces by default. A device can loop the packets back to the source interface, which usually occurs because there is a logical loop in the network
Все хорошо и понятно, но что из себя представляет в данном случае этот keepalive фрейм и что подразумевается под logical loop(это не L2 петля)
keepalive это мультикастовый фрейм, который отправляется коммутатором, а в случае, если такой фрейм коммутатор получит со своим мак-адресом в качестве отправителя, считается, что образовалась петля. В данном контексте logical loop это именно L2 петля.
Может быть у провайдера что-то, может у самой циски с портом. show errdisable recovery что говорит?
Порт на коммутаторе менять пробовали?
errdisable говорит что петля, убираю keepalive, STP молчит, шторма нет . Это не может быть L3 мультикаст, так как это комок. Если, как вы говорите, это L2 мультикаст, то SRC mac = Switch mac, DST mac = FF::FF, тогда все логично
Но нашел инфу что это фрейм SRC=DST, поле Ethernet type = 0x9000. В таком случае если коммутатор выплевывает данный фрейм из своего интерфейса, то устройство обрабатывающее фреймы на другой стороне должно вернуть его в том же виде(SRC mac = DST mac) и соответственно errdisable потушить интерфейс из-за петли. Или это фрейм должен как-то измениться/обработаться?
Alexander: Действительно, в случае Циски это mac src=dst=собственный цискин.
Это у D-Link и еще некоторых вендоров мультикастовый дест.
Эти фреймы никак не обрабатываются.
Вообще по стандарту свич не возвращает пакет обратно, но есть исключение: https://www.juniper.net/documentation/en_US/junos1...
Возможно, у вашего провайдера что-то подобное включено, или сбоит оборудование.
Всем спасибо. Выяснилось, что у провайдера там активное транзитное устройство GPON(bridge), которое на старой прошивке некорректно отрабатывает данные фреймы, пока остановился на [no keepalive] на интерфейсе
Все верно, ту же информацию нашел и я, что это фрейм для проверки работоспособности протокола. И у него SRC mac = DST mac, но в таком случае если коммутатор выплевывает данный фрейм из своего интерфейса, то устройство обрабатывающее фреймы на другой стороне должно вернуть его в том же виде(SRC mac = DST mac) и соответственно errdisable потушить интерфейс из-за петли. Или это фрейм должен как-то измениться/обработаться?
A switch never forwards a frame back the port through which it arrived.
...
When SwitchB discovers that the destination MAC address of this LOOP frame is learned on the same port, it will discard the frame rather than forwarding it back to SwitchA. So in a well-behaved switched network, LOOP frames are never forwarded back to their senders because that would necessitate sending them back through the very port they arrived through - and that is prohibited.
Тестовый LOOP-пакет вернется только если на всех свичах по пути его следования маршрут до отправителя иной, нежели тот, по которому поступил пакет. А это и есть петля.
Всем спасибо. Выяснилось, что у провайдера там активное транзитное устройство GPON(bridge), которое на старой прошивке некорректно отрабатывает данные фреймы, пока остановился на [no keepalive] на интерфейсе
Точка удаленная, можно сделать mirroring, но это наврятли что-то даст, трафик я и так знаю какой ходит. Я хочу понять, как keepalive должен отрабатываться корректно если у него в L2 SRC mac = DST mac
Alexander - у меня ближайшая ассоциация со Spanning Tree, с твоей стороны проверить конфиги, но вопрос уже больше к провайдеру - как твои фреймы возвращаются к тебе. Или что маловероятно - в сети совпадение маков на разных устройствах. Вариант 3 - кто-то генератором фреймов балуется.
Всем спасибо. Выяснилось, что у провайдера там активное транзитное устройство GPON(bridge), которое на старой прошивке некорректно отрабатывает данные фреймы, пока остановился на [no keepalive] на интерфейсе
На средствах широковещания, таких как Ethernet, механизмы поддержки активности отчасти уникальны. Поскольку количество возможных соседей в Ethernet велико, сообщения поддержки активности не предусматривают определения доступности пути по кабелю к какому-то определенному соседу. Данные сообщения позволяют только выполнить проверку доступа локальной системы к кабелю Ethernet для чтения и записи. Маршрутизатор создает Ethernet-пакет, который содержит MAC-адрес источника и назначения самого маршрутизатора и специальный код Ethernet, равный 0x9000. Оборудование Ethernet отправляет этот пакет по кабелю Ethernet и затем немедленно получает этот пакет обратно. Таким образом, выполняется проверка аппаратных средств приема и передачи в адаптере Ethernet, а также проверка целостности кабеля.
Сложный
