CEF – Cisco Express Forwarding – przegląd technologii

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

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.

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.

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.

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?