- Android alkalmazások - szoftver kibeszélő topik
- Mobil flották
- Google Pixel topik
- Külföldi SIM-ek itthon
- Hónap végén érkezik a Xiaomi Band 10, ára is van
- Motorola Razr 50 Ultra - ajtó, ablak
- Xiaomi Mi 11 Ultra - Circus Maximus
- Apple iPhone 16 Pro - rutinvizsga
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 - és mégis mozog a kép
-
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
-
-
#7392
oleeg
tag
sunyijanika
#7391
oleeg
tag
válasz
sunyijanika
#7391
üzenetére
Szia!
Nekem az gyanús, hogy ügyfél forgalom nélkül nincs csomagvesztés.
Ez tipikusan akkor fordulhat elő ha mondjuk van egy Ethernet vonalad amit átadnak mondjuk FastEth vagy GigEth interfészen, de vonali sávszélesség igazából csak az interfész sebességének töredéke és a szolgáltatói vonal nem tolerálja burst -öt. Nálad szerintem mindenképpen probléma lehet, hogy az egyik interfész FastEth a másik pedig GigEth. Ilyenkor az eszköz képes elárasztani (forgalom burst-ös jellege miatt) úgy a vonalat, hogy csomagvesztést tapasztalsz. De ha nincs forgalom a vonalon akkor akár 100e vagy 1m ping is hiba nélkül visszajön. Az interfész számlálók (drop) pedig tiszták. Ilyenkor egy egyszerű shape segíthet melyet mindkét WAN interfészre outbound irányba ráírsz, feltéve, hogy a platform támogatja és még amúgy sincs semmilyen QoS a vonalon.
Utána érdemes ellenőrizni a policy-map -ot a sh policy-map int <interfész neve> paranccsal működés közben a Queueing rész nézni ahol a (queue depth/total drops/no-buffer drops) 0/0/0 mutatja, hogy ha a shape aktív. Ha a látszik, hogy a default (64 packet) queue limit nem elegendő és emiatt továbbra is dobál akkor növeld a queue limit értékét. Rossz esetben nem lesz már csomagvesztésed, de a válaszidő akár több másodperc is lehet
o
-
#7390
oleeg
tag
sunyijanika
#7389
oleeg
tag
válasz
sunyijanika
#7389
üzenetére
Szia!
LL milyen technológia és milyen sávszélesség?
Üdv:
o
-
#7389
sunyijanika
tag
crok
#7388
sunyijanika
tag
kipróbáltam az említett pattern-ket, de hibátlan mind. Az issue főleg akkor tapasztalható ha az ügyfél forgalom van a vonalon, ha átkapcsolom akkor hibátlan a LL a teszt nem mutat semmit. viszont az ügyféllel se szórakozhatok ugyebár..
valóban a scrambleing jó megközelítés lehet és az MTU-t is ellenőrzöm.
Köszöntem!
-
#7388
crok
Topikgazda
sunyijanika
#7387
crok
Topikgazda
válasz
sunyijanika
#7387
üzenetére
1. kétlem, hogy a LAN *ethernetek és nem fognak 1500-ra darabolni.
2. esetleg a local loop eth-over-sdh és az sdh "user" MTU-ja 4460-ra van lőve.Esetleg amit kérj: payload vagy line scrambling-et az SDH vonalra.
Valószínű a csomag még talán meg is érkezik de valszeg keret szinten
van bithiba (könnyen előfordul és reprodukálható, tesztelhető).
Én spec ezt csinálnám, az eredmények megmondják mi lehet a cink:ping <IP> df si 1500 re 10000 ti 1 da abcd
ping <IP> df si 1500 re 10000 ti 1 da 0000
ping <IP> df si 1500 re 10000 ti 1 da ffff
ping <IP> df si 1500 re 10000 ti 1 da 8888Az első (default) ping data egyfajta "kvázirandom" bithalmaz: 1010101111001101.
A második a csupanulla. (SAP csomagok sokszor tartalmaznak '0' padding-et).
A harmadik a csupaegy. Az utolsó pedig 1000100010001000.
Ezekkel szokott általában minden vonal "szarakodni".
Ha valahol valamelyik "médiát átalakító eszköz" (DSLAM pl..) vagy multiplexer
(SDH MUX, soros repeater) szarul végzi a dolgát akkor ezekkel általában kijön. -
#7387
sunyijanika
tag
sunyijanika
tag
Sziasztok,
Az egyik client packet loss issue-val küzd az egyik LL. Annyit kiderítettem, hogy a transmitter pathval lesz valami, mivel elkezd dobálni 4461 bytes Lan-to-Lan csomagoknál viszont megy 4460al, receiver az OK. de ügyfél traffic-el akár 1500 is dobál a LL.-on. Másik path megy szóval nem a Lan vagy a Backbone.
A kérdés: milyen bottleneck okozhatja ezt a 4460 bytes-os határt? mielőtt belevetném magam dobjatok néhány tippet
-
FecoGee
Topikgazda
-
#7382
fogi
tag
Hedgehanter
#7376
fogi
tag
válasz
Hedgehanter
#7376
üzenetére
Meg is érkezett, köszönöm!
-
Gesztiboy
tag
válasz
Hedgehanter
#7376
üzenetére
toldacuccot szerintem okés lenne a feladatra
-
#7377
fogi
tag
Hedgehanter
#7376
fogi
tag
válasz
Hedgehanter
#7376
üzenetére
Húú, de jó.
Ezzel?
http://indabox.hu/
ide: tux kukac index pont huNagyon köszönöm!
-
#7374
Ygg
senior tag
suomalainen
#7371
Ygg
senior tag
válasz
suomalainen
#7371
üzenetére
S mondja még valaki, hogy érdemes tanulni...
-
#7373
tusi_
addikt
suomalainen
#7371
tusi_
addikt
válasz
suomalainen
#7371
üzenetére
-
#7372
Cyber_Bird
senior tag
suomalainen
#7371
Cyber_Bird
senior tag
válasz
suomalainen
#7371
üzenetére
Van benne valami
-
#7371
suomalainen
tag
suomalainen
tag
-
bugizozi
őstag
Sziasztok!
Cisco ASA 5505 típusú eszközön szeretnék beállítani VPN-t de nem igazán sikerült
Cisco ASDM-IDM Launcher-rel próbálom összekattingatni eme videó alapján, a Cisco VPN Client csatlakozik, viszont a belső hálót nem érem el.Hálózat: (az ip címeket nem akarom kiadni a nagyvilágnak úgyhogy ezek kitaláltak)
Inside network (10.10.10.0/24) - ASA - Outside network (172.16.0.0/24)
Az IP pool ahonnan a VPN kliensek kaphatnak IP-t: 192.168.0.0/24
Rádugtam egy-egy számítógépet a belső és a külső hálózatra, beállítom az ip-ket, a külső hálózatról becsatlakozom, de nem tudom onnan pingelni a belső gépet. Ha mindkét gép a belső hálón van akkor megy a ping.
A videó alapján mennie kéne a dolognak? Milyen infot (pl parancs kimenetek) szolgáltassak, ami alapján esetleg lehet nekem segíteni?!
Köszönöm!
-
#7358
Cyber_Bird
senior tag
Cyber_Bird
senior tag
Nah erdekes dolgot talaltam.
Uj gns3-ban IOU-val kiserleteztem, es osszeraktam egy topologiat, amiben a default-networkot akartam eigrp-n keresztul propagalni a tobbi routerre a border routeremrol:R1-----R2------R3
R1-en volt a default network, 192.168.100.1/24 felhuzva a loopbackra, ezt eigrp-vel hirdettem tovabb R2-nek egy masik C osztalyu halozaton. R2-n ip default-network 192.168.100.0, ahogy illik lett is gateway of last resort, es a routing tablaban latszik a candidate default. viszont R3-n nem lesz beallitva a gateway of last resort, bar a route megerkezik eigrpn: D* 192.168.100.0/24 [90/435200] via 192.168.3.2, 00:01:08, Ethernet0/1
Kezdtem mar aggodni, hogy en vagyok a hulye( ez mondjuk igy sem kizart) ugyhogy osszeraktam hagyomanyos gns3-ban dynamips alapokon, ahol ugyanez a konfig, csodaszepen mukodik es beallitja a gw os last resortot R3-on is
IOS minden esetben 12.4, eigrp no auto-summary-val konfigolva.
Valaki mas is belefutott ilyesmibe, vagy csak en benazok?
-
f_sanyee
senior tag
hi,
eleg reg jartam mar itt, de latom a kemeny mag az ugyanaz mint 2-3 eve
februarban lejar ccna-m, arra gondoltam, hogy megcsinalom a ccna securityt.
eleg ehhez gns3, vagy van benne olyan amihez kell mondjuk asa?sysadminkent dolgozom, de networkos tudasnak sokszor hasznat veszem, nem tudom erdemes e veszni hagyni ccna-t
-
#7356
Cyber_Bird
senior tag
zsolti.22
#7354
Cyber_Bird
senior tag
válasz
zsolti.22
#7354
üzenetére
Bocsi, irasban neha nem jon at nekem
Amugy ezekkel egyszer okorkodtunk egy ciscos emberkevel, eloadast tartott az asr9k feature-eitol, es valahogy elojott talan a kapcsolo, vagy forgalomiranyito szo, es elkezdte onnantol forditani ezeket a kifejezeseket.
1.5 perc utan rohogesbe fulladt
Biztonsagos aljzat reteg volt az utolso ami meg remlik -
#7355
quby
őstag
Cyber_Bird
#7352
quby
őstag
válasz
Cyber_Bird
#7352
üzenetére
NYULE vazzzegg....ezen vinnyogok egy negyed órája....
Mellesleg a netacademy CCNA discovery-je is megvan magyarul. Abban voltak "kapcsolók" meg "útválasztók" meg "átviteli közeg elérés vezérlési cím"... -
#7354
zsolti.22
senior tag
Cyber_Bird
#7352
zsolti.22
senior tag
válasz
Cyber_Bird
#7352
üzenetére
Nem jött át az irónia?
-
#7353
FeRkE
őstag
Cyber_Bird
#7352
FeRkE
őstag
válasz
Cyber_Bird
#7352
üzenetére
+1. Semmi értelme lefordítani, meg így megszokni a szakszavakat, szakmai körökben is vicces szerintem, ha valaki magyarul nyomja ezeket, például konferenciákon se nagyon hallom, hogy fordítanák a dolgokat.
-
#7352
Cyber_Bird
senior tag
zsolti.22
#7351
Cyber_Bird
senior tag
válasz
zsolti.22
#7351
üzenetére
Lehet en vagyok tul angloman, de STP inkabb. Vagy akkor ne alljunk meg itt, pl az iranyito protokollok:
Nyilt Legrovidebb Ut Eloszor(NYLUE),Fejlesztett Belso Atjaro Protokoll(FBAP)...
Az IT nyelve az angol szerintem, es valahogy bantja a szemem/fulem, ha ezeket magyarul hallom. -
quby
őstag
válasz
zsolti.22
#7348
üzenetére
Én most kezdek CCNP-re tanulni. Szép lassan öregurasan. Minden doksi jól jön, ha csak helyesirási hibák vannak az nem érdekel. Ha nem irsz olyanokat mint amit ma hallottam akkor nem lehet gáz (ma egy okos
barátomismerősöm közölte hogy márpedig az STP az routing protokol). Mindig tanul az ember.
-
#7345
tusi_
addikt
Hedgehanter
#7344
tusi_
addikt
válasz
Hedgehanter
#7344
üzenetére
Peg van, TAC lett belöle
-
A_ScHuLcZ
addikt
Szerintetek le lehet valahogyan menteni az online PT vizsgákat, miközben csinálja az ember, és meg vannak nyitva a gépen? Gyakorlásnak szánom, hogy ha nem úgy sikerül, ahogy szeretném, akkor itthon nekifutnék még1x, hogy lássam mit rontottam el.
Tehát konkrétan arra gondolok, hogy miközben megnyitjuk a PT feladatot a webről a saját gépünkön, feltételezem valahová (pl a temp mappába) letöltődik a pka fájl, hogy meg tudjon nyílni, ezt pedig le lehetne menteni. Nyilván a PT-n belüle Save as funkció le van tiltva, ezért szeretném másképp menteni.
Ui: nem igazi vizsga PT, csak a netacad-os tananyag PT vizsgái.
-
#7339
FeRkE
őstag
Cyber_Bird
#7338
FeRkE
őstag
válasz
Cyber_Bird
#7338
üzenetére
Kolléga belökött az egyik ticketbe véletlen egy Nemzeti Sport linket
Főnök 5 perc múlva írta is neki, hogy érdekes ticket update
-
#7337
zsolti.22
senior tag
Cyber_Bird
#7336
zsolti.22
senior tag
válasz
Cyber_Bird
#7336
üzenetére
Jó persze, előfordul elég sűrűn itt is, de eddig a csikó vitte a pálmát
-
zsolti.22
senior tag
Ismét HSRP. Adott az alábbi topológia. Tegyük fel, hogy SW1-en trackelve van a Gi5/1. Ha ez lemegy, akkor -10 a prioritásból, így a SW2 lesz az aktív VLAN 150-re. Viszont ha az adminisztrátor követte azt a logikát, hogy SW1 nemcsak az aktív átjáró, de a root bridge is a VLAN150-re, akkor jelen esetben a tracking miatt a csomagok kerülőúton fognak eljutni az SW2-höz, igaz?
Mivel a 2. sorban lévő switcheknek a root portja az SW1 lesz, azért minden csomag át fog haladni SW1-en, de mivel nem ő az aktív, ezért megy tovább a csomag SW2-nek, majd újra vissza SW1 és úgy vissza a küldőhöz. Jól látom? -
-
-
Mr.csu
csendes tag
én is ezt tapasztalom.A suboptimal route rendben van ,mondhatni természetes hogy default beállításokkal az 110-es AD-jű útvonalat használja.Az a nem természetes hogy a másik boarder router nem azt választja. Ő milyen szabály szerint választja a rosszabb AD -jű útvonalat???
-
Gesztiboy
tag
-
Mr.csu
csendes tag
Redistribout működésével kapcsolatban nem értek valamit ha vlaki tud segítsen légyszi mert az őrületbe kerget hogy sehol nem találom rá a választ.
Rajzoltam egy fapados ábrát.R4 injektálja 10.0.0.0 hálózatot EIGRP-be external routként, amit R2 és R3 redistribouttal hirdet OSPF-be ,tag-el szűrök hogy ne hirdetődjön vissza EIGRP-be.R3 a 10-es hálózat felé hall egy hirdetést R2-től R1-en keresztül AD 120-al ,R4 felől AD 170-el.Ugyanez igaz fordítva R2-re.Elméletem szerint tehát R2 és R3 is az OSPF felől hallott kisebb AD-jű útvonalat írja a routing táblájába,hurkot okozva R2 és R3 között.Egymásnak kellene dobálniuk a 10-es hálózat felé menő csomagokat amíg az OSPF external routok AD-ját legalább 171-re fölviszem.
DE NEM!! MŰKÖDIk default 110-el!!R2 és R3 küzül legalább az egyik mindig az R4 felé néző 170-es Ad-vel rendelkező útvonalat írja a routing táblájába.
Miért?Miért? Mi veszi rá R2-t R3-at hogy a nagyobb AD-vel rendelkező útvonalat írja a routing táblájába??
-
zsolti.22
senior tag
Most jutottam el odáig, hogy próbálgatom a HSRP-t, de csak a v1-et. Egyelőre a CCNP SW Simplified alapján csináltam és ott írtak le olyat, hogy a v1 nem kezeli a msec időzítőt (vagyis a hello üzenetekben csak egész számok vannak, mondjuk ezt még nem sikerült ki-vájörsárkolnom). Ezzel ellentétben a valóságban megy szépen. A másik, hogy egyik switchen meg van adva a standby 1 ip 192.168.40.254 parancs, a másikon csak simán standby 1 ip, és simán tudja így is, hogy mi a virtuális IP anélkül, hogy megmondanám neki.
Lesz itt még mit beírogatni a jegyzetfüzetbe =)
-
robesz87
tag
válasz
FecoGee
#7322
üzenetére
Végülis loopot csináltam arra az útra, ahol lerontottam a metric-et, ezért kikerült még az "all-links" eigrp táblából is, de valahol azt olvastam, hogy a "Show ip eigrp topology all-links" kimenet tartalmazza az összes utat ( nem csak az S-t és FS-t ), hanem még azokat is, amik loopot okozhatnak, amíg a jelenlegi S út fent van. Ezek szerint ez nem így van, vagy IOS függő.
-
-
#7321
Cyber_Bird
senior tag
quby
#7317
Cyber_Bird
senior tag
-
robesz87
tag
Sziasztok!
Egy kis magyarázatra lenne szükségem a következő EIGRP jelenséghez.
2 route van egy hálózathoz.
R1#sh ip eigrp topology all-links | begin 172
P 172.16.1.8/30, 1 successors, FD is 307200, serno 16
via 10.1.1.2 (307200/281600), FastEthernet0/0
via 14.14.14.4 (332800/307200), FastEthernet0/1A parancs elvileg listázza az összes utat.
"The show ip eigrp topology all-links command lists all possible routes, including
those that are neither successor nor feasible successor routes."Ha elkezdem rontani az egyik route metricáját, akkor az egy idő után kitörlődik még ebből a database-ből is.
Ebben a példában pl. akkor, amikor a delay-t a duplájára növeltem. ( alapból 100 )1,
R4(config-if)#delay 199R1#sh ip eigrp topology all-links | begin 172
P 172.16.1.8/30, 1 successors, FD is 307200, serno 16
via 10.1.1.2 (307200/281600), FastEthernet0/0
via 14.14.14.4 (358144/332544), FastEthernet0/12,
R4(config-if)#delay 200R1#sh ip eigrp topology all-links | begin 172
P 172.16.1.8/30, 1 successors, FD is 307200, serno 16
via 10.1.1.2 (307200/281600), FastEthernet0/0Nem találtam erre magyarázatot, esetleg tudjátok? Mikor válik egy route "impossible"-é?
Köszi előre is.
-
quby
őstag
válasz
Gesztiboy
#7312
üzenetére
Ez igen érdekes amúgy. A minap a következőbe futottam.:
Még CCNA előtt regeltem a pearsonvue-n hogy megnézzem a felületet stb. Majd mikor ténylegesen jelentkeztem a vizsgára újra regeltem (ne kérdezzétek miért, régen volt) Aztán mivel egy ideig nem vizsgáztam nem jártam arra, természetesen elfelejtettem a user/pass-t.
Új jelszó kérése előtt még próbálkoztam egy kicsit és hopp beengedett. Akkor még nem vettem észre hogy az első reg-el létrehozott accountba engedett be. Végigcsináltam a CCNAS -re való jelentkezést (aminek ugye előfeltétele a CCNA) és már a fizetésnél jártam amikor kiderült hogy nem is jó cisco id-vel vagyok bent (az első accountnál még ez nem stimmelt), és ez is ugy derült ki hogy nem fogadta el a voucheremet. Amikor kiderült csak próbaképp továbbcsinltam, és már a fizető felületen voltam ahol kártyaszám stb jön.Szóval simán engedett jelentkezni egy CCNAS-re egy olyan acc-al amiben nem volt meg az előfeltétel. Ahoz az acchoz ugyanis nem tartotzott CCNA. Kiváncsi vagyok ha véletlenül fizetek akkor ez hogy és mikor derült volna ki. Mert ha nincs voucherem simán jelentkezek a rossz acc-al.
(#7315) FecoGee
Én ugy tudom 2 év lehet az első és utolsó között. -
tusi_
addikt
Route utan van 3 eved a Switchre, aztan megint 3 eved a Tshootig.
Rgo CCNA utan 9 even belul megszerezheted a CCNP-t.
Gesztiboy: ettol felek en is, bele is irtam a tiketbe, hogy a STP loop es missverkabelung kizart.
Ha olvassa a mailt, remelem utananez es kiderul, hogy megis csak felre ment az a kabel.
Ha meg nem az a baj, akkor lehet eppen millio mas is....
-
-
Gesztiboy
tag
Ha CCNP-ből 1 vizsgát megcsinálsz, az automatikusan meghosszabbítja a CCNA-t, újra 3 évig érvényes lesz. Kb. 2 hónap után megcsinálsz még egyet, újra 3 év lesz. Megcsinálod az utolsót, ismét 3 év és megvan a CCNP, szintúgy 3 év érvényességi idővel. Igazából addig van időd, amíg a CCNA-d le nem jár. Ha lejár, akkor kezdheted CCNA-tól újra az egészet (tudomásom szerint)
tusi_: Tapasztaltam már olyat, hogy rámondta, "jó" helyre dugta vissza és a végén kiderült, mégsem...
-
tusi_
addikt
válasz
FecoGee
#7300
üzenetére
Kihuzza a kabelt. Allitolag villog, de azt nem tudta megmondani, hogy milyen gyorsan, csak pislog, vagy szinte vilagit folyamatosan. Kertem is az ügyfelet, hogy melo utan legyen egy termin, akkor nem baj, ha kiesik a switch. Lehet meg egy PAGP authentication failure is, ha nem jo helyre dugta vissza az uplinkeket. Eskuszik, hogy jo, de nekem gyanus....
. Sirt is szegenyem. De sajnos megallt a klima a teremben
Beállítottam és egyből ment minden: VPN, portforward, menedzsment belülről és VPN-ről is stb... 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- 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!
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 14 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- Új Apple iPhone 16 Pro 128GB, Kártyafüggetlen, 3 Év Garanciával
- Honor Magic7 Lite 512GB, Kártyafüggetlen, 1 Év Garanciával
- Honor 400 lite 256GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest