Tomasz Wendlandt

W architekturze 6500 przy zastosowaniu DFC następuje rozproszone przetwarzanie ramek (distributed switching). W takiej kofiguracji każda karta liniowa ma własną tablice CAM. Co w praktyce oznacza, że każda karta z DFC uczy się MACów niezależnie i przechowuje je w tablicy przez określony czas (aging time). Naturalne jest wówczas, że Supervisor nie widzi ruchu dla danego MAC adresu, ponieważ ruch ten zostanie wysłany z pominięciem Supervisora (bezpośrednio przez kartę liniową), a ponieważ przez dłuższy czas Supervisor nie będzie widział ruchu do danego MACa, zostanie on usunięty z jego tablicy CAM.

Co się dzieje dalej? Ponownie przychodzi ruch dla danego MACa, ale ponieważ inne karty w chassis nie mają go w CAMie ruch ten jest wysyłany do wszystkich kart. W efekcie widzimy unicast flooding w ramach jednego vlanu. Jak można rozwiązać taki problem? Należy włączyć synchronizację tablic MAC adresów DFC z PFC Supervisora oraz opcjonalnie wydłużyć czas aging-time:

(config)#mac-address-table synchronize
(config)#mac-address-table aging-time 900

#sh mac address-table address 0014.0000.aabb all
Legend: * - primary entry
        age - seconds since last seen
        n/a - not available

  vlan   mac address     type    learn     age              ports
------+----------------+--------+-----+----------+--------------------------
Module 2[FE 1]:
   10  0014.0000.aabb   dynamic  Yes        180   Gi9/21
Module 2[FE 2]:
   10  0014.0000.aabb   dynamic  Yes        180   Gi9/21
Module 3[FE 1]:
   10  0014.0000.aabb   dynamic  Yes        145   Gi9/21
Module 3[FE 2]:
   10  0014.0000.aabb   dynamic  Yes        145   Gi9/21
Module 4[FE 1]:
   10  0014.0000.aabb   dynamic  Yes        180   Gi9/21
Module 4[FE 2]:
   10  0014.0000.aabb   dynamic  Yes        180   Gi9/21
Active Supervisor:
   10  0014.0000.aabb   dynamic  Yes         15   Gi9/21
Module 7[FE 1]:
   10  0014.0000.aabb   dynamic  Yes         20   Gi9/21
Module 7[FE 2]:
   10  0014.0000.aabb   dynamic  Yes         20   Gi9/21
Module 8[FE 1]:
   10  0014.0000.aabb   dynamic  Yes        170   Gi9/21
Module 8[FE 2]:
   10  0014.0000.aabb   dynamic  Yes        170   Gi9/21
Module 9[FE 1]:
*  10  0014.0000.aabb   dynamic  Yes         15   Gi9/21
Module 9[FE 2]:
*  10  0014.0000.aabb   dynamic  Yes        180   Gi9/21

#sh mac address-table synchronize statistics

MAC Entry Out-of-band Synchronization Feature Statistics:
---------------------------------------------------------

    Module [2]
    -----------

    Module Status:
Statistics collected from module                    :  2
Number of L2 asics in this module                   :  2

    Global Status:
Status of feature enabled on the switch             :  on
Default activity time                               :  160
Configured current activity time                    :  160

    Statistics from ASIC 0 when last activity timer expired:
Age value in seconds from age byte register         :  0x3D
Current activity interval start time for seconds    :  0x20
Current activity interval end time for seconds      :  0x40
Current inactive interval start time for seconds    :  0x0
Current inactive interval end time for seconds      :  0x20
Age value in minutes from age byte register         :  0x2F
Current activity interval start time for minutes    :  0x2C
Current activity interval end time for minutes      :  0x2F
Current inactive interval start time for minutes    :  0x29
Current inactive interval end time for minutes      :  0x2C
Age value in hours from age byte register           :  0x27
Current activity interval start time for hours      :  0x26
Current activity interval end time for hours        :  0x27
Current inactive interval start time for hours      :  0x26
Current inactive interval end time for hours        :  0x26
Age value in days from age byte register            :  0x16
Current activity interval start time for days       :  0x15
Current activity interval end time for days         :  0x16
Current inactive interval start time for days       :  0x15
Current inactive interval end time for days         :  0x15
Number of active entries read                       :  1372435
Number of entries ignored with update to age byte   :  3812323
Number of entries updated with age byte             :  1781719
Number of entries created new                       :  4194

    Statistics from ASIC 1 when last activity timer expired:
