Savaoff Опубликовано 23 июля, 2010 · Жалоба Есть связка 3560E и 6506-SUP720-3BXL через 10G медный линк, со стороны 3560 это Te0/1. 3560E периодически и подолгу начинает жаловаться: Jul 23 08:30:33 c3560e-m9-1 142903: Jul 23 07:30:31: %SW_MATM-4-MACFLAP_NOTIF: Host 0080.c800.0000 in vlan 819 is flapping between port Gi0/13 and port Te0/1 При этом на 3560: interface GigabitEthernet0/13 switchport access vlan 819 switchport mode dot1q-tunnel switchport nonegotiate load-interval 60 mls qos vlan-based l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp l2protocol-tunnel point-to-point pagp l2protocol-tunnel point-to-point lacp l2protocol-tunnel point-to-point udld no cdp enable spanning-tree bpdufilter enable hold-queue 4096 in hold-queue 4096 out Порт Te0/1 обычный транковый в котором куча виланов, а на 6506 этот виланчик (819) тупо уходит в составе транка на другой узел... Короче нигде нет колец, 100% проверенно, более того, у клиента все работает нормально (через QnQ по нашей сети у него поднят EtherChannel). Единственное неудобство - множество вышепреведенных сообщений в логах.. Куда копать? Появилась сия проблема недавно, месяц как, а до этого год отработало тихо. Иосы не меняли, свичи не бутили. >0080.c800.0000 искать пробовали? может дуп? искали, не нашли ничего... c3560e-m9-1#sh mac-address-table address 0080.c800.0000 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 819 0080.c800.0000 DYNAMIC Te0/1 Total Mac Addresses for this criterion: 1 c3560e-m9-1# Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
marikoda Опубликовано 23 июля, 2010 (изменено) · Жалоба Есть связка 3560E и 6506-SUP720-3BXL через 10G медный линк, со стороны 3560 это Te0/1.3560E периодически и подолгу начинает жаловаться: Jul 23 08:30:33 c3560e-m9-1 142903: Jul 23 07:30:31: %SW_MATM-4-MACFLAP_NOTIF: Host 0080.c800.0000 in vlan 819 is flapping between port Gi0/13 and port Te0/1 При этом на 3560: interface GigabitEthernet0/13 switchport access vlan 819 switchport mode dot1q-tunnel switchport nonegotiate load-interval 60 mls qos vlan-based l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp l2protocol-tunnel point-to-point pagp l2protocol-tunnel point-to-point lacp l2protocol-tunnel point-to-point udld no cdp enable spanning-tree bpdufilter enable hold-queue 4096 in hold-queue 4096 out Порт Te0/1 обычный транковый в котором куча виланов, а на 6506 этот виланчик (819) тупо уходит в составе транка на другой узел... Короче нигде нет колец, 100% проверенно, более того, у клиента все работает нормально (через QnQ по нашей сети у него поднят EtherChannel). Единственное неудобство - множество вышепреведенных сообщений в логах.. Куда копать? Появилась сия проблема недавно, месяц как, а до этого год отработало тихо. Иосы не меняли, свичи не бутили. >0080.c800.0000 искать пробовали? может дуп? искали, не нашли ничего... c3560e-m9-1#sh mac-address-table address 0080.c800.0000 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 819 0080.c800.0000 DYNAMIC Te0/1 Total Mac Addresses for this criterion: 1 c3560e-m9-1# 0080C8 D-link Systems Его и ищите. Может быть, например, какой-нибудь из неуправляемых свичей на чипах realtek со слетевшим ПЗУ, например DES-1016D. (точнее, такими свичами можно немного "управлять" по фирменному L2 протоколу) Изменено 23 июля, 2010 пользователем marikoda Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Savaoff Опубликовано 23 июля, 2010 · Жалоба Есть связка 3560E и 6506-SUP720-3BXL через 10G медный линк, со стороны 3560 это Te0/1.3560E периодически и подолгу начинает жаловаться: Jul 23 08:30:33 c3560e-m9-1 142903: Jul 23 07:30:31: %SW_MATM-4-MACFLAP_NOTIF: Host 0080.c800.0000 in vlan 819 is flapping between port Gi0/13 and port Te0/1 <skip> >0080.c800.0000 искать пробовали? может дуп? искали, не нашли ничего... c3560e-m9-1#sh mac-address-table address 0080.c800.0000 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 819 0080.c800.0000 DYNAMIC Te0/1 Total Mac Addresses for this criterion: 1 c3560e-m9-1# 0080C8 D-link Systems Его и ищите. Может быть, например, какой-нибудь из неуправляемых свичей на чипах realtek со слетевшим ПЗУ, например DES-1016D. (точнее, такими свичами можно немного "управлять" по фирменному L2 протоколу) Туннель QnQ пробегает через несколько наших каталистов, т.е. "заходит" в нашу сеть через gi0/19 3560e и "выходит" через другой каталист. Что там стоит у клиента, я не знаю, может длинк. Но как это влияет на сообщения нашего каталиста? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dIMbI4 Опубликовано 23 июля, 2010 (изменено) · Жалоба было такое при совпавших маках на 3550 - проследите по мак таблицам где это чудо стоит и прибейте. кстати такую проблему давал небезызвестный софт l2nt Изменено 23 июля, 2010 пользователем dIMbI4 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Savaoff Опубликовано 23 июля, 2010 · Жалоба было такое при совпавших маках на 3550 - проследите по мак таблицам где это чудо стоит и прибейте.кстати такую проблему давал небезызвестный софт l2nt Дык этот мак в нашей сети судя по sh mac-address-table address 0080.c800.0000 существует только на портах влана 819. где и должен. Больше в сети его нет нигде Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mic Опубликовано 23 июля, 2010 (изменено) · Жалоба На форуме Форум dlink. В частности вторая страница темы. Изменено 23 июля, 2010 пользователем Mic Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
