Jump to content
Калькуляторы

src mac 00:00:00:00:00:00 найти источник

Сервер, подключенный к коммутатору 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 и как найти порт, с которого они приходят?

Share this post


Link to post
Share on other sites

Сервер, подключенный к коммутатору 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

Share this post


Link to post
Share on other sites

Команда 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#

Edited by motorhunter

Share this post


Link to post
Share on other sites

Мак-адрес 0000-0000-0000 не изучается большинством коммутаторов, в том числе cisco, нормального способа его найти нет, только бегать со снифером, ну или может быть встроенным в дебаг фрейм-снифером по ACL. Бороться с этим относительно просто - L2 ACL. Причина появления - неисправное абонентское оборудование

Share this post


Link to post
Share on other sites

Во 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 я на эти грабли наступал...

Share this post


Link to post
Share on other sites

...Причина появления - неисправное абонентское оборудование

Ну да, как правило, где-то какое-то полуживое железо срет, причем эпизодически.

У нас так свитчи в управляемом влане отваливались, при просмотре арп виден был нулевой мак адрес.

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

как правило "на слух" как бы определяется откуда проблема,

путем анализа изменения/добавления оборудования в недавнее время или

где могут стоять дешевые свитчи и т.д.

Share this post


Link to post
Share on other sites

Спасибо, так и думал (про повреждённое железо), как раз гроза была недавно. На центральном коммутаторе выполнил

mac-address-table static 0000.0000.0000 vlan 101 drop

, вроде бы помогло, на сервер больше такие пакеты не доходят. А может, абонент сменил сетевушку :)

Edited by motorhunter

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this