MAC PAUSE

[M-a-x-Z]

Здравствуйте!

 

Сегодня с утра столкнулся с проблемой:

сегмент сети, построенный на неуправляемых коммутаторов (2-3 шт) резко перестал работать: задержки возросли до единиц секунд и потеря до 15% внутри сегмента. При этом сегменты, состыкованные с повреждённым через 2960 работали нормально.

 

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

ОС Win 8, подключение Ethernet, Wi-Fi отключен. Антивирус - Касперский Endpoint

 

Что это может быть и откуда могли взяться такие пакеты, кто и зачем их генерирует в системе и главное, что делать? Никогда раньше с таким не сталкивался.

Edited March 3, 2014 by M-a-x-Z

[Butch3r]

Не уверен, но не может быть это включенный flow control на сетевухе?

[darkagent]

http://ask.wireshark.org/questions/4799/spanning-tree-for-bridges_01-flooding-my-network

[M-a-x-Z]

http://ask.wireshark...ding-my-network

Тут поясняется значение этих пакетов, но они следуют из сетёвки явно в нарушение стандарта. Это, как я понимаю, пакеты замедления передачи. Но никакая передача не ведётся - два ноутбука соединены кабелем. При этом большая частота пакетов и огромное значение задержки.

Может быть кто-то сталкивался? Я понять не могу, что в системе может генерировать столько пакетов.

[darkagent]

тут может как flow control херней страдать (в свойствах сетевухи можно отключить), либо же "ответчик обнаружения топологии канального уровня" (отключается галочкой в свойствах соединения) в случае если соединение не стабильное (раздолбан разъем, окислился коннектор, кабель в конце концов погрыли грызуны или перетерся об дверной косяк, и т.д.).

[NikAlexAn]

Тут поясняется значение этих пакетов, но они следуют из сетёвки явно в нарушение стандарта. Это, как я понимаю, пакеты замедления передачи. Но никакая передача не ведётся - два ноутбука соединены кабелем. При этом большая частота пакетов и огромное значение задержки.

Может быть кто-то сталкивался? Я понять не могу, что в системе может генерировать столько пакетов.

А flow-control отключить нельзя? и пробуждение по волшебному пакету тож?

Столкнулся с одной машинкой в офисе - блажит только после выключения питания софтового и то не всегда - то есть сетевуха в режиме сна.

[M-a-x-Z]

 

А flow-control отключить нельзя? и пробуждение по волшебному пакету тож?

Столкнулся с одной машинкой в офисе - блажит только после выключения питания софтового и то не всегда - то есть сетевуха в режиме сна.

В свойствах сетёвки (вклатка дополнительно, хардварных настроек) отдельного пункта flow control нет

[[anp/hsw]]

Неуправляемые коммутаторы прошейте прошивкой с отключеным flow control, если найдете (реалтеки и IC+ точно умеют и все в открытом доступе) и есть время это делать. Если нет - меняйте на управляемые.

Flow control пакеты могут привести к полной неработоспособности сети (в том числе и управляемой, но по дефолту flow control отключен).

Самый простой вариант для теста: поставьте в свойствах сетевухи скорость 10 мегабит, и влейте более 10 мегабит udp потока. От нее повалят pause-фреймы.

А дальше уже смотрите, какая часть сети упала, и устраивает ли это вас.

[M-a-x-Z]

' timestamp='1393834407' post=939830]

Неуправляемые коммутаторы прошейте прошивкой с отключеным flow control, если найдете (реалтеки и IC+ точно умеют и все в открытом доступе) и есть время это делать. Если нет - меняйте на управляемые.

Flow control пакеты могут привести к полной неработоспособности сети (в том числе и управляемой, но по дефолту flow control отключен).

Самый простой вариант для теста: поставьте в свойствах сетевухи скорость 10 мегабит, и влейте более 10 мегабит udp потока. От нее повалят pause-фреймы.

А дальше уже смотрите, какая часть сети упала, и устраивает ли это вас.

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

[[anp/hsw]]

Ну так и подарите пользователю роутер, пусть через него работает.

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

[M-a-x-Z]

А такие пакеты по умолчанию на 2960 обрабатываются? Если да, то как запретить?

[[anp/hsw]]

Если другие сегменты у вас не повисли, то скорее всего не обрабатываются.

 

Сделайте "sh int fastethernet 0/1" - там будет сказано про flow control.

На моих 2950, например

input flow-control is unsupported output flow-control is unsupported

2960 нет, чтобы проверить.

Edited March 3, 2014 by [anp/hsw]

[M-a-x-Z]

Port Send FlowControl Receive FlowControl RxPause TxPause

admin oper admin oper

--------- -------- -------- -------- -------- ------- -------

Fa0/1 Unsupp. Unsupp. off off 0 0

Fa0/2 Unsupp. Unsupp. off off 0 0

Fa0/3 Unsupp. Unsupp. off off 0 0

Fa0/4 Unsupp. Unsupp. off off 0 0

Fa0/5 Unsupp. Unsupp. off off 0 0

Fa0/6 Unsupp. Unsupp. off off 0 0

Fa0/7 Unsupp. Unsupp. off off 0 0

Fa0/8 Unsupp. Unsupp. off off 0 0

Fa0/9 Unsupp. Unsupp. off off 0 0

Fa0/10 Unsupp. Unsupp. off off 0 0

Fa0/11 Unsupp. Unsupp. off off 0 0

Fa0/12 Unsupp. Unsupp. off off 0 0

Fa0/13 Unsupp. Unsupp. off off 0 0

Fa0/14 Unsupp. Unsupp. off off 0 0

Fa0/15 Unsupp. Unsupp. off off 0 0

