>НО! мы втыкали и напрямую, т.е. минуя свитч...
Вот тут уточните, пожалуйста. Вы имеете в виду, подключали устройства к маршрутизатору (без коммутаторов) и наблюдали те же проблемы?
Чтобы проверить предположение касательно мультикаста (и если мультикаст генерируется кем-то на LAN-стороне маршрутизатора), то вы можете: 1) в свободный ethernet-порт маршрутизатора (LAN-порт, из блока четырех портов) воткнуть сервер/ноутбук с установленным wireshark. 2) включить запись трафика с фильтром (capture filter) 'broadcast or multicast'. 3) пронаблюдать (в меню wireshark пункт Statistics -> IO graph), не было ли в момент повторения проблемы всплесков мультикаста/броадкаста. Но важно понимать, что даже с фильтрацией круглосуточный захват трафика может привести к зависанию используемого компьютера, возможно понадобится перезагрузка и т.д.
Я правильно понимаю, что кабель от HDSL-модема подключен к порту WAN (судя по картинкам из интернета, выделен желтым, расположен отдельно от друих портов) маршрутизатора Netgear N600, а кабеля от коммутаторов до кассы,пинпада, сервера - в Ethernet-порты (их четверо в монолитном модуле)?
Еще две версии - пики загрузки процессора (можно проверить, снимая данные по SNMP или посмотреть график в веб-интерфейсе, если есть) или всплески бродкаст/мультикаст-трафика. В случае, если мультикаст форвардится между интерфейсами, возможно кратковременное исчерпание буферов интерфейсов (наблюдал нечто подобное на коммутаторах, редкие массивные пачки ARP-запросов приводили к потерям пакетов). Характер трафика можно узнать опять-же через SNMP, собирая данные об утилизации интерфейса (oid 1.3.6.1.2.1.2 и глубже), в том числе количество переданных юникаст, мультикаст и бродкаст пакетов.
Учитывая нестабильный характер проявления проблемы, хорошей идеей было бы собрать статистику на протяжении длительного периода времени. Если ваш маршрутизатор поддерживает SNMP, то полезно было бы собрать (при помощи cacti, например, заодно и графики нарисует) данные об утилизации интерфейсов (в т.ч. какой процент трафика составляет броадкаст, мультикаст), об ошибках интерфейсов, о загрузке процессора и утилизации памяти. Чем больше данных, тем проще некоторые из них скоррелировать с наблюдаемыми симптомами.
Раз уж вы упомянули packet tracer, посоветую посмотреть в сторону эмулятора GNS3. В отличие от packet tracer, этот эмулятор запускает самый настоящий образ Cisco IOS, можно наблюдать сниффером обмен пакетами и прочая. По-моему, под Apple Macintosh работает.
Я слышал, книга Одома по курсу CCNA неплохая, есть перевод на русский. Я бы порекомендовал Routing TCP/IP от Jeff Doyle, том 1. Книга, конечно, из серии подготовки к CCIE, но первые 4 главы прочитать стоит и в начале пути. Ну и будьте готовы к тому, что: а) даже в крутых книжках вроде Дойла есть ошибки/опечатки б) экзамен (любой) к практике имеет довольно косвенное отношение
В заголовке статьи по вашему линку указано, что автор представляет Bell laboratories и Lucent technologies. Последняя организация вместе с Alcatel выпускает коммутаторы OmniSwitch, например.
Вполне подпадает под категорию 'вендор', с моей точки зрения.
Далее, термин 'filtering database' вводится в стандарте IEEE 802.1D-2004, глава 7.9 (https://standards.ieee.org/getieee802/download/802...
Как правило, в спецификациях коммутаторов указывают, какие стандарты он поддерживает, и стандарты IEEE занимают 'почетные места' в этом списке (тегирование вланов, xSTP).
Кто, где, в каком стандарте определяет термин 'Address forwarding table', я не знаю. Этот термин мне представляется излишне общим. В частности, из его названия неясно, какие именно адреса (L2,L3 и т.д.) используются, особенно в наши дни, когда многие устройства совмещают в себе L2 и L3 функциональность.
Ну и самое главное - полагать, что где-то есть конечная бесконечномудрая инстанция, задающая непротиворечивые стандарты, которым все всегда следуют и в результате в сетевом мирке наблюдается орднунг, благорастворение воздусей и безмятежность, несколько наивно.
Хотя бы потому, что ни порядка, ни безмятежности не наблюдается. Я считаю более конструктивным не полагаться на ниспосланныя нам грешным Откровения различных комитетов, а судить о вещах по их поведению на практике. В данном случае, я не вижу ни одного факта, ни одного свойства, чтобы отличать "Address Forwarding Table" из приведенных вами примеров от "Filtering database". Такие дела.
>он 100 фулл
Если 100/full - это заданный режим (не только фактический, но и специфично заданный в конфигурации), то попробуйте перевести в Auto/Auto и пронаблюдать ситуацию.
Еще одна гипотеза - если я правильно понял, потери пакетов возникают примерно раз в час? Посмотрите, нет ли релевантных сообщений в логе маршрутизатора. Также, если маршрутизатор получает IP-адрес по DHCP, проверьте время актуальности выданного адреса (dhcp lease time)
>роутер N600 netgear. он не может работать в полудуплексе
вы меня извините, но gigabit ethernet порт _обязан_ (стандартом на Gigabit ethernet) уметь работать режимах 10 Half, 10 Full, 100 Half, 100 Full. Поэтому просьба проверить состояние портов (в т.ч. счетчики late collisions/drops/errors) в интерфейсе маршрутизатора.
цитата из патента по вашей ссылке: "If the switch supports SNMP, the AFT is stored in the entry “mib2-dot1bridge-dot1dTp” of the MIB-II". Это, как я понял и есть BRIDGE-MIB (в частности, внутри mib2-dot1bridge-dot1dTp есть dot1dTpFdbTable), так что в данном случае AFT=FDB.
И в описании патента все-таки указано - первоначальный патентообладатель - Ericsson. Полагаю, очередное 'творчество' вендора без оглядки на стандарты IEEE.