Juniper switch storm control

[djfijolko]

Witam wszystkich

Nie mam zbyt dużej wiedzy na temat konfiguracji switchy dlatego poprosiłbym o pomoc w temacie konfiguracji switcha.

Chciałbym ustawić kilka portów w posiadanym przeze mnie switchu EX-4200 na ruch iSCSI. Wyczytałem gdzieś na forum że należałoby wyłączyć storm control i tu mam pytanie:

czy wpisując komend:
set ethernet-switching-options storm-control interface ge-0/0/11 level 100

wyłączyłem storm control? nie wiem jak to jest z tymi levelami - czy 100 oznacza wyłączony?
Czy Może lepiej posługiwać się np.
no-unknown-unicast

po wpisaniu dla interesujących mnie portów że level = 100 w show: wyskoczyło mi

show ethernet-switching-options storm control

interface ge-0/0/11.0 {
level 100;
}
.
.
.
.
.
interface ge-0/0/20.0 {
level 100;
}
interface all;

[djfijolko]

przestałem się bawić level i dla ruchu iSCSI postanowiłem ustawić jedynie opcję no-unknown-unicast

prosiłbym o podwowiedź (potwierdzenie) czy poniższa konfiguracja jest prawidłowa tj. czy wyłącza unicast strom contol na switchu dla wybranych portów ( na których u mnie przechodził będzie ruch iSCSI)

interface ge-0/0/11.0 {
no-unknown-unicast;
}
interface ge-0/0/12.0 {
no-unknown-unicast;
}
interface ge-0/0/13.0 {
no-unknown-unicast;
}
interface ge-0/0/14.0 {
no-unknown-unicast;
}
interface ge-0/0/15.0 {
no-unknown-unicast;
}
interface ge-0/0/16.0 {
no-unknown-unicast;
}
interface ge-0/0/17.0 {
no-unknown-unicast;
}
interface ge-0/0/18.0 {
no-unknown-unicast;
}
interface all;

w góry dziękuję

[Lukasz_eS]

EXy nie potrzebują dodatkowej konfiguracji dla portów iSCSI. Mechanizm Storm Control jest domyślnie dla EX4200 aktywny i threshold wynosi 80% przepustowości portu. Wpisując level 100 twierdzisz, że obciążenie portu na 100% jest całkiem normalne. Na pewno tego chcesz?

flaga no-unknown-unicast blokuje ruch na unknown unicast na tym porcie.

[djfijolko]

Bardzo Ci dziękuję za odpowiedź, tzn sugerujesz że nie powinienem kombinować ze storm control i zostawić domyślnie na level 80 i no-unknown-unicast też wykasować ??

Pytam o tyle rzeczy bo pierwszy raz konfiguruje switche pod iSCSI (chciałbym to zrobić dobrze przed zabraniem się za macierz - u mnie ruch będzie przechodził przez 2 niezależne switche jeden Juniper i awaryjnie Cisco 3750), a wyczytałem, że należy:

- ustawić auto negocjację na switchach dla portów iSCSI (domyślnie włączone na Juniper)

- wyłączyć unicast strom contol na switchach dla portów iSCSI (ustawiłem poprzez no-unknown-unicast jak w poprzednim poście)

- włączyć Flow Control na przełącznikach i sieciówkach (domyśnie włączone na Juniper)

- wyłączyć spanning tree na switchach dla portów iSCSI (może powodować opóźnienia)

- użyć Jumbo Frames jeśli infrastruktura wspiera. (zmieniłem na 9000 MTU)

[Lukasz_eS]

Bardzo Ci dziękuję za odpowiedź, tzn sugerujesz że nie powinienem kombinować ze storm control i zostawić domyślnie na level 80 i no-unknown-unicast też wykasować ??

Ciężko jest walczyć z zagrożeniem, którego nie jesteś w stanie zidentyfikować. W internecie ludzie piszą różne rzeczy. Bardziej bym się skupił na zrozumieniu mechanizmu storm control niż na wyłączaniu go. Level 100 wskazuje, że dopiero w momencie gdy BUM będzie stanowił 100% ruchu stanie się jakaś akcja (shutdown portu, err-dis). Inna sprawa czy przewidujesz wykorzystanie przepustowości tych serwów w takim dużym stopniu (większym niż 80%).

[djfijolko]

dzięki za wyjaśnienie szczególnie level

co do info z internetu --> poszukiwałem czegoś w rodzaju "best practice" dot. ustawień dot. ruchu ISCSI - i starałem się znaleźć jakieś w miarę potwierdzające i uzasadnione informacje

Tak jak doradzasz postaram się obserwować obciążenie portów po dodawaniu kolejnych wirtualnych maszyn, ale obciążenie portu może być spore biorąc pod uwagę to że na jednym hoście jest kilka wirtualek a wszystkie one łączą się przez jedną fizyczną kartę sieciową (druga pracuje jako awaryjna) do jednego dysku (macierzy dyskowej)

Puki co z level postanowiłem nic nie kombinować. No unknown unicast z tego co zrozumiałem zablokuje nieznany ruch unicast na konkretnych portach, z tego co się orientuję nie powinno być nieznanego ruchu pomiędzy ESX a macierzą więc zastanowię się jeszcze nad tą opcją.

No nic pozostaje mi w miarę możliwości czasowych obserwacja wdrażanego środowiska