Флудерасты типа "Метроном"

[Barsick]

Симптомы:

На коммутаторе ритмично моргает лампочка одного из абонентов, 1-2 раза с секунду. Коммутатор в 95% параличе, ходят только бродкасты, если комм управляемый - вебморды/телнета/пингов нет

Соседние коммы в легком обмороке, 20-50% потерь, управление то есть, то нет

Коммы через один и далее - управление в норме, потери 5-10%

Сниффером (wireshark) ничего не ловится!!!

Что это?

Случаи не частые, пару раз в месяц на ~5000 абонентов. Пролазит ли флуд в соседние виланы - пока не понял

 

[Nafanya]

Симптомы:

На коммутаторе ритмично моргает лампочка одного из абонентов, 1-2 раза с секунду. Коммутатор в 95% параличе, ходят только бродкасты, если комм управляемый - вебморды/телнета/пингов нет

Соседние коммы в легком обмороке, 20-50% потерь, управление то есть, то нет

Коммы через один и далее - управление в норме, потери 5-10%

Сниффером (wireshark) ничего не ловится!!!

Что это?

Случаи не частые, пару раз в месяц на ~5000 абонентов. Пролазит ли флуд в соседние виланы - пока не понял

а из какой точки сети снифили? прямо с того порта, предположительно флудящего? Судя по описанию

Соседние коммы в легком обмороке, 20-50% потерь, управление то есть, то нет

Коммы через один и далее - управление в норме, потери 5-10%

до вас могло уже ничего и не дойти...

 

похоже на arp-атаку на свитч, дабы превратить его в "хаб" :)

Edited August 29, 2008 by Nafanya

[Heggi]

Было такое несколько раз. Самое странное - комп у юзера в этот момент выключен, т.е. флудит непосредственно сама сетевая карта (на нее питание всегда подается)

 

этот флуд ложит весь сегмент мыльниц (сеть поделена управляемыми мутаторами типа Compex SXP2224WM. Он весьма успешно отсекает такой флуд

[Barsick]

а из какой точки сети снифили? прямо с того порта, предположительно флудящего? Судя по описанию

Снифил непосредственно с абон. кабеля

этот флуд ложит весь сегмент мыльниц

Если бы... Des-3526 и Ex3525 (или как его? ёжык который?) тоже укладываются

Самое странное - комп у юзера в этот момент выключен, т.е. флудит непосредственно сама сетевая карта

Походу да. Либо абонент выключил свет и не пускал никого домой :)

 

[Дегтярев Илья]

Снифил непосредственно с абон. кабеля

А там точно не было 1q тегированного трафика? Мож юзер случайно поднял.

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

 

[Kaban]

Barsick, у вас что, юзера и управляющий IP свича в одном VLAN-е ?

[Ruslan_R]

Было такое несколько раз. Самое странное - комп у юзера в этот момент выключен, т.е. флудит непосредственно сама сетевая карта (на нее питание всегда подается)

этот флуд ложит весь сегмент мыльниц (сеть поделена управляемыми мутаторами типа Compex SXP2224WM. Он весьма успешно отсекает такой флуд

Сталкивались с подобным один раз. Повторялось с периодичностью раз в месяц. Вылечилось установкой у пользователя другой сетевой карты (карта была встроенная, Nforce-какой-то).

[Barsick]

Barsick, у вас что, юзера и управляющий IP свича в одном VLAN-е ?

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

Сталкивались с подобным один раз. Повторялось с периодичностью раз в месяц. Вылечилось установкой у пользователя другой сетевой карты (карта была встроенная, Nforce-какой-то).

Nforce? Единственая ассоциация - зачем-то запущеный VCT (Virtual Cable Tester)

[Kaban]

Сильно сомневаюсь чтоб флуд просачивался между VLAN-ами. Конструкция свич фабрики этого не позволяет. Скорее всего флуд тупо вали свич.

Попробуйте на клиентских портах врубить loopdetect, broadcast/multicast storm control и port-security с жестко вбитыми МАК адресами.

Edited August 30, 2008 by Kaban

[ram_scan]

Сильно сомневаюсь чтоб флуд просачивался между VLAN-ами. Конструкция свич фабрики этого не позволяет. Скорее всего флуд тупо вали свич.

Да лехко, особенно на длинках. Там мак адрес не целиком анализируется, а обычно только младшие 32 бита (а то и меньше).

[EvilShadow]

Сильно сомневаюсь чтоб флуд просачивался между VLAN-ами. Конструкция свич фабрики этого не позволяет. Скорее всего флуд тупо вали свич.

Да лехко, особенно на длинках. Там мак адрес не целиком анализируется, а обычно только младшие 32 бита (а то и меньше).

Не подскажете, откуда такие сведения?

[IvanI]

на длинках невидел а на планетах 2401 виндовый клиент начинает работать иногда до того как PVID правильно выставиш....

[Дегтярев Илья]

ланетах 2401 виндовый клиент начинает работать иногда до того как PVID правильно выставишЬ

 

Так у роутера во всех виланах один и тот же адрес? И если не циска, то и на arp в левом вилане может ответить. А сетевуха спокойно забирает тегированный трафик из своего вилана.

[ingress]

Сильно сомневаюсь чтоб флуд просачивался между VLAN-ами. Конструкция свич фабрики этого не позволяет. Скорее всего флуд тупо вали свич.

Да лехко, особенно на длинках. Там мак адрес не целиком анализируется, а обычно только младшие 32 бита (а то и меньше).

Не подскажете, откуда такие сведения?

из даташита на чип

 

вот к примеру из документа на чип который в Edge-core EC3526XA v1

 

Q-M008 Hash Functions, Request more information/example ?

Ans There are two hash algorithms selectable for address table access. The first one is CRC algorithm on

the address; the second one is a simple extraction of lower bits of the address.

 

 

p.s. по теме очень мне кажется что это FlowControl включенный на порту и фрейм PAUSE

во всех тупых свичах FlowControl по умолчанию включен :)

