-
GAMEPOD.hu
--- 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
-
Tsory
tag
Az ábrán látszik, hogy statikus DLCI IP összerendelés történt. A távoli IP-t kell a lokális DLCI-vel összerendelni. Attalla esetében már az IP is problémás, mert a saját interface IP-je van beállítva, nem a távoli IP. A státusz jelentései:
ACTIVE: sikeres end-to-end kapcsolat.
INACTIVE: Sikeres kapcsolat a frame-relay switch-ig, de a PVC túlsó vége nem válaszol. Valószínűleg rosszul van konfigurálva a switch.
DELETED: Olyan DLCI van konfigurálva, amit a switch nem fogad el ezen az interface-en. Vagyis valószínűleg rosszul van konfigurálva a DLCI érték.Így a C válasz a jó. Az E a statikus összerendelés miatt nem jó, ebben az esetben automatikusan kikapcsol az inverse ARP.
"When static mapping is configured on an interface for a protocol and a specific DLCI, the router automatically disables dynamic Inverse ARP for the protocol and the specific DLCI on the interface."
Ts
-
Tsory
tag
Ez az ábra ne annyira jó . Melyik könyvből van? A DLCI értékek layer 2-es címek, gondolj úgy rájuk, minha MAC címek lennének. A hozzád legközelebb eső FR switchet címzed vele. Az FR hálózaton több ilyen switch is lehet, így a DLCI érték állandóan változik, míg a layer 3 cím nem (hasonlóan Ethernet hálózat esetében hop-ról hop-ra változik a forrás és cél MAC cím, míg az IP változatlan marad).
Ts
[ Szerkesztve ]
-
Tsory
tag
Jó lesz az a könyv. Az ábrán FR global címek vannak feltüntetve. Néhány oldallal előrébb el is magyarázzák a különbséget. Vagyis a local DLCI-k vannak úgy beállítva, hogy a túloldal global DLCI-vel egyezzen meg.
"Frame Relay Global Addressing (DLCIs)
The previous section discusses how Frame Relay addressing really works with local addressing.
If you happened to come to this section on global addressing, and have not yet understood local addressing, stop now, and go back! Global addressing only makes sense if you have a good understanding of local addressing.
Global addressing, or global DLCIs, is a convention service providers may use when choosing local DLCIs. By using the global addressing convention, documentation becomes easier, adding new sites becomes more predictable, and the DLCIs appear to be more like MAC addressing, with one DLCI per router.
NOTE The use of global Frame Relay addressing does not change how Frame Relay uses local addresses, or the DLCIs in the frames as they pass over the network, and most importantly, routers still only configure and see local DLCIs."
Ts
[ Szerkesztve ]
-
Tsory
tag
válasz zsolti.22 #518 üzenetére
Az LMI type ezek közül lehet valamelyik, IETF nem:
R2(config-if)#frame-relay lmi-type ?
cisco
ansi
q933aA 11.2-es vagy nagyobb verziójú IOS eszközöknél az LMI autosense-es, vagyis megpróbálja automatikusan detektálni a router az FR switch LMI típusát.
Az end-to-end kapcsolatnál érdekes a frame-relay encapsulation típusa. Ez alapból cisco, habár ilyen opció nem látszik a helpben. Ha nem cisco router van a túloldalon, akkor ezt kell ietf-re állítani:
R2(config-if)#encapsulation frame-relay ?
MFR Multilink Frame Relay bundle interface
ietf Use RFC1490/RFC2427 encapsulation
<cr>Ts
-
Tsory
tag
Én máshogy csoportosítanám őket: 2 telephely, több telephely multipoint, több telephely point-to-point. Az alapvető dolgok talán egy pont-pont kapcsolatnál érthetőek meg a legegyszerűbben, hiszen ilyenkor nem kavarnak be az alinterfészek, valamint nincs több DLCI egy porton. Először a DTE-DCE kapcsolatnak kell rendben lennie (helyi router--szolgáltató frame-relay switch), itt működik az LMI. Utána a DTE-DTE kapcsolatnak (router-router kapcsolat), itt lényeges a frame-relay encapsulation. Ezután rendben kell lennie a layer2-layer3 címek összerendelésének, ezt vagy az inverz ARP intézi, vagy mi kézzel veszük fel frame-relay map paranccsal. Ezek nem feltételnül múlnak azon, hogy Cisco eszközökből építkezünk, pl. a frame-relay enkapszulációnak meg kell egyeznie a két oldal között. Ha az egyik oldalon ietf van beállítva, akkor a másik oldalon is azt kell beállítani. Ha az inverz ARP ki van kapcsolva, akkor kézzel kell felvenni a frame-relay map-et, szintén függetlenül az eszköz gyártójától.
Nézzünk egy egyszerű két telephelyes kapcsolatot:
Budapest (192.168.1.1/24) -- DLCI 16 -- FRSW1..FRSW2 -- DLCI 20 -- Debrecen (192.168.1.2/24)
Ha minden automatizmus működik, akkor a kapcsolat így épül fel pl. Budapest oldalról:
Frame-relay encapsulation:
A helyi routeren beállítjuk a soros interface-en a frame-relay enkapszulációt.LMI:
Ha működik az automatikus LMI típus beállítás, akkor lekérjük az FRSW1-től az elérhető PVC-k DLCI-jét. LMI üzenetben megkajuk, hogy a DLCI 16 van számunkra fenntartva.Inverz ARP:
A budapesti router kihirdeti jelenlétét a virtuális áramkörön a 192.168.1.1/24 címének kiküldésével, DLCI 16-al. Debrecen router fogadja ezt az információt és hozzárendeli a kapott 192.168.1.2 IP-címet a helyi DLCI 20 címéhez. Gyakorlatilag hozzá már úgy érkezik a csomag, hogy a 2. rétegbeli cím DLCI 20 lesz benne. Debrecen router is hirdeti saját IP-címét a virtuális áramkörön, vagyis 192.168.1.2/24, DLCI 20 lesz a csomagban. Budapest router ezt úgy kapja meg, hogy 192.168.1.2 IP és DLCI 16 lesz benne. Ezt felveszi a saját frame-relay map táblájába.Hibakeresés:
Layer 1: kábel stb.
Layer 2: Nem egyezik az LMI típusa a szolgáltató FR switchével. Ez pl. észrevehető a show frame-relay lmi parancsból. A Num Status Enq. Sent valamint Num Status msgs Rcvd mezőknek nagyjából együtt kell nőniük, valamint a timeouts értékeknek nem szabad nőniük.
R1#show frame-relay lmi
LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = ANSI
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 122 Num Status msgs Rcvd 122
Num Update Status Rcvd 0 Num Status Timeouts 0
Last Full Status Req 00:00:04 Last Full Status Rcvd 00:13:24Ilyenkor az interfacen kiadott frame-relay lmi-type [cisco | ansi | q933a] paranccsal kell beállítani az LMI típusát.
PVC problémák
A show frame-relay pvc parancs kimenetén látszik a PVC állapota. Ha a hibát a nem megfelelő frame-relay enkaszuláció okozza, akkor azt az encapsulation frame-relay [cisco | ietf] paranccsal változtathatjuk meg.
Ha az inverz ARP nem működik (nem támogatja valamelyik eszköz, vagy ki van kapcsolva), akkor kézzel kell összerendelni a helyi DLCI-ket a távoli IP címekkel. Ez látszik a show frame-relay map kimenetén. A frame-relay map ip ip-cím dlci broadcast paranccsal korrigálhatjuk a problémát.
[ Szerkesztve ]
-
Tsory
tag
válasz zsolti.22 #610 üzenetére
A packet tracer-rel ellentétben a GNS3 magát a hardvert emulálja, ebbe lehet valódi ios-t betölteni. Az emuláció miatt erőforrás igényesebb, de cserébe a hardver közeli parancsok kivételével az összes ios parancsot lehet használni. Pl. én megszoktam a w rövidítést a packet tracerben, és meglepődtem, hogy a GNS3-ban és valódi eszközön ez nem elég, hiszen sokkal több parancs elérhető, így w-vel is több kezdődik, így wr-t kell gépelni. A felhő emulátoron keresztül össze lehet kötni fizikai hardverekkel is.
A GNS3-hoz érdemes az ios-t kitömöríteni pl. winrar-ral, mert így jobban fut vele. Ha betöltesz egy ios-t, akkor érdemes ellenőrizni a minimális követelményeit, amit az ios lapon elhelyezett linkkel könnyen meg tudsz tenni. Pl. Image Name c3745-adventerprisek9-mz.124-15.T14.bin DRAM / Min Flash 256 / 64. A 3700-as routereknél valamiért 16 MB a flash alapértelmezett értéke (legalábbis nálam), ezt át kell állítani legalább 64 MB-re, amit a router konfigurációjánál lehet megváltoztatni. Ezután már rendesen elindul a router. Az összekötéseknél ha manuális módot választasz, akkor meg lehet adni neki konkrétan, hogy melyik portot mivel akarod összekötni.
Szerintem jóval kényelmetlenebb a kezelése a GNS3-nak, mint a packet tracernek, de mivel valódi IOS-t lehet betölteni, ezért több mindenre használható, mint a packet tracer. Az emuláció miatt sok eszköznél nem árt az erős PC alá.
-
Tsory
tag
válasz zsolti.22 #752 üzenetére
Multipoint frame-relay esetén ahhoz, hogy a pingek menjenek, a spoke routereknek tudni kell pingetni egymást. Ehhez tudniuk kell, hogy az azonos alhálózatban lévő másik router merre van. Ehhez fel kell venni kézzel még egy frame-relay map parancsot a spoke routereken.
Pl. R2 192.168.1.2/24 -- DLCI201 -- FRSW --DLCI102 ---- R1 192.168.1.1/24 --- DLCI103 -- FRSW --- DLCI301 --- R3 192.168.1.3/24
Ilyenkor R2-n ki kell adni:
frame-relay map ip 192.168.1.1 201 broadcast
frame-relay map ip 192.168.1.3 201 broadcastR3-n:
frame-relay map ip 192.168.1.1 301 broadcast
frame-relay map ip 192.168.1.2 301 broadcastÍgy egy traceroute parancsnak érdekes kimenete lehet:
R2#traceroute 192.168.1.3
Type escape sequence to abort.
Tracing the route to 192.168.1.31 192.168.1.1 29 msec 28 msec 28 msec
2 192.168.1.3 64 msec * 56msecEkkor már a ping is meni fog.
A routing update-ek általában broadcast vagy multicast forgalommal mennek. Ezt alapból a routerek nem továbbítják. A frame-relay map parancs végén kiadott broadcast kiegészítéssel azonban ezeket a forgalmak is továbbításre kerülnek, így elvileg kiépülhet a szomszédsági viszony is a spoke routerek között, habár ezt ki kellene próbálni.
-
Tsory
tag
válasz sunyijanika #757 üzenetére
Nem csak az update-ek, de a szomszédsági viszony kiépítéséhez szükséges hello csomagok is multicastban mennek ospf és eigrp esetében is, így itt is szükség lehet a broadcast kiegészítésre.
-
Tsory
tag
-
Tsory
tag
válasz zsolti.22 #846 üzenetére
Hát ez érdekes. Én kétszer rendeltem eddig az amazom.com-ról, mert olcsóbb volt mint a uk, és minden gond nélkül megjött. Legutóbbi pl. ez: "CCNP Routing and Switching Official Certification Library (Exams 642-902, 642-813, 642-832) (Certification Guide Series)"
Odom, Wendell; Hardcover;Shipping Method: Standard International Shipping
Items: $100.79
Shipping & Handling: $13.98
------
Total Before Tax: $114.77
Estimated Tax To Be Collected: $0.00
------
Order Total: $114.77Most látom, hogy te kiválasztottad a legolcsóbb megoldást, ahol más az eladó: new_books_today. A 37,79-esből biztosan szállítanak ide is (CCNP Switch).
[ Szerkesztve ]
-
Tsory
tag
Természetesen GNS3-al
"GNS3Vault is offering you labs and scenarios that you can download and use with the GNS3 / Dynamips software. My goal is to have a full range of labs to study for CCNA, CCNP and even CCIE. Besides "full" labs there are also plenty of labs focusing on a single technology like BGP, OSPF, EIGRP,MPLS but also Multicast, RIP and more!"
[ Szerkesztve ]
-
Tsory
tag
A GNS3 edit - preferences - general - terminal settings fülön tudod szabályozni, hogy milyen terminal emulátorral csatlakozzon fel a konzolra. Itt esetleg ki tudsz választani másik programot, de ne felejtsd el megnyomni mellette a use gombot.
A másik megoldás lehet szerintem, hogy a GNS3 könyvtárába megrpóbálod elindítani a putty.exe programot (alapból c:\program files\gns3), és ott állítod be a karakter kódolást.
-
Tsory
tag
A GNS3 a dynamips emulátor programot használja az IOS emulálásához. Több egyéb programot is tartalmaz, de talán a dynamips a legfontosabb. Ezekhez ad egy egységes grafikus felületet. Ha elindítasz rajta egy eszközt, akkor alul a console ablakban kiadott list paranccsal megmutatja, hogy milyen eszköz milyen portokon fut rajta. Itt látható egy console port is, ami alapbeállítások szerint 2000-től indul, de állítható. Ezt a parancssorból kiadott netstat -a -n paranccsal is ellenőrizheted, ekkor látszik, hogy a 2000-es TCP port listen állapotban van. Ezután bármilyen általad kedvelt terminál emulátorral rá tudsz csatlakozni, csak meg kell adni, hogy telnet protokollal kapcsolódjon a 127.0.0.1:2000-re.
Ha már a GNS3 kezelőfelülete dob alul hibát, mielőtt megpróbálnál rácsatlakozni az eszközre, akkor félreértettem, és más lehet a probléma oka.
-
Tsory
tag
Megzavartál az újratelepítettem a gépemet mondatoddal, innen automatikusan a Windowsra asszociáltam .
Windowson c2600-al nekem addig nem látszik a serial port, amíg meg nem nyitom a beállítások ablakát a routernek, és el nem fogadom. Olyannyira nem működik addig, hogy a konzolban sem mutatja, hogy lenne ilyen portja. Ne kérdezd miért. Linux alatt nem tudom, hogyan működik.
[ Szerkesztve ]
-
Tsory
tag
Előtte le is fényképeznek, meg elektronikus aláírás van . A többi hasonló, kapsz egy gépet, aztán hajrá.
Itt vannak róla infók:
https://learningnetwork.cisco.com/community/certifications/ccna/ccna_exam
[ Szerkesztve ]
-
Tsory
tag
Még ezt érdemes megnézni:
-
Tsory
tag
Igen. Tipikusan DHCP relay agent-et kell beállítani az adott VLAN default gateway-én (ip helper-address address). Ez elkapja a broadcast üzenetben küldött DHCPDISCOVER üzenetet, majd unicastban továbbküldi a beállított DHCP szervernek. Ebben a csomagban benne van a relay agent IP-je, innen tudja a DHCP szerver, hogy milyen pool-ból kell címet osztania. Természetesen az adott pool-nak léteznie kell a DHCP szerveren. Gyakorlatlag a relay agent közvetít a DHCP szerver és a kliens között.
[ Szerkesztve ]
-
Tsory
tag
Még mindig azt mondom, hogy az amazon.com-ról kell rendelni, sokkal olcsóbb:
CCNA 640-802 Official Cert Library, Updated, 3rd Edition
Itt kb. 8300 HUF, szállítás eddig nekem 13-15 USD volt, az kb még 3500 HUF, így kb. 11800 HUF-ra jön ki. Bár érdemes egyszerre több könyvet rendelni, úgy jobban megéri.
[ Szerkesztve ]
-
Tsory
tag
Jó lesz ez az akció, de csak náhány napig tart. Az árakat te számoltad ki, vagy látszott a felületen? NMekem kérdéses, hogy az általad kiválasztott két tétel miatt esetleg csak 30% kedvezmény jár, illetve hogy a kedvezményt az eredeti árból számolják-e. Mert úgy már nem olyan jó az ár.
-
Tsory
tag
Bocs, revision numbert akartam írni, de tartom az előző hisszászólásomat. Csak akkor nullázódik le, ha átváltasz transparent módba, vagy megváltoztatod a vtp domain name-et, vagy törlöd a vlan.dat-ot és újraindítod. A Configuration Revision a vlan.dat-ban van, újraindulás után simán felolvassa onnan.
Másrészt különben sincs értelme, hiszen a VTP szinkronban fogja tartani a Configuration Revision numberöket, valamint a vlan adatbázist is, gyakorlatilag ez a működésének az alapja.
[ Szerkesztve ]
-
Tsory
tag
A nagyobb Configuration Revision számú és azonos domain-ban lévő (ha van jelszó, annak is meg kell egyeznie) írja felül a kisebbet. Akkor lehet gond, ha pl. teszthálóból hozol eszközt, nem nézed a Configuration Revision-t és ugyanaz a domain. Ekkor az alacsonyabb Configuration Revision számú eszköz elkéri a magasabb számú eszköz vlan adatbázisát, és azzal felülírja a sajátját.
Ha nincs vtp domain name megadva, akkor nem küldd vtp hirdetéseket a switch. Érdekes még, hogy a client módú eszköz is elmenti a beállításait a vlan.dat-ba (még a vtp mode is ott van client és server esetében), és képes a server adatbázisát felülírni.
[ Szerkesztve ]
-
Tsory
tag
Tuti, ki is próbáltam.
CCNA ICND2 640-816 Official Cert Guide Third Edition
Caveats When Moving Away from Default VTP Configuration
The default behavior of VTP introduces the possibility of problems when first configuring VTP. To see why, consider the following five points about VTP:
■ The default VTP configuration on Cisco switches is VTP server mode with a null domain name.
■ With all default settings, a switch does not send VTP updates, even over trunks, but the switch can be configured with VLANs because it is in server mode.
■ After configuring a domain name, that switch immediately starts sending VTP updates
over all its trunks.
■ If a switch that still has a (default) null domain name receives a VTP update—which
by definition lists a domain name—and no password was used by the sending switch,
the receiving switch starts using that VTP domain name.
■ When the previous step occurs, the switch with the higher VLAN database revision
number causes the switch with the lower revision number to overwrite its VLAN
database.[ Szerkesztve ]
-
Tsory
tag
Kivéve a vlan.dat-ot. Azt külön kell törölni!
An interesting side effect of this process is that when you use a VTP client or server switch in a lab, and you want to remove all the configuration to start with a clean switch, you must issue more than the erase startup-config command. If you only erase the startup-config and reload the switch, the switch remembers all VLAN config and VTP configuration that is instead stored in the vlan.dat file in flash. To remove those configuration details before reloading a switch, you would have to delete the vlan.dat file in flash with a command such as delete flash:vlan.dat.
[ Szerkesztve ]
-
Tsory
tag
Na ez is érdekes:
■ If a switch that still has a (default) null domain name receives a VTP update—which by definition lists a domain name—and no password was used by the sending switch, the receiving switch starts using that VTP domain name.
■ When the previous step occurs, the switch with the higher VLAN database revision number causes the switch with the lower revision number to overwrite its VLAN database.És tényleg így van. Ha kézzel váltasz vtp domain nevet, akkor nullázódik configuration revision number, viszont ha a switch állítja be magának a vtp üzenetből (null domainről vmire), akkor nem változik a configuration revision number! Így is felül lehet vágni a hálózaton lévő vlan-okat.
-
Tsory
tag
válasz FecoGee #1158 üzenetére
Na én is kipróbáltam a dtp-t access porton. Úgy tűnik, mindenkinek igaza van . Amint beállítom access módba a portot, akkor elindul a dtp, mint az őrült, és megpróbálja a túloldalt rávenni, hogy szintén access port legyen. Ezután főbelövi magát.
SW2940(config-if)#switchport mode access
SW2940(config-if)#
00:08:09: DTP-decision:Fa0/5:old NS/NT = 0x01/0x05
../dyntrk/dyntrk_core.c:629
00:08:09: DTP-decision:Fa0/5:Loc/Nbr Comb = 0xDF/0xBF ../dyntrk/dyntrk_core.c:638
00:08:09: DTP-decision:Fa0/5:loc_start = 30, nbr_start = 42, loc_end = 40, nbr_end = 50 ../dyntrk/dyntrk_core.c:695
00:08:09: DTP-decision:Fa0/5:Local Search: ../dyntrk/dyntrk_core.c:703
00:08:09: DTP-decision:Fa0/5:loc_ind = 30, loc_comb_tab = 0xA0, loc_dont_care_tab = 0xE0 ../dyntrk/dyntrk_core.c:710
00:08:09: DTP-decision:Fa0/5:loc_ind
SW2940(config-if)#= 31, loc_comb_tab = 0x84, loc_dont_care_tab = 0xFF ../dyntrk/dyntrk_core.c:710
00:08:09: DTP-decision:Fa0/5:loc_ind = 32, loc_comb_tab = 0xC4, loc_dont_care_tab = 0xFF ../dyntrk/dyntrk_core.c:710
00:08:09: DTP-decision:Fa0/5:loc_ind = 33, loc_comb_tab = 0xE4, loc_dont_care_tab = 0xFF ../dyntrk/dyntrk_core.c:710
00:08:09: DTP-decision:Fa0/5:loc_ind = 34, loc_comb_tab = 0x9F, loc_dont_care_tab = 0xFF ../dyntrk/dyntrk_core.c:710
00:08:09: DTP-decision:Fa0/5:loc_ind = 35, loc_comb_tab = 0xDF, loc_dont_car
SW2940(config-if)#e_tab = 0xFF ../dyntrk/dyntrk_core.c:710
00:08:09: DTP-decision:Fa0/5:Done with Local Search, loc_ind = 5, loc_found = 1 ../dyntrk/dyntrk_core.c:716
00:08:09: DTP-decision:Fa0/5:Neighbor Search: ../dyntrk/dyntrk_core.c:723
00:08:09: DTP-decision:Fa0/5:nbr_ind = 42, nbr_comb_tab = 0x40, nbr_dont_care_tab = 0x67 ../dyntrk/dyntrk_core.c:730
00:08:09: DTP-decision:Fa0/5:nbr_ind = 43, nbr_comb_tab = 0x04, nbr_dont_care_tab = 0x67 ../dyntrk/dyntrk_core.c:730
00:08:09: DTP-decision:Fa0/5:nbr_ind = 44, nbr_co
SW2940(config-if)#mb_tab = 0x07, nbr_dont_care_tab = 0x67 ../dyntrk/dyntrk_core.c:730
00:08:09: DTP-decision:Fa0/5:nbr_ind = 45, nbr_comb_tab = 0x20, nbr_dont_care_tab = 0x60 ../dyntrk/dyntrk_core.c:730
00:08:09: DTP-decision:Fa0/5:Done with Neighbor Search, nbr_ind = 45, nbr_found = 1 ../dyntrk/dyntrk_core.c:735
00:08:09: DTP-decision:Fa0/5:tos_map = 0x00007FE0 ../dyntrk/dyntrk_core.c:749
00:08:09: DTP-decision:Fa0/5:tot_map = 0x00000000 ../dyntrk/dyntrk_core.c:750
00:08:09: DTP-decision:Fa0/5:tos_mask = 0x0400 ../dyn
SW2940(config-if)#trk/dyntrk_core.c:760
00:08:09: DTP-decision:Fa0/5:tot_mask = 0x00300000 ../dyntrk/dyntrk_core.c:761
00:08:09: DTP-decision:Fa0/5:tot_result = 0x00000000 ../dyntrk/dyntrk_core.c:768
00:08:09: DTP-state:Fa0/5:Starting state transition from state S6:TRUNK, event 3a:CFG TO ACC ../dyntrk/dyntrk_fsm.c:631
00:08:09: DTP-state:Fa0/5:Executing action 5 ../dyntrk/dyntrk_fsm.c:756
00:08:09: DTP-timer:Fa0/5:Stopping access timer ../dyntrk/dyntrk_process.c:1812
00:08:09: DTP-pkt:Fa0/5:Sending packet ../dyntrk/dy
SW2940(config-if)#ntrk_process.c:1235
00:08:09: DTP-pkt:Fa0/5: TOS/TAS = ACCESS/OFF ../dyntrk/dyntrk_process.c:1238
00:08:09: DTP-pkt:Fa0/5: TOT/TAT = 802.1Q/802.1Q ../dyntrk/dyntrk_process.c:1241
00:08:09: DTP-pkt:Fa0/5:datagram_out ../dyntrk/dyntrk_process.c:1273
00:08:09: DTP-timer:Fa0/5:Starting negotiation timer on interface FastEthernet0/5 ../dyntrk/dyntrk_process.c:1766
00:08:09: DTP-timer:Fa0/5:Starting hello timer on interface FastEthernet0/5 ../dyntrk/dyntrk_process.c:1736
00:08:09: DTP-state:Fa0/5:Ending
SW2940(config-if)#state transition to state S5:T-DTP ../dyntrk/dyntrk_fsm.c:659
00:08:09: DTP-state:Fa0/5:Starting state transition from state S5:T-DTP, event 1:IF DOWN ../dyntrk/dyntrk_fsm.c:631
00:08:09: DTP-state:Fa0/5:Executing action 1 ../dyntrk/dyntrk_fsm.c:680
00:08:09: DTP-state:Fa0/5:Ending state transition to state S1:OFF ../dyntrk/dyntrk_fsm.c:659[ Szerkesztve ]
-
Tsory
tag
válasz FecoGee #1251 üzenetére
Arra gondoltam, hogy ha több switch van felfűzve egymás után, akkor mi történik.Pl. SW1-SW2-SW3-SW4-SW5 esetében tegyük fel, hogy a 100-as vlan csak SW1 és SW5 switcheken létezik. Ebben az esetben SW2, SW3, SW4 switcheknek nem szabad pruningolni a 100-as vlant, hiszen akkor a két szélső switchen lévő 100-as vlanba tartozó eszközök nem tudnának kommunikálni egymással. Ebben az esetben hogyan működik a vlan pruning?
RSS megjavult .
-
Tsory
tag
Az első mondattal egy kicsit vitatkoznék. Az OSPF-nél is ugyanúgy kettős szerepe van a network parancsnak, mint a többi IGP esetében:
1. Meghatározza azokat az interfészeket, amelyeken engedélyezett az OSPF csomagok küldése és fogadása.
2. Azonosítja azokat a hálózatokat, amelyeket az OSPF irányítási frissítéseinek tartalmaznia kell.Az elsőt szükség esetén a passive-interface-el le lehet tiltani.
-
Tsory
tag
Átfogalmazom, mert úgy tűnik, hogy elbeszélünk egymás mellett.
1. A network parancs meghatározza azokat az interface-eket, amelyeket az adott IGP küdhet és fogadhat csomagokat.
2. Ezeknek az interface-eknek a hálózatait fogja hirdetni.A passive-interface ok, pont olyan interface-en lehet jó, aminek a hálózatát hirdetni akarom, de abban az irányban nincs másik IGP-t futtató eszköz.
Tehát a network parancs nem azt a hálózatot adja meg, ami közvetlenül hirdetésre kerül, hanem azt az interface-t, aminek a hálózata hirdetésre kerül. Így értem, hogy megadja a hirdetésre kerülő hálózatot.
-
Tsory
tag
EIGRP-nél bárhol adhatsz summary route-ot packet tracerben is:
Router(config-if)#ip summary-address eigrp 1 ?
A.B.C.D IP addressOSPF-nél tudtommal csak area határon lehet ilyet tenni. Az OSPF ASBR eszköz forgalomirányító konfigurációs üzemmódjában az alábbi parancs segítségével konfigurálható összevont útvonal:
area terület-azonosító range IP-cím maszk
Na ilyet nem találtam a packet tracerben. De CCNA anyagban csak single area OSPF szerepel, és packet tracer ehhez készült.
[ Szerkesztve ]
Ú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!