Fa0/16 Unsupp. Unsupp. off off 0 0

Fa0/17 Unsupp. Unsupp. off off 0 0

Fa0/18 Unsupp. Unsupp. off off 0 0

Fa0/19 Unsupp. Unsupp. off off 0 0

Fa0/20 Unsupp. Unsupp. off off 0 0

Fa0/21 Unsupp. Unsupp. off off 0 0

Fa0/22 Unsupp. Unsupp. off off 0 0

Fa0/23 Unsupp. Unsupp. off off 0 0

Fa0/24 Unsupp. Unsupp. off off 0 0

Fa0/25 Unsupp. Unsupp. off off 0 0

Fa0/26 Unsupp. Unsupp. off off 0 0

Fa0/27 Unsupp. Unsupp. off off 0 0

Fa0/28 Unsupp. Unsupp. off off 0 0

Fa0/29 Unsupp. Unsupp. off off 0 0

Fa0/30 Unsupp. Unsupp. off off 0 0

Fa0/31 Unsupp. Unsupp. off off 0 0

Fa0/32 Unsupp. Unsupp. off off 0 0

Fa0/33 Unsupp. Unsupp. off off 0 0

Fa0/34 Unsupp. Unsupp. off off 0 0

Fa0/35 Unsupp. Unsupp. off off 0 0

Fa0/36 Unsupp. Unsupp. off off 0 0

Fa0/37 Unsupp. Unsupp. off off 0 0

Fa0/38 Unsupp. Unsupp. off off 0 0

Fa0/39 Unsupp. Unsupp. off off 0 0

Fa0/40 Unsupp. Unsupp. off off 0 0

Fa0/41 Unsupp. Unsupp. off off 0 0

Fa0/42 Unsupp. Unsupp. off off 0 0

Fa0/43 Unsupp. Unsupp. off off 0 0

Fa0/44 Unsupp. Unsupp. off off 0 0

Fa0/45 Unsupp. Unsupp. off off 0 0

Fa0/46 Unsupp. Unsupp. off off 0 0

Fa0/47 Unsupp. Unsupp. off off 0 0

Fa0/48 Unsupp. Unsupp. off off 0 0

Gi0/1 Unsupp. Unsupp. off off 0 0

Gi0/2 Unsupp. Unsupp. off off 0 0

 

Но не обрабатываются (а они не обрабатываются) совершенно не значит что не передаются далее по сети (

[NikAlexAn]

' timestamp='1393836295' post='939853']

2960 нет, чтобы проверить.

На них по умолчанию input flow-control is off.

[[anp/hsw]]

Но не обрабатываются (а они не обрабатываются) совершенно не значит что не передаются далее по сети (

 

Тогда поставьте на порты ACL с запретом этого трафика (если возможно).

Также поможет просто неуправляемые сегменты разбить в отдельные vlan'ы на управляемых свичах насколько это возможно.

Вообще в стандарте сказано так: фрейм не должен форвардиться, если коммутатор понимает такие фреймы. При этом сам он не обязан его обрабатывать как "pause".

Что такое "unsupp" - не понимает, или понимает, но не следует им - хз.

[NikAlexAn]

' timestamp='1393845526' post='939936']

Тогда поставьте на порты ACL с запретом этого трафика (если возможно).

Также поможет просто неуправляемые сегменты разбить в отдельные vlan'ы на управляемых свичах насколько это возможно.

Вообще в стандарте сказано так: фрейм не должен форвардиться, если коммутатор понимает такие фреймы. При этом сам он не обязан его обрабатывать как "pause".

Что такое "unsupp" - не понимает, или понимает, но не следует им - хз.

У ТС: send-unsupported а reseive-off - так что не надо acl.

 

Для ТС: подключите глючащий ПК к свободному порту каталиста и проверьте как сеть к этому отнесётся. Вроде не сложно ведь.

[M-a-x-Z]

' timestamp='1393845526' post='939936']

Тогда поставьте на порты ACL с запретом этого трафика (если возможно).

Также поможет просто неуправляемые сегменты разбить в отдельные vlan'ы на управляемых свичах насколько это возможно.

Вообще в стандарте сказано так: фрейм не должен форвардиться, если коммутатор понимает такие фреймы. При этом сам он не обязан его обрабатывать как "pause".

Что такое "unsupp" - не понимает, или понимает, но не следует им - хз.

У ТС: send-unsupported а reseive-off - так что не надо acl.

 

Для ТС: подключите глючащий ПК к свободному порту каталиста и проверьте как сеть к этому отнесётся. Вроде не сложно ведь.

За сегодняшний день диагностика показала - через каталисты плохойт рафик не проходит. Теперь это точно. В неуправляемых сегментах подобная проблема появилась только там, где есть Win8. Завтра будем экспериментировать. Что характерно проблема первый раз появилась в пятницу - до этого никогда не возникала. При этом новые узлы не появлялись, конфигурация сети не менялась. Что стало катализатором проблемы - теряюсь в догадках. М.б. какой-то виндовый апдейт. Хотя тогда эта проблема была бы массовой.

[Ivan_83]

В свойствах сетёвки (вклатка дополнительно, хардварных настроек) отдельного пункта flow control нет

Дрова обновите на родные от производителя.

[M-a-x-Z]

Проблему удалось решить перепрошивкой мыльниц ASUS RT-N13RU. При встрече с ОС Win8 они и ОС начинали генерировать паразитный трафик. Причём их рассоединение не прекращало поток пауз. Даже при перезагрузке интерфейса. Только полная перезагрузка роутера и пк с последующим размещением в разных сегментах. После установки dd-wrt проблема ттт решилась.