Jump to content

очень странное поведение DES1100

sk011

By sk011,
in Switch Layer 2

 Share Followers 2

Recommended Posts

sk011

sk011 0

Posted
Posted

Вчера в сети в одном клиентском влане увидел следующее

 

12:05:51.699379 c8:be:19:e2:36:e8 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:97:0e:3f:7d:de, length 300
12:05:51.699545 28:10:7b:c4:d1:ad > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:97:0e:3f:7d:de, length 300
12:05:51.699918 28:10:7b:c4:d1:af > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:97:0e:3f:7d:de, length 300
12:05:51.700418 c8:be:19:e2:36:e9 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:97:0e:3f:7d:de, length 300
12:05:51.700422 28:10:7b:c4:d1:dc > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:97:0e:3f:7d:de, length 300
12:05:51.700763 c8:be:19:e2:36:ed > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:97:0e:3f:7d:de, length 300
12:05:51.700888 c8:be:19:e2:36:ee > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:97:0e:3f:7d:de, length 300
12:05:51.701013 28:10:7b:c4:d1:ba > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:97:0e:3f:7d:de, length 300
12:05:51.701699 c8:be:19:e2:37:06 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:97:0e:3f:7d:de, length 300

такого гов.. очень много, вот распарсенный дамп за 3 минуты

cat broad.txt | awk '{print $2}' | sort | uniq -c
20044 28:10:7b:c4:d1:ad
20033 28:10:7b:c4:d1:ae
44088 28:10:7b:c4:d1:af
19848 28:10:7b:c4:d1:b0
43866 28:10:7b:c4:d1:b9
44066 28:10:7b:c4:d1:ba
44574 28:10:7b:c4:d1:dc
39946 28:10:7b:c4:d2:18
46259 c8:be:19:e2:36:e8
20047 c8:be:19:e2:36:e9
20017 c8:be:19:e2:36:ea
44555 c8:be:19:e2:36:ec
44087 c8:be:19:e2:36:ed
44561 c8:be:19:e2:36:ee
20037 c8:be:19:e2:37:05
20255 c8:be:19:e2:37:06
46153 c8:be:19:e2:37:22

 

все маки это DES1100 включены в EdgeCcore 4612 и Dlink DGS3420-28

что это такое ума не приложу

на всех DES1100 прописан ip, MGM vlan

доступа к ним нет - они тупа не отвечают - трафик через них идет

на аплинке стабильно 2К броадкаста, на самом деле на самих 1100 наверно еще больше

просто стоит ограничение на 4612 который узловой по 500pack/sec

 

 

куда смотреть и что это за хрень такая? мне кто то может подсказать

Link to post
Share on other sites
sk011

sk011 0

Posted
  • Author
Posted

dhcp relay похоже, ловят dhcp от 3c:97:0e:3f:7d:de и футболят оный далее уже от собственного MAC-а...

DES-1100-26 нет такого функционала, сильно обрезанный L2

Link to post
Share on other sites
sk011

sk011 0

Posted
  • Author
Posted

Если честно, то похоже на петлю.

Вы вообще на броадкастные пакетики внимание обратите при сниффинге - множит их?

насколько я понимаю то нет

при arping -w 1000 на несуществующий ip

 

13:24:02.654784 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.664780 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.675777 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.685784 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.695777 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.705777 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.715776 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.726777 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.736782 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.747775 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.757785 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.767778 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.777782 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.788785 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.798788 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.809784 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.819783 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.830781 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28
13:24:02.840783 ARP, Request who-has 10.170.10.25 tell 10.170.10.1, length 28

Link to post
Share on other sites
Гайджин

Гайджин 574

Posted
Posted

А Вы этот а АРП Реквест именно в тот влан в котором у Вас безобразие послали?

И не нужно их тысячами слать, достаточно послать 1-10 штук и посмотреть сколько увидите.

Link to post
Share on other sites
greyshadow

greyshadow 22

Posted
Posted

