Elvileg igen, a részleteket nem ismerem. Elvileg egy virtuális ip-n van több router, és ezt a virtuális ip-t "birtokolja" valamelyik eszköz. FecoGee?

[ Szerkesztve ]

Csak mert jó lenne előre tudni, hogy konfiguráljam a routert. Nem szeretném azt, hogy a végefelé újra át kéne állítani, mert mégse úgy kell mint ahogy terveztem.
Egyenlőre cska az egyik interfészt fogom subinterfészekkel ellátni az switch felé. A másikat addig nem fogom bántani, míg rá nem jövök hogy kell.

If you chase two rabbits you will lose them both.

Hirdetnek egy virtuális IP-t, és azt kell beállítani a klienseknél gateway-nek. Pl. két router(192.168.1.2 és 192.168.1.3) hirdeti HSRP-vel a 192.168.1.1-et, amelyet beállítasz a klienseknek. Az egyik routered active, a másik standby. Ha az active kiesik, a standby automatikusan active lesz, így biztosítva redundanciát.

[ Szerkesztve ]

És ez hogy működik össze a subinterfészekkel? Ott is csak 1 virtuális ip lesz és majd a router eldönti melyik csomag hova megy?

If you chase two rabbits you will lose them both.

Ez mind szép és jó, de egy packet tracerben ezt elég nehéz lesz szimulálnia. - layer 3 switchek nélkül.

Igen, ez a jó kérdés, hogy ezt packet tracerben routerral L2 switchekkel hogy oldom meg?
Legegyszerűbb lenne kiszedni egy switchet. De ha van megoldás rá, ne tartsátok vissza.

If you chase two rabbits you will lose them both.

Asajnos a packet tracer nem tudja ezeket: First Hop Redundancy Protocols (HSRP, VRRP, GLBP).

Amúgy van a packet tracerben multilayer switch is (WS-C3560-24PS), de ez most nem releváns.

[ Szerkesztve ]

Akkor hogy tudom megoldani, hogy a fenti ábrán mind a 2 switch működjön normálisan?

If you chase two rabbits you will lose them both.

Szerintem felejtsd el a redundanciát. valós környezetben egy nagyon jó és hasznos dolog, de packet-ben ez sehogy nem fog működni. esetleg GNS3-mal lehetne próbálkozni, de ennyi eszközhöz erős gép fog kelleni (és még akkor is macerás).

Most akkor álljak vissza az eredeti, redundancia nélküli verzióra? Esetleg hagyjak bent 1 switchet a router és a többi switch között? Mert akkor legalább a vtp-nek van értelme.

If you chase two rabbits you will lose them both.

Jobb lesz, ha vissza állsz, mert persze a mostani sokkal jobban néz ki és több értelme is lenne, de sajnos packettel hiába is próbálkoznál.. vtp attól maradhat persze, ha szeretnéd, bár egy ilyen szintű hálózathoz nem feltétlenül szükséges.

Layer 2 redundanciát tudsz benne kialakítani STP-vel, ez is több a semminél.

Teljesen jogos, elnézést, én a valós életbeli megoldást néztem. Packet Tracerben valóban nem tudod ezeket kipróbálni. GNS3-mal igen.
Szerintem attól még csinálj két disztribúciót, hogy megalább link szakadás esetén védve legyél a disztribúció és az access között. A Spanning Tree majd szépen blokkolja az egyiket, de ha gáz van, átáll. Javaslom továbbá az uplinkfast bekapcsolását az access switcheken - bár nem tudom, hogy PT-ben ez támogatott -e.

Valami ilyesmit kellene csinálni (a való életben):

Két bérelt vonal, disztribúciós switchek (itt route-lni a VLAN-okat), access switchek redundánsan a disztrikre kötve.

Nem tud uplinkfastot, csak portfastot.

