CCNP este certificarea de nivel avansat de la Cisco pe ramura de Routing and Switching. Este, de obicei, văzută ca o continuare pentru CCNA și un pas intermediar pentru CCIE, deoarece, majoritatea se orientează spre R&S.

În prezent, cerificarea de CCNP se obține după trecerea a 4 examene: BSCI, BCMSN, ISCW și ONT. BSCI este examenul de routare (o continuare pentru CCNA2) iar BCMSN cel de switching (continuare la CCNA3). ISCW are multe elemente de securitate, fiind mai plăcut pentru cei ce vor să își dea CCSP-ul, pe când ONT este orientat spre QoS, cu elemente de VoIP și mai plăcut pentru cei ce se orientează spre CCVP.

Anul acesta, Cisco a decis schimbarea structurii certificării de CCNP. Din 4 examene, se ajunge la 3 examene: ROUTE, SWITCH și TSHOOT. ROUTE și SWITCH sunt, în mare parte, BSCI, respectiv BCMSN. ROUTE tratează subiecte ca OSPF, EIGRP, BGP și IPv6 și SWITCH tratează VLANs, STP, Securitate Layer 2. THSOOT este examenul nou introdus, ce acoperă depanarea problemelor legate de EIGRP, OSPF, BGP, VLANs, VoIP,  ACLs.

Cum examenul de CCNA l-am luat atunci când se trecea de la examenul 640-801 la 640-802, așa și CCNP-ul l-am prins pe final, cu cele 4 examene.

Sala de expoziție a fost foarte plină de dimineață.

Prima vizită a fost la Cronus, unde și anul acesta au avut un quiz pentru premii. Din păcate nu au mai avut aplicația pe un IP Phone ci pe un ecran cu touch. I shall return…

Am mers după la Logicom, unde la Cisco Expo 2008 am avut o dicuție interesantă legată de soluții de Voice. Anul acesta mi-au prezentat o soluție Cisco Small Business, care, am aflat, sunt, de fapt, produsele de la Linksys rebrand-uite sub numele Cisco. Aparent Cisco încearcă să elimine complet brandul Linksys, numele rămânând doar pe produsele low end (cum ar fi routerele wireless WRT), nu și în lumea SOHO.

Cea mai interesantă discuție a fost la IBM, unde am vorbit cu cineva de la tehnic. Mi-a prezentat o soluție de optimizare WAN. Produsul este un Cisco WAE (WAN Application Engine) 600. Soluția este gândită de a avea un punct central la HQ și mai mulți clienți în branch offices. Echipamentele sunt puse în serie cu routerele de WAN și comunică între ele pentru a marca traficul ce poate fi fie compresat, fie cache-uit. Optimizările se văd atunci când există în puncte servere web, de fișiere, sau de video/audio streaming.

Ultima oprire înainte de prezentări a fost la EMC2, care, am aflat, este firma ce deține VMWare. Soluția lor integrează Cisco cu VMWare (produse cunoscute ca ESX sau vSphere) și cu produse ale lor. La prezentarea lor au prezentat exact ce produse integrează (printre care Avamar și Ionix).

După un an pauză, Cisco Expo revine în România [1]. Oficial, și anul trecut, în 2009, s-a ținut, dar la distanță, prin Telepresence. Deși au mărit prețul de intrare (150€), au restrâns evenimentul la o singură zi, și anume 17 Martie. Anul acesta, locul de desfășurare este JT Marriott.

21 de participanți anul acesta, printe care un partener Platinum (Romtelecom) și  3 parteneri Gold (Cronus, Frontal și Datanet). Dintre ceilalti parteneri, unii au fost si în alți ani, alții sunt noi intrați în rândul partenerilor.

Ziua de azi, 16 martie, a însemnat ziua pregătirior, adică multă muncă de cărat, mutat, instalat. Firmele au venit cu foarte multe echipamente pentru a-și promova solutiile. Standurile au fost pregătite pentru ziua de expoziție. În paralel, în sălile de prezentare, se vor ține prezentările tehnice.

[1] http://www.cisco.com/web/RO/ciscoexpo/2010/index.html

O retrospectivă destul se subiectivă legată de activitățile desfășurate în cadrul grupului nostru din facultate. Part I.

Instructorii din grupul nostru au avut un an plin și în cadrul Academiei locale (ccna.ro) și, mai ales în cadrul CATC România.

Academia Cisco UPB