Age value in seconds from age byte register         :  0x3D
Current activity interval start time for seconds    :  0x20
Current activity interval end time for seconds      :  0x40
Current inactive interval start time for seconds    :  0x0
Current inactive interval end time for seconds      :  0x20
Age value in minutes from age byte register         :  0x2F
Current activity interval start time for minutes    :  0x2C
Current activity interval end time for minutes      :  0x2F
Current inactive interval start time for minutes    :  0x29
Current inactive interval end time for minutes      :  0x2C
Age value in hours from age byte register           :  0x27
Current activity interval start time for hours      :  0x26
Current activity interval end time for hours        :  0x27
Current inactive interval start time for hours      :  0x26
Current inactive interval end time for hours        :  0x26
Age value in days from age byte register            :  0x16
Current activity interval start time for days       :  0x15
Current activity interval end time for days         :  0x16
Current inactive interval start time for days       :  0x15
Current inactive interval end time for days         :  0x15
Number of active entries read                       :  2043307
Number of entries ignored with update to age byte   :  3928935
Number of entries updated with age byte             :  993682
Number of entries created new                       :  0

Źródło:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00807347ab.shtml

Mała rzecz, której używam od dawna i jest przydatna w codziennej pracy – plugin do FF, IE oraz Google Chrome umożliwiający szybkie przeszukiwanie strony Cisco.com, a dokładniej obszarów:

Tools

* BugID Lookup Tool
* Command Lookup Tool for IOS Commands
* Error Message Decoder Tool
* RMA/Service Order Status Tool
* TAC Service Request Query

Searches

* Search Cisco
* Search Cisco Brazil
* Search Cisco Japan
* Search Cisco Latin America
* Search Cisco Russia
* Search Forums, Blogs, and Wikis
* Search Software Downloads

http://www.cisco.com/web/tsweb/searchplugins/plugin_homepage.html#

Przydatna sprawa dla tych, którzy używają Cisco ASA i dostępu VPNowego po SSLu. Pluginy klientów dla SSH, RDP, VNC do dostępu via SSL VPN. Nie wiadomo dlaczego głęboko zakopane na stronie Cisco.

http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=/cisco/crypto/3DES/ciscosecure/asa/customer/vnc-plugin.jar
http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=/cisco/crypto/3DES/ciscosecure/asa/customer/ica-plugin.zip
http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=/cisco/crypto/3DES/ciscosecure/asa/customer/ssh-plugin.jar
http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=/cisco/crypto/3DES/ciscosecure/asa/customer/rdp-plugin.jar
http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=/cisco/crypto/3DES/ciscosecure/asa/customer/citrix_plugin_howto.doc

Cisco w końcu wypuściło IPSec’owego klienta VPN dla Windowsa w wersji 64bitowej.

Do pobrania z tego miejsca.

Krótkie wprowadzenie do stackowania switchy 3750. Na początek łączymy wszystkie switche na krzyż kablami CAB-STACK. Mamy do wyboru trzy długości: 1m, 3m i 50cm.

Sprawdzamy czy podłączone kable są widziane w IOSie:

Switch#sh switch stack-ports
  Switch #    Port 1       Port 2
  --------    ------       ------
    1           Ok           Ok
    2           Ok           Ok

I czy ring, który właśnie stworzyliśmy ma pełną prędkość czyli 32Gbps. Co oznacza, że w modelu C3750 24-portowym osiągniemy pełną prędkość jednocześnie na wszystkich portach. Jednak w C3750 48-portowym już nie. Prędkość ringu jest dzielona pomiędzy urządzenia w stacku. Ponadto każdy port ASIC ma połączenie do obu ringów.

Switch#sh switch stack-ring speed

Stack Ring Speed        : 32G
Stack Ring Configuration: Full
Stack Ring Protocol     : StackWisePlus

Powyżej widać, że protokół użyty w ringu to StackWise Plus dostępny w nowszych switchach 3750-E. Dla StackWise w wersji Plus jeżeli ramka ma src i dst na tym samym switchu wchodzącym w skład stacka to nie jest ona rozgłaszana na ringu, wówczas w ruchu bierze udział jedynie wewnętrzny fabric. Z kolei dla zwykłego StackWise, który jest dostępny na zwykłych przełącznikach 3750 każda ramka rozgłaszana jest na ringu. Ponadto dla ramek Unicast StackWise Plus używa Destination Stripping co powoduje usunięcie ramki z ringu w momencie, gdy dotrze ona do przełącznika, na którym jest odbiorca. Dzięki temu pozostaje więcej pasma na ruch między pozostałymi switchami. W zwykłym StackWise dostępny jest jedynie Source Stripping co powoduje, że ramka zawsze musi przejść przez cały ring.

