Więcej

    Problemy w sieci – routing asymetryczny, unicast flooding i inne

    W dzisiejszym artykule dowiesz się o czterech problemach, z którymi możesz się zetknąć w trakcie pracy z sieciami. Skutki niektórych z nich są mało widoczne, podczas gdy inne powodują naprawdę spore utrudnienia w prawidłowej pracy sieci. O czym tu mowa? O routingu asymetrycznym, zjawisku unicast floodingu, pakietach docierających do hosta docelowego w niewłaściwej kolejności oraz o tzw. micro-bursts. Przyjrzyjmy się nieco bliżej każdemu z tych problemów.

    Routing asymetryczny

    Routing asymetryczny to sytuacja, w której ruch wychodzący z sieci wraca do niej inną ścieżką niż ta początkowa:

    untitled-4
    Routing asymetryczny

    Może to spowodować problemy np. w sytuacji gdy na ścieżce przychodzącej (niebieska) znajduje się stateful firewall – ruch powrotny nie będzie mu znany ponieważ sesja została zarejestrowana na firewallu na ścieżce wychodzącej (czerwona). Cisco ASA mógłby sobie z tym problemem poradzić dzięki sparowaniu obu zapór w zsynchronizowany klaster, ale nie każdy firewall oferuje taką możliwość. Mogą również wystąpić problemy z NATowaniem oraz z opóźnieniem w transmisji gdy jedno z łącz jest bardziej wykorzystywane od drugiego. Ponadto routing asymetryczny może przyczyniać się do powstawania kolejnego problemu na naszej liście: unicast floodingu.

    Unicast flooding

    Przełączniki otrzymując ramkę z nieznanym adresem docelowym domyślnie wysyłają tę ramkę unicastem na wszystkich portach (poza nadawczym) w celu dotarcia do odbiorcy – nie jest to nic dziwnego gdyż jest to standardowe zachowanie switcha, gwarantujące dostarczenie pierwszej ramki w danej konwersacji. Problemem są jednak takie niekontrolowane zalewy ramkami unicastowymi, a problem ten zwie się „unicast flooding„.

    pic1
    Unicast flooding

    Wyróżnia się trzy przyczyny powstawania takiego niekontrolowanego ruchu:

    1. Routing asymetryczny: jeśli przełącznik nie zna danego MACa to roześle unicast flooding, to już wiadomo. Jeśli ten przełącznik nie otrzyma ruchu powrotnego (a w przypadku routingu asymetrycznego tak się właśnie może stać) to będzie on wysyłał unicast flooding za każdym razem gdy będzie musiał wysłać pakiet do nieznanego adresu MAC. I tak w nieskończoność. Ponadto pakiety powrotne przechodzą ścieżką, w której adresy docelowe MAC również mogą być jeszcze nieznane przełącznikom po drodze. Pakiety te spowodują zatem również powstawanie unicast flooding na ścieżce powrotnej. Rozwiązaniem mogłoby być dodanie statycznych adresów MAC, aczkolwiek jest to mało skalowalne – lepiej skupić się na pozbyciu asymetrycznego przepływu danych.

    2. Zmiany w topologii STP: za każdym razem gdy następuje zmiana w topologii STP rozsyłane są komunikaty TCN – Topology Change Notifications, w celu poinformowania pozostałych przełączników o zmianie. Poza zalewaniem sieci TCN, problemem może być również związany z nimi mechanizm skracania aging time tablicy MAC (domyślnie z 3 minut do 15 sekund). W przypadku wygaśnięcia dużej ilości wpisów sieć jest narażona na zwiększoną ilość unicast flooding aby ponownie się nauczyć lokalizacji hostów. Szczególnie paskudne są „flapujące” hosty – to one powodują rozsyłanie nadmiarowych TCN. Rozwiązaniem tego problemu jest właściwe zaprojektowanie topologii STP oraz ograniczenie ilości rozsyłanych TCN poprzez uruchomienie PortFast na portach dostępowych.

    3. Przepełnienie tabeli MAC: to jest znany problem – w momencie, w którym tabela MAC ulega przepełnieniu, przełącznik działa jak hub – generuje unicast flooding. Najczęściej przyczyną przepełnienia jest atak hakerski, ale funkcja port-security dobrze sobie radzi z tym problemem.

    Jako ciekawostkę można dodać, że o ile port-security zabezpiecza port przed nieznanymi żródłowymi adresami, to istnieje również funkcja zabezpieczająca port przed braniem udziału w samym procesie unicast floodingu. Funkcja ta to Unknown Unicast Flood Blocking (UUFB), a uruchamia się ją z poziomu interfejsu komendą switchport block unicast. Dobrym miejscem na zastosowanie tej funkcji mogą być np. wyizolowane porty private vlan.

    Micro-bursts

    Micro-bursts to nazwa, którą określamy krótkotrwałe skoki wykorzystania łącza do 100%. Spowodowane są one nagłymi wyrzutami dużych ilości pakietów do sieci, które w rezultacie mogą powodować przepełnienia buforów pamięci i zatłoczenie (congestion). Efekt jest krótko-trwały i wielokrotnie niedostrzegalny, jednakże powoduje mikro-opóźnienia w sieci, które mogą być istotne np. dla firm z branży finansowej.

    microburst
    Micro-bursts

    Micro-bursts mogą spowodować:

    • odrzucanie oraz opóźnianie ramek/pakietów
    • zatłoczenie na łączach, które skupiają większe ilości ruchu (np. w warstwie dystrybucyjnej gdy intensywny ruch z wielu serwerów wpada w niewielką ilość łącz między warstwą core i dystrybucyjną a ich przepustowość jest za niska)
    • niedotrzymywanie SLA
    • błędy w działaniu aplikacji (zwłaszcza tych podatnych na niewielkie opóźnienia w transmisji)

    Micro-bursts są ciężko dostrzegalne ponieważ wykresy wykorzystania łącza w interwale 1-minutowym pozostają niskie. Rozwiązaniem problemu jest przede wszystkim zastosowanie traffic-shapingu.

    Out-of-order packets

    Problemem dla niektórych aplikacji mogą być pakiety otrzymywane nie w kolejności. Problem ten dotyczy zwłaszcza UDP, który nie posiada wbudowanego mechanizmu składania segmentów (reassembly) z powodu braku numerów sekwencyjnych. Problem ten dotyczy również TCP gdy ilość pakietów poza kolejnością jest zbyt duża – powoduje to, że odbiorca buforuje pakiety (spowalniając przepływ danych do wyższych warstw i tym samym osłabiając ich wydajność) oraz wysyła duplicate ACKs prosząc nadawcę o szybką retransmisję. W następstwie zwiększa się stopień wykorzystania sieci oraz CPU po obu stronach transmisji. Ponadto nadawca interpretuje tę sytuację jako powstanie zatłoczenia w sieci i ogranicza congestion window spowalniając cały ruch. Spowolniony ruch TCP przechodzi w fazę slow start i jeśli takie przerwania następują często to może on nie dać rady się „rozpędzić” ponownie.

    64-tcp-segment
    Out-of-order packets

    Powodami takiego stanu rzeczy mogą być:

    • istnienie wielu ścieżek w sieci (zarówno w warstwie drugiej jak i trzeciej) i stosowanie load-balancingu per packet
    • manipulacje na pakietach związane z QoS (przede wszystkim gdy pakiety przechodzą dwiema ścieżkami, z czego jedna z nich jest optymalizowana)
    • problemy z routingiem powodujące tymczasową niedostępność niektórych tras

    Rozwiązaniem problemu mogą być:

    • wybieranie ścieżki przepływu danych per-destination (per-session) – czyli coś co oferuje CEF
    • mechanizm składania segmentów wykorzystywany w TCP
    • zezwolenie na procesowanie nieposkładanej mieszanki pakietów na urządzeniach pośredniczących takich jak IPS czy firewalle (urządzenia te mogą domyślnie odrzucać pakiety przychodzące w niewłaściwej kolejności)

    Opisane powyżej problemy nie należą do często pojawiających się – warto jednak mieć świadomość ich istnienia. Nigdy nie wiadomo kiedy taka wiedza się przyda w troubleshootingu… 🙂

    A Ty, spotkałeś się kiedyś z którąś z przedstawionych sytuacji?

    🗳 Jak przydatna była ta publikacja?

    Średnia ocena 5 / 5. Ilość głosów: 8

    Brak ocen. Bądź pierwszy!

    Dziękujemy za ocenę! Zapraszamy Cię do obserwowania NSS w mediach społecznościowych!

    Przykro nam, że ta publikacja okazała się być dla Ciebie nieprzydatna!

    Uwaga: Twój głos będzie liczony tylko jeśli udzielisz feedbacku używając formularza poniżej.

    Jak możemy poprawić tę publikację?

    Damian Michalak
    Network Consultant, Twórca Na Styku Sieci

    4 KOMENTARZE

    guest
    4 - Ilość komentarzy
    Sortuj wg najstarszych
    Sortuj wg najnowszych Sortuj wg najlepszych
    Inline Feedbacks
    View all comments
    PJ

    Wiele lat temu unicast flooding spowodowany przez ruch unicast udp PVR/VOD robił nam w sieci sporo problemów. Rozwiązaniem okazało się skorelowanie arp timeout w L3 z fdb-aging time w L2, tak, by arp timeout był minimalnie krótszy niż fdb-aging, dzięki czemu tablice fdb dla aktywnych urządzeń nie wygasały

    M

    Mam małą prośbę aby zamiast słowa utylizacja używać słowo np. wykorzystanie.

    Przygotowujesz się do certyfikacji CCNA?

    Zapisz się na nasz NSSletter, a co tydzień we wtorek rano otrzymasz porcję sieciowej wiedzy oraz porady dotyczące certyfikacji.

    Uzupełniając powyższe pole wyrażasz zgodę na otrzymywanie od GetGoodNet Damian Michalak z siedzibą we Wrocławiu newslettera zawierającego treści edukacyjne. Zgodę możesz wycofać w każdym czasie.

    NSS na Social Media

    1,611FaniLubię
    72ObserwującyObserwuj
    133ObserwującyObserwuj
    1,220SubskrybującySubskrybuj

    Najnowsze artykuły

    spot_img

    Może Cię też zainteresować...

    4
    0
    Co sądzisz na temat tej publikacji? Zostaw proszę komentarzx
    ()
    x