dhcp relay похоже, ловят dhcp от 3c:97:0e:3f:7d:de и футболят оный далее уже от собственного MAC-а...

Отрелееный DHCP запрос юникастный если че.

он юникастный если явно IP сервака указан.

Link to post
Share on other sites
Гайджин

Гайджин 574

Posted
Posted

dhcp relay похоже, ловят dhcp от 3c:97:0e:3f:7d:de и футболят оный далее уже от собственного MAC-а...

Отрелееный DHCP запрос юникастный если че.

он юникастный если явно IP сервака указан.

Он юникастовый, если произошел факт релеинга DHCP пакета из одного броадкастного езернет клауда в юникастовую форму с дальнейшей отправкой оного по роутингу в сторону DHCP сервера.

В этом случае он, понятное дело, идет от MACа (и IP) L2 свича в управляющем влане, ибо других вариантов просто нет.

 

В случае если релеинга не происходит, а свич доступа просто подшивает в броадкастному пакету дополнительные опции (типа opt82 и т.д.) то MAC адрес отправителя не меняется.

 

Т.е. тут случай не тот.

Link to post
Share on other sites
sk011

sk011 0

Posted
  • Author
Posted

А Вы этот а АРП Реквест именно в тот влан в котором у Вас безобразие послали?

И не нужно их тысячами слать, достаточно послать 1-10 штук и посмотреть сколько увидите.

да влан тот

при arping -i vlan945 -c 1 10.170.10.25

получаю

 

16:24:00.687125 00:25:90:75:aa:b1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.170.10.25 tell 10.170.10.1, length 28

 

В этом случае он, понятное дело, идет от MACа (и IP) L2 свича в управляющем влане, ибо других вариантов просто нет.

это летит не в управляющем влане

Link to post
Share on other sites
sk011

sk011 0

Posted
  • Author
Posted

в центре стоит 4612

uplink

|

DES1100 <-------------> es4612 <-------------> DGS3420 <---------------> DES1100

сейчас потушил порт на DGS3420

кол-во маком с которых летит г-но уменьшилось на кол-во свичей DES1100 подключенных через DGS3420

 