Értem, köszönöm!
Szerintem packet tracerrel csak a network diagramot kellene lerajzolni és ha lehet GNS3-mal a routereket és igazi switcheken a switchinget felhúzni konfignak. Nem tudom van -e rá lehetőség a szakdolgozat írójának. Bár ha már csak rajzolás, akkor inkább Visio.

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 ]

Igen, ezt én is észrevettem, de azt hittem pont belefogtam az update-ba ami 30 mp-ként fut.

Fene a ciscoba. Ha már kiad egy szimulátort mi a fenéért nem tölti rá a teljes IOS-t? Miért kell letiltani funkciókat? Hogy tanuljon így az ember. Vagy elvárják, hogy aki tanulni akar az is vegyen otthonra 3-4 routert meg ugyanennyi switchet?

Azt hogy lehet megcsinálni, hogy az distrib layerben lévő switcheket kötöm össze egymással, pl két épületben lévőt egy külön kábellel, hogy ha valaki kapával neki esik a core switch és a distrib közötti kábelnek, akkor küldje át az adatot a másik switchen keresztül?
Vagy ilyenkor ha lehal akkor a másik felél broadcastol egyet, hogy tudja-e a címet a gw felé (mivel annak a switchnek is ugyanaz)?

(ma sok a meló fene enné meg, nem nagyon fogok tudni foglalkozni a hálóval )

If you chase two rabbits you will lose them both.

Gondolom azért mert CCNA-hoz készült. CCNP-hez pedig már kell a valós eszköz úgyis.

Neked most collapsed core architektúrád volt: a core és disztribúciós réteget összevontad. Ezzel semmi gond, mert nem akkora a hálózat, hogy kelljen. Amit küldtem tegnap, az alapján redundáns minden. Ha lenne külön core és disztri réteged, minden disztribúciót mindkét core-ra rá kell kötnöd.

nem egeszen igy mukodik a dolog nem tiltottak le benne semmit, mert nem az eredeti ios-t futtatja, hanem irtak egy szimulatort ami hasonlit az ios-re es adtak neki nehany funkciot.

Csak semmiképpen sem akarok L3 switchet a hálózatba. 1 router a többi mind L2.
Azon gondolkodtam, hogy a routerből megy 1 vonal a switch felé, majd abból ágazik el, hogy a vtp-nek legyen értelme. Vagy vissza az eredetihez, egyből megy minden a routerbe. Viszont akkor nincs redundancia.

If you chase two rabbits you will lose them both.

Es ha az a switch meghal vagy a link leesik akkor nem lesz senkinek halozata. Miert vagy ennyire ellene a L3 switchnek?

Drága
Amúgy azért, mert nem terveztem be. De ha ennyire mondjátok, lehet beteszem mostmár a tervbe azt a két L3-ast. Csak akkor meg minek router? L3 switch gyakorlatilag minden tulajdonsággal rendelkezik, amivel egy router.

If you chase two rabbits you will lose them both.

Azert nem... Pl. nem tud NAT-olni.

Napi kép. Ezt a héten szedtem ki a hálózatból. Nem romlott el, csak lecseréltük. Egy régi Catalyst. Majdnem 13 (!) évig teljesített szolgálatot. Azt hiszem megérdemli a tiszteletet!

Meg lehet változtatni a vtp domain nevet anélkül, hogy egyesével kelljen felülírnom a switcheken?

If you chase two rabbits you will lose them both.

nem hiszem. ha meg nem volt beallitva domain akkor megtanulja a masiktol, de ha mar be volt allitva valami, akkor nem.

Valaki korábban lehurrogott, hogy nincs CCNA Securityn írásbeli rész, pedig a Cisco honlapján ki is van írva, hogy van, volt és lesz is.

[ Szerkesztve ]

Nem lehet.

Nem ugy van mint a CCNA R/S hogy vizsgaprogramban kell kattogatni?

Engem a Written Exam Topics arra enged következtetni, hogy beza van írásbeli.

[ Szerkesztve ]

Megjöttek a CCIE laborhoz az eszközök:

