Unlike Linux’s iptables, Cisco’s filtering via Access Control Lists sometimes has hidden behavior.

Let us test how ACL filtering works using the following topology. We assume that we have Layer 3 connectivity via static routes. We will apply ACLs on the outbound direction of F1/0 on R2 (we want it to be somewhere in the path from R1 to R3)

With no ACLs applied anywhere, all traffic will flow.

R1#ping 3.3.3.3 source 1.1.1.1
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent

Let’s start with the basics and make a classic standard access list that denies R1′s loopback.

R2(config)#access-list 42 deny host 1.1.1.1
R2(config)#int f1/0
R2(config-if)#ip access-group 42 out

The loopback on R1 is blocked…

R1#ping 3.3.3.3 source 1.1.1.1
U.U.U
Success rate is 0 percent (0/5)

… but so is any other traffic that goes out of R2′s F1/0.

R1#ping 3.3.3.3 source F0/0
U.U.U
Success rate is 0 percent (0/5)

The first rule of Cisco’s ACLs is that there is an implicit deny (ip) all (all) rule at the end of every ACL. But this is not visible anywhere. You have to know it.

R2#sh access-lists
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Extended IP access list BLOCK_HTTP

But if that ACL is empty? What if you apply an access list that does not contain any rules (was not declared)?

R2(config)#int f1/0
R2(config-if)#ip access-group 28 out
R2(config-if)#do sh access-lists
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Extended IP access list BLOCK_HTTP

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
!!!!!
Success rate is 100 percent

Traffic passes. The inexistent ACL applied on an interface is ignored. But this is because you can’t have an empty classical (numbered) ACL. What if you do the same thing with a named ACL?

R2(config)#ip access-list standard EMPTY_ACL
R2(config-std-nacl)#exit
R2(config)#do sh ip access-list
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Standard IP access list EMPTY_ACL
Extended IP access list BLOCK_HTTP
R2(config)#int f1/0
R2(config-if)#ip access-group EMPTY_ACL out

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
!!!!!
Success rate is 100 percent

Traffic is still not filtered. So, the rule is that a empty (inexistant or deleted) ACL is ignored by the interface filter.

One more ACL applied on R2 with a deny all rule (no traffic should pass out of F1/0).

R2(config)#ip access-list standard DENY_ALL_ACL
R2(config-std-nacl)#deny any
R2(config-std-nacl)#do sh ip access
Standard IP access list 42
10 deny 1.1.1.1 (8 matches)
Standard IP access list DENY_ALL_ACL
10 deny any (8 matches)
Standard IP access list EMPTY_ACL
10 deny any (8 matches)
Extended IP access list BLOCK_HTTP
R2(config-std-nacl)#int f1/0
R2(config-if)#ip access-group DENY_ALL_ACL out

Ping form R1 is filtered.

R1#ping 3.3.3.3 source 1.1.1.1
Packet sent with a source address of 1.1.1.1
U.U.U
Success rate is 0 percent (0/5)

Since no traffic should go out the interface, a ping from R2 to R3 should also fail, yet it doesn’t.

R2#ping 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/44 ms

As a final rule, traffic generated by a router is never filtered by an ACL applied any interface of that router.

Scenario:
You have two routers running RIP, but the two routers aren’t directly connected because there is a third router between them. See topology below. How do you get routes across because RIP only communicates with routers that are directly connected?

The simple answer is to create a GRE tunnel between R1 and R3 so a tun interface simulates a direct connection of the two routers. But let’s take a more didactic approach to remember some things about RIP.

RIP v2 sends the updates to the address 224.0.0.9 that is a local multicast address (TTL=1). But there is another, very important in some situations (like some Frame Relay networks), way to send routes, and that is via unicast to a statically configured neighbor. Configuration is done via the neighbor command in the router rip configuration. The routes will be encapsulated in normal IP unicast packets and since RIP runs on top of UDP, they should be routed as any other packet.

R1:

interface Serial0/0/1
ip address 10.1.2.1 255.255.255.0
interface Loopback 0
ip address 192.168.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 192.168.0.0
neighbor 10.2.3.3
no auto-summary

R3:

interface Serial0/0/1
ip address 10.2.3.3 255.255.255.0
interface Loopback 0
ip address 172.16.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 172.16.0.0
neighbor 10.1.2.1
no auto-summary

You still need to have a network command for the interfaces when you send and receive the updates (in this case 10.0.0.0) otherwise the received updates will be ignored.

First thing you should be careful of is the fact that R1 and R3 need layer3 communication. So you do need static routes for the R1 and R3 routers through R2.

Having connectivity between each other, the router starts sending unicast packets with the routes. debug ip rip would show the following:

RIP: sending v2 update to 10.1.2.1 via Serial0/0/1 (10.2.3.3)
RIP: build update entries
172.16.0.0/24 via 0.0.0.0, metric 1, tag 0

Notice the update is sent to an unicast address and not 224.0.0.9.

Routes are received but they still are not in the routing tables. debug ip rip shows why:

RIP: ignored v2 update from bad source 10.2.3.3 on Serial0/0/1

This reminds us of how RIP works: if a router receives an update it checks to see if the source of the packet is on the same subnet as the IP configured on the interface. If they don’t match, the update is ignored. In our case, the source of the updates are not on the same network because R2 does not modify the packet source/destination in any way.

The solution to this is to disable the default mechanism with the no validate-update-source command in the router rip configuration. This way any updates will be accepted.

Here is a wanted route in the routing table of R3:

R 192.168.0.0/24 [120/1] via 10.1.2.1, 00:00:27

Notice that the next hop is not directly connected so it need to do a recursive lookup and use the static route to send it to R2 first.

S 10.1.2.1/32 [1/0] via 10.2.3.2

Cel mai important proiect CATC România [1] şi al echipei ccna.ro [2] din acest an a fost iCompetition [3]. A doua ediţie a Competiţiei Instructorilor din Europa Centrală şi de Est s-a desfăşurat la Bucureşti în Universitatea Politehnică Bucureşti. Este un proiect de importanţă internaţională deoarece este singura competiţie de acest gen din lume şi Cisco a avut mari interese pentru a ieşi cum trebuie. După runda online [4], cei 10 finalişti au venit la Bucureşti pentru Runda finală.

Runda da doua a constat în două zile intense de teste, laboratoare şi prezentări ţinute de Academia din UPB. A existat un quiz online pe Moodle, similar cu cel din Runda 1. Proba practică a constat într-un laborator numit CCNA Adventure Lab şi a testat cei 10 instructori la un nivel foarte ridicat. Au existat şi două prezentări, una despre “Next Generation Protocols” şi una despre “Writing Embedded Applications on Cisco Routers and Switches“. Prima prezentare a fost urmată şi de un laborator pe aceeaşi temă. Ultima probă pe care concurenţii au fost testaţi a fost o prezentare făcută din laboratorul respectiv.

Feedback-ul a fost foarte bun şi din partea Cisco, şi din partea reprezentanţilor Cisco Networking Academy regionalii şi, mai important, din partea concurenţilor, care au considerat că a fost un concurs foarte “challenging”. Câştigăgorul a fost Peter Paluch din Slovacia iar locul doi a fost luat de Romeo Lungu din România. Concurenţii au plecat cu premii, dar mai ales cu o experienţă indeită (din spusele lor).

Proiectul a fost o încercare foarte mare pentru echipa instructorilor CATC, efortul depus pentru iCompetition fiind, probabil, mai mare ca la orice alt proiect de până acum. Dar rezultatul a fost pe măsură şi, în urma succesului de anul acesta, Cisco deja îşi face planuri pentru ediţia de anul viitor.

[1] http://catc.ro

[2] http://ccna.ro

[3] http://icompetition.net

[4] http://alexj.info/?p=836

Certificarile Cisco sunt oferite prin Career Certifications & Paths. Si sunt doua cateogrii: Certificarile Generale ce sunt structurate sub forma unei piramide si certificarile de Specialist. Diferenta inte ele este ca cele generale cuprind un domeniu destul de mare (exemplu Securitate sau Routing&Switching) , necesita trecerea a mai multor teste si au o valabilitate de 3 ani iar cele de specialist sunt pe un produs specific (exemplu ASA Specialist, Firewall Specialist, Unitiy Specialist), necesita un examen si au valabilitate de 2 ani. Certificarile genelare se impart pe trei nivele: Associate, Professional si Expert.

Cea mai cunoscuta certificare este CCNA – Cisco Certified Network Associate. Este certificarea care sta la baza piramidei, adica orice alta certitificare are ca prerequisite CCNA-ul. Obtinerea certificarii de CCNA necesita fie trecerea unui examen compus 640-802 CCNA (acesta este examenul nou de CCNA ce inlocuieste 640-801) fie trecerea a doua examene ce reprezinta jumatati din 640-802 : 640-822 ICND1 si 640-816 INCD2 (ce inlocuiesc fostele INTRO si INCD).

Tot la nivelul Associat mai este o certificare de Networking Design: CCDA – Cisco Certified Design Associate, ce necesita de asemenea un singur test: 640-863 DESGN.