что такого могло пролететь, что все они стали дублировать пакет от своего мака в клиентский влан ? :(

Link to post
Share on other sites
sk011

sk011 0

Posted
  • Author
Posted

Просмотр таблицы коммутации на одном из DES1100 что дает? - Вы разберитесь сначала откуда у Вас мак свича в пользовательском влане.

управления на свичах отвалилось, человек рядом будет только завтра утром (

Link to post
Share on other sites
greyshadow

greyshadow 22

Posted
Posted

То, что это валиться с mac-ов именно комутаторов, и такой функционал в коммутаторе не документирован - говорит о возможном глюке прошивки, обратитесь в ТП длинка с описанием проблемы.

Link to post
Share on other sites
Гайджин

Гайджин 574

Posted
Posted

То, что это валиться с mac-ов именно комутаторов, и такой функционал в коммутаторе не документирован - говорит о возможном глюке прошивки, обратитесь в ТП длинка с описанием проблемы.

Согласен, при сконфигурированом влане управления маков коммутатора не должно быть видно ни где кроме него.

Но опять же - если этот влан сконфигурирован.

 

Может они просто массово "сбросились"?

Link to post
Share on other sites
nevidomuj

nevidomuj 33

Posted
Posted

Колєгі, на світчі 1100-16 є та проблема, що світч доступний з УСІХ віланів, незалежно від того, чи налаштований Менеджмент. Це вже підтверджено не лише мною.

Наскільки я бачив на форумі Г-лінка - вони хотіли випускати МЕ прошивку для цієї лінійки, але поки не бачив її.

Link to post
Share on other sites
Гайджин

Гайджин 574

Posted
Posted

Ага, и массово стали футболить dhcp discover с левого мас-а от своего собственного мас-а... как-то не клеиться...

Почему же не клеится? - как раз клеится. Вы представьте себе, что им крышу сдуло совсем и этот DHCP Request не какой то чужой, а их собственный - т.е. они для себя ip просят.

 

p.s. Это то как раз проверить не сложно. Нужно выбрать какой то MAC свича, и наблюдать на снифере DHCP активность. При этом послать на свич ремонтника и заствить его выдернуть все присоединения из этого свича, кроме аплинка. Если DHCP Request быдут иметь место и после этого, то значит это сам свич головой об стенку бьется.

Link to post
Share on other sites
Гайджин

Гайджин 574

Posted
Posted

Колєгі, на світчі 1100-16 є та проблема, що світч доступний з УСІХ віланів, незалежно від того, чи налаштований Менеджмент. Це вже підтверджено не лише мною.

Наскільки я бачив на форумі Г-лінка - вони хотіли випускати МЕ прошивку для цієї лінійки, але поки не бачив її.

Консоль у них есть? - Если есть, то лезте на дом, втыкайтесь в свич и смотрите чего у него в голове происходит.

Link to post
Share on other sites
sk011

sk011 0

Posted
  • Author
Posted
То, что это валиться с mac-ов именно комутаторов, и такой функционал в коммутаторе не документирован - говорит о возможном глюке прошивки, обратитесь в ТП длинка с описанием проблемы.
Согласен, при сконфигурированом влане управления маков коммутатора не должно быть видно ни где кроме него. Но опять же - если этот влан сконфигурирован. Может они просто массово "сбросились"?

не могу быть уверен что сконфигурированы правильно, сам настроил только пару. Сегодня человек с ноутом станет на месте, по питанию перегрузит, посмотрит что с таблицей МАК

Link to post
Share on other sites
sk011

sk011 0

Posted
  • Author
Posted
Ага, и массово стали футболить dhcp discover с левого мас-а от своего собственного мас-а... как-то не клеиться...
Почему же не клеится? - как раз клеится. Вы представьте себе, что им крышу сдуло совсем и этот DHCP Request не какой то чужой, а их собственный - т.е. они для себя ip просят. p.s. Это то как раз проверить не сложно. Нужно выбрать какой то MAC свича, и наблюдать на снифере DHCP активность. При этом послать на свич ремонтника и заствить его выдернуть все присоединения из этого свича, кроме аплинка. Если DHCP Request быдут иметь место и после этого, то значит это сам свич головой об стенку бьется.

по крайней мере один из них отвечает на настроенный ip (с потерями от нагрузки) в mgm влане и при это шлет от своего мака пакеты в клиентском. Если "снесло" совсем, то и таблица вланов была бы сброшена.

Link to post
Share on other sites
Гайджин

Гайджин 574

Posted
Posted

не могу быть уверен что сконфигурированы правильно, сам настроил только пару. Сегодня человек с ноутом станет на месте, по питанию перегрузит, посмотрит что с таблицей МАК

Не правильная последовательность действий - сначала смотреть и нюхать, потом откидывать даунлинков и нюхать, а уж по питанию только в последнем случае. Ибо Вы можете так и не разобраться с причиной. Просто повторить подобное состояние не сможете.

Link to post
Share on other sites
nevidomuj

nevidomuj 33

Posted
Posted

2

Гайджин

 

На правах офтопу)

Підкажіть, будь-ласка, для нуба, не можна почитати, як сніфити мережу? Тобто подивитись що бігає по конкретному порту?

Якщо можна дайте лінк.

Link to post
Share on other sites
Гайджин

Гайджин 574

Posted
Posted

2

Гайджин

На правах офтопу)

Підкажіть, будь-ласка, для нуба, не можна почитати, як сніфити мережу? Тобто подивитись що бігає по конкретному порту?

Якщо можна дайте лінк.

Ну если нужно "понюхать" порт прямо таки на месте, т.е. Вы рядом со свичем, то втыкаться в свободный порт свича и выполнят port mirroring.

Если же это нужно выполнить дистанционно, то необходимо применять функционал RSPAN.

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
 Share
Followers 2
Go to topic listing

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...