Nem ám, csaak költözés volt

Egy percig sem hittem, hogy újonnan vettél ilyen eszközöket Nálunk is fel lettek bontva a szviccsek és a dobozaik szét lettek osztva, mert költözéshez jók

Nemsokára megérkeznek a CCNP további könyvek, már köln-ben szunyáznak, tlaán ideérnek holnapra, vagy szerdára

[ Szerkesztve ]

C3500XL POST FAILURE: Testing Switch Core: Failed
C3500XL POST FAILURE: Testing Buffer Table: Failed
C3500XL POST FAILURE: Data Buffer Test: Failed
C3500XL POST FAILURE: Configuring Switch Parameters: Failed
C3500XL POST FAILURE: Switch Core BIST failed.
C3500XL POST FAILURE: Cannot test Modules due to failure of Switch Core POST
Del Mar Failure (0th Del Mar): req system failed to init
C3500XL POST FAILURE:
C3500XL POST FAILURE: ATM: required system failed to init
C3500XL POST: Ethernet Controller Test: Passed
C3500XL POST FAILURE: MII Test: Failed
C3500XL POST FAILURE: Error waiting for Ethernet Controller and SW_PARAMS
C3500XL POST FAILURE: Initialization/POST failed
C3500XL POST FAILURE: AT: Failing because system POST failed
Exception (8192)! Debug Exception (Could be NULL pointer dereference)

Ez eléggé HW hibának tűnik..
Vagy?
Szerintetek?

Létezik az, hogy szerver felé trunk port használható? mert eddig úgy tudtam, za cska a switchek között van.

Az a szitu, hogy nekünk teaminget kell konfigolni egy szerveren, hogy több gigabites adatforgalmat tudjon kezelni. De a network teamtól kapott válasz furcsa, legalábbis nekem.
Azt írja, hogy a network portok pre-konfigurálása trunkra hálózati kiesést fog okozni, míg nincs megfelelően konfigurálva bounding módra.

"pre-configuring the network ports as a trunk will disable the ports until it is properly configured for bonding mode."

Számítógépek felé nem csak access port lehetséges?

If you chase two rabbits you will lose them both.

VMwaren pl. tudsz létrehozni vlan-okat a virtuális switchen és ahhoz hogy egy fizikai szervert azonos vlan-ba tegyél egy virtuális szerverrel a fizikai switchen a portot trunk-re kell állítani. Így gyakorlatilag a VMware-ben lévő virtuális switchet kötöd össze a fizikai Cisco switcheddel.

If it is not broken then don't fix it!

Fizikai szerver, nincs virtualizáció rajta.

If you chase two rabbits you will lose them both.

letezik.

Persze, pl. BladeCenter felé sokszor kell trunk.

Nekem hardverhibának tűnik. A 3500XL elég régi széria már, megszolgálta a magáét.

Megvan. Port channel.

If you chase two rabbits you will lose them both.

Nekem is annak.
Igen, nem mai gyerek a kicsike.

Van tippetek, ki tudná javítani?

Sajnos nem tudom, mi mindig RMA-zunk ha még lehet.

Igen, de port-channelben is tudsz trunk-öt csinálni, és ott allowed vlan-okat megadni.

Napi kép.
Van rajta link!

VTP PRUNING - MÉLYVÍZ - HUNCISCOBLOG.WORDPRESS.COM

VTP Pruning. Gondolkoztatok már a pontos működésén? Én CCNP SWITCH-ből annyit tudok, hogy egymás közt “megbeszélik” a switchek, mely VLAN-ban nincs portjuk, és ezért oda nem kell továbbítani a broadcastot / unknown unicastot / unknown multicast-ot.

Menjünk bele kicsit bővebben!

Legyenek adottak az alábbi VLAN-ok:

LABSW#sh vl b