Academia a avut parte de o reîmprospătare în mai multe sensuri. Are un site nou [1], rezultatul unui proiect ce s-a desfășurat în vară, la ROSEdu Summer of Code, proiect în care echipa de dezvolare a luat platforma open source Moodle și a transformat-o într-un site pe de-o parte business și pe de alta util pentru desfășurarea cursurilor Cisco și Linux.

Printre proiectele interne de reorganizare s-a numărat și refacerea topologiilor de routere și switch-uri din cele două săli ale Academiei. Echipamentele vechi au fost aruncate, s-au adus unele noi și s-a refăcut cablarea. Muncă a fost destulă, dar efortul a meritat. De asemenea, s-a investit ceva timp și în reinstalarea software-ului pe stațiile din laboratoare (upgrade la Windows7 și Ubuntu 9.10).

Dar, probabil, cea mai importantă împrospătare, vine din faptul că au venit un număr foarte mare de echipamente noi pentru un laborator de CCIE. Academia va avea primul laborator din țară dotat specific pentru pregătirea pentru examenul practic de CCIE. Au fost multe zile investite de întreaga echipă pentru achiziționarea (hârțogăraie) mutarea și montarea echipamentelor și lucrurul încă nu este gata… dar anul viitor rack-urile vor fi funcționale.

Alt proiect ce merită menționat este o inițiativă din partea unui instructor, ce constă într-un un site/blog cu articole pentru cei cu adevărat pasionați de lumea Cisco.  Site-ul ccielab.ro [2] se dorește a fi o resursă pentru cine lucrează în viața reală cu echipamente Cisco sau pentru cei ce se pregătesc pentru examenul practic de CCIE. Cry in the Lab, Laugh in the Datacenter.

La sfârșitul verii, toată echipa a fost plecată la un eveniment de Team Builing, pentru se reface înainte de a începe semestrul de toamnă.

Toamna a început cu o campanie de promovare ce a constat într-un concurs cu premii și un Lan Party organizat în holul facultății, numit Academy War Games (AWG).

Imediat după AWG a urmat ACM-ul, concursul de programare susținut de IBM, faza pe regiunea noastră a Europei, unde echipa ccna.ro s-a ocupat de infrastructură.

Per total, echipa de instructori Cisco s-a mărit și în număr dar și în calitate. Și echipa de instructori LPIC a avut un membru nou.

CATC România

Pe partea de CATC, anul 2009 a fost unul foarte important. Primele luni au fost ocupate cu proiectul la nivel internațional numit iCompetition [3]. Multe zile și, mai ales nopți, au fost petrecute pentru dezolvare de conținut pentru concurs.

Alt concurs, ceva mai mic a fost AcadNet, faza națională, organizată la noi.

Pe tema concursurilor, doi dintre instructorii noștrii au obținut locuri în top la Cisco Academy Games în Cehia.

CATC România a căpătat o importanță destul de mare pe regiune atunci când a câștigat dreptul de a fi regională de CCNA Security, cursul nou scos de la NetAcad pentru certificarea cu același nume. Asta a însemnat că academiile din țările din regiune și-au trimis instructorii la noi (virtual, prin WebEx) pentru a putea preda clase de CCNA Security.

Ca o recunoaștere a efroturilor depuse de CATC România, am primit, în octombrie, o vizită din partea lui Amy Christen, vicepreședinte Cisco, responsabilă pe programul NetAcad la nivel mondial. Amy a prezentat noua direcție ce o va lua programul Cisco Networking Academy.

În ultimele zile înainte de vacanța de iarna, am ținut un scurt training de Moodle unor instructori de la echilentul CATC din Olanda. Aceștia doresc să organizeze un concurs similar cu iCompetition la ei acasă.

ITAcad

Anul acesta a marcat nașterea unei noi echipe, echipa Academiei Microsoft [4], parțial desprinsă din cea de la Academia Cisco. Membrii acestei echipe au fost foarte ocupați dezvoltând de la zero materiale pentru cursurile Microsoft.

[1] http://ccna.ro

[2] http://ccielab.ro

[3] http://icompetition.net

[4] http://itacad.ro

Pe un switch Cisco putem configura VLAN-uri (Virtual LANs) pentru a segmenta rețeaua în mai multe domenii de broadcast. VLAN-urile pentru Ethernet sunt de la 1 la 1001 dar există și VLAN-urile extinse, de la 1006 la 4096 (protocolul de trunking IEEE 802.1Q suportă până la 4096 valori) ce pot fi folosite.

