Jump to content

Recommended Posts

Posted

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

Posted

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

Posted (edited)

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

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

Posted

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

Posted

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

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

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

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

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

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

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

Posted (edited)

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

mac-address-table static 0000.0000.0000 vlan 101 drop

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

Edited by motorhunter

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.