A 2. rétegben kezelt keretek fejlécében nem találunk olyan mezőt, amely ellátná azt a feladatot, amelyért a 3. rétegben az IP protokoll time-to-live mezője felelős, vagyis annak detektálása, hogy az adott csomag hurokba kerül. Ilyen hurkok akkor alakulnak ki, ha alternatív útvonalak is rendelkezésre állnak a hálózatban két eszköz között. Mivel a 2. rétegben a…
Redundancia a hálózatokban Redundanciára szükség van a hálózatokban, hiszen csak így biztosítható, hogy amennyiben egy útvonal kiesik, egy másik beléphessen automatikusan a helyére. Gondoljunk csak arra, hogy a való életben is élünk ezzel a lehetőséggel: Ha például leáll a metróközlekedés, átszállunk villamosra, és azzal közelítjük meg a célállomásunkat. (Feltéve persze, ha jár arra villamos.) A…
A bejegyzés a https://www.practicalnetworking.net/stand-alone/eigrp-feasibility-condition/ cikk fordítása alapján készült. Bevezetés Az EIGRP a hurokmentes útvonalakat úgy biztosítja, hogy megvizsgálja rajtuk az alkalmasság feltételét. (Ezen kívül a látóhatármegosztást is alkalmazza, de erről majd később.) Induljunk ki a következő topológiából: A topológiában 4 EIGRP forgalomirányítót láthatunk. Fókuszáljunk az R4-hez kapcsolódó 9.9.9.0/29 hálózatra. Mindegyik linkre ráírtuk az EIGRP költségét….
A 2. és a 3. rétegben nagyon könnyen tudjuk redundáns útvonalakkal megbízhatóbbá tennünk a hálózatunkat. Viszont egy gyenge pontja lehet a LAN hálózatainknak, és ez az alapértelmezett átjáró, amelyet közvetlenül a végállomásokon állítunk be (akár statikusan, akár dinamikusan), és nincsen arra módszer, hogy amennyiben az alapértelmezett átjáró nem lenne elérhető, az állomások automatikusan keressenek egy…
A GRE (General Routing Encapsulation, RFC 2784) protokoll segítségével nagyon egyszerűen tudunk két vagy több távoli forgalomirányító között alagutat létrehozni. Tegyük fel, hogy cégünk két telephellyel rendelkezik, és ezek között szeretnénk olyan kapcsolatot létrehozni, amelyet az internet szolgáltatónk nem támogat. Például mindkét telephely hálózatban konfiguráltuk az OSPF protokollt, de értelemszerűen a határ forgalomirányítóink nem képesek…
Ha még nem olvastad, a cikksorozat első részét, ITT elérheted. A címpazarlás problémája Mi a gond az osztályos hálózatokkal? Az, hogy pazarlóak. Gondoljuk el: 3 féle méretű hálózatból választhatunk: Vagy 16 millió címesből (A osztályú), vagy 65 ezer címesből (B osztályú), vagy 254 címesből (C osztályú). Ha egy kis iroda, ahol 10-12 gép található, publikus…
Alapok Az Internet maga különböző helyi (fizikai) hálózatok összekapcsolásából jött létre. Annak érdekében, hogy ezek a különböző helyi hálózatok összekapcsolhatók legyenek egymással, lehetővé kellett tenni, hogy azokból egymás állomásai megcímezhetők legyenek. Erre az egyes eszközök fizikai (hardver, MAC) címe nem volt alkalmas, hiszen semmi nem garantálta, hogy az egyes hálózatok egymással kompatibilis fizikai címzést alkalmazzanak….
Egy Frame Relay hálózat kialakításakor a DLCI és az IP címzésen kívül, az LMI típusát és a Frame Relay begyazást kell megterveznünk. Ebben a cikkben ezeket vesszük sorra. Ha még nem olvastad, olvasd el ezt a bejegyzést is: Frame Relay kapcsoló konfigurálása 2. rétegbeli (DLCI) címzés megtervezése Noha a virtuális áramköröket azonosító DLCI címeket általában…
Ha még nem olvastad, olvasd el ezt a bejegyzést: Frame Relay konfigurálása Mind a Packet Tracer-ben, mind a GNS3-ban ugyan beépítve találunk egy-egy Frame Relay kapcsolót, de mindkettő csupán szimulálja ezt az eszközt. A Cisco forgalomirányítókból azonban egy nagyon egyszerű konfigurációval magunk is készíthetünk Frame Relay kapcsolót. Nézzük meg most ezt. Induljunk ki a már…
A Frame Relay alapjai cikkben tárgyaltak logikája szerint vegyük végig lépésről lépésre a példahálózat konfigurációját GNS3-ban. Ha még nem olvastad, olvasd el előtte ezt a bejegyzést: Frame Relay alapok Induljunk ki a következő topológiából: Mindenekelőtt a FR1 Frame Relay kapcsoló beállításait végezzük el a következők szerint: Most végezzük el a forgalomirányítók konfigurációját. Mint láthatjuk, nincsen…