- Bemutatkozott a Poco X7 és X7 Pro
- Yettel topik
- Magyarított Android alkalmazások
- Hónap végén érkezik a Xiaomi Band 10, ára is van
- iPhone topik
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- Google Pixel topik
- Milyen okostelefont vegyek?
- Fotók, videók mobillal
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
-
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
-
FecoGee
Topikgazda
tusi_, nem vicc, ez ra a kifejezes!
En hasznalok E1-et, jobban szeretem az E2-nel, bar a legtobb esetben nincs jeelntosege. De jobban tudom befolyasolni a traffic flow-t (meg ha nem is kell, de megtartom a lehetoseget).
EIGRP-t is lattam mar elesben. 4 routeres haloban
-
oleeg
tag
Szia!
Köszönöm, a baj csak az, hogy esnek ki részek. Valamelyik nap előkerült a Type 4 LSA használata az E2 vs E1 metric-type -nál, aztán csak gondolkodtam, hogy is van, miközben ezt pedig többször átnéztem, mert kevésnek éreztem a magyarázatot a könyvben. Na mindegy. Készülök a TSHOOT-ra az OCG-ből, szerencsére ott is van bőven ismétlés. Ha minden jól megy akkor jövő héten csütörtökön megyek.
Amúgy nekem a ROUTE nagyon tetszett és szerettem, a SWITCH-ről nem tudom már ugyanezt elmondani.
Üdv:
o
-
zsolti.22
senior tag
De, az. Nekem most 3750-re vannak kötve predátor routerek, amik a hosztok és úgy emlékeztem - de leírni már nem mertem, mert nem voltam benne teljesen biztos -, hogy köze van a portfastnak és a bpduguardnak a Port Type Incosistenthez, viszont ha a 3750 észleli, hogy bpdu-t kapott access porton és err-disable-be teszi a portot, akkor nem ír semmit a show spanning-tree inconsistent kimenetbe. Korábban lehet, hogy a 3550-en próbáltam...
Megoldani meg annyi, hogy BPDU-t forgalmazó eszközt felgyújtani, és sh no sh után mindenki boldogUgyanez amúgy a TSHOOT könyvben is benne van.
-
FecoGee
Topikgazda
A BKN az BlocKiNg.
Most rákerestem és nem egészen csak az, amit írtam. Ezeket találtam:
There can be different types of STP inconsistencies:
Loop inconsistency—This is detected by the Loop Guard feature. For more information, refer to Spanning-Tree Protocol Enhancements using Loop Guard and BPDU Skew Detection Features.
Root inconsistency—This is detected by the Root Guard feature. For more information, refer to Spanning-Tree Protocol Root Guard Enhancement.
EtherChannel inconsistency—This is detected by the EtherChannel consistency detection feature. For more information, refer to Understanding EtherChannel Inconsistency Detection.
Port VLAN ID (PVID) inconsistency—A per-VLAN spanning tree (PVST+) Bridge Protocol Data Unit (BPDU) is received on a different VLAN than it was originated: (Port VLAN ID Mismatch or *PVID_Inc).
Type inconsistency—A PVST+ BPDU is received on a non-802.1Q trunk.
http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24063-pvid-inconsistency-24063.html
-
FecoGee
Topikgazda
"- edge portok RSTP-ben vannak, ide PC csatlakozik pl., és hogyha valami oknál fogva ez az edge port portfasttal van konfigurálva, akkor amint BPDU érkezik be a portra, akkor az már nem edge port lesz, hanem normál STP port (nade a portfastnal alapból van bpduguard is, akkor ez meg így nem igaz
)"Igen, kivéve a bpduguard részt. Portfastnál:
- ha interface level, akkor normál STP lesz
- ha global, akkor is (ez csak annyit csinál hogy nem kell interface range-re rakni a konfigot, hanem minden access portra ráteszi)"- ha a porton van bpdufilter, akkor ott se ki se be nem megy BPDU, nem történik semmi az edge porttal, ha azon bpdu érkezik be a bpdufilteres portra (mert elvileg a STP nem is fut a porton - de nekem még így is fut...wtf)."
Akkor nem megy ki és jön be BPDU, ha interface-re konfiugurálod a bpdufiltert. Ekkor bármi történik, megy rajta a forgalom. Szép hurok ki tud alakulni. Ha globalban konfigolod, akkor kiküld 11 BPDU-t (azért 11, mert a hello time 2 sec, maxage 20, és 11x2 = 22, szóval tuti meghallja a másik oldal). Ha kap rá választ, normál STP port lesz.
"- ha a show spa incosistentport parancsban Port Type incosistent sorokat látunk, akkor az a portfast+bpduguard miatti és sh no sh-val lehet rendbe hozni (a show spa TYPE incosistent-et ír majd a porthoz és discarding lesz a port)"
Ez inkább az, hogy superior BPDU jön a porton, de nem jöhetne. Pl. mikor MST régióban nézel egy switchet, de a PVST+ domaiben van a root. Mivel nem lehet a root a domainen kívül, ezért Inconsistent lesz a port.
"- PVST-ben nincs olyan, hogy edge port kimondottan"
Nincs. Ez csak RSTP-ben van. Lenyúlták a Cisco portfast feature-t és szabványosították egy hangzatos névvel.
-
zsolti.22
senior tag
Próba cseresznye
Ugyanitt firmware is van. Nálunk mondjuk anno az e1752-es stickekkel volt a baj, hogy openwrt router alól van, hogy random elbontotta a netet, de ezen a fw mondjuk segített
Őket amúgy azóta utáltam meg, amióta átálltunk a vodára és pont azóta nem ment eleinte a viber...nekem senki ne korlátozza, mit használok, mit nem..![;]](//cdn.rios.hu/dl/s/v1.gif)
-
crok
Topikgazda
Hát nekem sajnos majd' mindent fejből *kell* tudni, mert az ügyféllel kapcsolatban kb. egy törvényszerűség van csak: "Mindig félrevezet, mert azt akarja, hogy csak vele foglalkozz és azt hiszi, hogy így fog sikerülni csak.".
Nincs centrális management hanem helyi contol gép van? Elég fura.. mindenesetre akkor lentről felfelé mész és nézed a utilisation-t.. az elv attól még ugyan az.
-
crok
Topikgazda
A routerek alatti legmagasabban levő switchek általában azért elérhetőek - legalábbis nálam még mindig elérhető volt valamilyen (max. baromilassú) szinten. (Ha nem akkor volt mindig "Adidas" - valaki kiment és console + Webex megosztás = never fails.) Storm- és broadcast control:még ha be is kapcsol a mechanizmus 2 lehetőséged van akcióra: shutdown és trap.. a shutdown túl sok (mondjuk megtörné a loop-ot valószínűleg), a trap meg túl kevés.. A megoldásom: MQC QoS a Core switch uplinkeken és a routeren is. A telnet/SSH traffic ha routerről van indítva akkor az alap DSCP jelölés az a CS6 (IP Prec. 6; egyébként átírható a local-policy-vel), ezt érdemes megtartani a management area-ba/-ból is hiszen erre már lehet alapozni egy jó kis MQC QoS konfigban: elkerítesz némi sávszélt management-re a core felé a router felől (ez nem befolyásolja a loop alatti kommunikációt de alapból jó ha van, hisz' a loop miatt azon a linken inkább csak core->router forwarding van) valamint elkerítesz némi sávszélt a router felé a core felől - így mindig lesz egy kevés sávszéled telnetre/SSH-ra a loopoolt forgalom közt (mert a loop okozta forgalom is a QoS szabályai alá esik, szóval abból is dob ha megkéred rá). Ez nem instant megoldás - ezt már a tervezéskor alapértelmezetten kell csinálni, mindenhol, okosan, előre.
-
-
crok
Topikgazda
Egy vizsgalehetőséget minden vizsgából áll a cég, felkészülni meg szerintem jobb magad. Plusz van lab, nem óriási, de egy jó közepes, az INE CCIEv4 pl. egyben van, van egy sandbox 4 routerrel és 4 switchel (külön rack de bármikor kombinálható, én felügyelem (: meg egyéb más is van (: Tanulni On-The-Job módszerrel szerintem sokkal jobb, mert rá is vagy kényszerítve, hogy csináld és nézz utána - ennél jobban nem tudod megtanulni szerintem - plusz fizetést kapsz érte. A vizsga meg úgyis mindig célirányos - egy jó szakember úgyse a certekről ismerszik meg hanem a megoldásairól, módszereiről.
-
crok
Topikgazda
Első blikkre:
(config)# logging source-interface [interface]
[Szerk.] Meg még ez. -
crok
Topikgazda
Tippre a gépednek nincs routing infoja hogy hol van R2 192.168.2.2 vagy
ha van akkor rossz (mondjuk a Def.GW nem kifejezetten R1 hanem még
mindig a netes routered) - valamint ez a helyzet visszafele is élhet, vagyis
R2-nek van-e megfelelő útja a gépedhez (R1 Fa1/1 interface-e szintén a
VRF-ben van-e vagy van-e route-leaking csinálva ha mégse abban a VRF-
ben van (vagy a globálban van?)). Első blikkre.. -
crok
Topikgazda
Először is bocs, hosszabb lett mint számítottam - ne alkalmazz TL;DR-t (:
Na, már értem a kérdést - ez egy nagy design fail (:
Ilyet nem szabad csinálni.. akkor a core és a dist közt van vagy n+1 OSPF
neighbor? Jó-jó, a C6500 jó vas, elbír egy ekkora LSADB-t de azért mégis.. (:A másik kérdésem: hogy jön a képbe a VRF? Úgy értem VRF-et meg nem
szokás a core-ba téve használni. Az külön rétegben van megoldva, felette. Ha
a LAN-ban szét akarod választani, akkor megteheted, hogy a core uplinkeket
felpattintod ebbe a "WAN" rétegbe, egy trunk-ön minden VRF-re egy-egy SVI
-al.. aztán több megoldás is kínálkozik a szétválasztásra lent, onnantól, hogy
szűrhetsz/szabályozhatsz mondjuk egy-egy bump-on-the-wire tűzfallal úgy,
hogy minden VLAN külön context; vagy pl. eleve lehet egy-egy FWSM (tudom,
régi..) a core-okban, minden VLAN-t felpattintasz az FWSM-re, minden VRF-
re külön context; vagy akár a trunk-ökön levő SVI-okat mindet más-más
OSPF process alatt indítod a dist rétegben, minden process alatt megadhatod
hogy melyik network melyik process alatt legyen és hogy milyen area-ban így
elválaszthatod a VRF-eket de természetesen nem viszed fel az STP-t a core-ba
(mert lehet hogy már ott is lassan VSS-t használnál (: és ha akarod akkor leak-
elhetsz prefix-eket a core-ban is, a "WAN" rétegben is, a dist-ben is.. Én a
WAN-ban leak-elnék ha kellene (majd a tűzfalak megfogják amit meg kell, arra
vannak véve..), alatta meg core-ban minden SVI-t azon OSPF process alá
vennék fel amelyikbe lent és fent tartozik így szétválasztva a LAN-ban a
globális VRF-eket - kifelé a WAN réteg általában úgyis eBGP, akkor meg a
LAN mehet valamilyen kiforrott de lehetőleg gyártófüggetlen IGP-vel (OSPF,
mert ugyan az EIGRP már "nyílt" de nem bízom benne, hogy más gyártók
hogy írják meg a maguk programját.. a Cisco is tele van hibákkal.. a RIP meg
nem valami elegáns megoldás már) így ha platformot váltasz se lesz bonyolult
a migráció. Ez persze csak addig okos amíg IPv4-et akarsz használni, de
azért az IPv6 már más kérdés lesz úgyis (: ezerféleképp lehet egyszerűsíteni
de bonyolítani is - minden az ügyfél kívánalmaitól függ. Ha te írhatod a saját
kívánalmaidat az k#>&ajó mert lehetsz kreatív - persze Occam borotváját
vedd elő mert nem árt az operációt és az ott dolgozókat is figyelembe venni (: -
crok
Topikgazda
Nos igen - a helyzet a következő: valaha, mikor még nem volt VSS ez
egy jó kis megoldás volt, pl. 4 eszköz összekötve az alábbiak szerint:+----------------+
| |
| WAN/MPLS/Etc.. |
| |
+-+------------+-+
| |
+----+---+ +---+----+
| Core A +----+ Core B |
+----+---+ +---+----+
| \ / |
| \/ |
| /\ |
| / \ |
+----+---+ +---+----+
| Dist A +----+ Dist B |
+----+---+ +---+----+
| \ / |
| \/ |
| /\ |
| / \ |
+----+---+ +---+----+
| Acce A | | Acce B |
+--------+ +--------+VSS nélkül, DIST és CORE közt L2 linkek SVI-okkal működtetve.
Jó, mert van benne redundancia, lehetnek az uplinkek etherchannel-
be kötve, mehet rajta egyszerű static routing HSRP-re mutatva, etc..
Egyszerű, mint egy százas szeg.. bár pazarlás is egyben..Routing megegyezés szerint mondjuk OSPF, DIST layer minden
utat küld de CORE csak egy default-ot injektál be (megint meg-
egyezés szerint vagy equal path load-balance vagy pri+sec).NA.. jön az okosság, Cisco VSS. Átállás, migráció szükséges.
Összehúzzák a DIST réteget és a CORE-on semmit se kell majd
változtatni (kvázi) - transzparens lesz a dolog, csak 2 helyett 1
OSPF neighbor lesz DIST felé.[Bár az eredeti felállás már ma nem szokásos]
Ha esetleg érdekel, akkor Design Zone for Campus @Cisco.com -
-
Gesztiboy
tag
A tunnel kiépülésénél az az ASA lesz az initiator, ahonnan az interesting traffic "első csomagja" jön. Pölö ASA1 mögül elkezded pingelni az ASA2 mögötti gépet, akkor az ASA1 lesz az initiator és az ASA2 a responder. Átkapcsolni szerintem úgy lehet, ha lebontod a tunnelt és ASA2 irányából indítasz egy pinget
-
Gesztiboy
tag
"1 órája pingelem az ASA-ról a tunnel endpoint routert és nuku" - Korábban csináltam site-to-site VPN-t ASA-k között és hasonlót én is szívtam. ASA-ról pingelve nem épült ki a tunnel. Asszem az segített, ha egy, az ASA mögött lévő gépről végeztem el a pinget. Ne kérdezd miért, így működött (ha jól emlékszem)
-
crok
Topikgazda
-
FecoGee
Topikgazda
A TSHOOT az gyilkos. Itt a pelda topologia a Cisco Live-rol a v5-hoz.
https://ccie4all.files.wordpress.com/2014/06/cciev5_tshoot.png
Ticket 1 peldaul legyen (en talaltam ki) hogy R30 (mire megtalalod fel perc) nem tud telnetelni R29-re. Es ez egy kozepes nehezsegu ticket. De az MPLS-ben meg szebb ticketeket tudnak kitalalni.
-
FecoGee
Topikgazda
En is ezt mondtam, megis neki futottam. Nem vagyok benne biztos hogy evek tapasztalataval ANNYIVAL kozelebb vagy a sikeres vizsgahoz. Persze szamit, de nagyon jok a workbook-ok, ha erted a technologiat eselyes szerintem komolyabb tapasztalat nelkul is. Sok 0 perces CCIE van a piacon (foleg India, Kina). Mas kerdes hogy mikor munkat keres hatranyban lesz. De a vizsga leteheto.
-
FeRkE
őstag
-
#7075
Hedgehanter
őstag
tusi_
#7061
Hedgehanter
őstag
Nem proxy arp a hibas.. Kikpacsoltam minden letezo helyrol es meg mindig kapom az IP-t a wrong range-bol. Csinaltam egy teszt vlan-t kiszedtem a trunk port-bol az uj vlan-t connect laptop es jon a rossz IP. Wireshark ban latom hogy DHCP requestre jott a valasz a servertol...
IP helper sincs sehol..
! Azert par eve en is toltam 70 oras munkaheteket 
. Persze ebben volt boven tanulas is.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Jó tudni ilyesmit.
Ú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!
- A fociról könnyedén, egy baráti társaságban
- Gigabyte alaplap topik
- Hegesztés topic
- DVBViewer
- Kazy Computers - Fehérvár - Megbízható?
- Autós topik látogatók beszélgetős, offolós topikja
- Max
- One otthoni szolgáltatások (TV, internet, telefon)
- Path of Exile (ARPG)
- AMD Navi Radeon™ RX 9xxx sorozat
- További aktív témák...
- BESZÁMÍTÁS! Samsung Galaxy A34 5G 128GB mobiltelefon garanciával hibátlan működéssel
- Bomba ár! Lenovo ThinkPad X270 - i5-6G I 8GB I 256GB SSD I 12,5" FHD I HDMI I Cam I W10 I Garancia!
- BESZÁMÍTÁS! ASRock H310CM i3 9100F 8GB DDR4 240GB SSD 1TB HDD GTX 1060 3GB AeroCool Strike-X 500W
- BESZÁMÍTÁS! MSI B450M R5 5500 16GB DDR4 512GB SSD RTX 2070 8GB Rampage SHIVA FSP 650W
- BESZÁMÍTÁS! ASRock A520M R3 3100 16GB DDR4 512GB SSD RX 6500XT 4GB BitFenix Neos Thermaltake 500W
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest