Więcej

    CEF – Cisco Express Forwarding – przegląd technologii

    spot_img

    Często się słyszy sformułowanie „packet switching” w kontekście przekazywania pakietów przez routery. Obecność słowa „switching” może być tu trochę myląca – w zasadzie chodzi o proces przenoszenia pakietu z interfejsu wejściowego na wyjściowy i to zarówno w routerach jak i przełącznikach. Pierwsze implementacje tego procesu nie należały do najefektywniejszych i to stało się motywem dla stworzenia CEF – Cisco Express Forwarding.

    W tym artykule wspomnę tylko przelotem o poprzednikach tej technologii, skupię się natomiast głównie na CEF i na wyjaśnieniu w jaki sposób on działa.

    Rodzaje przełączania

    W urządzeniach Cisco mamy do czynienia z trzema typami przełączania:

    • process switching
    • fast switching (nazywany również demand-based switching lub route caching)
    • CEF (topology-based switching)

    Część z nich nie jest już wykorzystywana w nowszych urządzeniach, ale może być spotykana w starszych także warto znać je wszystkie.

    a) process switching

    W przypadku process switchingu, każdy pakiet przechodzi przez control plane i angażuje CPU. Można podejrzeć proces angażowania CPU w przeglądanie tablicy routingu – jest to proces zwany IP Input (można sprawdzić komendą show processes cpu) – a dokładniej proces 87 (show processes 87).

    Process switching
    Process switching

    b) fast switching

    Fast switching usprawnia ten proces poprzez dodanie pamięci cache w data plane. Tylko pierwszy pakiet z danego przepływu jest routowany przez CPU – wtedy też jest generowana właściwa informacja w cache. Każdy następny pakiet z tego przepływu nie opuszcza już data plane – jest routowany na podstawie informacji w cache. Nadal jednak ruch SNMP, Telnet, SSH czy też debugowanie muszą być procesowane przez CPU.

    Fast switching
    Fast switching

    Architektura CEF

    W przypadku CEF mamy do czynienia z dodatkowymi strukturami w data plane: FIB oraz Adjacency table. FIB jest uproszczoną kopią RIB (Routing Information Base, czyli tablica routingu). Można również powiedzieć, że jest to tzw. shadow copy, co dość dobrze oddaje charakter FIB – jest to wszakże uproszczona wersja RIB, nie zawierająca informacji dotyczących protokołów routingu. Adjacency Table jest z kolei wypełniane z użyciem tabel warstwy drugiej, takich jak ARP Table czy Frame-Relay Mapping Table. W przypadku routerów MPLS, które używają etykiet (labels) mówimy odpowiednio o LIB (odpowiednik RIB) oraz LFIB (odpowiednik FIB). Na przełącznikach wielowarstwowych CEF jest domyślnie włączony i działa w tle. CEF ponadto jest odpowiedzialny za wypełnianie pamięci TCAM.

    CEF switching
    CEF switching

    Przypadki, w których CEF nie procesuje pakietów:

    • pakiety, w których następuje manipulacja opcjami w nagłówku IP
    • wygasający TTL
    • pakiety, które powinny zostać wysłane przez interfejs tunelowy
    • pakiety przekraczające MTU (muszą podlegać fragmentacji)
    • pakiety które muszą być przekierowane za pomocą IGMP
    • CDP
    • pakiety wymagające szyfrowania
    • ruch związany z protokołami routingu
    • zapytania ARP
    • generalnie pakiety wymagające zaangażowania CPU routera

    Komendy związane z działaniem CEF (mogą się różnić w zależności od platformy):

    • aby włączyć CEF globalnie:
    (config)#ip cef
    • aby włączyć CEF na interfejsie: (config-if)#ip route-cache cef
    (config-if)#ip route-cache cef
    • aby sprawdzić czy CEF jest włączony na interfejsie: 
    show ip interface gi0/0 | include CEF

    FIB

    Komendy związane z FIB:

    • show ip cef summary – zawiera informację o ilości prefiksów w FIB
    • show ip cef – wyświetla FIB
    • Aby obejrzeć szczegółowy wpis w FIB dla konkretnego hosta – show ip cef 8.8.8.8 255.255.255.255 internal

    Wartości które możemy spotkać w kolumnie „Next Hop”:

    • attached – wskazuje na sieć która jest podłączona bezpośrednio do urządzenia i interfejs wyjściowy – ruch ten zostanie przekazany do dalszego procesowania w adjacency table
    • receive – przekazanie do CPU w celu dalszego procesowania, w tym przypadku prefixami mogą być przykładowo adres IP na interfejsie routera, adres sieciowy i broadcastowy danej sieci
    • no route – nie ma informacji o trasie, np przy 0.0.0.0/0 w przypadku braku trasy domyślnej
    • drop – prefixy dla których ruch ma być odrzucany
    • adres IP – podany adres jest next hop IP a wpis dotyczy sieci zdalnej

    Adjacency Table

    Komendy związane z Adjacency Table:

    • show adjacency summary – zawiera informację o ilości zbieżności w tabeli
    • show adjacency gi0/0 – pokazuje zbieżności na wskazanym interfejsie – lista IP w odległości jednego skoku na danym interfejsie
    • show adjacency detail – wyświetla szczegóły zbieżności dotyczącej konkretnego adresu IP. W rezultacie tej komendy można znaleźć kompletną informację potrzebną do skonstruowania nagłówka L2, przykładowo:
      000EA6A8CAD6ACF2E5F8E5F00800
      MAC docelowy MAC źródłowy typ protokołu L3 (0800=IP)

    W Adjacency Table znajdziemy różne specjalne rodzaje zbieżności:

    • null – czyli bit bucket, odrzucanie pakietów
    • glean – używany gdy FIB posiada wpis dla danej sieci a nie dla konkretnego hosta – w takiej sytuacji prefix sieciowy w FIB wskazuje na glean adjacency (rodzaj kolektora dla bardziej szczegółowych wpisów dotyczących poszczególnych hostów) – musi zostać zaangażowany CPU – np. zrobiony ARP dla danego adresu docelowego w celu wygenerowania pełnej zbieżności dla hosta
    • punt – pakiety, które nie mogą być procesowane przez CEF trafiają w punt adjacency i są wysyłane do procesu routingu (czyli wpisy receive w FIB wskazują na punt adjacency)
    • discard – odrzucanie pakietów związanych np z procesowaniem ACL (musi zostać wygenerowany log)
    • drop – odrzucanie pakietów do nieznanych adresów docelowych (bez generowania loga)

    Koncepcja polaryzacji

    Mając kilka różnych ścieżek o tym samym koszcie (Equal-Cost Multi-Path (ECMP), CEF może obrać tylko jedną z nich, pozostawiając pozostałe nieużyte (w przypadku loadbalancingu per-destination). Jest to tzw. problem polaryzacji.

    Koncepcja polaryzacji
    Koncepcja polaryzacji

    W przypadku loadbalancingu per-packet ten problem nie występuje, jednakże dobrą praktyką jest używanie loadbalncingu per-destination. W celu uniknięcia problemu polaryzacji, należy manipulować tzw. loadbalancing hash, czyli funkcją odpowiedzialną za wybór ścieżek dla poszczególnych sesji.

    Loadbalancing hash

    W przypadku loadbalancingu per-destination, w starszych wersjach IOS domyślnie używana jest formuła hashowania z dwoma składowymi – source i destination IP – co oznacza, że wszystkie konwersacje pomiędzy tymi dwoma IP pójdą tą samą ścieżką. Można poinstruować CEF żeby wykorzystywał również informacje z L4 – porty, uzyskując w ten sposób loadbalancing po różnych ścieżkach dla różnych konwersacji między tymi samymi hostami. W tem celu można użyć nastepujące komendy:

    • mls ip cef load-sharing full – używanie L3 + L4 do hashowania po wielu zbieżnościach
    • mls ip cef load-sharing full simple – nadal L3 + L4, ale ograniczamy ilość zbieżności które będą wykorzystywane przez loadbalancing
    • mls ip cef load-sharing simple – używaj tylko L3 do hashowania (domyślnie)
    • w powyższych komendach dostępna jest również opcja exclude – służy do wyłączenia konkretnego IP lub portu z funkcji hashowania

    W nowszych wersjach IOS można również dodać do kalkulacji hasha uniwersalną wartość generowaną niezależnie przez każdy router. Spowoduje to że poszczególne konwersacje będą obierać różne ścieżki. Komenda:

    • ip cef load-sharing algorithm universal – można podać ID żeby nadać statycznie wartość. Bez podania jej konkretnie, IOS wylosuje wartość (i robi to zawsze podczas bootowania)

    Uniwersalny algorytm jest domyślną metodą hashowania w nowszych wersjach IOS i skutecznie powoduje wykorzystanie wszystkich ścieżek o równym koszcie dla poszczególnych sesji.

    A co Ty uważasz o stosowaniu CEF?

    🗳 Jak przydatna była ta publikacja?

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

    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

    10 KOMENTARZE

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

    \”Obecność słowa „switching” może być tu trochę myląca\” – z tym się nie zgodzę. Słowo switching nie było związane z tym że było to wykonywane przez \”switche\” a z przełączaniem pakietów poprzez switch fabric albo crossbar matrix, trochę taki MUX/DEMUX. I to zawsze było przenoszenie/przełączenie z intf. wej. na wyj. trzeba tylko podjąć decyzje z którego na który i zrobić to w miarę szybko ;).

    Mateusz Ruszkowski

    CEF to kluczowy mechanizm na Cisco. Na niektórych platformach nawet nie można go już wyłączyć. Jest bardzo ważny przy implementowaniu MPLS – zapewnia labeling w data plane.

    Paweł Zaręba

    Podoba mi się. Ja bym dodał taki szczegół, że przy fast – switchingu dane w pamięci cache są przechowywane max 60 sekund oraz to iż ten mechanizm działa na podstawie adresu przeznaczenia – to znaczy router sprawdza czy pakiet z takim samym miejscem przeznaczenia istnieje już w pamięci – jeśli go nie ma to cały proces przetwarzania wykonuje się \’normalnie\’ bez użycia pamięci cache (wolniej). Pozdro.

    Piotrek

    CEF ma również bardzo duży wpływ na działanie routingu – i powstawanie pętli podczas używania static routingu kierując next hop per interface zamiast per IP address:
    https://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/26083-trouble-cef.html

    Pawel

    super, chyba najasniejsze wyjasnienie w calym wszechswiecie 😉 Moglibyscie zrobic artykul o swiatlowodach (typy sfp, SMF, MMF, kompatybilnosc itp.)

    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ć...

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