Przypadkiem trafiłem na plugin F5 do Wiresharka.
This package contains the source for a Wireshark 0.99.7 plugin to decode additional data encoded in a tcpdump capture from an F5 device.
http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/F5WiresharkPlugin.html
Niestety pod Windowsem trzeba się trochę pomęczyć, żeby to zainstalować.
Filtrowanie prefixów w BGP bywa uciążliwe. Szczególnie w przypadku, gdy nie chcemy otrzymywać całej tablicy od naszego ISP i filtrować ją u siebie na wejściu, a jedynie otrzymywać prefixy które nas interesują. Trzeba wówczas dogadywać się z naszym ISP i prosić go o aktualizację filtrów po jego stronie. Po kilku takich prośbach możemy zostać zakwalifikowani przez naszego dostawcę do kategorii meczybuła;). Dlatego idealnym rozwiązaniem w takim przypadku jest użycie ORFów. Wystarczy, że na routerze ISP zostanie wprowadzone:
(config-router)# neighbor NASZE_IP capability orf prefix-list recive
A my po swojej stronie dodamy do konfiguracji:
(config-router)# neighbor IP_ISP capability orf prefix-list send
(config-router)# neighbor IP_ISP prefix-list DENY_PREFIXES inPowiedzmy, że nie chcemy otrzymywać prefixu 1.1.1.0/24 i 2.1.1.0/24. Natomiast interesują nas wszystkie pozostałe.
(config)# ip prefix-list DENY_PREFIXES seq 5 deny 1.1.1.0/24
(config)# ip prefix-list DENY_PREFIXES seq 10 deny 2.1.1.0/24
(config)# ip prefix-list DENY_PREFIXES seq 15 permit 0.0.0.0/0 le 32Trzeba tylko pamietać, że w trakcie konfiguracji ORF rezwie się sesja BGP z naszym ISP, ale od tego momentu wszystkie zmiany w filtrowanych prefiksach możemy robić już po stronie ISP. Daje to dużo większą elastyczność i wygodę w filtrowaniu tras.
Jeżeli chcemy zmodyfikować prefix-listy to po jej modyfikacji trzeba wykonać:
# clear ip bgp neighbor in [prefix-list]
Przy wykonywaniu tego polecenia dla ORFów trzeba podać właśnie taką składnie z in i prefix-list NAZWA
Ciekawe zestawienie największych graczy na rynku loadbalancerów.
Od paru(nastu) dni krąży po sieci exploit pozwalający na położenie Apache’a oraz Squid’a. Idea działania exploitu jest taka, że skrypcik perlowy nawiązuje normalne połączenie TCP a następnie wysyła kolejno częściowe request’y HTTP. Każde z takich częściowych wywołań rezerwuje zasoby serwera do wykonania odpowiedzi i czeka na resztę wywołania, które nie przychodzi. Skutki są łatwe do przewidzenia.
Jest kilka metod zabezpieczenia się przed tym atakiem. Okazuje się, że nie tylko F5tkowy ASM, ale również LTM z ustawionym profilem http dla danego VServera potrafi ochronić farmę Apache/Squid przed atakiem Slowloris’em. Po raz kolejny potwierdza się, że F5 LTM rządzi:).
UPDATE: https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10260.html
Jestem na konferencji Velocity 2009. Całkiem ciekawa impreza poświęcona wydajności sajtów i ich architekturze. Na miejscu można posłuchać prelekcji takich ludzi jak Jeremy Zawodny (znany spec od MySQLa), Steve Souders (pracujący dla Google’a, autor m.in. wtyczki YSlow oraz książki “High Performance Web Sites”) czy Matt Mullenweg (założyciel projektu WordPress). Do tego ludzie z czołowych firm IT: Facebook, Google, Twitter, Youtube, Yahoo, MySpace, Wikia, AOL czy Mozilla. Oczywiście jak to bywa przy takich imprezach nie może zabraknąć też nudziarzy czy ludzi opowiadających o rzeczach, o których już dawno się wie. Jednak po obejrzeniu większości prezentacji uważam, że warto było się tutaj pojawić i dostać parę newsów i rozwiązań z pierwszej ręki. Czasami dobrze jest sięgnąć do źródeł i posłuchać o rozwiązaniach z samego serca Silicon Valley tak by nie wynajdywać na nowo koła budując własny portal:). Polecam Velocity dla wszystkich zainteresowanych tematyką wydajności stron www.
Jako ciekawostkę wrzucam link do dokumentu opisującego instalację BIG-IP v4.5.10 na Bladzie IBMa HS20. Tak, żeby było wiadomo, że da się;).
Musiałem przeczyścić bazę ze SPAMerskich komentarzy, możliwe że przy okazji poleciały też komentarze od czytających mojego bloga. Jeżeli ktoś czuje sie pokrzywdzony to proszę o ponowny komentarz;).
Przy okazji czyszczenia bazy ze spamu, trafiłem na perełkę. Waldemar Duszyk podał link do swojej stronki domowej, gdzie można poczytać o AIXie. Idealna stronka dla osób startujących z AIXem – http://www.wmduszyk.com.
Cisco Unified Computing System czyli Blade’y według Cisco:). Już od kilku miesięcy pojawiały się informacje o tym, że Cisco chce wejść na rynek serwerów Blade. W końcu 16 marca miała miejsce oficjalna prezentacja. Widać po niej, że duży nacisk będzie kładziony na Fiber Channel over Ethernet. W obrębie Blade’ów Cisco, SAN jest realizowany wyłącznie przy pomocy FCoE. Oczywiście chassis Blade’owe można podłączyć do istniejącego Fabrica w tradycyjny sposób, ale dostarczenie zasobów z SANa do Blade’ów na samej końcówce dzieje się po FCoE i nie ma innej możliwości. Oczywiście, aby było to możliwe Ethernet w Blade’ach musi być 10Gb i tak też jest. Jak wygląda chassis Blade’owe w wykonaniu Cisco?
Zestaw składa się z przełącznika Cisco UCS 6100 Series Fabric Interconnects, który jeżeli się nie mylę tak naprawdę jest przerobionym Nexusem 5000. Obudowy Cisco UCS 5100 Series Blade Server w której zmieści się do ośmiu “małych” serwerów Blade lub czterech “podwójnych” Blade’ów (podobne rozwiązanie do HP BL480) i do dwóch przełączników Cisco UCS 2100 Series Fabric Extender oraz z urządzeń UCS Network Adapters. Serwery będą wyposażone w najnowszy modele procesorów Intela – Xeon Nehalem. Zarówno SAN, Ethernet jak i Management jest zamknięty w jednym pudle (UCS 6100) i przy jego pomocy obsługiwany. Czyli nie mam osobnego switcha FC, switcha ethernetowego i osobnego modułu zarządzającego per chassis. Są dwa (dla redundancji) UCS 6100 i z ich poziomu obsługujemy całość. Cisco poszło nawet dalej z tym pomysłem i dzięki dwóm UCS 6100 jesteśmy w stanie zarządzać do 40 chassis! Myślę, że może to być szczególnie przydatne dla środowisk z duża ilością Blade’ów. Sporo wygody, łatwiejsze zarządzanie i szybsza instalacja nowego chassis. Brakuje nam mocy w naszym środowisku? Dokładamy nową pułkę Blade’ową i podpinamy jej Fabric Extendery do naszych dwóch UCS 6100 i gotowe.
Z ciekawych informacji Blade’y te będą miały do 48 slotów na RAM. Do każdego slotu będzie można wsadzić kość 8GB co da 384GB RAMu per Blade! Dzięki dużej ilości RAMu i wbudowanej nowej technologii VN-Link, Blade’y Cisco mogą się okazać idealną platformą sprzętową pod wirtualizację, a zwłaszcza pod VMware’a, którego Cisco jest po części właścicielem. Ponadto Blade’y Cisco mają mieć jeszcze kilka innych ciekawych ficzerów, których nie ma konkurencja, ale ponieważ nie znam do końca szczegółów nie chce o nich pisać.
Całość moim zdaniem wygląda ciekawie. Pomysł nieco inny niż u największych konkurentów czyli HP i IBMa. Jeżeli nie spartolą wykonania mogą zamieszać na rynku serwerów Blade. Niestety na tą chwilę nie zostały podane żadne daty dostępności tego sprzętu, ceny czy dokładniejsze szczegóły techniczne. Pozostaje cierpliwie czekać i obserwować.
Cisco Unified Computing System
UPDATE: Pojawiła się już książka o Unified Computing System.
Ostatnio pisałem o kernelu 2.6.27. Okazuje się, że od paru dni krąży exploit pozwalający na lokalny atak denial of service na wersje starsze niż 2.6.27.5 .
The __scm_destroy function in net/core/scm.c in the Linux kernel 2.6.27.4, 2.6.26, and earlier makes indirect recursive calls to itself through calls to the fput function, which allows local users to cause a denial of service (panic) via vectors related to sending an SCM_RIGHTS message through a UNIX domain socket and closing file descriptors.
Miesiąc temu wydano kernel 2.6.27, m.in. usprawniono w nim obsługę page cache’u dla systemów wieloprocesorowych. Ciekawe jak bardzo nowa funkcja get_user_pages_fast() potrafi poprawić wydajność systemu, może ktoś już to testował?
The page cache is the place where the kernel keeps in RAM a copy of a file to improve performance by avoiding disk I/O when the data that needs to be read is already on RAM. Each “mapping”, which is the data structure that keeps track of the correspondence between a file and the page cache, is SMP-safe thanks to its own lock. So when different processes in different CPUs access different files, there’s no lock contention, but if they access the same file (shared libraries or shared data files for example), they can hit some contention on that lock. In 2.6.27, thanks to some rules on how the page cache can be used and the usage of RCU, the page cache will be able to do lookups (ie., “read” the page cache) without needing to take the mapping lock, and hence improving scalability. But it will only be noticeable on systems with lots of cpus (page fault speedup of 250x on a 64 way system have been measured).
In 2.6.27, a new get_user_pages_fast() function has been introduced, which does the same work that get_user_pages() does, but its simplified to speed up the most common workloads that exercise those paths within the same address space. This new function can avoid taking the mmap_sem semaphore and the page table locks in those cases. Benchmarks showed a 10% speedup running a OLTP workload with a IBM DB2 database in a quad-core system.