Pentru ca un frame să circule în rețeaua de switch-uri, toate switch-urile trebuie să știe de VLAN-ul de care aparține respectivul frame. VTP (VLAN Trunking Protocol), proprietar Cisco, este un protocol care propagă în rețea lista de VLAN-uri. Astfel, în loc de a adăuga fiecare VLAN manual pe fiecare switch,  VTP face treaba pentru noi.

Ce este uneori ciudat este locul unde sunt stocate intrările pentru VLAN-uri. Curiculumul CCNA, în mare, spune că ele nu sunt salvate în running-config din NVRAM ci în fișierul vlan.dat din Flash. Astfel, atunci când trebuie să resetăm switch-ul, trebuie să ștergem și running-config și vlan.dat. Primul lucru de reținut este faptul că VLAN-urile extinse (1006-4096) NU sunt stocate în vlan.dat ci în running-config, deci, dacă se șterge vlan.dat , acestea vor rămâne.

Un alt lucru ciudat l-am observat la o resetare de switch-uri. Dacă există o rețea de switch-uri, conectate și configurate cu VTP, este greu de șters baza de date de VLAN-uri. Atunci când ștergem flash:vlan.dat de pe un switch și îl repornim (pentru că am șters și startup-config), vom vedea că rămân VLAN-urile, motivul fiind preluarea lor din VTP de la celelalte switch-uri, neresetate.

Pentru a putea reseta switch-urile, ar trebui să le trecem in VTP Transparent mode, pentru a nu mai lua de la vecini VLAN-urile. Și aici intervine excepția Cisco: dacă switch-ul este în Transparent, orice VLAN adăugat va fi configurat în running-config (deci înclusiv cele cu ID mai mic decât 1001). Aceste VLAN-uri nu vor fi afectate de ștergerea vlan.dat, deci s-ar putea să rămână active fără să vă dați seama de ce.

Explicația vine, probabil, din faptul că VTP-ul nu transmite în rețea VLAN-urile extinse, deci, switch-ul va încerca să țină în vlan.dat doar ceea ce trimite prin VTP și restul să fie plasat în running-config.

Switching-ul poate fi destul de ciudat nu din cauza protocoalelor și tehnologiilor folosite pe echipamente ci, de multe ori, din cauza diferențelor de comportare între diverse modele de switch-uri sau între versiuni de IOS.

