Czy „Switchport Protected” ma blokować zalewanie emisji pojedynczej?

Czy switchport protectedskonfigurowanie interfejsu zapobiega zalewaniu emisji pojedynczej dla adresu MAC, którego przełącznik się nie nauczył?

Informacje, które widzę w konfliktach - strona Wikipedii na temat powodzi unicast podaje tryb chroniony jako mechanizm blokowania powodzi, podczas gdy dokumentacja Cisco mówi, że switchport protectedto nie ma znaczenia, i switchport block unicastnadal byłoby potrzebne, aby zapobiec powodziom.

Ostatnio jednak natknąłem się na problem polegający na tym, że w 2950G z relatywnie starym kodem 12.1 (22) zalewanie emisji pojedynczej wydawało się całkowicie przerwane dla chronionego portu - czas starzenia się na przełączniku wynosił 5 minut, podczas gdy limit czasu ARP routera trwało 30 minut, a jedno połączenie TCP korzystające z tego interfejsu miało tendencję do uśpienia przez 10 minut na raz - i w tym przypadku nie działało po przebudzeniu po 10 minutach.

Przechwyty uruchomione na hoście nie pokazały powodzi unicast, gdy oczekiwano, a zwiększenie czasu starzenia MAC na przełączniku, aby dopasować ARP, całkowicie rozwiązało problem.

Czy to zachowanie jest niezdefiniowane lub niespójne w starszych wersjach IOS, czy to tylko błąd w tym starym kodzie?

— Shane Madden
źródło

Cześć Shane, poprawnym rozwiązaniem dla tej sytuacji jest zwykle ustawienie timera ARP nieco niższego niż timera CAM . Jest to rozsądne pytanie o ochronę portów Switchport, ale prawdopodobnie nie jest to najlepszy sposób na rozwiązanie problemu ...

— Mike Pennington,

@MikePennington Gotcha, ma sens. W tej chwili wszystko działa świetnie z dopasowanymi licznikami, po prostu zastanawiam się, dlaczego niespójność między dokumentacją a obserwowanym zachowaniem.

— Shane Madden

Czy został switchport protectedskonfigurowany na wszystkich portach przełączania w sieci Vlan? Czy jest jakaś szansa, że zobaczymy konfiguracje i schemat ścieżki między dwoma hostami?

— Mike Pennington,

@MikePennington Tak, jest skonfigurowany na wszystkich portach tego vlana, z wyjątkiem łącza w górę. Router następnego przeskoku (przez który przepływa problematyczny ruch) to przełącznik, do którego przełącza ten łącze w górę. Konfiguracje byłyby trudne, ale w razie potrzeby mogę zdobyć określone części zainteresowań.

— Shane Madden,

Informacje, które widzę w konfliktach - strona wikipedii na temat powodzi unicasta podaje tryb chroniony jako mechanizm blokowania powodzi, podczas gdy dokumentacja Cisco mówi, że ochrona switchport nie ma znaczenia, i że unicast blokowania switchport byłby nadal potrzebny, aby zapobiec zalaniu .

switchport protectedsłuży do egzekwowania prywatności w sieci vlan ... polecenie uniemożliwia portom komunikowanie się z innymi portami skonfigurowanymi za pomocą switchport protected. To polecenie zmniejsza zalewanie jako efekt uboczny używania go na wszystkich portach w Vlan, ale robi znacznie więcej niż „tylko” usuwa zalanie z portu przełączania. Szczerze mówiąc, myślę, że są lepsze sposoby na osiągnięcie twoich celów.

switchport protectedjest przydatny, jeśli agregujesz klientów kolokacji w tym samym vlan; to polecenie jest jednym ze sposobów oferowania prywatności między klientami bez komplikacji prywatnych sieci vlan. Artykuł w Wikipedii, o którym wspomniałeś, mówi, że możesz „odbić” ruch od domyślnej bramy (która nie powinna znajdować się w chronionym portie przełączania), aby dotrzeć do tych innych miejsc docelowych ...

switchport block unicastpowstrzymuje nieznane powodzie unicast; zobacz jednak poniżej, dlaczego uważam, że nie powinieneś potrzebować tego polecenia.

Ostatnio jednak natknąłem się na problem polegający na tym, że w 2950G z relatywnie starym kodem 12.1 (22) zalewanie emisji pojedynczej wydawało się całkowicie przerwane dla chronionego portu - czas starzenia się na przełączniku wynosił 5 minut, podczas gdy limit czasu ARP routera trwało 30 minut, a jedno połączenie TCP korzystające z tego interfejsu miało tendencję do uśpienia przez 10 minut na raz - i w tym przypadku nie działało po przebudzeniu po 10 minutach.

Jak wspomniałem w moim komentarzu, jeśli istnieje potencjał dla asymetrycznej trasy routowanej w tej sieci, albo potrzebujesz nieznanego zalewania emisji pojedynczej, albo musisz dopasować timery CAM i ARP, aby upewnić się, że wpisy CAM nie zestarzeją się przed Wpisy ARP.

W większości przypadków dopasowanie timerów ARP i CAM jest właściwym sposobem naprawienia sytuacji , ale wybór należy do Ciebie ...

EDYTUJ, aby odpowiedzieć na komentarze:

Ustawienie czasomierzy, które pasują, działa świetnie jako obejście - po prostu nie rozumiem, dlaczego powódź nie dzieje się zgodnie z oczekiwaniami.

Cytując z „CCIE Practical Studies, Tom 2”, str. 115 Karl Solie, Leah Lynch, Charles Ragan:

Jeśli nieznany ruch emisji pojedynczej i multiemisji zostanie przekazany do chronionego portu, mogą wystąpić problemy z bezpieczeństwem. Aby zapobiec przekazywaniu nieznanego ruchu emisji pojedynczej lub multiemisji z jednego portu do drugiego, można skonfigurować port (chroniony lub niezabezpieczony) w celu blokowania nieznanego ruchu emisji pojedynczej i multiemisji.

3550_switch(config-if)#switchport block unicast
3550_switch(config-if)#switchport block multicast

— Mike Pennington
źródło

Pozwól, że wyjaśnię: switchport protectedw tym przypadku został zaimplementowany jako mechanizm izolacji między systemami, które nie powinny mieć możliwości komunikacji. Wspomniany ruch dociera do przełącznika na niezabezpieczonym porcie i nie powoduje emisji pojedynczej zalanych chronionych portów w sieci vlan - z tego powodu występują awarie połączenia. Ustawienie czasomierzy, które pasują, działa świetnie jako obejście - po prostu nie rozumiem, dlaczego powódź nie dzieje się zgodnie z oczekiwaniami.

— Shane Madden,

@ShaneMadden, słusznie spodziewałeś się zalania emisji pojedynczej w chronionym portie przełączania. Zobacz moją edycję.

— Mike Pennington,

Zgadza się - jakieś myśli na temat tego, co powoduje niepowodzenie powodzi? Nie mogę wymyślić wielu pomysłów innych niż błąd IOS.

— Shane Madden,