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…
|
||||||
|
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? 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 Miután elfogytak az IPv4-es címek gondotam sokak fantáziáját mozgatja hogy akkor most mi is lesz? 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. 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 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. 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) 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.
Reflexív ACL-ek a csomagszűrést nem csupán IP cím alapon végzik, hanem vizsgálják a felsőbb rétegbeli session információkat is. Általában a kimenő forgalmat engedélyezik, a bejövő irányban pedig visszafele csak a válaszforgalom engedélyezett. Reflexiv ACL először a Cisco IOS 11.3-ban lett bevezetve, és csak named extended ACL-t lehet reflexív ként definiálni. BGP esetén az ismert route-ok száma egyszerüen a show ip bgp summary paranccsal megtudható. Más routing protokollok esetén a helyzet nem ilyen egyszerü, azonban a megoldás a routing tábla összegzése. |
||||||
|
Copyright © 2012 Cisco CCNA, CCDA, CCNP, CCIP, CCDP - All Rights Reserved |
||||||