În cazul DTP, Dynamic Trunking Protocol, care ajută la negocierea legăturilor de trunk, este diferență la setarea default pe anumite modele. Un port poate fi fie în ‘auto’, fie în ‘desirable’, fie în ‘non-negociate’. Schema este următoarea (setare capăt #1 – stare capăt#2 => rezultat):

• auto – auto => access
• auto – desirable => trunk
• desirable-desirable => trunk
• auto – trunk => trunk
• auto – access => access
• desirable – trunk => trunk
• desirable – access => access

Scopul este ca atunci când scoatem două switch-uri din cutie, să știm ce legătură avem când introducem cablul în porturi. Problema este la setarea default a porturilor. De exemplu, pe 2950 (switch Layer2) și pe 3550 (switch Layer3), setarea implicită este ‘desirable‘. Prin urmare, pe două swich-uri de acest model proaspăt pornite, se va negocia un trunk. Pe alte modele, de exemplu 2960 (L2) și 3560 (L3) setarea este ‘auto‘, deci se va negocia un link de tip access (implicit în VLAN 1). Mergând pe aceeași idee, trebuie avut grijă că dacă avem în rețea switch-uri de modele diferite în rețea, s-ar putea să ne trezim cu rezultate neașteptate (un 2950 cu setări default + un 2960 cu setări default, va negocia un trunk).

Aceste observații nu sunt prea clar specificate pe site-ul Cisco, în curriculumul pentru CCNA3 sau BCMSN sau în Certification Study guide, și la un examen de certificare, sau în viața reală, s-ar putea să aveți probleme neașteptate.

CATC România [1], mai bine cunoscut ca Academia Cisco din Facultatea de Automatică şi Calculatoare (ccna.ro [2]) a primit anul acesta din partea Cisco un proiect de nivel internaţional: Ediţia a doua a Competiţiei Instructorilor din Europa Centrală şi de Est, rebrand-uită sub numele iCompetition [3]. Competiţia reuneşte instructori NetAcad din Europa într-un efort de apropiere a Academiilor din această zonă.

Concursul este organizat pe două runde. Prima are loc online şi este compusă din 3 Quiz-uri din materiile de CCNA2, CCNA3 respectiv CCNA4. Un quiz presupune un test grilă şi un test de Packet Tracer. Fiecare concurent trebuie să participe la cel puţin unul din cele 3 quiz-uri, primii 10 cu cele mai mari punctaje pe oricare din quiz-uri vor promova la runda următoare. Materialele de test au fost pregătite de echipa de instructori ccna.ro şi sunt la un nivel destul de avansat de dificultate. Primele două quiz-uri au avut deja loc în ultimele 3 săptămâni şi ultima şansă este peste două săptâmâni la Quiz 3. Runda a doua va avea loc la Universitatea Politehnică Bucureşti, unde finaliştii vor fi învitaţi să participe la un examen hands-on.

[1] http://catc.ro/

[2] http://ccna.ro/

[3] http://icompetition.net/

Una din direcţiile majore de dezvoltare a Cisco este Voice over IP. Cisco oferă un număr mare de echipamente, software şi soluţii pentru VoIP.

Soluţiile VoIP se conectrează în jurul a Cisco Call Manager care este un Call Agent. Este un software ce face administrarea reţelei de VoIP. Acest software vine în două variante: Cisco Call Manager (sau după noua denumire dată de Cisco Unified Communications Manager… este acelaşi lucru) ce este un software ce rulează pe un server x386 peste MS Windows sau Call Manager Express (CME sau Cisco Unified Communications Manager Express) ce este un pachet ce rulează pe un router Cisco peste IOS. Ambele oferă aceleaşi facilităţi de bază. Imaginile de IOS ce vin cu CME au, de obicei, ‘voice’ în nume.

CME este compatibil cu o suită întreagă de protocoale VoIP printre care SIP, H323 şi SCCP. SSCP ( sau Skinny) este protocolul proprietar Cisco şi este suportat de majoritatea echipamentelor Cisco de Voce.

Clienţii pentru Call Manager sunt de obicei Telefoane IP ( ex 7960, 7906G )sau Cisco IP Communicator care este un program pentru Windows ce simulează un telefon (mai este cunoscut şi ca Softphone).

Call Manager Express oferă un wizard pentru configurarea telfoniei IP prin comanda “telephony-service setup”.

Iată o configurare simplă ( liniile notate cu * sunt explicaţii)

Router>enable

Router#configure terminal

Router(config)#interface f0/0

Router(config-if)#ip address 10.0.0.254 255.0.0.0

Router(config-if)#no shutdown

Router(config-if)#exit

Router(config)#telephony-service setup

Do you want to setup DHCP service for your IP Phones? [yes/no]: yes

*Activează un pool DHCP pentru telefoane

IP network for telephony-service DHCP Pool:10.0.0.0

Subnet mask for DHCP network :255.0.0.0

TFTP Server IP address (Option 150) : 150

* Prin Opţiunea 150 de la DHCP (netransmisă implicit), telefonul IP va ştii adresa serveului TFTP

TFTP Server IP address (Option 150) :10.0.0.254

Default Router for DHCP Pool :10.0.0.254

Do you want to start telephony-service setup? [yes/no]: yes

Enter the IP source address for Cisco IOS Telephony Services :10.0.0.254

Enter the Skinny Port for Cisco IOS Telephony Services : [2000]:

How many IP phones do you want to configure : [0]: 2

*Numărul de telefoane ce se vor conecta la CME

Do you want dual-line extensions assigned to phones? [yes/no]: yes

What Language do you want on IP phones : 0

Which Call Progress tone set do you want on IP phones : 0

What is the first extension number you want to configure : 100

*Numărul de telefon primit pe prima linie a primului telefon ce se înregistrează la CME

Do you have Direct-Inward-Dial service for all your phones? [yes/no]: no

Do you want to forward calls to a voice message service? [yes/no]: no

Do you wish to change any of the above information? [yes/no]: no

Acest setup va crea in running-config setările necesare pentru VoIP.

Se observă că adresa 10.0.0.254 a fost completată de 3 ori (ca Default Gateway, TFTP server şi IOS Telephony Services). Nu este obigatoriu ca aceste adrese să coincidă, pentru că nu este obligatoriu ca routerul respectiv să indeplinească toate rourile acestea. Default Gateway este routerul setat pe telefonul IP pentru a ieşi din reţeaua locală (serverul SCCP sau TFTP poate să fie în alt broadcast domain). Serverul TFTP oferă telefonului setările sale sub forma unui fişier XML (în acest fişier se va afla adresa/protul serverului SCCP). IOS Telephony Services este serverul cu CME ce are pornit serverul SCCP şi care va procesa semnalele de telefonie.

[1] http://alex.clubcisco.ro?p=104

Iată o problemă ce nu prea este documentată dar cu care, dacă lucraţi cu switch-uri cu management, foarte probabil o veţi întâlni.

Topologie:

Trei switch-uri Catalyst legate între ele în linie şi două hosturi ataşate la capete.

Situaţie:

În primul rând avem între switch-uri legături trunk şi, important, nu rulează VTP (switchurile sunt în transparent mode). Pe switch-uri nu există alt VLAN decât cel default (VLAN1). Host-urile au adrese din acelaşi broadcast domain.

Pe Switch1 şi Switch3 adăugăm VLAN10 şi plasăm porturile spre host-uri în respectivul VLAN. Pe legăturile trunk sunt permise toate VLAN-urile (sau cel puţin 1 şi 10).

Traficul intre host-uri nu va merge. Motivul: Switch-ul 2 nu ştie de VLAN-ul 10. Deşi liniile de trunk ar trebui să permită traficul pe toate VLAN-urile, el nu va comuta cadre din VLAN-uri care sunt sunt propria listă de VLAN-uri. Comanda “show interfaces trunk” dată pe Switch2 va arată ca ‘permite’ toate VLAN-urile, dar nu ‘face forward’ decât la VLAN-urile de care ştie.

Aici intervine VTP-ul şi nevoie adevărată de VTP. Mulţi ar zice că VTP nu îşi are sensul pentru că el doar adaugă/şterge VLAN-uri de pe switch-uri şi oricum porturile trebuiesc introduse manual în respectivele VLAN-uri (iar atunci când un port de tip access este introdus într-un VLAN inexistent, VLAN-ul este creat automat).  Dar şi pentru switch-urile unde nu avem porturi access trebuie să adăugăm VLAN-urile din reţea (de fapt VLAN-urile ce vor trece prin switch-ul respectiv). Prin urmare VTP, care este, din păcate, protocol propietar Cisco, este foarte important pentru a informa întreaga rețea de topologia de VLAN-uri.

Nu ştiu încă daca este doar o problemă de implementare şi dacă această problemă se regăseşte doar pe switchurile Cisco. Dar este bine de luat în considerare când avem de a face cu VLAN-uri.

Am mai vorbit de Dynamips/Dynagen [1] şi despre cum, nativ, nu are suport pentru a emula un Switch Catalyst. Ce putem face pentru a avea switchuri în toplogiile de testare? Răspunsul este folosirea unui modul de switch încărcat într-un slot din routerul virtual, cum ar fi NM-16ESW.

Scopul folosirii respectivului modul a fost captutarea de pachete DTP (Dynamic Trunking Protocol) pentru a observa negocierea între doua switch-uri.

Am pornit de la înstalarea Dynagen [1] şi configurarea unei interfeţe de loopback [2].

În fişierul de configurare am încărcat o imagine pentru un Router Cisco 3640 cu modulul de switching şi am setat ca o interfaţă din slot-ul de porturi de switch să fie legată cu interfaţa de loopback [3].

Configurarea unui Router arată astfel:

[[Router R1]]
model = 3640
slot0 = NM-16ESW
F0/0 = NIO_gen_eth:\Device\NPF_{7A7D2C17-D0C3-44AA-B17C-5417EF972BF9}

După ce am pornit routerele, comenzile de switchport au fost activate, inclusiv posibilitatea configurării interfeţei de management Vlan1 pe care am pus IP pentru a avea conectivitate între cele două switchuri şi calculatorul gazdă.

Următorul pas a fost instalarea Wireshark [4]. Wireshark, fostul Ethereal, este un program Open Source de captură a pachetelor. Suportă un număr foarte mare de protocoale, de la layer 2 până la 7 şi este un utilitar foarte puternic de analză a traficului.

Topologia a functionat ok, Wireshark a capturat traficul STP, CDP şi altele dintre “switch-uri”.

Problema a fost că am aflat tărziu de limitările modulului de switching. Nu suportă DTP, PAgP / LACP, BPDU-guard, ISL, şi VLAN-uri private (şi altele probabil).

Mulţumesc, BogdanS pentru ajutor.

[1] http://alex.clubcisco.ro/?p=80

[2] http://alex.clubcisco.ro/?p=171

[3] http://alex.clubcisco.ro/?p=104

[4] http://www.wireshark.org/