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

[sk011 0]

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

 

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

 

 

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

[greyshadow 22]

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

[greyshadow 22]

Вполне логично если какая-нить option 82 настроена.

[Гайджин 574]

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

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

[sk011 0]

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

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

[Гайджин 574]

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

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

[sk011 0]

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

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

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

при 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

[Гайджин 574]

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

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

[greyshadow 22]

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

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

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

[Гайджин 574]

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

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

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

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

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

 

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

 

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

[sk011 0]

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

И не нужно их тысячами слать, достаточно послать 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 свича в управляющем влане, ибо других вариантов просто нет.

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

[sk011 0]

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

uplink

|

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

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

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

 

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

[Гайджин 574]

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

[sk011 0]

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

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

[greyshadow 22]

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

[Гайджин 574]

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

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

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

 

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

[greyshadow 22]

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

[nevidomuj 33]

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

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

[Гайджин 574]

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

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

 

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

[Гайджин 574]

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

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

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

[sk011 0]

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

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

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

[sk011 0]

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

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

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

[Гайджин 574]

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

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

[nevidomuj 33]

2

Гайджин

 

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

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

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

[Гайджин 574]

2

Гайджин

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

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

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

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

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