motorhunter Опубликовано 15 мая, 2012 · Жалоба Сервер, подключенный к коммутатору c3750g, регистрирует такие пакеты: root@debian-nas-10:~# tcpdump -i eth0 -pne ether host 00:00:00:00:00:00 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 13:26:41.989987 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.2.158 tell 10.10.5.218, length 46 13:26:42.079980 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.6.15 tell 10.10.5.218, length 46 13:26:42.749990 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.2.158 tell 10.10.5.218, length 46 13:26:42.750000 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.6.15 tell 10.10.5.218, length 46 13:26:43.750065 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.2.158 tell 10.10.5.218, length 46 13:26:43.750075 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.6.15 tell 10.10.5.218, length 46 Насколько я понимаю, пакеты с нулевым src mac коммутатор должен отбросить как неверные, однако в логах молчит. Вопросов два: как заставить c3750g отбрасывать пакеты с таким src mac и как найти порт, с которого они приходят? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vladimirslk Опубликовано 15 мая, 2012 · Жалоба Сервер, подключенный к коммутатору c3750g, регистрирует такие пакеты: root@debian-nas-10:~# tcpdump -i eth0 -pne ether host 00:00:00:00:00:00 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 13:26:41.989987 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.2.158 tell 10.10.5.218, length 46 13:26:42.079980 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.6.15 tell 10.10.5.218, length 46 13:26:42.749990 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.2.158 tell 10.10.5.218, length 46 13:26:42.750000 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.6.15 tell 10.10.5.218, length 46 13:26:43.750065 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.2.158 tell 10.10.5.218, length 46 13:26:43.750075 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.10.6.15 tell 10.10.5.218, length 46 Насколько я понимаю, пакеты с нулевым src mac коммутатор должен отбросить как неверные, однако в логах молчит. Вопросов два: как заставить c3750g отбрасывать пакеты с таким src mac и как найти порт, с которого они приходят? посмотреть таблицу маков - там видно на каком порту какие маки.. конкретно по циске не помню чтото вроде show mac-table Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
motorhunter Опубликовано 15 мая, 2012 (изменено) · Жалоба Команда sh mac address-table address 0000.0000.0000 не выдавала результатов. Сейчас активность прекратилась, но на будущее хотелось бы найти способ отслеживать её источник. c3750g#sh ip arp 10.10.5.218 Protocol Address Age (min) Hardware Addr Type Interface Internet 10.10.5.218 34 0000.0000.0000 ARPA Vlan101 c3750g#sh mac address-table address 0000.0000.0000 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- c3750g# Изменено 15 мая, 2012 пользователем motorhunter Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 15 мая, 2012 · Жалоба Мак-адрес 0000-0000-0000 не изучается большинством коммутаторов, в том числе cisco, нормального способа его найти нет, только бегать со снифером, ну или может быть встроенным в дебаг фрейм-снифером по ACL. Бороться с этим относительно просто - L2 ACL. Причина появления - неисправное абонентское оборудование Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 15 мая, 2012 · Жалоба Во FreeBSD недопривязанный к сетевому интерфейсу Vlan имеет такой mac, типа vlan705: flags=8002<BROADCAST,MULTICAST> metric 0 mtu 1500 ether 00:00:00:00:00:00 vlan: 0 parent interface: <none> И иногда вылезает наружу, по крайней мере на 7.x я на эти грабли наступал... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 15 мая, 2012 · Жалоба ...Причина появления - неисправное абонентское оборудование Ну да, как правило, где-то какое-то полуживое железо срет, причем эпизодически. У нас так свитчи в управляемом влане отваливались, при просмотре арп виден был нулевой мак адрес. Приходилось путем снятия тега управляемого влана с портов выяснять откуда источник срача, как правило "на слух" как бы определяется откуда проблема, путем анализа изменения/добавления оборудования в недавнее время или где могут стоять дешевые свитчи и т.д. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
motorhunter Опубликовано 16 мая, 2012 (изменено) · Жалоба Спасибо, так и думал (про повреждённое железо), как раз гроза была недавно. На центральном коммутаторе выполнил mac-address-table static 0000.0000.0000 vlan 101 drop , вроде бы помогло, на сервер больше такие пакеты не доходят. А может, абонент сменил сетевушку :) Изменено 16 мая, 2012 пользователем motorhunter Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...