Изпечатай

[never_mind]

Значи тази вечер си направих малък експеримент... мрежате е следната, рутер с OpenBSD, след него суич и към суича 2 клиента... давам loop на 2 от портовете на суича и цялата мрежа умира... но ми умира и bsd-то... как мога да предотвратя подобно нещо, някак си да огранича този флууд от арп заявки да не влияе на интерфейса на bsd-то...

[spirtbrat]

Може би проблема ти е друг, но все пак разгледай това малко поостаряло сравнение между Linux, FreeBSD, OpenBSD и NetBSD. OpenBSD има scalability (не знам как точно се превежда на български; може би 'мащабируемост' ) под всякаква критика. Дори разработчиците твърдят, че целта им винаги е била сигурност, а не скорост или scalability и нямат никакво намерение да правят промени в това отношение.
С две думи - при голямо натоварване (особено при мрежово) OpenBSD губи своята отзивчивост (забива).
Ако искаш, пробвай FreeBSD или Linux на рутера. Ако са добре настроени, много се доближават по сигурност до OpenBSD.

[never_mind]

И аз имам подобни наблюдения върху него, при мрежово натоварване много ми забива... и преди експеримента с лууп-а... но все пак не може да няма нещо, с което да го ограничавам, така че вместо да забива, да отрязва самите заявки... кофтито е, че не знам защо забива, РАМ-а ли му свършва, процесора ли... но в момента в който разкача луупнатите портове всичко си идва на мястото... ако по време на луупа съм писал в шела ( той не отговаря естествено ), след прекратяване на луууп-а изведнъж шела ми изплюва всичко написано... тоест системата не е  тотално забила, ами е зависнала само... тоест с правилни ограничения според мен може да се постигне резултат... само че не знам с какъв инструмента да ги направя...
п.с. и 2-та клиента за суича са на Хр, не лоши пс-та, но и 2-та зациклят в лууп-а ... '>

[gat3way]

Много прекъсвания '>

Иначе има начин разбира се '> Смъкваш интерфейса и готово '>

[never_mind]

Добре, а как да си сваля интерфейса, като системата е зависнала... мога само ръчно като измъкна кабела... '> ... това не ме устройва... или пък да го направя автоматично да го сваля при достигане на някакъв лимит, ама там е въпроса, че не знам как... ако са прекъсвания както ти казваш, какво трябва да следя... cputime? ...

[gat3way]

Ммммнезнам, от BSD не разбирам. Предполагам top ще покаже нещо там под графите "hi" и "si" на процесорната утилизация, едното е процесорното натоварване потрошено от хардуерни прекъсвания, другото грубо казано от функции в ядрото, свързани с обработката на тези прекъсвания (softirq).

А и защо ти е да лимитираш такива неща, не е ли по-лесно да не се получават ethernet loops? Например вземи си суичове, които подържат STP.

[teleport]

Цитат (gat3way @ Април 16 2008,16:10)

Например вземи си суичове, които подържат STP.

В описаната ситуация STP-то изобщо няма да помогне. Или поне всичко с което съм работил като управляеми L2 switch-ове не реагира на такъв loop.

STP се задейства само ако затвориш връзката между 2 порта на управляемия switch. ( корекция: ако я затвориш на L2 само ).

В случая помага Broadcast Storm Protection.

[never_mind]

Да си взема STP суич... а ако нямам права върху суича, а просто искам да си защитя рутера?

Знам какво помага в този случай, въпросът е някой реализирал ли го е досега при BSD/Linux...

[gat3way]

STP по принцип е създаден да решава проблемите с forwarding loops когато имаш няколко суич-а. Аз някак си не мога да си представя че по грешка някой може да хване и да свърже 2 порт-а на суича с един кабел по грешка, съжалявам, но ми е трудно да си представя как това ще стане без да искаш. Докато L2 loops възникнали покрай навързани няколко суич-а или машини, които го играят bridge без STP съм виждал.

В смисъл такъв че нещата трябва да си имат някаква обосновка и причина.

Освен това, предполагам на повечето управляеми суичове които си виждал, всички портове по дефолт са били административно смъкнати преди ти да решиш да ги вдигнеш. И ето ти още нещо: ти ще ги активираш ли при положение, че знаеш че правят L2 loop? Не знам ама цялата работа ми се вижда малко ненормална. В смисъл да, има някаква там вероятност да стане такава издънка, но според мене това не е лесно да се случи и ако има отговорни network администратори, такива неща не би следвало да се случват.

[never_mind]

Хахахах... на мен ми е ясно, че трябва да си рядко тъп за да го направиш... но понякога се прави от невнимание или недоглеждане... имам колеги, които бачкат за големи ISP-та и какви ли не работи са ми разказвали... но не е там цялата работа... работата е да си подготвен за всичко, без значение дали е възможно или не...

[teleport]

