- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Azonnali mobilos kérdések órája
- OneSport OT05 - finomhangolás
- Honor 200 Pro - mobilportré
- iPhone topik
- Honor Magic6 Pro - kör közepén számok
- Milyen okostelefont vegyek?
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 13 - felnőni nehéz
- Vodafone mobilszolgáltatások
Hirdetés
-
Limitált ideig már kipróbálható a The Alters PC-s verziója
gp A 11 bit studios különleges túlélőjátéka konzolokra is megjelenik majd.
-
Z Fold6 imitátor árulkodik a fogyókúrázó igaziról
ma Több lesz kívül a változás, mint belül.
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Mobilarena
--- Még az új vizsgarendszer előtti információk, majd frissítjük! ---
Gyakran ismételt kérdések
Olvasd el a cikkeket itt.
Új hozzászólás Aktív témák
-
klambi
addikt
válasz zsolti.22 #1780 üzenetére
hát nekem még az a jővő zenéje bőven még suliban a köv, félévben befejezem a Network Academy-t utána a ccnp könyv kéne és majd valamikor cucc hozzá. Nem tudom hogy packet tracer mennyire tud segíteni ccnp-ben, gondolom ti sem poénból vettétek meg a cuccokat hozzá...
"Mond szépen angolul: Gyors róka!"
-
tusi_
addikt
válasz zsolti.22 #1818 üzenetére
Igazából nem nehéz a switching anyag, ha ott tartasz majd, nem lesz problémád vele. Igy most, hogy másodjára is elolvastam a switchet - fejezetenként kilaborozva - , azt mondom, sokkal egyszerűbb, mint a route. Tegnap bele néztem a routingba és nyeltem nagyokat. Abban a 370. oldalnál tartok, de szvsz nehezebb, mint a switch. Ha azt megtanultad, akkor a switch sem lesz gond.
eat, sleep, play, replay
-
tusi_
addikt
-
crok
Topikgazda
válasz zsolti.22 #1836 üzenetére
Gondolj úgy a stub-ra, mint olyan routerre, ami mögött már nincs más hálózat,
csak a saját LAN-ja.. Azért jó a stub EIGRP-nél, mert hub-and-spoke design
esetén például nem fog a hubtól EIGRP-n kérést kapni, hogy egy épp eltűnt
route nála megtalálható-e, ahogy más, normális esetben történne, mert a stub
router egy speciális EIGRP packet-el minden szomszédot értesít arról, hogy ő
csak egy stub - egy csonk a hálózaton, egy "végpont" EIGRP szempontból.
Ez nem csak emiatt jó, hogy a hub nem kérdez feleslegesen, de mivel a spoke
router egy stub - tehát nincs (vagy csekély számú..) másik WAN kapcsolata
van csak így nem kell a teljes hálózat routing tábláját megtanulni, a stub csak
elküldi a saját hálózatait és kap a hub(ok)tól egy default utat. Így erőforrást és
konvergenciaidőt spórolsz: a spoke (stub) router routing táblája kicsi, a hub(ok)
meg tudnak róla hogy a stub felől érkezett route-ok ha eltűnnek az EIGRP-ből
akkor azokat nemigen kell máshol keresni. Kicsit ASCII art-osan:Ilyen van, hogy:
LAN |==stub spoke == hub == stub spoke==| LAN..de olyan nincs hogy:
LAN |==stub spoke == hub == stub spoke==| LAN
|| ||
"======================="mert ekkor a stub már nem stub, nem egy "lezárt hálózat" mert van kapcsolata
egy másik spoke-al, így az egyik stub a másiknak a hálózatait nem csak a hub
routeren keresztül ismeri. A Cisco oldala tök jól leírja.[ Szerkesztve ]
-
Tsory
tag
válasz zsolti.22 #1840 üzenetére
Ha subinterface-eket használtál, akkor a split horizon nem játszik:
Configuring Frame Relay subinterfaces ensures that a single physical interface is treated as multiple virtual interfaces. This capability allows you to overcome split horizon rules so packets received on one virtual interface can be forwarded to another virtual interface, even if they are configured on the same physical interface.
-
crok
Topikgazda
válasz zsolti.22 #1840 üzenetére
> teljesen vagy csak részlegesen, de ne legyen full mesh a PVC-k és
routerek között <---ez nem tiszta.Nem csodálom. A "teljesen" és a "full mesh" számomra ugyan az.
A 3 router összekötéséhez egy negyediket vagy Frame-relay switchet
használtál? Mi a konfigja? Akkor lenne baj, ha így nézne ki a kiépítés:LAN
_
|
R1
|
|
[] <- Frame-relay switch (lehet router is..)
||
/ \
/ \
R2 R3
| |
_ _
LAN LANEzen esetben, amint látod, R1 egyetlen interface-én 2 router lóg. Nyilván
más DLCI-vel éri el a másik 2 routert ám itt bizony bejön a képbe a split
horizon szivatás, hiszen egy interface-en át érsz el 2 eszközt, mind a
kettőtől kapsz utakat, de ugyan azon interface-en keresztül nem küldhet
ki a router routing információkat R1 ahonnan kapta.. tehát R1 megkapja
R2 és R3-tól a routing információkat ám nem küldheti ki az R2-től kapott
információkat R3-nak, hisz ugyan azon interface-en kellene kiküldeni,
mint amin kapta (még akkor is, ha más DLCI). Képet és konfigot adj,
akkor meg tudom nézni hogy miért megy máshogy, mint várod.[ Szerkesztve ]
-
crok
Topikgazda
válasz zsolti.22 #1844 üzenetére
Igen, csak a középsőn volt, de a split horizon csak azon játszhatott.. volna!
De mivel subint volt, gondolom 2, így az egyik egyfelé, másik másik felé
ment, így a split horizon miatt a subint már nem fogja meg a routing update-
eket, hiszen már másik interface-en megy a dolog -
crok
Topikgazda
válasz zsolti.22 #1849 üzenetére
Ahogy látom R1-en van ugyan subinterface, de csak egy. Kíváncsi lennék
a konfigra. pastebin.com-ra is teheted. De ahogy látom Null0-ra mutat az
az EIGRP route amit kaptál.. az nem valami jó Egyébként az EIGRP
konfigban van no autosum? Ja és akkor a FR SW-ben csak 2 entry van?[ Szerkesztve ]
-
Tsory
tag
válasz zsolti.22 #1840 üzenetére
> teljesen vagy csak részlegesen, de ne legyen full mesh a PVC-k és routerek között <---ez nem tiszta.
Ha full mesh topológiát használsz, akkor minden router közvetlenül eléri a másikat, így a routing update-eket is közvetlenül megkapják. Így nem tud közbeszólni a spit horizon rule.
Ha nincs full mesh topológiád, akkor lesz olyan része a hálózatnak, ahol egy router a multipoint subinterface-en bejövő routing update-et nem fogja továbbítani ugyanazon subinterface-én lévő másik DLCI alatt elérhető másik routernek, így az nem fogja megkapni az update-et. Ebben az esetben vagy ki kell kapcsolni a split horizont, vagy point-to-point subinterface-t kell alkalmazni.
-
Tsory
tag
válasz zsolti.22 #1859 üzenetére
Hát ez nekem elég sztochasztikusan viselkedik. Van, hogy a pingek sem mennek, vagy akár az interface-eket sem mennek up/up állapotba.
A konfig nekem jónak tűnik, mondjuk a no auto-summary-t beállítanám az eigrp alá.
Hát erősen elgondolkoztam, hogy vagy nagyon alaposan ki kell választani a megfelő router/ios típust a GNS3-ban, vagy érdemes ezeket is fizikai eszközökön gyakorolni. Szerencsére a 26XX sorozathoz serial interface-el már elég olcsón hozzá lehet jutni, talán az is jó a tesztekhez. FR switchet is lehet belőlük csinálni.
-
sunyijanika
tag
válasz zsolti.22 #1849 üzenetére
Nézzük ezt a FR-t.
1. Nincs kiadva a (no auto-summary) - ahogy ezt már írták,
2. a hubra mindenféle kép kell a no split-horizon eigrp x parancs.
3. Ahogy látszik, néhány útvonalat ismer, néhányat nem a 2 spoke. Ha megnézed a frame-relay map-t akkor láthatod, hogy csak egy út van és az a "hub"-hoz vezet. a hubon kivan adva a no split parancs ezért ő szépen küldi az update-t mind2 irányba ezért látod a subneteket, de soha nem fogja elérni őket (no ping). Ezért mindenképp kell további map-ket hozzáadni.
R2 ---> frame-relay map ip 10.0.0.3 201 broadcast
R3 ---> frame-relay map ip 10.0.0.2 301 broadcast
Ezek után szépen működni fog a dolog!
- Az mind1, hogy a fizikai vagy multipoint-t konfigurálsz a spokekon mind2 egyaránt működik (bár nincs sok értelme)
-
Tsory
tag
válasz zsolti.22 #1869 üzenetére
Nézd meg az FR switch konfigját. Ha megnyitom a feltöltött project fájlodat, akkor nálam így néz ki a konfigja:
1:102 - 2:201
1:103 - 3:301
2:201 - 1:102
3:301 - 1:103Mintha duplázná a konfigot. Ilyet nekem nem is enged előállítani. Törölve az összerendeléseket, resetelve az FR switchet, majd felvéve:
1:102 - 2:201
1:103 - 3:301már rendesen működik nálam.
Enélkül azt kapja vissza R1, hogy nem is léteznek ilyen DLCI-k:
R1#sh frame-relay map
Serial0/0.1 (down): ip 10.0.0.2 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status deleted
Serial0/0.1 (down): ip 10.0.0.3 dlci 103(0x67,0x1870), static,
broadcast,
CISCO, status deleted[ Szerkesztve ]
-
Tsory
tag
válasz zsolti.22 #1872 üzenetére
Take it easy! Nem mondtam, hogy te írtad be, csak meglepődtem, mert nálam nem jelent meg. Csak próbáltam rájönni, mi lehet a megoldás. Sunyijanika már felvilágosított engem, hogy ez így természetes.
Itthon újra megcsináltam a konfigot, itt is működik. Úgy látszik, tud ez konzekvensen is működni .
-
jerry311
nagyúr
válasz zsolti.22 #1902 üzenetére
A széptől még messze van, inkább alapkonfig.
Egyszerűsítve: 2 fázisból áll:
1, ISAKMP
2, IPSec1,
crypto isakmp policy 1
encryption 3des
authentication pre-share
group 2crypto isakmp key jelszo address 128.107.9.9
Polciy: a használt encryption, hash authentication és a DH Key exchange-ben használt key nagysága
A hash-t nem látod, mert default maradt, ami emlékeim szerint SHAisakmp key: pre-shared-key - jelszó
2,
crypto ipsec transform-set nev esp-3des esp-sha-hmaccrypto map valami_nev 10 ipsec-isakmp
set transform-set nev
set peer 128.107.9.9
match address 101access-list 101 permit ip 10.99.1.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 101 permit gre any anyTransform set: ugyanaz mint az ISAKMP policy csak a második fázisra vonatkozik.
A crypto map-ban pedig az egészet egybegyúrod: melyik peerrel, milyen transform set-et használva milyen forgalmat (ACL) teszel a VPN-be.3,
interface dialer 2
crypto map valami_nevA VPN tunnelbe persze csak akkor rakja bele a forgalmat, ha az adott interface-re rá van rakva a crypto map.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#1903
Nem feltétlenül szükséges, de erőteljesen ajánlott.
[ Szerkesztve ]
-
tusi_
addikt
válasz zsolti.22 #1902 üzenetére
crypto isakmp policy 1 = policy "sorszáma"
encryption 3des = titkositás módja
authentication pre-share = hitelesités módja alőmegosztott kulcs
group 2 = Diffie Hellman 2 1024 bites IKE kulcs.
(Innen nekem hiányzik a hash)crypto isakmp key jelszo address 128.107.9.9 = Ezt a "jelszót" küldi át tikositva diffie hellmannal az ip-re
crypto ipsec transform-set nev esp-3des esp-sha-hmac
crypto map valami_nev 10 ipsec-isakmp
set transform-set nev = ez a parja a késöbbi crypto map interfésznek
set peer 128.107.9.9 = szomszéd ip
match address 101 = acces list, amiben engeded a forgalmat. Saját ip és a távoli ip.access-list 101 permit ip 10.99.1.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 101 permit gre any anyinterface dialer 2
crypto map valami_nev = ez lesz a neve, ezzel engeded az interfészen hogy a kifele menő csomagok titkositva menjenek át.eat, sleep, play, replay
-
jerry311
nagyúr
válasz zsolti.22 #1906 üzenetére
Az ISAKMP tulajdonképpen egy szabvány, hogy két fél azonosíthassa egymást és kulcsot cserélhessenek. Elméletileg a kulcs-csere módjától független, gyakorlatilag szinte csak IKE protocolt használnak rajta.
Az IKE meg arra való, hogy biztonságos kulcs-cseével létrehozzon egy biztonságos csatornát, nem biztonságos hálózatokon.
Azonosításra certificate vagy jelszó, esetleg RSA keypair használatos benne. Az egymás közti forgalmat titkosítják (megadott encryption mód), hash-elik, hogy tudják nem változott-e útközben. Mindehhez elsőként ott van a DH key exchange, amivel gyakorlatilag biztonságos kulcs csere lehetséges anélkül, hogy a kulcs bármikor is átment volna a nem biztonságos csatornán.tusi_
set transform-set nev = ez a parja a késöbbi crypto map interfésznek
vagy inkább az előbbi crypto ipsec transform-set parancsnak
[ Szerkesztve ]
-
tusi_
addikt
válasz zsolti.22 #1972 üzenetére
ip ospf authentication message-digest
Ha jól emléxem, erre a parancsra indul el azokon az interfészeken a hitelesités, amelyikeken beállitottad a "ip ospf message-digest-key 1 md5 jelszó" -t. Ez csak azon a szomszédon érvényes, amelyikkel egy interfészen van. Ha egy router f0/0-n cisco a jelszó, a f0/1 -en meg casco, akkor is menni fog a hitelesités, de csak azzal a szomszéddal, amelyikkel az azonos intefészen van.
[ Szerkesztve ]
eat, sleep, play, replay
-
crok
Topikgazda
válasz zsolti.22 #1993 üzenetére
Nos első körben ez egy discontinous net.. a loopback címek egy alhálóban
vannak. :/ Másik: OSPF alap design, hogy az area 0 contiguous. Itt az area
0-kat virtual-linkeled össze? Az nem okos.. A virtual link az arra jó, hogy egy
area-n keresztül csatlakozz az area 0-hoz.. tehát pl 2-1-0 , virtual link 1-en át.
[Szerk.]Vagy én látok valamit rosszul?[ Szerkesztve ]
-
crok
Topikgazda
válasz zsolti.22 #1999 üzenetére
Tévedtem, benne van, 3.132 - 2 cég Area 0-áját teszi összefüggővé, de alapból
írja, hogy ne használd design szerint, mert temp megoldásként még elviselhető.Host-nak én 1700-as routereket teszek be általában (a kép lesz csak host) vagy
linux boxokat (tinycore vagy hasonló kis disztribúciókat).Melyiket nem olvastad amit írtam?
-
zsolti.22
senior tag
válasz zsolti.22 #2036 üzenetére
Belekukkantottam a könyvbe: 10.10.32.0 szerepel benne, nem 10.100, ahogy írtad és írja is, hogy Choose two answers, és mivel a 2 válasz kapásból meg van, szerintem nem kell rágódni, hogy az A miért jó. Vizsgán ezzel rengeteg időd menne a levesbe.
Szerintem azért, mert egy részét lefedi az ACL. A másik kettő, D és E-nek meg abszolút nem fedi le. Más magyarázat nem lehet.
[ Szerkesztve ]
-
tusi_
addikt
válasz zsolti.22 #2040 üzenetére
Sógorom hozta, ezekből vizsgázott az Ő rg-juk. Hogy Ő honnan szedte, azt nem tudom.
Biztos igaza van a könyv irónak, nem vitatom, de szeretném megérteni. Számomra nem csak a vizsga fontos, szeretném érteni is, mert zavar van az erőben, ha valamit nem értek
Persze, hogy emléxem. (engem rá nem vennél, hogy könyvből tanuljak, nekem ez a legjobb megoldás. Esetleg egy E-book olvasót elfogadnék a forditás miatt)
[ Szerkesztve ]
eat, sleep, play, replay
Új hozzászólás Aktív témák
- Kérlek használd a keresőt, mielőtt kérdezel!
- Olvasd el a téma összefoglalót mielőtt kérdezel!
- A dumpok és a warez tiltott témának számítanak!