Piotr Wojciechowski

Ja mam tak dość często, że zabieram się do pewnych rzeczy od tzw. "dupy strony", co bynajmniej nie powoduje, że cel nie zostaje osiągnięty - ot ścieżka jest nieco nietypowa. I tak poważne już przygotowania do writtena 350-001 zacząłem.... od odpalenia laba Ponieważ teoria idzie w parze z praktyką to przypominam sobie zanikłe przez nieużywanie fragmenty wiedzy przez co czytanie mojego stosiku książek jest nieco przyjemniejsze.
No ale nie o tym miało być. Odgrzebując workbooki InternetworkExpert natknąłem się na info o wydaniu dwóch nowych workbooków po 10 labów każdy dedykowanych pod dynamipsa. Bardzo przyjemna rzecz. Z jednej strony zawsze to 20 scenariuszy więcej do przećwiczenia, z drugiej nie będzie już problemów, że coś nie da się na dynamipsie zasymulować. Karty NM-16ESW są dość mocno ograniczone w swojej funkcjonalności, przez co człowiek staje przed dylematem czy czegoś nie wie, nie pamięta czy może nie da się zaimplementować. Plus może był taki, że trzeba było wymyśleć obejście, by dalsze części laba poprawnie działały. Z workbookami dedykowanymi pod dynamipsa tego problemu nie będzie.

Cisco has recently released many some new versions of firmware for WLC (latest with major number 5.x) and its supporting software WCS (also 5.x). Good that they are patching and implementing new features in their software but fast developing process causes some incompatibility problems. Here are two of them you have to keep in mind.
First of all current WLC firmware version 5.0.148.0 does not support old lightweight access points - 1000 family. This is big disadvantage because many networks are still using them as they were quite cheap and they are EoS not for a long time. There is no info from Cisco if future releases of new software will still support old devices.
Second are incompatibilities between WLC firmware supported by each version of WCS. In example latest release of WCS (5.0.56.2) does not support WLC firmware 4.2.99.0 and 4.2.112.0, which are two latests from 4.2 mainline. This all causes that engineer have to be really careful deciding which version of firmware and software load on devices.

Managing networks with many levels of privileges is common thing nowadays. Also building WLAN as a extension of wired LAN is nothing unusual. Usually users are divided into groups that differs privileges and resources they can access. Easy way is to create separate VLAN for each of the group. You can extend it to wireless network by propagating each VLAN under unique SSID, but that make a lot of broadcasted (or not) SSIDs which is not nice thing, especially if we don't want to inform our users how many groups we have. Better broadcast just one, right? If you are using ACS to authenticate users your task is pretty simple if your users are already divided into groups.
Configuration is easy. First in Interface Configuration->RADIUS (Cisco Airespace) you have to enable Aire-Interface-Name option.

Then in Group Settings in particular group in section Cisco Airespace RADIUS Attributes you will find previously enabled option. Now the only thing you have to do is to set interface name you created on WLC to which user have to be assigned after successful login.

And thats all. Now you can create one WLAN on your wireless network which will be used for user authentication before they can get access to your network. Using Aironet extensions in ACS you can tell controller to switch VLAN assignment per group basis after successful login. This way our Manager will have access to its VLAN and you are broadcasting only one SSID.

It took me about half a year to become CCVP certified. From point I'm standing now I can honestly say it's the hardest of all Professional tracks. In this case people who are not working with IP Telephony shouldn't even think about starting this track - and I mean full IP Telephony because implementing gateways and small Unified Communication Manager Express (aka. CallManager Express) solutions are not enough, not to mention that UCME is not covered by exams at all.

What you need to study except books is IP telephony lab. I had CallManager 6.0, 3 routers with FXS, FXO, E1 and ISDN cards, 1 switch, 4 different IP phones, 2 webcams, 2 laptops with software IP Phone and 2 analog telephones, one connected to SIP gateway and one to FXS port. Thats pretty much what you should have to practice. Of course you can have less phones, use more software phones or so, less routers but then you won't really practice advanced and semi-advanced functionality of Cisco Unified Communication Manager, and in new track there are two exams covering that product, not one like it was previously. With this lab you can practice almost everything except clustering.

What you also need is field practice. There are so many things that may go wrong, are not configured straight forward or just are pretty much complicated that only real experience can help you to understand all mechanisms and protocols that are working below IP Telephony. I think that so far, even in era of easy-to-find tests over internet, CCVP is still certification track which is chosen by those who really work with those technologies. Thats why there are less CCVP's in Poland that CCIE's. Dynamips won't help you here.

Jak już wspomniałem wcześniej zmienił się sposób zarządzania sygnaturami w nowych IOSach od wersji 12.4(11)T. Po pierwsze wydając polecenie ip ips signature-category lub ip ips signature-definition przechodzimy do trybu konfiguracji sygnatur. Zmiany przez nas wprowadzane nie będą aplikowane na routerze, dopóki nie wyjdziemy z trybu konfiguracyjnego i nie potwierdzimy enterem chęci ich zaaplikowania. Szkoda, że zmiany nie są wprowadzane jakimś poleceniem jak na Juniperach - jeżeli się rozpędzimy z konfiguracją bądź będziemy polegać na odruchach (takich jak używanie CTRL+Z), możemy odrzucić mozolnie wprowadzane zmiany bądź zaakceptować te, których w efekcie nie chcieliśmy wprowadzić.

Zarządzać możemy albo całymi kategoriami sygnatur albo poszczególnymi sygnaturami. O ile zmiany wprowadzone dla całych kategorii widoczne są w show running-config, co widać w moim poprzednim wpisie, o tyle zmiany w poszczególnych sygnaturach już nie. Jak dla mnie jest to wielka niedogodność - nie widać jakie zmiany zostały wprowadzone w funkcjonalności podsystemu względem oryginalnej konfiguracji. Trzeba przekopywać się przez listing show ip ips signature sprawdzając stan interesującej nas sygnatury.

Konfiguracja sygnatur odbywa się poprzez wchodzenie do odpowiedniego podsystemu danej sygnatury.

C1841(config)#ip ips signature-definition
C1841(config-sigdef)#signature 1000 0
C1841(config-sigdef-sig)#?
Category Options for configuration:
  alert-severity   Alarm Severity Rating
  engine           Engine
  exit             Exit from Category Actions Mode
  fidelity-rating  Signature Fidelity Rating
  no               Negate or set default values of a command
  status           Status

W podsystemie engine definiujemy zachowanie się IPSa gdy dana sygnatura złapie ruch zgodny z jej charakterystyką

C1841(config-sigdef-sig-engine)#event-action ?
  deny-attacker-inline    Deny Attacker
  deny-connection-inline  Deny Connection
  deny-packet-inline      Deny Packet
  produce-alert           Produce Alert
  reset-tcp-connection    Reset TCP Connection

Za pomocą status włączamy oraz wyłączamy dane sygnatury

C1841(config-sigdef-sig-status)#?
Status options for signatures:
  enabled  Enable Category Signatures
  exit     Exit from status submode
  no       Negate or set default values of a command
  retired  Retire Category Signatures

Tu warto zauważyć różnicę między enabled a retired - pierwsza wyłącza sprawdzanie danej sygnatury dla analizowanego ruchu, druga wyłącza dodatkowo jej kompilację, czyli zapobiega ładowaniu do pamięci.