Цитат (gat3way @ Април 16 2008,22:34)

STP по принцип е създаден да решава проблемите с forwarding loops когато имаш няколко суич-а. Аз някак си не мога да си представя че по грешка някой може да хване и да свърже 2 порт-а на суича с един кабел по грешка, съжалявам, но ми е трудно да си представя как това ще стане без да искаш.

Ами напротив точно това е идеята. STP се ползва за да имаш L2 връзка през други L2 switch-ве без значение дали говорят STP или не, поне по 2 пътя. Т.е. правиш ring топология и затваряш кръг. Един от STP switch-овете ще прекъсне ring-а, в зависимост от скорост на портовете, разстояние до целта ( ако има и други STP switch-ове в ring-a ) и административно настроен приоритет. При отпадане на единия път трафика се пренасочва по другия.

Това е простото обяснение. Сложното, както и истинската функционаност на STP можеш да разгледаш примерно тук: http://en.wikipedia.org/wiki/Spanning_tree_protocol

PS: да, трябва да си "рядко тъп" всъщност леко невнимателен или просто разсеян за да вържеш 2 порта един към друг. Обаче има една подробност. Един управляем L2 switch няма абсолютно никакъв начин да разбере дали си му вързал 2 порта с кабел или са вързани през 20 последователно неуправляеми switch-a. При активиран STP и на двата порта за управляемия switch всичко е наред: има 2 пътя до клиентите, единия порт е активен и във forward state, другия порт е активен в blocked state. "Блокнатия" порт ( или портове, може да са повече от 1 ) прави мониторинг дали кръга няма да се разпадне слушайки за stp пакетите от активния.

Да направиш оптимална STP топология е едно от най-трудните неща, които могат да ти се паднат в голямо ISP.

[smelkomar]

Понякога самият switch е дефектен или дефектира '>

[teleport]

Абсолютно съм съгласен. Единствения начин да спасиш остатъка от ethernet сегмента е да имаш управляем L2 който минимум да може да лимитира broadcast storm-а, и силно желатено да го съобщава ( snmp trap примерно ).

В случая мрежата няма никаква вина че конкретната машина/ос не може да поеме голям брой пакети/сек заради хардуерни/софтуерни ограничения ( брой физически прекъсвания/сек ).

[gat3way]

Ъъм немаш ring топология. T-то идва от tree.

Цитат

Един управляем L2 switch няма абсолютно никакъв начин да разбере дали си му вързал 2 порта с кабел или са вързани през 20 последователно неуправляеми switch-a.

Това дали е управляем суич-а не е  в пряка зависимост с това дали подържа spanning tree протокола. Да, очаква се управляем суич да го подържа и не, не е задължително суич да не го подържа без да е управляем. Протоколът е относително прост за имплементиране и предполагам, има клас комутатори, които не са управляеми и същевременно подържат протокола. Интересно какъв приоритет си слагат в тези фреймове, това е друг въпрос.

Използването на STP в среда, където не всички устройства го подържат е безсмислено и опасно. В това число влизат и системи, които bridge-ват интерфейси. Ако имаш виртуализация, там наистина е опасно, защото бридж-ването е често срещано явление, а там грешките стават лесно '>

За щастие, stp не е нещо непознато в света на линукс, пак казвам за BSD не знам.

[teleport]

Цитат (gat3way @ Април 17 2008,00:43)

Ъъм немаш ring топология. T-то идва от tree. Използването на STP в среда, където не всички устройства го подържат е безсмислено и опасно.

В едно tree има много ring-ове :)

Дай пример защо е опасно?

Мисля че се заблуждаваш относно идеята на STP. Протокола е измислен за да осигурява много алтернативни пътища на пакетите до клиентите и при отпадане на физически линк. Единствения начин в L2 среда е като се внимава да няма едновременно повече от един активен път между два L2 клиента.

STP не е измислено за да се пази сегмента от L2 loop. Ако в един STP ethernet сегмент забиеш кабел в 2 порта на неуправляем switch ще предизвикаш моментално broadcast storm в целия сегмент и STP-то няма да реагира изобщо. И изобщо не е необходимо всичко включено в тоя сегмент да говори STP. Ако едно pc с 2 или повече лан карти в bridge го включиш в сегмента така че всяка лан карта да води до различен stp switch или до различни портове на един stp switch то протокола ще го открие, ще калкулира best path и ще блокира всички други портове. Ако забиеш повече от една лан карта в един stp сегмент правиш веднага l2 loop и съответно broadcast storm.

Това пак стана доста offtopic. Но просто заглавието на темата не е коректно. Човека има проблем с машина която не издържа на голям брой пкаети/сек, просто l2 loop-а е един то начините да се предизвика голям брой пакети/сек към машината му. Въпроса в крайна сметка е какво може да се направи с BSD-то за да почне да носи на много пакети/hard/soft irq-та без да умира.