Incepand de vara aceasta, Cisco a introdus trei certificari noi de nivel associate: CCNA Security, CCNA Voice si CCNA Wireless. Acestea vin ca o completare a CCNA-ului pe directiile respective si sunt un raspuns din partea Cisco la cerinta pietei IT pentru securitate, mobilitate si VoIP. Fiecare din acestea au nevoie de cate singur test: 640-553 IINS, 640-460 IIUC respectiv 640-721 IUWNE, dar, desi sunt de nivel associate, e nevoie sa fi avut certificarea de CCNA inainte (la fel ca CCDA).

Mai exista si o certificare de tip Entry Level (ceea ce modifica piramida clasica Cisco), adica sub associate. In acesta categorie intra certificare CCENT care se obtine prin trecerea examenului640-822 ICND1 (adica prima jumate din CCNA).

[to be continued]

Certificarile noi scoase sunt CCNA Security, CCNA Wireless si CCNA Voice. Ciudat cum nu au ales nume mai simple gen CCSA, CCWA si CCVA, dar banuiesc ca e din politica de a promova cel mai de succes produs al lor: CCNA. Nici una din aceste certficiari nu este echivalenta cu CCNA si toate au ca prerequirement certificarea de CCNA.

Din pacate odata cu anuntul despre introducerea certificarilor nu au fost scose si documentatiile. Stirea despre certificari este relativ veche. Zilele trecute Cisco Press a scos o versiune Routh Cut (adica un fel de beta) cartea cu materiale pentru examenul de Wireless (ocazie cu care scriu si articolul), dupa ce deja se scosese cea de Security. Astept in mod special scoaterea cartii de Voice. Pana in toamna ar trebui sa fie scoase toate materialele necesare. Este un zvon (pe care si Cisco il evita) ca se vor scoate cursuri in cadru Cisco Networking Academy pentru aceste certificari.

Impreuna cu un coleg-instructor din Academie am mers ‘in delegatie’ la Galaciuc, unde am avut de facut doua lucruri: 1) O prezentare in fata elevilor despre Packet Tracer (si despre basic networking) 2) Un concurs de Packet Tracer ( l-am numit Cisco Packet Tracer Challenge ) a doua zi. Am fost foarte placut surprinsi de interesul ‘copiilor’ in Packet Tracer si bucurosi ca s-au descurcat foarte bine la concurs (desi aveau exprienta de cateva ore cu produsul).

Pe langa aceste doua event-uri, a mai avut loc si o prezentare a Managerului Regional Cisco NetAcad, domnul Nicolai Sandu si cel mai interesant mi s-a parut teleconferinta organizata de dl Nicolai cu Ciprian ‘Cip’ Popoviciu de la Cisco, din America, care ne-a povestit despre expeditia sa pe Everest (powered by Cisco ). Bineinteles toata teleconferinta a fost facuta cu tehnologie Cisco .  De asemenea a mai fost un concurs de cablare organizat de domnul Daniel Popa de la Academia Cisco din Orastie.

Am fost onorati ca am primit atata atentie din partea participantilor si mandrii ca eram ‘tipii de la Cisco’ (dupa cum ni s-a mai zis ). Pacat ca nu am putut participa si la alte evenimente pentru ca a trebuit sa plecam repede deoarece seara aveam sedinta instructorilor in Academie (sunt mandru de masinuta mea care nu prea a vazut viteze sub 130 tot drumul).

(am asteptat sa apara pozele inainte de a posta)

(have a new Cisco T-Shirt btw )

Nelegat de eveniment, s-a scos Packet Tracer 5. A fost scos cu cateva zile inainte sa plecam la Galaciuc, deci nu am putut sa prezentam pe el… am facut prezentarea pe 4.11.

Packet Tracer este un simulator de network disponibil studentilor din Academia Cisco. Il recomand cu cea mai mare placere. Mi-a fost foarte util atunci cand faceam cursurile de CCNA (atunci fiind la versiunea 3.0-3.1). Versiunea 4.0 a adus imbunatatiri substantiale si 4.1 si 4.11 au fost updateuri bune. Packet Tracer 5.0 nu m-a impresionat in mod special. A adaugat un switch multilayer dar nu cu multe optiuni de configurare (pacat ca nu l-au scos inainte sa fac BCMSN-ul). Macar am reusit sa fac un EtherChannel in PT. A fost adaugata optiunea de multiarea OSPF si facitilati pt IPv6 (desi eu nu am reusit sa configurez nimic cu IPv6). O chestie interesanta pare a fi “Multiuser Connection” care permite conectarea mai multor instante de PT (chiar de pe masini diferite). Desi nu am explorat optiunea, pare foarte promitatoare.