Kapcsolat

Kategóriák

Facebook

2013-as új CCNA vizsgák

Ahogy arról már sokan értesülhettetek, a Cisco CCNA vizsgák 2013. áprilisában megujjultak. Ez azt jelenti hogy az új vizsgákba új témakörök kerültek bele, egy témakör esetlegesen mélyebben van érintve, illetve az “elavult” témakörök kikerültek belőle. Folytatás >>> 2013-as új CCNA vizsgák

object-group port matchelése

Több IP cím, port vagy egyéb elem object-group-ba történő szervezésével egyszerűsíthetőek az ACL-ek. Tegyük fel hogy van három szerverünk (10.1.1.10, 20.1.1.10 és 22.1.1.10), melyeken web, ssh és telnet hozzáférést kell engedélyezni a 192.168.1.0, 192.168.2.0, 172.16.1.0 és 172.30.1.0 hálózatok számára. Ez 36 darab ACL bejegyzés lenne ha egyenként párosítanánk össze a forrás IP címeket a portjaikkal a cél hálózatokhoz. Object group-ok alkalmazásával azonban ez a feladat lényegesen leegyszerűsödik, és a későbbi adminisztrációnál is nagy segítséget fog jelenteni.

Folytatás >>> object-group port matchelése

IP SLA konfigurálása

IP SLA segítségével a hálózatot jellemző értékek mérhetőek. Így ezzel akár a szolgáltatási szerződésben vállalt értékek betartása is mérhető. Ilyen értékek lehetnek például:

  • delay
  • jitter
  • port/szolgáltatás elérhetősége
  • Voice minőség paraméterek
  • stb…

Folytatás >>> IP SLA konfigurálása

NAT két outside interfésszel

Lulla a tanfolyamon feltette a kérdést, hogy mi van akkor ha a két outside interfészünk van, és az egyik interfészre NAT-olunk, azonban a csomagot egy másik interfészen keresztül küldjük ki?

Folytatás >>> NAT két outside interfésszel

switchport nonegotiate + speed auto + duplex auto

nonegotiate és auto???

Sokakben felmerülhet a kérdés hogy ha nonegotiate-et bekapcsoljuk mégis hogyan fog a speed auto és duplex auto működni. Márpedig igenis működik akkor is. Két auto-auto eszköz full-duplex és a legmagasabb elérhető sebessében fog megegyezni.

Folytatás >>> switchport nonegotiate + speed auto + duplex auto

Egyszerűen IPv6

Miután elfogytak az IPv4-es címek gondotam sokak fantáziáját mozgatja hogy akkor most mi is lesz?
Nos a válasz: IPv6 lesz, sőtt már van

Mégis miben különbözik az IPv4-től? Van amiben igen, van amiben nem. Egész más főleg ha a kinézetét nézzük. Másrészről hasonló mert ugyanúgy IP cím, ugyanúgy van routing, ugyanúgy ott a prefix hossz is. Az “ember” IPv4-es címekhez van hozzászokva, ezért az első, meg talán a második ránézésre is egy kicsit idegen lesz az IPv6-os cím. De ez is egy cím, úgyhogy ha elfogadjuk hogy 32 bit helyett 128 bittel gazdálkodhatunk, akkor nem lesz annyira nehéz megérteni.

Folytatás >>> Egyszerűen IPv6

Forrás és cél IP cím NAT-olása egyszerre

Címfordításra sokszor van igény, elsősorban olyan helyzetekben, ha az eredeti IP címet valami miatt el kell rejteni, vagy meg kell változtatni, például egymással átfedésben levő hálózatok vannak, vagy a cél szerver IP címe megváltozott, azonban a kliens szoftverbe bele van programozva a cél IP cím és azon változtatni nem lehet.

NAT (Network Address Translation) esetén általában az inside oldalról jövő forrás IP címet szoktuk megváltoztatni. Természetesen az outside oldalról jövő forrás címet is meg lehet változtatni, amely felér azzal hogy az inside oldalról jövő cél IP címet változtatjuk. (A válasz csomagban a cél cím az eredet csomag forrása, illetve fordítva a válasz csomag forrása az eredeti csomag cél címe, akár csak egy postán küldött levél és a válaszboríték címzésénél) Folytatás >>> Forrás és cél IP cím NAT-olása egyszerre

Zone-Based Firewall konfiguráció

A hagyományos interfész alapú tűzfal konfiguráció nem volt elég flexibilis, számos újítást nem lehetett benne megoldani. Ezért vezették be a zóna alapú tűzfal konfigurációt. Parancsai eltérnek az interfész alapú konfigurációtól, és a két módszert nem lehet egyszerre alkalmazni ugyanazon az interfészen. Ha egy interfész a CBAC tűzfallal van konfigurálva, nem lehet zone-based tűzfalhoz konfigurálni, nem lehet zóna tagja.
Folytatás >>> Zone-Based Firewall konfiguráció

hibaérzékelés BFD-vel (Bidirectional Forwarding Detection)

Néhány évvel ezelőtt egy hiba esetén a hálózat konvergálása néhány (néhány tíz) másodperc alatt még elfogadható volt. Kritikus alkalmazásoknál volt csupán szükség szinte azonnali konvergenciára. Napjainkban azonban a VoIP megjelenésével, a hiba azonnali érzékelésére és konvergenciára az igény magas lett.

Folytatás >>> hibaérzékelés BFD-vel (Bidirectional Forwarding Detection)

Flash-ről törölt file helyének felaszabadítása

Flashről történő törlés után az IOS csupán megjelöli a file-t hogy le lett törölve, azonban a helyét nem szabadítja fel. A megoldás a squeeze parancsban rejlik.


Router#sh flash

System flash directory:
File Length Name/status
1 17748616 c2600-is-mz.123-15a.bin
2 15257044 c2600-is-mz.122-13.T5.bin
[33005788 bytes used, 24352 available, 33030140 total]
32768K bytes of processor board System flash (Read/Write)

Folytatás >>> Flashről törölt file helyének felaszabadítása