W łatwy sposób możemy sprawdzić ile ramek zostało wysłanych przez ring.

Switch#sh switch stack-ring activity

Sw  Frames sent to stack ring (approximate)
------------------------------------------------
1           82425
2           53761

Total frames sent to stack ring : 136186

Note: these counts do not include frames sent to the ring
by certain output features, such as output SPAN and output
ACLs.

Można też zweryfikować który kabel stackujący jest podłączony do którego portu w sąsiednim switchu.

Switch#sh switch neighbors

  Switch #    Port 1       Port 2
  --------    ------       ------
      1         2            3
      2         3            1
      3         1            2

Trzeba pamietać, że przy dodawaniu nowego przełącznika do stacku urządzenie zrebootuje się, a jego konfiguracja zostanie nadpisana przez konfigurację obowiązującą w stacku. Można oczywiście dodać nowy przełącznik jako mastera, przez nadanie mu odpowiednio wysokiego priorytetu. Wówczas nowy master zostanie dołączony, a pozostałe switche w stacku zrebootują się z nową konfiguracją.

Switch#switch stack-member-number priority new-priority-value

I jeszcze jedna ważna sprawa. Przy budowaniu stacku warto ustawić stack-mac persistent timer na 0.

Switch#sh run | i stack
stack-mac persistent timer 0

Zapobiega to zmianie MAC adresu stacku, w przypadku pojawienia się nowego mastera, np. przez dodanie nowego switcha z wyższym prio niż obecny master lub uszkodzeniu obecnego mastera.

Na koniec przydatne linki: Creation and Management of Catalyst 3750 Switch Stacks, Cisco StackWise Technology White Paper.

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 in

Powiedzmy, ż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 32

Trzeba 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

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.

Kolejność wg. której BGP bierze pod uwagę atrybuty dla neighbor’a.

Dla outbound updates:
1. prefix-list, lub distribute-list
2. filter-list
3. route-map

Dla inbound updates:
1. route-map
2. filter-list
3. prefix-list, lub distribute-list

Źródło.

Pojawiła sie nowa wersja software’u do FWSMa, Version 4. Pełen release notes dostępny na stronie Cisco. Jedną z ciekawszych rzeczy jest:

The most obvious additions are in using the power of the supervisor to accelerate flows in hardware. There are two implementations of this:

Trusted Flow Acceleration – the FWSM programs a “cut-through” on the PFC so that trusted flows get forwarded in hardware without hitting the FWSM after the first packet. This is for a Sup720 or Sup32 in the same chassis. Targeted performance is 20 – 50+ Gbps Aggregate Throughput and 10+ Gbps Throughput per Flow, but your mileage may vary. Nothing is free, and this takes entries away from the NetFlow TCAM.

PISA Integration – a Sup32-PISA can tag packets, so that a FWSM elsewhere in the network can detect them. For example, an edge PISA can do deep packet inspection of the data and determine that it is safe based on the application layer; the packet is then tagged so that when it arrives at the Datacentre the FWSM does not inspect it again.

Note that both features rely on new versions of supervisor code that are currently expected in an Autumn release.

Bardzo przydatnym featurem dostępnym w Catalystach 3560/3750, 4500, i 6500 jest TDR dostępny na portach miedzianych 10/100/1000. Oczywiście nie dotyczy to portów 10/100 i SFP. Mało jednak osób wie, że zwykłe Cat2960 również posiadają tą funkcjonalność. Dzięki TDR można sprawdzić, czy kabel miedziany wpięty do portu switcha nie jest uszkodzony. Łatwo wykonać zdalny troubleshooting bez odchodzenia od biurka.

sw#test cable-diagnostics tdr interface gi0/48 
TDR test started on interface Gi0/48
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.

a następnie

sw#show cable-diagnostics tdr interface gi0/48
TDR test last run on: March 01 02:09:30

Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/48    auto  Pair A     0    +/- 2  meters Pair A      Open                
                    Pair B     N/A                Pair B      Normal              
                    Pair C     N/A                Pair C      Normal              
                    Pair D     N/A                Pair D      Normal