Barsick Опубликовано 29 августа, 2008 · Жалоба Симптомы: На коммутаторе ритмично моргает лампочка одного из абонентов, 1-2 раза с секунду. Коммутатор в 95% параличе, ходят только бродкасты, если комм управляемый - вебморды/телнета/пингов нет Соседние коммы в легком обмороке, 20-50% потерь, управление то есть, то нет Коммы через один и далее - управление в норме, потери 5-10% Сниффером (wireshark) ничего не ловится!!! Что это? Случаи не частые, пару раз в месяц на ~5000 абонентов. Пролазит ли флуд в соседние виланы - пока не понял Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nafanya Опубликовано 29 августа, 2008 (изменено) · Жалоба Симптомы:На коммутаторе ритмично моргает лампочка одного из абонентов, 1-2 раза с секунду. Коммутатор в 95% параличе, ходят только бродкасты, если комм управляемый - вебморды/телнета/пингов нет Соседние коммы в легком обмороке, 20-50% потерь, управление то есть, то нет Коммы через один и далее - управление в норме, потери 5-10% Сниффером (wireshark) ничего не ловится!!! Что это? Случаи не частые, пару раз в месяц на ~5000 абонентов. Пролазит ли флуд в соседние виланы - пока не понял а из какой точки сети снифили? прямо с того порта, предположительно флудящего? Судя по описаниюСоседние коммы в легком обмороке, 20-50% потерь, управление то есть, то нетКоммы через один и далее - управление в норме, потери 5-10% до вас могло уже ничего и не дойти... похоже на arp-атаку на свитч, дабы превратить его в "хаб" :) Изменено 29 августа, 2008 пользователем Nafanya Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Heggi Опубликовано 29 августа, 2008 · Жалоба Было такое несколько раз. Самое странное - комп у юзера в этот момент выключен, т.е. флудит непосредственно сама сетевая карта (на нее питание всегда подается) этот флуд ложит весь сегмент мыльниц (сеть поделена управляемыми мутаторами типа Compex SXP2224WM. Он весьма успешно отсекает такой флуд Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Barsick Опубликовано 29 августа, 2008 · Жалоба а из какой точки сети снифили? прямо с того порта, предположительно флудящего? Судя по описаниюСнифил непосредственно с абон. кабеляэтот флуд ложит весь сегмент мыльницЕсли бы... Des-3526 и Ex3525 (или как его? ёжык который?) тоже укладываютсяСамое странное - комп у юзера в этот момент выключен, т.е. флудит непосредственно сама сетевая картаПоходу да. Либо абонент выключил свет и не пускал никого домой :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 30 августа, 2008 · Жалоба Снифил непосредственно с абон. кабеляА там точно не было 1q тегированного трафика? Мож юзер случайно поднял.У меня однажды на ноуте броадкомоская начала такое вытворять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 30 августа, 2008 · Жалоба Barsick, у вас что, юзера и управляющий IP свича в одном VLAN-е ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ruslan_R Опубликовано 30 августа, 2008 · Жалоба Было такое несколько раз. Самое странное - комп у юзера в этот момент выключен, т.е. флудит непосредственно сама сетевая карта (на нее питание всегда подается)этот флуд ложит весь сегмент мыльниц (сеть поделена управляемыми мутаторами типа Compex SXP2224WM. Он весьма успешно отсекает такой флуд Сталкивались с подобным один раз. Повторялось с периодичностью раз в месяц. Вылечилось установкой у пользователя другой сетевой карты (карта была встроенная, Nforce-какой-то). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Barsick Опубликовано 30 августа, 2008 · Жалоба Barsick, у вас что, юзера и управляющий IP свича в одном VLAN-е ?В разных, т.е. между виланами эта гадость таки просачивается.Сталкивались с подобным один раз. Повторялось с периодичностью раз в месяц. Вылечилось установкой у пользователя другой сетевой карты (карта была встроенная, Nforce-какой-то).Nforce? Единственая ассоциация - зачем-то запущеный VCT (Virtual Cable Tester) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 30 августа, 2008 (изменено) · Жалоба Сильно сомневаюсь чтоб флуд просачивался между VLAN-ами. Конструкция свич фабрики этого не позволяет. Скорее всего флуд тупо вали свич. Попробуйте на клиентских портах врубить loopdetect, broadcast/multicast storm control и port-security с жестко вбитыми МАК адресами. Изменено 30 августа, 2008 пользователем Kaban Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ram_scan Опубликовано 30 августа, 2008 · Жалоба Сильно сомневаюсь чтоб флуд просачивался между VLAN-ами. Конструкция свич фабрики этого не позволяет. Скорее всего флуд тупо вали свич. Да лехко, особенно на длинках. Там мак адрес не целиком анализируется, а обычно только младшие 32 бита (а то и меньше). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilShadow Опубликовано 30 августа, 2008 · Жалоба Сильно сомневаюсь чтоб флуд просачивался между VLAN-ами. Конструкция свич фабрики этого не позволяет. Скорее всего флуд тупо вали свич. Да лехко, особенно на длинках. Там мак адрес не целиком анализируется, а обычно только младшие 32 бита (а то и меньше). Не подскажете, откуда такие сведения? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IvanI Опубликовано 30 августа, 2008 · Жалоба на длинках невидел а на планетах 2401 виндовый клиент начинает работать иногда до того как PVID правильно выставиш.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 30 августа, 2008 · Жалоба ланетах 2401 виндовый клиент начинает работать иногда до того как PVID правильно выставишЬ Так у роутера во всех виланах один и тот же адрес? И если не циска, то и на arp в левом вилане может ответить. А сетевуха спокойно забирает тегированный трафик из своего вилана. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 31 августа, 2008 (изменено) · Жалоба Сильно сомневаюсь чтоб флуд просачивался между 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 по умолчанию включен :) Изменено 31 августа, 2008 пользователем ingress Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rst7.CBSIE Опубликовано 31 августа, 2008 · Жалоба p.s. по теме очень мне кажется что это FlowControl включенный на порту и фрейм PAUSEво всех тупых свичах FlowControl по умолчанию включен :) Похоже. Только банально выключать FlowControl не стоит. Надо смотреть, есть ли у свича возможность задания максимального количества пакетов PAUSE. Например, RTL8324 имеет 2 режима, бесконечность и лимит в 128 пакетов. Причем управляется бутстрепом (т.е. подтяжками пинов при старте). Если железо сделано так, что выбрана бесконечность - вполне возможна такая зопа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 31 августа, 2008 · Жалоба p.s. по теме очень мне кажется что это FlowControl включенный на порту и фрейм PAUSEво всех тупых свичах FlowControl по умолчанию включен :) Похоже. Только банально выключать FlowControl не стоит. Надо смотреть, есть ли у свича возможность задания максимального количества пакетов PAUSE. Например, RTL8324 имеет 2 режима, бесконечность и лимит в 128 пакетов. Причем управляется бутстрепом (т.е. подтяжками пинов при старте). Если железо сделано так, что выбрана бесконечность - вполне возможна такая зопа. только смысла в нём чтобы оставлять включенным? только в случае рейтлимитинга на низких скоростях, чтобы потери пакетов не было.(сами блинки рекомендуют) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rst7.CBSIE Опубликовано 31 августа, 2008 · Жалоба только смысла в нём чтобы оставлять включенным? Ну перекладывать проблемы дропа пакетов из-за переполнения буферов на протоколы более высокого уровня (в частности на TCP) тоже не выход... Просто флоу-контрол приостановит поток данных, потом возобновит, в результате будем мягкое ограничение скорости. А при его отсутствии пакет дропнется и когда там еще TCP приспичит повторить (обычное число 200-400мс)... Некошерно :) А вот если уж совсем туго (ну стоит какой-то абонент в паузе; кстати, похоже у абонента хитрозопая сетевка, которая при отсутствии жизни у главного мозга генерит PAUSE-пакеты, дабы мозг по просыпанию мог их получить), тогда надо обязательно лимитить количество пакетов PAUSE, чтобы не положить всю сетку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 31 августа, 2008 (изменено) · Жалоба странно, но на мой взгляд локомотив движется к тому чтобы возложить весь контроль целостности, отслеживание очередей и фрагментацию на более высокие уровни, чтобы об этом думали(оффлоадили) конечные хосты, а не сетевое оборудование. как примеры обязательный checksum в UDP и фрагментация пакетов только хостом в IPv6 Изменено 31 августа, 2008 пользователем ingress Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 31 августа, 2008 · Жалоба Да лехко, особенно на длинках. Там мак адрес не целиком анализируется, а обычно только младшие 32 бита (а то и меньше). А при чем тут МАК адрес ? Если я не ошибаюсь то в CAM таблице кроме адресной части есть еще поле VLAN. Коммутация и бродкастинг фреймов происходят только в пределах того VLAN-а откуда пришел фрейм. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 31 августа, 2008 · Жалоба Да лехко, особенно на длинках. Там мак адрес не целиком анализируется, а обычно только младшие 32 бита (а то и меньше). А при чем тут МАК адрес ? Если я не ошибаюсь то в CAM таблице кроме адресной части есть еще поле VLAN. Коммутация и бродкастинг фреймов происходят только в пределах того VLAN-а откуда пришел фрейм. вланы тоже можно подделывать, забыл я адрес где над телесином издевались за то нашёл вот такое http://www.sans.org/reading_room/whitepape...rkdevs/1090.php Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rst7.CBSIE Опубликовано 31 августа, 2008 · Жалоба странно, но на мой взгляд локомотив движется к тому чтобы возложить весь контроль целостности, отслеживание очередей и фрагментацию на более высокие уровни, чтобы об этом думали(оффлоадили) конечные хосты, а не сетевое оборудование. как примеры обязательный 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, и т.д.... Аналогичная проблема стоит в шейперах - шейпить накоплением пакетов или шейпить дропом. Так что выключение флоуконтрола - это может здорово усугубить ситуацию в загруженной сети. Особенно при больших потоках от абонентов (файлообмен, например). Поток от провайдера - ему так плохо не станет по простой причине - он широкий у провайдера и бьется на много маленьких ниже. Т.е. проблема возникнет только если пытаться запихнуть три по сто в один стакан :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 31 августа, 2008 (изменено) · Жалоба И что в той ссылке интересного ? О том что есть возможность из одного VLAN-а влезть в другой известно давно, например если клиент сидит в native VLAN то через двойное тегирование можно отправить все что угодно в любой VLAN. Но речь вроде как шла немного о другом. Изменено 1 сентября, 2008 пользователем Kaban Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...