Keresés

Hirdetés

Új hozzászólás Aktív témák

  • soma314

    tag

    válasz donatel #12205 üzenetére

    A packetracer egy szimulátor, ami csak azt tudja, amit beállitzottak neki.
    A rommon egy elég hardver közeli dolog, még GNS3-al, vagy IOU-val sem tudod elérni.
    Ehhez szerintem csak a valódi harver a megoldás.
    "Fillérekért" kapni ma már egy olyan 2600-os routert vagy pláne egy 2950-es switch-et amin ezeket lehet gyakorlolgatni.

  • soma314

    tag

    válasz zsolti.22 #12251 üzenetére

    miután defaultba tettem az interfészt show run all-ra ez látszik:

    interface FastEthernet0/20
    switchport
    switchport access vlan 1
    switchport trunk encapsulation negotiate

    no switchport nonegotiate
    no switchport protected
    no switchport block multicast
    no switchport block unicast
    no ip arp inspection trust
    ip arp inspection limit rate 15 burst interval 1
    ip arp inspection limit rate 15
    no shutdown
    power inline consumption 15400
    power inline auto max 15400
    mls qos cos 0
    snmp trap mac-notification change added
    snmp trap mac-notification change removed
    snmp trap link-status
    cdp tlv location
    cdp tlv server-location
    cdp tlv app
    spanning-tree port-priority 3
    spanning-tree cost 3
    ip igmp snooping tcn flood

    Igaz nem 15-ös IOS van rajta, hanem csak 12.2

    Összedugtam egy másik 3560-assal, amin szintén default-ba raktam a csatlakozó interfészt

    show int switchport-ra:
    Name: Fa0/12
    Switchport: Enabled
    Administrative Mode: dynamic auto
    Operational Mode: static access
    Administrative Trunking Encapsulation: negotiate
    Operational Trunking Encapsulation: native
    Negotiation of Trunking: On
    Access Mode VLAN: 1 (default)
    Trunking Native Mode VLAN: 1 (default)
    Administrative Native VLAN tagging: enabled
    Voice VLAN: none
    Administrative private-vlan host-association: none
    Administrative private-vlan mapping: none
    Administrative private-vlan trunk native VLAN: none
    Administrative private-vlan trunk Native VLAN tagging: enabled
    Administrative private-vlan trunk encapsulation: dot1q
    Administrative private-vlan trunk normal VLANs: none
    Administrative private-vlan trunk associations: none
    Administrative private-vlan trunk mappings: none
    Operational private-vlan: none
    Trunking VLANs Enabled: ALL
    Pruning VLANs Enabled: 2-1001
    Capture Mode Disabled
    Capture VLANs Allowed: ALL

    látszik, hogy access, de ha az egyik oldalon ha beállitom a trunk módot encapsulation megadása nélkül:

    SW_3560_3(config-if)#switchport mode trunk
    Command rejected: An interface whose trunk encapsulation is "Auto" can not be configured to "trunk" mode.

    Érdekes lenne IOS 15-el is kipróbálni!

    A neten viszont olvasni olyat, hogy a 15-ös IOS-el IOU alatt már trunk mód lesz ISL encapsulation-nel.

    [ Szerkesztve ]

  • soma314

    tag

    válasz soma314 #12257 üzenetére

    ja egyébként találtam egy video-t, ahol "rommod"-ba lépnek packetracer-ben control+break segitségével.

    https://www.youtube.com/watch?v=k2fvp1bPvUc

    Kipróbáltam és simán ment (nálam notebook-on ctrl+fn+pause) billentyűkkel

    Persze ez nem igazi rommod, ahogy a packet tracer-ben semmi sem igazi

    [ Szerkesztve ]

  • soma314

    tag

    válasz FecoGee #12260 üzenetére

    valóban nem kérte. a végeredmény egy switchport mode dynamic desireable - switchport mode dynamic auto-n ISL lett IOS 12.2-vel

    SW_3560_4(config-if)#switchport mode dynamic desirable

    SW_3560_4#show int switchport | b 0/12
    Name: Fa0/12
    Switchport: Enabled
    Administrative Mode: dynamic desirable
    Operational Mode: trunk
    Administrative Trunking Encapsulation: negotiate
    Operational Trunking Encapsulation: isl
    Negotiation of Trunking: On
    ...

    Ami még mindig nem nyugtatott meg abban, hogy IOS 15-nél nem lesz-e a végeredmény dot1q?

    Lehet felküzdöm az IOS 15-öt az egyik nap. Mivel nincs 32 Megás flash-em, ezért xmodem-el két switchre elég küzdelmes, de lehet rászánom magam.
    Én mindig úgy vagyok vele, hogy a hardver úgyis jobban tudja nálam :) Amit lehet kipróbálom, ami kicsit lassú tanulási módszernek tűnik, de általában nagyobb eséllyel jegyzem meg azt amit kilaborozok, mint azt amit olvasok.

  • soma314

    tag

    válasz FecoGee #12294 üzenetére

    Egy időben úgy tudom, hogy hozzáférhető volt a csr1000v image tanulásra. Aktíválás nélkül a troughput-ja nem teszi alkalmassá produktív használatra.

    Ehhez kell még építeni egy baremetal hyperviser-t, amihez oprendszernek szintén tanulásra ingyenesen hozzáférhető a vmware ESX 32 Gygabyte-ig, ami kell is.

    Szóval kell egy servert építeni 4 magos intel procival (nem feltétlenül kell nagy teljesítmény, tehát nem csak cor i5 vagy i 7 lehet hanem régebbi xeon-ok is) 32 Giga rammal és ez elvileg alkalmas vagy 10 cloud service router futtatására minden feature-el.

    Az INE laborja is ilyenekből áll.

    Ezzel ugye nincs megoldva a switch kérdés. Ma már azonban emberi áron hozzá lehet jutni egy Catalyst 3560-hoz 12-es IOS-el.

    15-ös IOS-t azért a legtöbbre csak azért nem lehet feltölteni, mert nincs hozzá 32 mega flash.
    Hát eddigi tapasztalataim alapján a CCIE 5.1-nél (erre készülök) tul sog dolog nincs, amit 12-es IOS-el ne lehetne switch oldalon kipróbálni.

    Ahhoz a kevéshez, ami kell van egy lehetőség: 15-ös IOS-t fel lehet rájuk tölteni xmodel-el.
    Először érdemes a konzol sebességét a maxra állítani rommod módból (115200-as boud-ra) és utána próbálkozni. Így is egy jó 15 perc mire felmegy. Ez macerás, pláne 4 switchre feltölteni, de azon feauter-ök gyakorlására meg lehet tenni egyszer és bekapcsolva hagyni egy hátvégére a switch-eket. (Szünetmentes táp nem baj ha van.)

    Én egyébként pont Feco honlapjáról értesültem a Cisco dcloud-ról, ami ugye full free és remek.
    Nincs sajnos legális módja az IOL-nek, de állítólag az meg világbajnok, de a fent leírtakat nézzük akkor munka oldalról kell bele időt fektetni, de anyagilag mondjuk 2-300 eFt-ből össze éehet rakni egy CCIE R&S-re alkalmas labort.
    Ez a CCIE vizsgadíjakhoz + utazási költség képest semmi.

    Lehet online laborokat bérelni szép számmal (pl. INE), sőt érdemes hybrid megoldásokban is gondolkodni:
    - valós hardver + GNS3 + bérelt labor

    Szóval szerintem még Cisco esetén a legjobb a helyzet, ha a többi gyártót nézzük.
    Pl. Alcatel-Lucent vagy Juniper -rt szintén lehet virtuális gépként futtatni, akár GNS3-ba ágyazva is, de nem mindegy, hogy a dynamips a hypervisor vagy a virtualbox. Ez utóbbiakhoz lényegesen több erőforrás kell, ha sok eszközt futtatunk.

    Ez az (egyik) bajom a VIRL-el is, mármint hogy bár nem ingyenes megoldás, mégis erőgép kell hozzá.

  • soma314

    tag

    válasz soma314 #12300 üzenetére

    egy hasznos link, ahol ezek jól össze vannak foglalva: http://labs.ine.com/workbook/view/rs-v5-workbook/task/ines-ccie-r-s-v5-hardware-topology-MjU1NA%3D%3D

  • soma314

    tag

    válasz TheProb #12313 üzenetére

    van
    rommon módban elindítod és ott van rá lehetőség a set BAUD paranccsal

    [ Szerkesztve ]

  • soma314

    tag

    válasz FecoGee #12264 üzenetére

    Kipróbáltam IOS 15-el és a gyakorlat igazolta amit irtál:

    amíg sima default-ban vannak összekötve, akkor az eredmény:

    SW_3560_4#show interfaces fa 0/12 switchport
    Name: Fa0/12
    Switchport: Enabled
    Administrative Mode: dynamic auto
    Operational Mode: static access
    Administrative Trunking Encapsulation: negotiate
    Operational Trunking Encapsulation: native
    Negotiation of Trunking: On

    Ha az egyik oldalon átállitom dynamic desirable-re, akkor meglesz a trunk ISL-el:

    SW_3560_3(config-if)#do sh int fa 0/12 swi
    Name: Fa0/12
    Switchport: Enabled
    Administrative Mode: dynamic desirable
    Operational Mode: trunk
    Administrative Trunking Encapsulation: negotiate
    Operational Trunking Encapsulation: isl
    Negotiation of Trunking: On
    Access Mode VLAN: 1 (default)

    a platform és IOS:
    Cisco IOS Software, C3560 Software (C3560-IPBASEK9-M), Version 15.0(1)SE3,

    [ Szerkesztve ]

  • soma314

    tag

    válasz TheProb #12321 üzenetére

    hogy ne lehetne értelme, nem csak az eszközön belül tudsz route-olni a vlan-ek között
    erre keress rá: router on a stick

    Amúgy el tudok képzelni olyan speciális helyzetet is, amikor egy hairpin-el van összekötve két vlan (egy olyan kábellel, ami kijön az switch egyik vlan-jéhez hozzárendelt portjából és egy másik vlan-hez rendelt porthoz megy). Az is lehet, hogy ez a link pedig csak ideiglenesen van bekapcsolva.

    De igazából te tudod mire van szükséged!

  • soma314

    tag

    válasz tusi_ #12322 üzenetére

    hogyan megy 2960-assal az intervlan routing? (az sem multilayer switch)

    az ok, hogy éppen RSTP fut mondjuk, de ha később valaki STP-re kapcsolja? Azért szerintem mindig jó, ha ezek a best practice-ok be vannak konfigurálva.

    A storm kontrollnál az adott szitu és tapasztalat alapján lehet belőni mi az amit megengedsz még. Én például találkoztam olyan sajátos szoftver megoldással, ami a broadcast-ra címez, így a rendszer "normál" üzemében sem elhanyagolható a broadcast forgalom!

    Ezért is szokták ajánlani baseline forgalom elemzés felvételét.

  • soma314

    tag

    válasz tusi_ #12322 üzenetére

    meg is találtam a kérdésemre a választ: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_55_se/configuration/guide/scg_2960/swipstatrout.html

    statikus route-olást tud SVI-vel vlan-ek között

  • soma314

    tag

    válasz FecoGee #12328 üzenetére

    én nem Cisco eszközöknél láttam hasonlót, ahol RSTP futott volna, ha fut, nem PVRSTP+

  • soma314

    tag

    válasz TheProb #12329 üzenetére

    van egy sokkal egyszerűbb módszer is, bizonyos szempontból még professzionálisabb is, mint a router on a stick subinterface-ekkel és az asus routereddel simán meg tudod csinálni:

    a routered egyik interfészét a switch egyik vlan-hez tartozó portjához csatlakoztatod, a másikat a másikhoz. Ezután a routeren kersztül már átjárható két vlan között az adatforgalom.

    (attól professzionálisabb, hogy a router on a stick esetén a sávszélességet lefelezed azzal, hogy oda-vissza azonos linken megy minden)

    [ Szerkesztve ]

  • soma314

    tag

    válasz tusi_ #12327 üzenetére

    hát attól, hogy utólag kirúgnak valakit az nem előz meg egy rendszer leállást :)

    ilyen alapon lehetne azt is tenni, hogy jól leirjuk egy szabályzatban, hogy aki jogosulatlanul köt rá egy eszközt a hálózatra azt kirúgjuk
    és már nem is kell a vtp módot transparensre állitani, minek a port security a passive interfész beállitások, a dhcp snooping...

    Nekem ez új volt. Ipari Cisco switcheknél nézegettem a statikus route-olás lehetőségét, de a 2960-ból nem néztem ki!

    Mindig tanul az ember :R

    [ Szerkesztve ]

  • soma314

    tag

    válasz FecoGee #12335 üzenetére

    elég életszerű példa: Hirschmann RS20 ipari switch, elején két dip kapcsoló, ha ezeket átkapcsolod üzem közben lekapcsol a switchen futó spanning tree flavor (akár RSTP, akár MST futott). Persze ez nem ugyanaz, mint PVRSTP+-ról PVSTP+-ra átváltani és persze ez nem Cisco és nem is irodai környezet, de a dolog lényege valódi kritikus rendelkezésre állású rendszereknél, hogy "mindenre számits" ezért is kell szerintem a best practice-hez ragaszkodni a konfigurációnál

    ahogy az uplink fast-nek nincs jelentősége rapid vagy multiple spanning-tree-nél, de ennek bekapcsolása semmi hátránnyal nem jár

    egyébként az már inkább elgondolkodtató, hogy mivel az RSTP kompatibilis az STP-vel, miért nem az a eleve a default egy 2950-esnél , meg sok másik switch-nél

    [ Szerkesztve ]

  • soma314

    tag

    válasz FecoGee #12334 üzenetére

    abban az esetben nem csak azért mert a Cisco sajátja a perVlan technológia

    egyébként az MST óta nem látom a perVlan létjogosultságát, úgyis bármilyan topológiád van max 3 instance-el tudod az ideális rendelkezésre állást biztositani

    akárhány switch-et kötsz össze akárhánnyal max 3-as szegmensekből áll, ezért nincs értelme 3 külön stp-nél többel terhelni a switch-eket

  • soma314

    tag

    válasz tusi_ #12333 üzenetére

    kifejezetten rendszer gazdák ellen találták ki a root guard-ot :) nem a végfelhasználók ellen

  • soma314

    tag

    válasz FecoGee #12335 üzenetére

    eszembe jutott egy életszerű példa: rapid-ról fejleszt a rendszer multiple-ra
    közben még talán az is előfordulhat, hogy legacy stp-be esek egyik másik link, de ezt végig kéne gondolni

  • soma314

    tag

    válasz FecoGee #12335 üzenetére

    egyébként ha a per vlan rapid spt-t futtató port a másik oldalon legacy stp-re talál, akkor pvstp+-ban üzemel tovább ha jól emlékszem (már rég próbáltam) ?

    tehát, ha van egy switch csere, és betolnak egy default konfigurációjó switch-et egy meghibásodott helyére, mert sürget az idő, akkor a kapcsolodó switch a linken nem rapid-ban fog menni, hanem legacy-ban, amig az új switchen nem aktiválják a rapid-ot

  • soma314

    tag

    válasz soma314 #12340 üzenetére

    kipróbáltam: rossz elgondolás volt
    az rapid oldal ugyan kívülről nézve stp-re esik vissza, de uplinkfast szempontjából, azaz abból, hogy ha kiesik a root port és van alternative, akkor rögtön átvált nem változik

  • soma314

    tag

    válasz FecoGee #12328 üzenetére

    kipróbáltam a hairpin-t egy 3750-esen bekapcsolt STP-vel
    nem estek a portjai blocking state-be:

    konfiguráció

    SW_3750_1#sh run int fa 1/0/1
    Building configuration...

    Current configuration : 35 bytes
    !
    interface FastEthernet1/0/1
    end

    SW_3750_1#sh run int fa 1/0/17
    Building configuration...

    Current configuration : 86 bytes
    !
    interface FastEthernet1/0/17
    switchport access vlan 2
    switchport mode access
    end

    STP output:
    SW_3750_1#sh spanning-tree

    VLAN0001
    Spanning tree enabled protocol ieee
    Root ID Priority 32769
    Address 0023.3426.5780
    This bridge is the root
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

    Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
    Address 0023.3426.5780
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
    Aging Time 300 sec

    Interface Role Sts Cost Prio.Nbr Type
    ------------------- ---- --- --------- -------- --------------------------------
    Fa1/0/1 Desg FWD 19 128.3 P2p

    VLAN0002
    Spanning tree enabled protocol ieee
    Root ID Priority 32769
    Address 0023.3426.5780
    Cost 19
    Port 19 (FastEthernet1/0/17)
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

    Bridge ID Priority 32770 (priority 32768 sys-id-ext 2)
    Address 0023.3426.5780
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
    Aging Time 300 sec

    Interface Role Sts Cost Prio.Nbr Type
    ------------------- ---- --- --------- -------- --------------------------------
    Fa1/0/17 Root FWD 19 128.19 P2p

    az más kérdés, hogy a CDP hisztizik a tag-elés miatt:
    *Mar 1 00:11:14.402: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/0/1 (1), with SW_3750_1 FastEthernet1/0/17 (2).
    *Mar 1 00:11:14.410: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/0/17 (2), with SW_3750_1 FastEthernet1/0/1 (1).

    Pont azért nem gond az STP itt a hairpinnél, mert a Cisco-nál per vlan fut. Mivel a Cisco-nál nincs per vlan nélküli hagyományos RSTP vagy STP ezért MST-t állitottam be egyetlen instance-el, ennek hatására szépen BLK-ba is esik a 17-es port:

    SW_3750_1(config)#spanning-tree mode mst
    SW_3750_1(config)#end
    SW_3750_1#
    *Mar 1 00:14:38.010: %SYS-5-CONFIG_I: Configured from console by console
    SW_3750_1#sh spa
    SW_3750_1#sh spanning-tree

    MST0
    Spanning tree enabled protocol mstp
    Root ID Priority 32768
    Address 0023.3426.5780
    This bridge is the root
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

    Bridge ID Priority 32768 (priority 32768 sys-id-ext 0)
    Address 0023.3426.5780
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

    Interface Role Sts Cost Prio.Nbr Type
    ------------------- ---- --- --------- -------- --------------------------------
    Fa1/0/1 Desg FWD 200000 128.3 P2p
    Fa1/0/17 Back BLK 200000 128.19 P2p

    Ha a portokat trunk-ra hardkódolom, akkor persze logikus módon defaultban ugyanúgy a 17-es port lesz BLK mindkét vlan-re:
    SW_3750_1#sh spanning-tree

    VLAN0001
    Spanning tree enabled protocol rstp
    Root ID Priority 32769
    Address 0023.3426.5780
    This bridge is the root
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

    Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
    Address 0023.3426.5780
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
    Aging Time 300 sec

    Interface Role Sts Cost Prio.Nbr Type
    ------------------- ---- --- --------- -------- --------------------------------
    Fa1/0/1 Desg FWD 19 128.3 P2p
    Fa1/0/17 Back BLK 19 128.19 P2p

    VLAN0002
    Spanning tree enabled protocol rstp
    Root ID Priority 32770
    Address 0023.3426.5780
    This bridge is the root
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

    Bridge ID Priority 32770 (priority 32768 sys-id-ext 2)
    Address 0023.3426.5780
    Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
    Aging Time 300 sec

    Interface Role Sts Cost Prio.Nbr Type
    ------------------- ---- --- --------- -------- --------------------------------
    Fa1/0/1 Desg FWD 19 128.3 P2p
    Fa1/0/17 Back BLK 19 128.19 P2p

    Dehát ugye nem arról volt szó, hogy trunk port-ot csinálnánk "önmagába" hanem, hogy egy hairpin biztosit átjárást a két vlan között.

  • soma314

    tag

    válasz tusi_ #12343 üzenetére

    mivel a rapid stp (és a per vlan rstp+ is) kompatibilis a legacy stp-vel, ezért simán működik vele. A példádban a régi HP amin STP futna simán működne STP-ként ha a Cisco RSTP-ben lenne. Szóval semmi értelme szerintem, hogy minimum nem az a default. De lehetne ma már az MST is.

  • soma314

    tag

    válasz tusi_ #12344 üzenetére

    Ahogy írod a lényege, hogy a par vlan (R)STP esetén a switch annyi féle topológiával számol alapból ahány aktív vlan létezik.

    Vegyünk egy példát: A-B-C switchet vannak hurokban összekötve
    sima STP-nél ennek hatására
    az A-B linken forward
    a B-C linken forward, akkor
    a C-A link egyik végén BLK állapotban lesz a port.

    Magyarán a C-A linken nincs adatforgalmad a BPDU-kon kívül. Nem ideális a sávszélesség kihasználásod.

    Ha van 3 aktív vlan-ed 100,200,300, akkor per vlan (R)STP-nél ugye meg lehet úgy csinálni, hogy csak a vlan 100-nak legyen BLK az A-B link, vlan 200-nak a B-C és vlan 300-nak a C-A vagyis minden linken lesz adatforgalom.
    (Ahogy az HSRP-nál is igy lehet load balancing-ot csinálni úgy, hogy ay egyik switch aktiv a vlan 100-ra, standby a 200-ra mig a másik fordítva.)

    A baj ezzel ott van, hogy ha van 300 aktiv vlan-ünk, akkor 300-szor kell ehhez elvégeznie a switchnek a számításokat.
    Az MST-nél ugye ezeket instance-ekbe csoportosítjuk. Persze itt is lehetne 300 instance-et is csinálni, de a 3-al elérjük az ideális mennyiséget. Ugyanis 3-al minden topológiában el tudjuk érni, hogy minden linken legyen adatforgalom.
    Pontosan ahogy irod az MST legnagyobb előnye, hogy magától nem lesz annyi topológia, amennyi aktív vlan.

  • soma314

    tag

    válasz FecoGee #12346 üzenetére

    mindezen nehézség ellenére ha multivendor környezetbe kell értelmes layer 2-es topológiát kialakitani, akkor ez marad, mivel ugye csak a Cisco-nak van per vlan STP flavor-je
    Legalábbis én más gyártónál még nem láttam. Persze nyilván nem láttam minden más gyártót :)

    MST viszont szabvány és elég nagy a támogatottsága.

    Nyilván bonyolultabb kb, mint routingnál single area OSPF és a multi area.

  • soma314

    tag

    válasz FecoGee #12348 üzenetére

    hát igen, ahol lehet (irodai környezet, általános szoftverek)

    viszont ahol követelmény a layer 2-es kapcsolat és óriás VPLS-ket kell csinálni, amire aztán további switch-ek csatlakoznak...

    Data Centernél már inkább a TRILL felé megy a jövő nem?
    Keveset hallottam erről, de valami olyasmit, hogy az IS-IS multiprotokoll képességeit használja ki, hogy "routoljon" layer 2-őn

  • soma314

    tag

    válasz tusi_ #12353 üzenetére

    mondom én: ne csak irodai környezetre gondolj
    stack-elni, vss-be vonni olyan switch-eket tudsz, ahol egymáshoz közel vannak. (Na jó VSS-nél elvileg lehetnek messze, de ott is kötött a topológia. Két core switch-re csatlakozik egy harmadik.)

    nekem speciel leginkább olyan környezet van, ahol igencsak távol (értsed sok-sok kilométerre) vannak a switch-ek egymástól a számítógépek (ne sima PC-ket képzelj el) között pedig csak layer 2-es kapcsolat lehet. Nem lehet routing.

  • soma314

    tag

    válasz TheProb #12360 üzenetére

    minek neked trunk, ha mindent hagytál egy vlan-be?

    conf t
    int gi0/1
    switchport mode access
    switchport access vlan X - az általad használt vlan száma

    utána mennie kellene

    még valami a 2950 nem tud MDIX-et, elvileg a router felé straight kábellel kéne menned, azzal mész?
    A routeren van MDIX?
    speed mindkét oldalon auto vagy mindkét oldalon gbps?
    full halfduplex?
    a switch nem dob fel CDP üzeneteket?
    esteleg érdemes nem kikapcsolni az auto negotiation-t

    [ Szerkesztve ]

  • soma314

    tag

    válasz kowika87 #12377 üzenetére

    Gratulálok! :R

    Én is CCIE RS-re készülök. Én azt a tanácsot kaptam, hogy ne külön készüljek az írásbelire meg a laborra, hanem készüljek eleve a laborra és, ha a felkészülés nagyja megvan, akkor jelentkezzek be az írásbelire.
    Te mint aki sikeresen túl vagy az írásbelin, hogy látod ezt a tanácsot? Te elsőnek az irásbelire készültél és most fogsz a laborra? Vagy Te is egyben?

    Anélkül, hogy bármi titoktartási szabályt megszegnél lehet azt mondani, hogy volt valami terület, amiből kevesebb kérdésre számítottál, de több volt a vizsgán? Pl. IPv6 vagy layer 2-es technológiák mennyire jelentek meg a kérdésekben érzésre volt olyan amit hangsúlyosabbnak éreztél az előzetes elképzelésekhez képest?

    Az Evolving technoligies-zal én is küzdök. Átolvasva a Russo féle jegyzetet számomra eléggé megfoghatatlannak tűnik, hogy ebből bármi konkrétat is kérdezzenek.

    A Cisco Evolving T. slide-okhoz van publikus hozzáférés?

  • soma314

    tag

    válasz kowika87 #12381 üzenetére

    Köszi az infókat.
    Én az INE alapján készülök, de ahogy javasolják egyben a labor/írásbeli. Mivel nem kell sietnem megújitani a CCNP-m, ezért megpróbálom igy.
    Én egyébként a korábbi vizsgákra is igy készültem, hogy gép előtt, amit láttam, olvastam már próbáltam is, hogy megmaradjon, amennyire csak lehet.

    Az INE Black Friday akciójában fizettem elő a CCIE RS bundle-re. Ez ugye integy kétszáz óra videó anyag.
    Mivel azonban én úgy megyek át rajtuk, hogy elsőre közben jegyzetelek (olyan 200 oldalnyi gépelt jegyzetnél tartok) és csinálom vele együtt laborban (mondjuk a jegyzetelés jó része a konfig, a show output-ok, a wireshark capture-ből screen shot-ok...

    Szóval mindezért olyan 4 óra alatt haladok előre 1 órányi videót.
    Több video sorozat van
    Advanced technologies video sorozat olyan 105 óra
    ezzel kezdtem és olyan 95 óránál tartok benne. Csak a laborban lévő bluprint témákkal foglalkozik. Az irásbeliben lévő describe témákkal nem.

    Ha ezzel végzek, akkor jönne a written, ami olyan 30 óra
    Itt is kell majd jegyzetelni, lesz amit laborozok is, mert csak akkor látok rá, hogy megjegyezzem új témákat (pl. IS-IS)

    Trouble shooting 17 óra
    Lab Cram 36 óra
    Bootcam 20 óra

    Meg persze külön csak a PPP-ról, csak az STP-ról, ha valaki át akarja ismételni a CCNP-t (60 óra)...

    No meg persze ott a workbook, amit követve kellene a gyakorlatot megszerezni.

    Az irásbeli előtt szeretném átfutni az Official Certification Guide kérdéseit, ott, ahol bizonytalannak érzem magam átolvasni.

    INE ajánlása szerint, ha nem sürget minket az idő, az irásbelit az első labor vizsga előtt 3 hónappal tervezzük letenni. Ez nálam még jóval odébb van.
    Munka gyerekek mellett kell még vagy 1-2 év az első olyan labor próbálkozáshoz, aminek értelme is van (lesz elméleti esély). Persze bármit hozhat az élet. Például, ha az ember munkahelyet váltana, akkor lehet kivennék egy félév alkotói szabadságot csak CCIE-t tanulni.

    Kifejezetten a CCIE-ra való felkészülést ősszel kezdtem. Elsőként ingyenesen hozzáférhető anyagokkal pl a youtube-on vannak értelmes anyagok (IPExpert, INE, CBTTNuggets) amik nem annyira a technológiai részében, inkább a felkészülés módszertanában segítenek.
    Sokat körbejártam a labor kérdést is és arra jutottam, amit többen tanácsolnak, hogy nem magam küzdök vele, hanem bérlek online labort (INE). Persze ez nem azt jelenti, hogy mindenre felhasználom a drága labor token-eket, de a troubleshootra például ideális, ha a kész mások által összeállított hibákkal teli topológia várja az embert és nem azt javítom ki, amit magam konfiguráltam, vagy nem azzal megy el az idő, amíg a beszerzett configok-at feltöltögetem. Bár ilyeneket lehet találni pl a gns3vault.com-on.

  • soma314

    tag

    válasz TheProb #12400 üzenetére

    Statikus IP címük van, vagy DHCP osztja ki?
    Leased time az IP címre?

    Honnan nem tudod pingelni?
    Válasz nem jöl, vagy elérni nem éri el a ping?

  • soma314

    tag

    válasz TheProb #12403 üzenetére

    én is a takaritónőre tippelek :)
    a monitorozó szoftver gondolom egy olyan szerveren fut, ami a switch-ekkel azonos lan-ben van vagy legalábbis nem az interneten keresztül próbálja elérni őket ugye?

    mennyi ideig nem lehet pingelni 1-2 perc és eygenként jelentkezik vagy egyszerre több switchnél

    ha egyszerre több switch-nél, akkor azok tápellátása nem azonos forrásról megy

    vicces a takaritónő, de simán el tudom képzelni, hogy megy végig valaki és kihúzkodja a switch-eket és amig újraboot-olnak, nem elérhetőek

    vagy szünetmentes ellátásról mennek

    a switch-eken nem lehet lekérdezni az uptime-ot egy ilyen elérhetőségi szünet után?

    nincs STP konvergencia a hálózatban? vagy akár routing protokol gyári timerekkel?
    Egy nem optimalizált OSPF konvergencia is eltarthat egy pár percig is akár! Lehet akár 120 mp broadcast network type-nál a dead timer

  • soma314

    tag

    válasz soma314 #12410 üzenetére

    már úgy értettem non-broadcast-nál 120 mp a default dead timer

    broadcastnál csak 40, de ugye van még 40 mp wait time, amig a DR/BDR election megtörténik, szóval az is kb másfél perces konvergencia, ha nincs optimalizálva

  • soma314

    tag

    válasz TheProb #12412 üzenetére

    na most kezdem nem érteni
    van egy site-od, ahol vannak a switch-ek és egy külföldi site-od, ahol a monitorozó szerver van
    eddig jól értem?

    mi a kapcsolat a külföldi és a helyi site között, ha nem internet?
    (akkor is használod az internetet, ha vpn kapcsolatként intranet-en lévőnek látja a szerver a switch-t)

    a másik dolog, ami nem tiszta
    egyszerre egy switch-et kérdez le véletlenszerűen, vagy véletlenszerű időpontban lekérdezi mind, amiből bizonyos switch-eket nem ér el?

    (van mondjuk 5 switch és 1:22-kor megpingeli az 1-est, 1:45-kor a 3-ast....
    vagy 1:22-kor megpingelni mind az 5-öt?)

    mi a topológia? a switch-ek hogy vannak az internetre kötve? egy router-en keresztül nem?
    a router-t is pingeli a szerver? mi a router uptime-ja?
    egyáltalán a router állandóan ugyanazt az IP címet kapja, vagy mint egy otthoni internetszolgáltatásnál időnként kap újat (ez utóbbi esetben is lehet "állandó" overlay IP címe a szerverről nézve)

    (Pl, ha egy DMVPN topológia van az intersite kommunikációhoz akkor elég ha a központi - HUB site-on van statikus IP cím, míg a remote site-okon , a spoke-okon lehet dinamikus is. Ha ez van nálatok, akkor amikor a szolgáltató új IP címet ad a site router-ének, akkor addig, amig nem épül fel a NHRP-al az új címmel a VPN kapcsolat, addig a remote site-on semmi nem lesz elérhető. De ezt tiszta ha adott időpontban semmi, vagy csak egy switch nem elérhető.)

  • soma314

    tag

    válasz TheProb #12414 üzenetére

    tételesen
    - a tököd biztos azt is tudja, hogy miért nem elérhetőek a switch-ek. Ne felejtsed el, hogy te tettél fel egy kérdést, amire ha értelmes választ válrsz akkor információval kell szolgálni.

    -nem nyilvánvaló, hogy interneten keresztüli VPN kapcsolat van csak azért mert távol, akár nagyon távol vannak egymástól a site-ok

    akkor összefoglalmom mennyi derült ki:
    - néha nem elérhető egy switch
    - vagy néhe nem elérhető több switch ezt nem sikerült eldöntened,
    - a kiesés 1-2 perces
    - interneten keresztüli VPN kapcsolat köti össze a site-ot, ahol a switch-ek vannak a site-al ahol a monitorozó szerver fut
    - nem tudjuk, hogy a VPN kapcsolat L2-es vagy L3-as,
    - ha L2-es akkor lehet, hogy a helyi core switch simán swithc portként csatlakozik valamihez a külföldi site.on. Ekkor nem kerülhet szóba IP cím kérdés.
    - ha L3-as akkor kell egy router, tüzfal, valamilyen L3-as eszköz ami az itteni site-on biztosítja a kapcsolatot az internet felé, ennek kellene tudni, hogy állandó statikus IP címe van-e, vagy az internetszolgáltató oszt ki neki IP címet. Ha a szolgáltató osztja ki, akkor milyen leased time-al.

    Itt többünk leírta, hogy a legvalószínűbb scenario az, hogy az internet felé lévő kapcsolatot "újítja" meg a szolgáltató, akár úgy, hogy kigyomlálja az inaktívakat, akár úgy, hogy újabb IP címeket oszt ki nekik.

    Ez alapján egy hozzáértő már tudja miket kell megnézni, hogy közelebb jussatok a megoldáshoz de úgy nem működik, hogy elmész az autószerelőhöz, hogy sokat fogyaszt az autóm és amikor megkérdezi, hogy milyen az a válasz, hogy piros (mikrohullámú az internetkapcsolatod fizikai rétegben).

    Amit például meg tudsz tenni, hogy ráakasztasz egy számítógépet az egyik adott switchre és megpróbálod trace-elni a monitorozó szerver IP címét, amikor hiba jelentkezik. Vagy kitükrözöl mindent ami a switch management vlan-jére -ről jön/megy.

    De ami a legegyszerűbb és már leírta más: megnézed a internetszolgáltatótok mit szolgáltat!

  • soma314

    tag

    válasz TheProb #12418 üzenetére

    Elnézést nem vagyok kiakadva csak valahogy úgy tűnt, hogy ötletelünk jó szándékkal, de az infók beszerzése, felvázolt elméleti lehetőségek leellenőrzése valahogy elmarad és nyűgnek tűnik.
    végül is valahol nyilván neked a legfontosabb tudni mi lehet az oka

    akkor összefoglalom azokat amiket leirtak itt többen lehetséges elméletekként és érdemes leellenőrizned

    - "takaritónő elmélet" lehet, hogy az adott időszakban valaki valamit csinál. kihúz egy kábelt, bedug egy kábelt. Lan partin nyomják a doom-ot a biztonsági őrök....

    - legvalószínűbb: szolgáltató oldali kinyirbálása azon host-oknak, amik nincsenek használatban. Lehet, hogy a ti oldalatokról úgy tűnik, hogy folyamatos internet kapcsolat van, de az is lehet, hogy az internetszolgáltató lekapcsol mindenkit akinek nincs forgalma. Kívülről ilyenkor hiába próbálnak kapcsolatot kezdeményezni.

    - CAM table timeout. Amig folyamatos forgalom van, addig a switch cam táblájában van melyik porton melyik MAC cim lakozik. Ha ez eléri a timeout-ot (Cisco-nál ez általában default-ban 300 sec), akkor újabb unknown unicast-ként keres mindenkit, ami tranziens jelleggel megnöveli a broadcast jellgű forgalmat. Ettől simán lehet egy pár elveszett ping.
    Simán lehet az is, hogy egyszerűen csak az üzemidőn kívüli switch-ek és router üres CAM táblákkal mire kiküldi az ARP-okat elveszik egy ping válasz és lehet, hogy már az generál egy riasztást (ez persze nem tarthat percekig, sőt másodpercekig sem)

    - STP/L3 konvergencia. Ha hagyományos STP fut default beállításokkal, akkor 50- mp-es kieséssel számolhatsz egy konvergenciánál. Ha RapidSTP, vagy MST akkor ugyan a konvergencia (egy jól megtervezett hálózaton) mondjuk csak 2 mp, de minden RSTP konvergencia (Topology Change Notification) esetén a root bridge küld egy TCA-t (TC Acknowladgement-et) aminek hatására a switchek kitörlik a CAM táblájukat és lásd előző pont. Ha layer 3 routing konvergencia van akkor ahogy irtam, ha nincs optimalizálva, akkor akár percekig is tarthat.

    - azt is el tudom képzelni, hogy egy állapottartó tűzfal van az internet felé. Lehet, hogy amig termelés van és a switch-ek forgalom alapján rendszeresen küldenek valami riportokat (SNMP, netflow...) addig tűzfal a site-ról indított forgalom miatt nyitva hagyja a pingelésre is használt port-ot a switch-ek menedzsment címére. Amikor nincs termelés a switch-ek nem generálnak riportokat kifelé, nem jön be semmi befelé, ezért a tűzfal lezárja a host címre irányuló forgalmat.

    - lehet az is (hogy mivel fogalmunk sincs milyen) a VPN tunnel sem állandó, hanem on demand jelleggel létezik, ezért üzemidőn kivül ha nincs forgalom, akkor elbontódik, mire kiépül, már sikertelen lesz a pingelése egy vagy több switch-nek

    Még biztos tudunk vagy 25 lehetséges scenario-t kitalálni, ami az általad megadott szegényes információra ráillik, de ez nem fog előrébb vinni a probléma megoldásában.
    Ez csípőből lövöldözés. Módszerességgel lehet a probléma okához eljutni.

  • soma314

    tag

    válasz TommyNagz #12548 üzenetére

    Én annak idején a kompozit vizsgát csináltam, mégis most én pont nem azt ajánlanám neked.

    Figyu, most a szerencsefaktor ellened szólt, de a tudás ott van, jelentkezz be újra és tedd le. Legalább ismerősök lesznek a kérdések, a vizsga. Én a helyedben, amig frissek az emlékek gyorsan amit tudok lejegyeznék.
    Kicsit morognék (mert tényleg szivás a szitu) aztán csakazért is tanulnám tovább.
    Másodikra lerakod és csúsztál 2 hetet az eredeti ütemtervedhez képest.

    A munkahelyeden, meg ha a sikeres az ICND1 és a CCNA még nincs meg negyedév végére kaphatsz halasztást. Ha meg nem akkor meg megcsinálod magadnak később és úgy keresel már új helyet, hogy van CCNA.

    Ha bejelentkezel a konpozitra március végére és nem jön össze, akkor lesz két elbukott vizsgád, ami még drágább. A munkahelyeden ennek sokkal rosszabb az optikája.

    Szerintem a dolgot úgy kell nézni, hogy nem a vizsga, vagy a tanúsitvány az igazi érték, hanem a a tudás, ami benned van. Ha tudod, hogy tényleg keményen nyomtad az elmúlt időben, akkor tuti egy csomó dolgot megtanúltál és csak idő kérdése, hogy mikor szerzel róla vizsgát, de a munkád során mindaz ott van a fejedben már!

  • soma314

    tag

    válasz Poultier #12568 üzenetére

    CBT Nuggets-nek vannak ilyen videói, ha kicsit akarsz elmélyülni:
    https://www.cbtnuggets.com/it-training/mpls-fundamentals

    egy hétig ingyenes ha regisztrálsz
    egy hét alatt simán végig lehet nézni

    Ha mélyebbre merülnél a témában, akkor INE CCIE RS, vagy pláne SP MPLS videók

    De a google-be egy jól feltett kérdés is segíthet olvasni valót találni:

    https://www.google.hu/search?q=ipexpert+mpls+pdf&ie=utf-8&oe=utf-8&gws_rd=cr&ei=Bb6lWIfcIKXw6ASszrqAAQ

  • soma314

    tag

    válasz kowika87 #12567 üzenetére

    félek, hogy nem csak az a plusz 150 dollár lesz az többlet, amit el fogok költeni mire oda jutok

  • soma314

    tag

    válasz TommyNagz #12612 üzenetére

    Ha építesz lebort, akkor ne csak a CCNA-t célozd meg vele, hanem olyat, ami legalább CCNP-ig hasznos lesz.

    én ha most építenék labort 2 multilayer switch-et vennék, egy layer 2-es switch-et és egy router-t

    Ha lehet és megengedheted magadnak akkor multilayer switchnek
    - Catalyst 3560, vagy 3750 - ezekkel lehet private vlan-t gyakorolni, VTP 3.0-t (ez még CCIE RS-hez is elég lehet)
    - ha szűkebb a keret, akkor 3550

    Layer 2-es switch-nek Catalyst 2950 (drágábbat nem érdemes szvsz), de ha éppen belefutsz 2960-asba nagyon jó áron, akkor az még jobb. (A tapasztalat inkább az, hogy a 2960 árából simán veszel, 3550-es multilayer switch-et, ami sokkal több lehetőséget ad.)

    Routernek szinte bármi, de legyen 2 db Ethernet interfésze és legalább IOS 12-es fusson rajta. Én 2611XM-et vennék.
    1 db router azért kell, mert csdak router-en fogsz tudni gyakorolni NAT-ot.

    A multilayer switch-ekkel tudsz routolni is, ezért elég összetett topológiát össze tudsz rakni.

    3 switch azért kell, hogy a spanning tree-t, VTP-t tudd gyakorolni, meggfelelő összetettségben.

    Amit kerülj: a fenti switcheken (2950. 3550, 3560, 3750) kívül minden másikat.
    Ne vegyél sok router-t. Magasabb szinteken (CCNP, CCIE) úgysem harveres router-eket fogsz már használni, hanem emuláltakat. A switch emuláció viszont sokkal nehézkesebb, ezért inkább jó (jobb) multilayer switch-ekre költsél.

    Amire már nem érdemes sokat (régen nagyobb hangsúllyal volt jelen a soros port a vizsgákra való felkészülés során. Ma már a CCNA-nél nincs Frame Relay csak PPP, csak ezért nem vennék két router-t soros portokkal és egy soros kábelt közéjük inkább gyakorolnál emulátorral (GNS3) vagy akár szimulátorral.

  • soma314

    tag

    válasz TommyNagz #12614 üzenetére

    egy ilyet találtam az aprók között
    gond nincs vele, de amit hirdetnek, annak csak egy darab ethernet portja van
    egy switch-el kiegészitve és subinterfészeket konfigurálva ezzel is rengeteg mindent lehet gyakorolni

    a "baj" az, hogy az elején még nem fogod tudni hogyan lehet subinterface-eket használni, majd később, amikor a router on a stick jön

    én azt tanácsolom, hogy olyan router-t vegyél, amiben van 2 db ethernet interfész, hogy keresztül tudjál route-olni rajta

    persze ez amit hirdetnek 2650XM is kiegészithető külön kártyán újabb interfésszel, de azt külön keresni kell

  • soma314

    tag

    válasz TommyNagz #12620 üzenetére

    A GNS3 remek dolog, de

    - csak a legfrissebb verzió és lehetőleg Linux alatt és úgyis sokszor instabil (nekem legalábbis ez a tapasztalatom)
    - a PT egy szimulátor (a GNS3 emulator), közel se úgy működik, mint a valóság, viszont a CCNA vizsgán is szimulálva mennel a labor feladatok ezért a "feeling" miatt érdemes használni
    - vannak dolgok, amit érdemben csak valós hardveren tudsz kipróbálni gyakorolni, mint amilyen például a password recovery, a IOS upgrade.... Ez a vizsga anyag jobb megértését szolgálja, és ami fontosabb, az életet! Másképp izzad az ember tenyere, ha élesben csinál ilyesmit az ember először, mintha otthoni cuccon.
    - ha limitált az időd, akkor párhuzamosan megtanulni a a GNS3 használatát (ami igy utólag nem nagy ügy) és a CCNA anyagot elég luxus
    - az elején mindenki bizonytalan a tudásában. Ha nem megy valami, akkor elsőre ki kell zárni, hogy a GNS3-ban tettünk valamit rosszul, vagy a konfigurációban. Ez nyilván nehezíti a dolgokat.
    - GNS3-ban (dynamips-el legalábbis) nem lehet hatékonyan emulálni switch-et (más kérdés az IOL) ezért leginkább multilayer swtich-et érdemes vásárolni igazi harverből

    Szerintem kell 3 switch (a SPT miatt), amiből
    - 1 db 2950 5-10 eFt között találsz (neked nem számít hány portos)
    - 2 db 3550/3560/3750 10-20 eFt/db
    - 1 db router min 12 IOS-el és lehetőleg két ethernet interfésszel 5-10 eFt

    Multilayer switch-ekről
    3550 a legolcsóbb, de nem tudja az auto MDIX-et (cross vagy strait kábel-t kell használni adott helyzetben, ami CCNA tanulás szempontjából még jó is lehet), a private VLAN-t (ez ha jól tudom még mindig csak CCNP-nél téma), nem tudja a stackwise-t (csak CCNP és kb 2 parancs)

    3560 a CCIE RS-hez is ez a hivatalos platform IOS 15-el. Ehhez 32 Mega flash-es változat kellene, de rá lehet trükközni xmodem-mel a 16 Megásokra is a 15-ös IOS-t, másrészt, ha most készülsz CCNA-re és egyszer eljutsz a CCIE-ra készüléshez, addigra ki tudja mi lesz.

    3750 pont, mint a 3560, de tudja a stackwise-t is, amihez minimum kettő 3750-es és egy stackwise kábel kell. Én nem vennék plusz pénzért, egyrészt, mert van, másrészt, mert tényleg kb. 3 parancs amit pluszban gyakrolsz vele.

    PoE-s switch-et érdemes, mert a CCNP RS-es Switch-nél téma (de kb ez is 2-3 parancs). Akkor érdemes többet költeni rá, ha wireless, vagy collaboration irányban tanulnál tovább.

    Layer 2 switchekről:
    a hivatalos a 2960-as, ami egy kevéssel tud többet, mint a 2950. Ráadásul azt a keveset tudod a multilayer switch-eken gyakorolni, ezért nem éri meg a többletet szerintem (lényegesen drágábban szokták árulni). Ami gyakorlati különbség inkább, az a már emlitett auto MDIX hiánya 2950-nél.

    A lényeg, hogy a laborra elköltött 30-60 eFt nem tűnik soknak a vizsga díjakhoz képest!

  • soma314

    tag

    válasz tusi_ #12695 üzenetére

    vagy az egyszál user gépe és a router switch portja közé teszel egy kétezer forintos asztali switch-et ami akkoris up-up-ba tartja a router switch moduljának a portját, ha az egyszál user lekapcsolja a gépét

    esetleg, ha van 3 portod, akkor még kettőt beleteszel abba a vlan-be, amiben az egyszál user van és bedugsz egy hairpin kábelt, aminek hatására a hairpin kábel egyik végén az egyik port ugyan discardingba fog esni, de a másik up/up-ba marad, igy mindig lesz up/up portod a vlan-ben

    [ Szerkesztve ]

  • soma314

    tag

    válasz soma314 #12700 üzenetére

    van még egy megoldás: hardveres 100 megás loopback plug az egyik portra, ami a user vlan-jében van:
    http://www.juniper.net/documentation/en_US/junos/topics/task/operational/fe-ge-loopback-plug-rj-45.html

  • soma314

    tag

    válasz crok #12696 üzenetére

    nekem ez 3560-assal kipróbálva nem tartja up/up-ban a vlan interfészt
    sem access portra, sem trunkra configurálva

    mit csinálok rosszul?

    voice-os access portra konfigurálva:

    interface FastEthernet0/1
    switchport access vlan 11
    switchport mode access
    switchport voice vlan 12
    spanning-tree portfast
    end

    SW_3560_4#sh ip int bri | i up
    Vlan1 unassigned YES NVRAM up down
    Vlan11 11.0.0.1 YES manual up down
    Vlan12 12.0.0.1 YES manual up down

    voice-os trunkra kofigurálva:

    interface FastEthernet0/1
    switchport trunk encapsulation dot1q
    switchport mode trunk
    switchport voice vlan 12
    spanning-tree portfast
    end

    SW_3560_4#sh ip int bri | i up
    Vlan1 unassigned YES NVRAM up down
    Vlan11 11.0.0.1 YES manual up down
    Vlan12 12.0.0.1 YES manual up down

  • soma314

    tag

    válasz crok #12707 üzenetére

    de én úgy értettem, hogy pont az a probléma, hogy ha az az egy user aki a példámban fa0/1-re van kötve lekapcsolja a gépét és ezzel a port down/down-ba esik, akkor a vlan interfész is up/down-ba esik

  • soma314

    tag

    válasz crok #12709 üzenetére

    ja értem van egy uplink is, ami access-ben van, de egy másik vlan-on, mint a user access port-ja
    (valamiért azt hittem, hogy a routed port az uplink)

Új hozzászólás Aktív témák