Тестовая конфигурация:
порт 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 явно имеет проблемы на канальном уровне.