VLAN Name
---- --------------------------------
1 default
10 VLAN10
800 LAB-OFFICE
801 LAB-SERVERFARM
802 LAB-WIFI
803 LAB-VOICE
804 LAB-TELEPRESENCE
900 LAB-TRANSIT
1002 fddi-default
1003 trcrf-default
1004 fddinet-default
1005 trbrf-default

Két switchünk van összekötve, trunk van közöttük. Az access-nek a 800, 802, 803-as VLAN-okban van portja. A disztribúciónak mindben, kivéve a 10-est.

LABSWDS#sh vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : LAB
VTP Pruning Mode : Enabled
VTP Traps Generation : Enabled
Device ID : 0817.35d8.9800
Configuration last modified by 10.10.202.2 at 9-26-11 08:00:43
Local updater ID is 10.10.202.2 on interface Vl800 (lowest numbered VLAN interface found)

Feature VLAN:
--------------
VTP Operating Mode : Server
Maximum VLANs supported locally : 1005
Number of existing VLANs : 12
Configuration Revision : 13
MD5 digest : 0xE4 0x35 0xE5 0x50 0xA7 0xF0 0xBA 0xC5
0x57 0xDA 0x8D 0x45 0x34 0x67 0x1A 0x80

LABSWDS#sh cdp ne
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

LABSW
Gig 1/0/8 ........ WS-C2960- Gig 0/1

Nézzük a disztribúció pruning-jét.

LABSW#sh int gi1/0/8 pruning
Port Vlans pruned for lack of request by neighbor
Gi1/0/8 10,802,804,900

Port Vlan traffic requested of neighbor
Gi1/0/8 1,800-804,900

Na ez ám az érdekes! Mit jelent a két paraméter: lack of request by neighbor és Vlan traffic requested of neighbor?

Vlans pruned for lack of request by neighbor

Ez azt jelenti, hogy a szomszédos switch ezeket a VLAN-okat jelölte meg pruning-ra a lack of request beállításával a VTP-ben

Vlan traffic requested of neighbor

Ez azt jelenti, hogy a switch, amelyen éppen vagyunk, mely VLAN-okat használja, azaz nem prune-olható.

Esetünkben tehát a szomszéd switch szerint prune-olható a 10, 802, 804, 900-as VLAN. Ez azt jelenti, hogy a másik switchen ha megnézzük a VLAN traffic requested of neighbor mezőt, ott azokat a VLAN-okat kell látnunk, amelyek az összes VLAN és a pruned VLAN-ok metszete. Tehát ha az összes VLAN-ból kivonjuk a prune listát, akkor megkapjuk ezt az értéket. Tehát:

Összes VLAN: 1, 10, 800, 801, 802, 803, 804, 900.

Ebből pruning-ra jelölve (ezt látjuk a disztribúción): 10, 802, 804, 900.

Ebből következik, hogy azon a switchen a kettő különbözete aktív, tehát: 1, 800, 801, 803.

Nézzük!

LABSW#sh int gi0/1 pruning

Port Vlans pruned for lack of request by neighbor
Gi0/1 10

Port Vlan traffic requested of neighbor
Gi0/1 1,800-801,803

És igen! Látható, hogy azokat jelöli használtnak. Itt a disztribúció által pruning-ra jelölt VLAN-okat is látjuk, amely jelen esetben a 10-es.

Összes VLAN: 1, 10, 800, 801, 802, 803, 804, 900.

Ebből pruning-ra jelölve (ezt látjuk a disztribúción): 10.

Ebből következik, hogy azon a switchen a kettő különbözete aktív, tehát: 1, 800, 801, 802, 803, 804, 900.

Nézzük ismét:

LABSW#sh int gi1/0/8 pruning
Port Vlans pruned for lack of request by neighbor
Gi1/0/8 10,802,804,900

Port Vlan traffic requested of neighbor Gi1/0/8 1,800-804,900

[ Szerkesztve ]

Több switch esetében ez az info hogyan megy végig a hálózaton? A VTP csomagok hogyan néznek ki ilyenkor?

Nem frissül az RSS a blogodon .