- Milyen GPS-t vegyek?
- Mobil flották
- Samsung Galaxy A55 - új év, régi stratégia
- Milyen okostelefont vegyek?
- Redmi Watch 5 - formás, de egyszerű
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Második bétánál jár a One UI 8
- Megvan, milyen chipet használ a Pura 80 Ultra
- Garmin Instinct – küldetés teljesítve
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
-
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
-
VeryByte
őstag
Csak az a baj, hogy a műtét sikerült, de a beteg meghalt.
Sajnos nem működik a dolog, mert dobálja a VPN kapcsolatot.
Kicsit átgondolva logikus is.
Az USB Redirector (ami ettől függetlenúl egy rettentő jó cucc) hálózaton keresztül osztja meg az USB-s eszközöket és azt lokálisan látod.
De a Cisco VPN kliens kapcsolódáskor elveszti a saját hálózat adatait és felveszi a partner hálózatét. Innentől pedig elveszti az USB Redirector által megosztott eToken-t is, és mivel nincs token, nincs tanusítvány, ezért eldobja a kapcsolatot.Mókás.
Még egy esély van, ha Hyper-V helyett VMWare-t használ az ember, mert abban viszont van USB megosztás.
Ez lesz a következő próba.
Azaz pont az amit Te csinálsz.
Viszont ez az USB Redirector baromi jól használható mondjuk elektronikus aláírásra, esetlegesen hardverkulcsos szoftver használatára.
-
#7034
Cyber_Bird
senior tag
tusi_
#7033
Cyber_Bird
senior tag
Detto igy vagyok vele en is.
Igazabol nekem van dontesi lehetosegem, hogy magamnak fizessem, vagy a ceg fizesse, de mivel a jelenlegi munkahelyemen mar a ccnp szintet sem tudnam kihasznalni, igy hiaba fizetnek ki, inkabb magamnak fizetem, mert igazabol a sajat erdekem, nem a cege. -
Hát, izé... Volt valami, de csak a fejeseknek lett visszaállítva, mert valamit nagyon elcseszett a fiú. Információs embargó volt a dologra, szóval igazából senki se tudja mi történt, de meredek dolgokat beszéltek. Dehát végül is nem gond, mint tudjuk, semmi nem rak akkora rendet, mint a format C:
-
crok
Topikgazda
-
zsolti.22
senior tag
Hát ez van, mivel a könyvekben az ember ezt olvassa, aztán jön a gyakorlat és hoppá, mégsem úgy van. Agyilag felqr, hogy nem lehet ezt a !%+%/"%/"!%/ switchinget úgy megtanulni, mint a route-t. Ott ahogy le volt írva, az úgy működött (jó, lehet, hogy volt egy-két kivétel, de nem kellett neten külön kukázni, mert csak összezavart....). Ha nem úgy van, ahogy írják, akkor minek írják bele? Ha bizonyos dolgoktól függ a működése, akkor írja le úgy, ne szentírásként, hogy márpedig úgy van...
Rosseb se akar ezen tovább vitatkozni, csak már eléggé frusztrált lettem.
@Feco: fel kéne gyújtani a cisco-t, hogy ne mondjon mást, mint amit a sz@ros eszközeik produkálnak.
-
zsolti.22
senior tag
Nagyon nem.
A transzparens switch nem frissíti be az adatbázisát, de tovább küldi a kapott vtp cuccokat.No komment.
Vtp v2 a token ring támogatás mellett , még elméletben a frissítéseket illetően annyi van, hogy nem veszi figyelembe a vtp domain neveket.
Ez megdőlni látszik. Server VTPv2, SECURE domain-névvel, Transparent VTPv2, namajdenmegmutatomavilagnak domain-névvel úgy nem frissíti le a klienst, ami rajta lóg vtpv2-vel és SECURE domain-névvel, mint a huzat.
-
crok
Topikgazda
Óóóó, imádott probléma - de egyszerűen azért, mert nincs rá szükség (:
Egyébként gyártónként és fejlesztőnként változik, hogy megy-e vagy nem,
pl. Cisco bizonyos IOS-ei a HSRP cím pingre válaszolnak, bizonyosok nem.
De mondok jobbat: pingeld meg a VRRP címet DE előtte indíts egy Wire-
sharkot. Lehet meg fogsz lepődni, ugyanis sok vendornál az implementáció
szerint _válaszol_ a virtuális pingre az eszköz ám NEM a virtuális IP a válasz
source-a hanem a _fizikai_ IP.. És hogy miért nincs rá szükség, hogy menjen?
Egyszerű! A virtuális IP arra való, hogy a hostnak legyen def.gw-je L3 szinten
valamint a virtuális MAC azért, hogy legyen L2 next-hop-ja hozzá. Az ARP
bejegyzést ugye leboxolja a VRRP. A tövábbi működéshez pedig más nem
kell! Nem kell tudnia a defgw-t a hostnak pingelni, hiszen ahhoz, hogy a
saját hálózatából kijusson ahhoz forwarding/routing kell _csak_ és más nem.
Ez a viselkedés pedig "hál'istennek" vendoronként és fejlesztőcsapatonként
változik. Próbáld ki a wireshark+ping kombinációt, mert szerintem válaszol
az az eszköz, csak nem a VRRP IP/MAC lesz a source, hanem a fizikai.
(Ha jól sejtem Enterasys lesz az a 2 eszköz, nem is Cisco.) -
zsolti.22
senior tag
Nem lehet, hogy IOS függő? Attól még, hogy routerből csinálod a switchinget, attól még nem kéne hülyének lennie, csak mert az IOS GNS3 alatt emulálódik. Mindenesetre a 3750 nyomott egy fuckot a GNS3-nak
@tusi_: elcsesztem az írást, mert megint túl gyorsan válaszoltál, meg én is, aztán szerkesztés, mégegyszer átolvasás, javítás, te már megint írtál és elfogyott az 5 (öt) perc. Csak annyi történt, hogy rosszul olvastam el, amit írtál.
@FecoGee: na vajon
az egy CCIE lab. -
zsolti.22
senior tag
Ja, írni is akartam, hogy ez nagyon GNS3-nak tűnik, de nézd meg eztet:
Amúgy Uplink fastot rstp mellett felesleges használni és a switched pvrstp-ben van. Mint írtam, ha megnézed a summary kimenetet, ott írja is, hogy uplinkfast enable but takes no effect. (vagy valami ilyesmit ír)
Amúgy nem különbözik sem a PVST, sem a RSTP ebben az uplinkfastban.
0 értelme van rstp-ben, ezt tudod te is, meg a birkáknak ki is írja ugyanezt. Ez csak ott jó, ahol valamelyik rokkant switch nem tudja az RSTP-t, egyébként az életben nincs semmi értelme. -
FecoGee
Topikgazda
Ez foleg design kerdese. Jobb helyeken port-channelt tesznek a disztrik koze, minimum ket linkkel. En mindig igy csinalom. Igy megelozhetem, hogy a disztrik az access switcheken keresztul kommunikaljanak.
Root guardot leegyszerusitve ott kell konfiguralni, ahol nem akarunk a root bridge fele forgalmat tovabbitani. Ha az access switcheken szamitunk arra hogy a ket disztri rajtuk keresztul kommunikal, nem konfiguralunk root guardot. -
Gesztiboy
tag
-
crok
Topikgazda
VRF Lite meg Internetmegosztás globál táblából több VRF felé, hmm..
fincsi kis eset.. volt vele dolgom, senkinek se kívánom, ellenségemnek
se.. plusz ZBFW kilőve, az IOS nem támogatja, hogy a zónákban levő
interface-ek különböző VRF-ben legyenek.. Amelyikbe az első bekerült
abba megy a többi is, ellenkező esetben az interface zónához rendelé-
sekor hibaüzenet, hogy a-aa, az nem fog menni. -
crok
Topikgazda
Router-on-a-stick, ZBFW, routeren subint-ek külön zónában, zónák közt
policy, hogy ki mit csinálhat kivel (lehet csak simán inspect mindenfelé,
így azt nem szűröd, hogy ki kivel kommunikál csak azt, hogy ne bab-
rálhassa senki a másikat mondjuk crafted TCP csomagokkal, et cetera).
Esetleg ha nem ZBFW akkor sima IP Inspection. Akár egy C800-as is
elég lehet, nem ismerem az Internethasználat mennyiségét - a határ
a csillagos és.. pontosabban a felhasználás módja, a cég pénztárcája
és az előre gondolkodás a jövőre nézve (: A C800-asokban azért van
olyan, amiben ott van a 4 portos 10/100-as apró switch, amiből ha le-
viszel egy/két linket trunk-ben a switch felé akár még használható is
lehet a dolog. Ha esetleg gondolsz a jövőre lehet olyat is választani,
aminek LAN linkje van 10/100/1000-es is, WAN-ja lehet valamilyen
DSL (C86x), esetleg még WLAN is mehet bele.. Itt találsz egy bros-
súrát, amiben a Cisco ajánlása van, hogy melyik ISR G2 mekkora
WAN sebességre van kiajánlva (ZBFW-vel, QoS-el, et cetera..).
Mindent az igények és a $$$ határoz meg. De lehet ám Juniper
eszközöket is használni (; Nevertheless hope this helps.. (: -
vadito
csendes tag
Csodálkoztam is, honnan tudsz rólam ennyit, de a written résznél már sejtettem, hogy nem valami látnoki dolog.
A leírtakban ettől függetlenül egyetértünk, nem rossz ez az eredmény. A folytatásról a döntést viszont nem feltétlen most kell meghozni, nem megy az a labor sehova. Az utóbbi fél évben sok (rém)történettel találkoztam a témában, van aki egész könyvet írt róla(szó szerint). Érdemes lehet pihenni néhány napot, addigra elmúlik a frusztráció, aztán folytatni a laborozást, sokan így tesznek.
-
zsolti.22
senior tag
1: Ha minden port gigás lenne, akkor fa0/1 N/A
2: csak sw4-nek kisebb a bidje. És akkor mi van? SW4 felé lesz a root port, SW4-nél meg sw 5 felé lesz a designated. És akkor én ilyenkor úgy csinálok, akkor az a rész letudva, marad sw5-sw6 közötti interfész. Erősebb kutya ....ik elven SW5-nek kisebb a bidje, mint sw6, és sw5-nél lesz a dp.Amit te írsz, az nem egyértelmű nekem. SW5 van középen és megkapja két oldalról a cuccot. Csak azért, mert SW4 bidje jobb, ezért ő zárja is az sw6 felé menő portot? Úgy, ahogy én nézem, úgy nem is kell megvizsgálni a kettő közötti (sw5-sw6) preferenciákat!?
-
#6668
Cyber_Bird
senior tag
tusi_
#6667
Cyber_Bird
senior tag
Szerk.: Nem tusinak szantam, csak valaszra nyomtam veletlen.
Alpha 5-os GNS3-at most probaltam ki windows alatt, (+ az adott linux vm virtualboxban) L2 + L3 IOU image-el.
Meg sokat nem szorakoztam vele, mert meloban vagyok, de rpvst belottem meg par vlan-t felhuztam, es keresztbe pingettem nehany l3 eszkozzal az l2 eszkozokon.(5 eszkoz ossz vissz) Teny, hogy nem sokat csinaltam vele, de egyelore nem futottam bele bugokba. Majd hetvegen jatszok vele meg, valami ertelmesebb topologian is. -
-
zsolti.22
senior tag
A második bekezdés után homlokcsapás volt, az most már legalább világos.
@FecoGee:
ALS1#sh int tru
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
Po10 on 802.1q trunking 1Port Vlans allowed on trunk
Po1 1-4094
Po10 1-4094Port Vlans allowed and active in management domain
Po1 1,100,200,300
Po10 1,100,200,300Port Vlans in spanning tree forwarding state and not pruned
Po1 1,100,200
Po10 300ALS2#sh int tru
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
Po2 desirable 802.1q trunking 1Port Vlans allowed on trunk
Po1 1-4094
Po2 1-4094Port Vlans allowed and active in management domain
Po1 1,100,200,300
Po2 1,100,200,300Port Vlans in spanning tree forwarding state and not pruned
Po1 300
Po2 1,100,200DLS1#sh int tru
Port Mode Encapsulation Status Native vlan
Po1 on 802.1q trunking 1
Po2 on 802.1q trunking 1
Po3 on 802.1q trunking 1Port Vlans allowed on trunk
Po1 1-4094
Po2 1-4094
Po3 1-4094Port Vlans allowed and active in management domain
Po1 1,100,200,300
Po2 1,100,200,300
Po3 1,100,200,300Port Vlans in spanning tree forwarding state and not pruned
Po1 1,100,200,300
Po2 1,100,200,300
Po3 1,100,200,300DLS2# sh int tru
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
Po10 on 802.1q trunking 1
Po3 desirable 802.1q trunking 1Port Vlans allowed on trunk
Po1 1-4094
Po10 1-4094
Po3 1-4094Port Vlans allowed and active in management domain
Po1 1,100,200,300
Po10 1,100,200,300
Po3 1,100,200,300Port Vlans in spanning tree forwarding state and not pruned
Po1 1,100,200,300
Po10 1,100,200,300
Po3 1,100,200,300 -
zsolti.22
senior tag
Most át van alakítva, hogy az alsó kábelek le vannak kapcsolva. Minden ether-channelbe van. Eddig az err-disableddel sz0ptam, de most már az is jó. VLAN200-nál a bal felső sw a root és a hsrp active, sugár irányba vannak a spanning-tree portok. VLAN300-nál ugyanez tükörképbe: jobb felső SW a root és a hsrp active, a spanning-treenél sugár irányba vannak a portok, mégse jó. No ip routing alapból nem kell switchen, ip def-gw beállítva a vlan100 hsrp virtual címére mindkettő ALS-nél.
Hogy kéne működnie ennek a nyomorult inter-vlan routingnak?
VLAN200-beli gép pingelné a VLAN300-at. Az én logikám: a csomag elér a VLAN200 SVI-jéhez (mivel a bal felső SW a HSRP master, ezért ő dolgozza fel), ami egy HSRP virtual cím, majd onnan már a VLAN300-on nyargal tovább a VLAN300-ban lévő PC-hez, ha tud, és a SPA nem blokkol semmi olyat, ami meggátolná a küldést. Visszafelé VLAN300-ban lévő PC válaszol a pingre, ami a VLAN300-as SVI-re érkezik (amit a jobb felső sw dolgoz mert, mert ő a HSRP master vlan300-ra), majd spanning-tree szempontjából a VLAN200-on halad visszafelé VLAN200-ban ülő PC-re.
@vadito: most már a hsrp címek se pingelhetőek...
kezdek berágni. Úgy megkevertem... -
-
-
Wolfy999
tag
Csinálj packet capture-t az R4-5 ASA felé menő lábain, van egy olyan tippem, hogy csomagok eljutnak az ASA-ig, csak az ASA nem továbbít.
Az ASA nem router, routing funkciókban elég nagy hiányosságai tudnak lenni. Pl nem tud olyat, hogy egy csomagot visszaroute-ol, arra a logikai interface-re ahonnan kapta.
Ha ezen a topológián PC A-nak az ASA a default gw, akkor hiába veszel fel route-ot a B subnetre a router felé, PC A nem tudja elérni PC B-t.Ez persze nem magyarázza, hogy nálad miért nem megy a ping, de lehet hasonló érdekesség itt is. Ha az ASA tényleg megkapja a csomagot, akkor nézd meg packet-tracer-rel az ASA-ban, hogy mit csinál vele.
-
FecoGee
Topikgazda
A linkeken allowed vlan 10,20, és RSTP-vel vagy MSTP-vel megcsinálod a load-balancing-ot (mondjuk R1 a root VLAN10-re, R2 a VLAN20-ra). Ha felszakad valamelyik linked, akkor így átáll a HSRP.
A VLAN pruning a control plane protokollokat nem, csak a user broadcast-ot prune-lja. Tehát a STP ugyanúgy futni fog mindkét VLAN-ra mindkét linken.
Egyébként mivel active vlan csak ez a kettő ezért nem lesz ezzel gond."Ebben az esetben viszont a képen jelölt ábra alapján, ha a link 1-en kiadom a sw tr all vl 10, link 2 -n hogy 20, akkor minden oké, a nem kellő Br-ok nem jönnek a switchre. (Persze R1-en is ki kell ehhez adni)" --> semmilyen forgalom nem megy, nemcsak a broadcast! Szóval olyan, mintha ott sem lenne a másik vlan. Gyakorlatilag access vlan-t csinálsz, hiszen 1 vlan-t viszel át.
"VISZONT. Ha R2 leáll, akkor R1 átveszi a vlan 20-t is, viszont le van pruneolva". --> átveszi, de traffic black hole van. R1-R3 között nincs vlan20 engedélyezve, ezért nem fogja kiszolgálni a klienseket, hiszen el sem jut hozzá a forgalom!
"Illetve ha van 20 vlan és csak a 2 használtat tartjuk meg, akkor ok, mert a többi kuka. " --> ezt nem egészen értem. Ha allowed and active 2 vlan-od van, akkor igen, a többire semmi nem fut.
"Tippem az all vlan 10,20, de szeretnék megerősítést. FecoGee-knél VTP van, de hátha valakinek van tapasztalata működő hálóban " --> én allowed vlan 10,20-szal csinálnám. Működő hálóban én kikapcsolom a pruning-ot. Volt már olyan, mikor olyan vlan-t is kiprunolt, amit nem kellett volna, ezért megálltak bizonyos szegmensei a hálózatnak. Mikor csináltam egy no pruning-ot majd visszakapcsoltam, meggyógyult. Bedöglött a process vagy nem tudom. Másrészt egy fontos info a pruning-hoz:
Topologia
SW1------SW2-------SW3----R1
Pruning mindenhol engedélyezett. SW3-R1 között router-on-a-stick.
A VTP Pruning nem fog működni, nem prune-l semmit. Miért? Mert ha nem kap VTP pruning választ egy trunkön, feltételezi, hogy oda minden vlan kell, ezért ő azt mondja a szomszédainak, hogy neki minden vlan kell. Márpedig R1 nem tud VTP-t. Innentől olyan mintha nem is lenne pruning. De ugyanez van szerverek felé is trunk kapcsolatoknál.Remélem érthető volt, ha nem kérdezz még
-
-
quby
őstag
Ha mindenképp zárod, feltétlen jelezd itt! Én is sokat látogatom, lementeném előtte.
A kislányhoz pedig minden jót kivánok, nekem is lesz egy két napon belül. Még meg sem született de már látom menyi időt fog rabolni. Augusztusra CCNP-t terveztem (switch) Nem tudom hogy gondoltam 
-
zsolti.22
senior tag
+1, egy 3 betűs szó, amivel a könyvet tudnám jellemezni
(amikor még azt hittem, hogy lesz olyan jó, mint a ROUTE, így okozva 14000 huf kárt nekem ![;]](//cdn.rios.hu/dl/s/v1.gif)
)DE!
Igaza van Cyber_Bird-nek, azért is guide van a könyv címében, mert nem ebből kéne megtanulni az anyagot, hanem máshonnan. Az, hogy Odom pöpecül megírta a ROUTE-t és ezzel elég sok időt takarít meg az emberek számára, az egy becsülendő dolog és részéről elég jó pont.
Viszont van olyan könyv, amiből a switch-palánták tanulni tudnak, az pedig ez.Egyelőre nem bántam meg, hogy beleolvastam
. Sot mar tobbet mint a brusszeli zako utan 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
kezdek berágni. Úgy megkevertem...
Új hozzászólás Aktív témák
Hirdetés
FecoGee
crok- 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!
- új, bontatlan, iPhone 16E gyárilag kártya-független, apple világgaranciával
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 1TB SSD Radeon Pro 5500M
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 2TB SSD Radeon Pro 5600M 8GB
- MacBook Pro 14" M1 MAX - 32GB / 1TB (2021) - 1 év garancia
- MSI RTX 4070 SUPER 12GB GAMING X SLIM WHITE - 20 hónap garancia
- BESZÁMÍTÁS! MSI B450 TomaHawk R5 3600 16GB DDR4 512GB SSD RX5500 XT 8GB Rampage SHIVA TT 530W
- Bomba ár! Lenovo ThinkPad L380 - i5-8GEN I 8GB I 256SSD I 13,3" FHD / MT I HDMI I Cam I W11 I Gari!
- Bomba ár! Dell Latitude E5570 - i5-6300U I 8GB I 256GB SSD I 15,6" FHD I HDMI I CAM I W10 I Gari!
- ÁRGARANCIA! Épített KomPhone i5 13400F 32/64GB RAM RX 7700 XT 12GB GAMER PC termékbeszámítással
- AKCIÓ! Apple MacBook Pro 16 M4 Pro - M4 Pro 24GB 512GB SSD garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest