Cisco Catalyst 6500: 10GE w akcji
-
- NetWorld,
- 01.04.2004
Egzekwowanie QoS
Cisco Catalyst prześcignął poprzednio testowane produkty na polu obsługi QoS. W tym teście ustalono trzy klasy ruchu i wymagano od przełącznika dostarczenia ruchu o wysokim priorytecie bez strat, nawet w sytuacji dużego obciążenia.
Wymagano także, aby przełącznik nie pozwalał na wykorzystanie przez ruch o niskim priorytecie pasma szerszego niż 2 Gb/s. Ponadto, aby uczynić test bardziej interesującym, zasymulowano 252 hosty na każdym z 20 portów brzegowych - w ten sposób powstało razem 5040 wirtualnych hostów.
Poprzedni test pokazał, że inni producenci chronili ruch o wysokim priorytecie, ale nie umożliwiali kontroli pasma dla ruchu o niskim priorytecie. Cisco wdrożyło do swojego produktu obie funkcjonalności - Catalyst 6500 nie tylko dostarczał cały ruch o wysokim priorytecie bez strat, ale również zapewnił skuteczność na poziomie 99,99% przy ograniczaniu pasma dla ruchu o niskim priorytecie.
Awaria? Jaka awaria?
W testach failover OSPF przełącznik Catalyst przekierowywał ruch w średnim czasie 195 milisekund. To trochę lepiej niż w przypadku Foundry, który uzyskał w tym teście czas 237 milisekund. W agregacji połączeń Catalyst zredukował ten czas do zaledwie 45 milisekund.
Dlatego też uruchomiono test z 2 mln strumieni i odnotowano, że w przypadku OSPF tryb failover zajmował przełącznikowi Catalyst 86 milisekund, a przy agregacji połączeń tylko 18 milisekund. Potwierdza to zdanie Cisco, że urządzenie może obsłużyć tryb failover przy ogromnej liczbie strumieni. Przyszłe testy sprawdzą, na co stać w tej dziedzinie innych producentów.
Tak jak w poprzednim teście (NetWorld 4/2003), w którym poproszono producentów o udostępnienie dwóch chassis z maksymalnie czterema interfejsami 10GE i 24 interfejsami GE, i tym razem badano wydajność urządzenia pod kątem przepustowości, opóźnienia i parametru jitter w prostej konfiguracji 10 Gigabit Ethernet, Gigabit Ethernet przez sieć 10 GE oraz w 10-gigabitowym szkielecie. Były również sprawdzane czasy trybu failover i działanie funkcji zapewniania jakości (QoS). Tym razem dodatkowo przeprowadzono rozszerzone testy funkcji failover i obsługi IPv6 (rutingu i forwarding).
Podstawowym narzędziem testowym był system analizy wydajności SmartBits firmy Spirent Communications, wyposażony w karty XLW-3720A TeraMetrics 10GE i LAN-3311 TeraMetrics GE. Do generowania ruchu wykorzystano aplikacje firmy Spirent: SAI, SmartFlow i TeraRouting.
W próbach 10 GE oraz szkieletu ruch testowy składał się z ramek 64-, 256- oraz 1518-bajtowych w przypadku protokołu IPv4. Minimalny rozmiar ramek w przypadku IPv6 był ograniczony możliwościami sprzętu testowego. Czas trwania wszystkich prób wyniósł 60 s, a rozdzielczość czasowa narzędzi SmartBits to plus minus 100 nanosekund.
W testach 10GE poproszono producenta o przypisanie różnych podsieci IP każdemu z czterech interfejsów w chassis. Skonfigurowano narzędzia SmartBits, aby generowały ruch z 510 wirtualnych hostów na interfejs i w układzie "każdy z każdym" (full mesh - ruch był dostarczany do wszystkich pozostałych interfejsów). Zmierzono przepustowość, średnie opóźnienie przy 10-proc. obciążeniu i jitter.
W testach szkieletu poproszono producenta o zestawienie dwóch chassis, każdego wyposażonego w interfejs 10GE i 10 brzegowych interfejsów Gigabit Ethernet. Producent miał też przypisać różne podsieci IP każdemu interfejsowi brzegowemu. Następnie skonfigurowano narzędzia SmartBits do przesyłania ruchu od 510 wirtualnych hostów na interfejs. Tym razem ruch z jednego chassis był dostarczany na wszystkie interfejsy drugiego chassis i vice versa (partially meshed multiple-device pattern - RFC 2889). Wykonano analogiczne pomiary jak w poprzednim teście.
W testach trybu failover zestawiono dwa chassis, każde wyposażone w jeden interfejs GE i dwa 10GE. Producent skonfigurował metryki OSPF do tego interfejsu 10GE, który miał działać jako główny, i drugiego pracującego jako zapasowy.
Wygenerowano pojedynczy strumień 64-bajtowych ramek do interfejsu GE z częstotliwością 100 tys. ramek/s - co oznacza, że jedna ramka była transmitowana co 10 mikrosekund. Po 10 s od rozpoczęcia testu fizycznie odłączono główne łącze, wymuszając na przełączniku przekierowanie ruchu na ścieżkę zapasową. Czas failover określono na podstawie utraty ramek. Następnie powtórzono ten sam test z 2 mln strumieni.
W testach zapewniania jakości QoS zestawiono dwa chassis, każde wyposażone w 12 interfejsów GE i jeden interfejs szkieletowy - 10GE. Wygenerowano 128-bitowe ramki z przepustowością linii na 24 interfejsach brzegowych (partially meshed), toteż stosunek obciążenia przełączników wyniósł 12 do 10. W tym teście generowano ramki o trzech klasach ważności w stosunku 1 do 7 do 4 (1 ramka o wysokim priorytecie na 7 ramek o średnim na 4 ramki o niskim).
Poproszono producenta o spełnienie czterech warunków. Po pierwsze, o oznaczenie nadchodzących ramek z wykorzystaniem specyficznych kodów Differentiated Services, co zweryfikowano przez przechwycenie i zdekodowanie ruchu. Po drugie, z trzech klas ruchu przełączniki powinny dostarczyć cały ruch o wysokim priorytecie bez straty. Po trzecie, przełączniki powinny ograniczać szybkość ruchu o niskim priorytecie, tak aby nie zajmował on pasma w szkielecie szerszego niż 2 Gb/s. I ostatni warunek, przełączniki powinny przydzielić całe pozostałe pasmo ruchowi o średnim priorytecie.
Aby sprawdzić, czy dla ruchu o najwyższym priorytecie nie przydzielono odrębnego pasma, ponownie wykonano ten test tylko z ruchem o średnim i niskim priorytecie w stosunku 9 do 3. Producent nie mógł zmieniać konfiguracji urządzeń pomiędzy testami pierwszym a drugim. Założono więc, że przełączniki przydzielą pasmo wcześniej wykorzystywane przez ruch o wysokim priorytecie niższym klasom.
W testach rutingu IPv6 wykorzystano tę samą topologię co w testach szkieletu. Korzystając z oprogramowania TeraRouting, utworzono 100 tys. sieci używających OSPFv3 i sprawdzono, czy system właściwie je obsługuje. Następnie TeraRouting wygenerował ruch w szkielecie od 250 wirtualnych hostów w każdej sieci do każdej innej sieci.