Edited August 31, 2008 by ingress

[Rst7.CBSIE]

p.s. по теме очень мне кажется что это FlowControl включенный на порту и фрейм PAUSEво всех тупых свичах FlowControl по умолчанию включен :)

Похоже. Только банально выключать FlowControl не стоит. Надо смотреть, есть ли у свича возможность задания максимального количества пакетов PAUSE. Например, RTL8324 имеет 2 режима, бесконечность и лимит в 128 пакетов. Причем управляется бутстрепом (т.е. подтяжками пинов при старте). Если железо сделано так, что выбрана бесконечность - вполне возможна такая зопа.

[ingress]

p.s. по теме очень мне кажется что это FlowControl включенный на порту и фрейм PAUSEво всех тупых свичах FlowControl по умолчанию включен :)

Похоже. Только банально выключать FlowControl не стоит. Надо смотреть, есть ли у свича возможность задания максимального количества пакетов PAUSE. Например, RTL8324 имеет 2 режима, бесконечность и лимит в 128 пакетов. Причем управляется бутстрепом (т.е. подтяжками пинов при старте). Если железо сделано так, что выбрана бесконечность - вполне возможна такая зопа.

только смысла в нём чтобы оставлять включенным?

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

 

[Rst7.CBSIE]

только смысла в нём чтобы оставлять включенным?

Ну перекладывать проблемы дропа пакетов из-за переполнения буферов на протоколы более высокого уровня (в частности на TCP) тоже не выход... Просто флоу-контрол приостановит поток данных, потом возобновит, в результате будем мягкое ограничение скорости. А при его отсутствии пакет дропнется и когда там еще TCP приспичит повторить (обычное число 200-400мс)... Некошерно :)

 

А вот если уж совсем туго (ну стоит какой-то абонент в паузе; кстати, похоже у абонента хитрозопая сетевка, которая при отсутствии жизни у главного мозга генерит PAUSE-пакеты, дабы мозг по просыпанию мог их получить), тогда надо обязательно лимитить количество пакетов PAUSE, чтобы не положить всю сетку.

[ingress]

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

 

как примеры обязательный checksum в UDP и фрагментация пакетов только хостом в IPv6

Edited August 31, 2008 by ingress

[Kaban]

Да лехко, особенно на длинках. Там мак адрес не целиком анализируется, а обычно только младшие 32 бита (а то и меньше).

А при чем тут МАК адрес ? Если я не ошибаюсь то в CAM таблице кроме адресной части есть еще поле VLAN.

Коммутация и бродкастинг фреймов происходят только в пределах того VLAN-а откуда пришел фрейм.

[ingress]

Да лехко, особенно на длинках. Там мак адрес не целиком анализируется, а обычно только младшие 32 бита (а то и меньше).

А при чем тут МАК адрес ? Если я не ошибаюсь то в CAM таблице кроме адресной части есть еще поле VLAN.

Коммутация и бродкастинг фреймов происходят только в пределах того VLAN-а откуда пришел фрейм.

вланы тоже можно подделывать, забыл я адрес где над телесином издевались

за то нашёл вот такое

http://www.sans.org/reading_room/whitepape...rkdevs/1090.php

[Rst7.CBSIE]

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

 

как примеры обязательный checksum в UDP и фрагментация пакетов только хостом в IPv6

Дык флоуконтрол на MAC-уровне не имеет никакого отношения к фрагментации и прочему. Это всего лишь инструмент повышения надежности сети при увеличении загрузки. Простой пример:

 

1. Допустим, есть 2 абонента, воткнутые в свич и аплинк. Все линки - по 100.

2. Допустим, первый абонент льет поток со скоростью 80. Все хорошо, дропов нет.

3. Второй абонент начинает лить поток. Как только общий траф достигает 100, в зависимости от того, работает флоуконтрол или нет, будут разные результаты.

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

б) Нет флоуконтрола - пакет, который не влез - просто дропается. Значит, если оба абонента пытаются лить одинаковые потоки, будет сдропано в среднем 50% пакетов у каждого.

 

Интересно поведение протоколов более высокого уровня в случае 3б. Допустим, источник заразы ;) - это TCP. Причем абоненты с одинаковыми стеками (для простоты). Допустим, первый льет и подключается второй. Пусть первый сдропнутый пакет будет отправлен абонентом 1. Тогда он не дождется ACK и через 200-400мс начнет повторение. За время молчания полоса будет принадлежать абоненту 2. Допустим, повторный пакет долетает до приемника и ACK долетает обратно. Абонент 1 начинает лить данные. Опять возникает дроп и в зависимости от того, пакет какого абонента дропнуло, тот абонент и будет курить 200-400мс TCPшной задержки перепосылки пакета. Если выбор, дропать пакет абонента 1 или абонента 2 случаен, то в среднем абоненты и будут делить полосу, только случайными интервалами, определяемыми временем перепосылки. Причем, ситуация дико усугубляется тем, что TCP повторяет пакеты по закону t,2t,4t и так далее, значит, после первого дропа если пакет не пройдет, то курить бамбук абонент будет уже 2t, и т.д....

 

Аналогичная проблема стоит в шейперах - шейпить накоплением пакетов или шейпить дропом.

 

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

[Kaban]

И что в той ссылке интересного ? О том что есть возможность из одного VLAN-а влезть в другой известно давно, например если клиент сидит в native VLAN то через двойное тегирование можно отправить все что угодно в любой VLAN. Но речь вроде как шла немного о другом.

Edited September 1, 2008 by Kaban