Тестовая конфигурация:

порт 1 - клиент1
порт 2 - клиент2 с запущенным tcpdump
порт 3 - uplink ISP

Дополнительное ПО - PPPoE Monitor (http://l2nt.info).

У ISP доступно 3 PPPoE концентратора с одним и тем же AC-Name, MAC адреса естественно разные.

Тест:
1. Перезапускаю свич, соответственно таблица коммутации (CAM table)очищается
2. Запускаю PPPoE Monitor, который шлет PADI и получает три ответа PADO. Все концентраторы доступны.
3. Смотрим: show fdb port 3. Пусто.
Вопрос: почему пусто? Согласно принципам коммутации запись в CAM должна записаться после первого прохождения фрейма с неизвестным для данного порта MAC адресом.
4. С клиент1 устанавливаю PPPoE соединение, в то же время клиент2 анализирует трафик. Клиент2 (естественно в promisc) видит только broadcast PADI. Отсюда делаю вывод, что все юникастовые фреймы PPPoE протокола (уровень сессии) уходят согласно таблице коммутации, а именно на третий порт свича.
Если бы в CAM небыло записи о соответствии 3-му порту MAC адреса PPPoE коммутатора - то первый юникастовый PPPoE пакет ушел бы на все порты. Но такого не произошло. Свич работает правильно.
Смотрим что на третьем порту: show fdb port 3 показывает пусто.
Как так?

Через пару минут появляется запись об одном коммутаторе (к которому подключен клиент1). Все это время запущен PPPoE Monitor который каждые 30 секунд шлет PADI и получает ответы от всех коммутаторов.
Где остальные записи?

Минут через 5 вижу все записи в таблице третьего порта.
Что за инертность?

Если я получил фрейм с неизвестным src-MAC адресом для данного порта - я должен это видеть в CAM, и не через 5 минут, а сразу же, и быть уверенным, что вижу результаты соответствующие действительности. (Иначе для чего тогда вообще это нужно?)

FW: 3.00.16

И когда уж наконец почините ping:

D:\l2nt>l2nt.exe -p 192.168.1.251
PING 192.168.1.251:
reply: 64 bytes from 192.168.1.251 time 172.992 ms
reply: 64 bytes from 192.168.1.251 time 3.183 ms
reply: 64 bytes from 192.168.1.251 time 2.855 ms
reply: 64 bytes from 192.168.1.251 time 94.331 ms
reply: 64 bytes from 192.168.1.251 time 559.349 ms
reply: 64 bytes from 192.168.1.251 time 2.891 ms
reply: 64 bytes from 192.168.1.251 time 3.127 ms
reply: 64 bytes from 192.168.1.251 time 309.807 ms
reply: 64 bytes from 192.168.1.251 time 2.833 ms
^C
--- 192.168.1.251 ping statistics ---
9 packet transmitted, 9 packet received, 0% packet loss
round-trip min/avg/max = 2.833/127.930/559.349 ms

Это ARP пинг. Если ICMP покажет проблемы включая сетевой уровень, то ARP не поднимется выше канального. В данном FW NMS явно имеет проблемы на канальном уровне.

Перезвоните пожалуйста завтра в офис по телефону 744-00-99 доб.390.

Благодарю за оказанную техподдержку.

Ясно, что функционал для данной модели значителен, что отражается на загруженности CPU и, соответственно, времени L2-L3 отклика (пинга).

В FW 3.00.16 есть "инертность" при показе таблицы коммутации, но зато без 2-х минутной задержки (как в 2.хх..). В следующей версии FW обещают изменить алгоритмы вывода таблицы коммутации.

Понянто, что данные вещи не являются критическими, но хочется лучшего

Ждем прошивку...

Извини за глупый, быть может, вопрос, но что такое "таблица коммутации", которую, по всей видимости, можно посмотреть? У меня прошивка 3.00.4 и там таблицу можно посмотреть только по SNMP (1.3.6.1.2.1.17.4.3) и то - через раз. Вот сейчас думаю перепрошить, но что нового в 16-й прошивке нигде найти не могу и стоит ли менять "шило на мыло" не знаю...

Я Вам прошивку выслал.

Можно мне выслать прошивочку новую? У меня такая же проблема.

Я Вам прошивку выслал.