- Felháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasni
- A luxusmárkáknak kell a bitcoin, az USA jegybankjának nem
- Letiltja az USA a politikusokat a telefonhívásokról és szöveges üzenetekről
- Nagy áttörés jön a napelemek piacán, nem kell annyi hely a paneleknek
- Belenyúlt az USA az Epic Games igazgatótanácsába, nyomoz az NVIDIA
-
IT café
--- 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
-
#9259
crok
Topikgazda
Cyber_Bird
#9258
crok
Topikgazda
válasz
Cyber_Bird
#9258
üzenetére
Ja arre én se emlékszem.. csak az ilyen fontos dolgokra : D Bakker, ja, 2.5 éves hozzászólás..
[ Szerkesztve ]
-
crok
Topikgazda
válasz
zsolti.22
#9223
üzenetére
Nos, a megoldás egyébként egyszerű: kérd át az ügyed intézését máshova.. hivatkozz az ügyfeled idábeosztására és hogy ahhoz az USA időzónák jobban passzolnak.. annyi, hogy ha WebEx vagy telefonbeszélgetés lesz akkor az valszeg a normál munkaidőn túl lesz, ezt be kell vállalni..
-
crok
Topikgazda
válasz
zsolti.22
#9219
üzenetére
A legjobb módszer eddig - ha az idő engedi: mindig 16.30 után, de mégjobb ha 17.00 után nyitsz TAC-et - így nem Jordániában hanem már az USA-ban landol a jegy ( : Eddig működőnek tűnik. [Szerk.] Egyébként az LMS-re meg a Prime Infrastructure-re eddig 10 hónap alatt összesen 27 jegyet nyitottunk eddig, egy volt ami kb egy órán belül.. hát nem megoldódott de meg tudták mondani mi a baj : ) De van olyan amit március 19-én nyítottam és már 4..5x volt Webex a TAC engineer-rel és 8x (!) a developerrel.. és még mindig nem tudják mi a daffffuq van..
[ Szerkesztve ]
-
#9172
crok
Topikgazda
Cyber_Bird
#9171
crok
Topikgazda
válasz
Cyber_Bird
#9171
üzenetére
Őszinte leszek: ez szánalmas.. nem tudok rá mit mondani.
-
crok
Topikgazda
Ja igen, meg még ez kellhet:
no errdisable detect cause gbic-invalid[Szerk:] De jó arc ám a Cisco, itt a link, megtaláltam,
"hoztam is ajándékot meg nem is": engedem de nem supportálom:Q. Do the Cisco Catalyst 3750 Series Switches interoperate with SFPs from other vendors?
A. Yes, starting from 12.2(25)SE release, the user has the option via CLI to turn on the support for 3rd party SFPs. However, the Cisco TAC will not support such 3rd party SFPs. In the event of any link error involving such 3rd party SFPs the customer will have to replace 3rd party SFPs with Cisco SFPs before any troubleshooting can be done by TAC.
[ Szerkesztve ]
-
#9169
crok
Topikgazda
Cyber_Bird
#9167
crok
Topikgazda
válasz
Cyber_Bird
#9167
üzenetére
Szegény ember vízzel főz..
3rd party SFP-re én ezt próbálnám meg:
#service unsupported-transceiver
Nálam bejött, sokfajta problémát generálhat a
3rd party SFP (inkompatibilityás) mint pl. fals
alacsony jelszint riasztás, fals link-down ,miatt
lent maradó interface (ez a legmókásabb, mert
sok SFP azt mondja magáról hogy force-up,
vagyis nem megy le, de lemegy, csak nem írja
az IOS se sh int desc-ben, de sh int-ben, sehol.
Így ott ülsz, up/up, mégse megy.. I <3 Cisco..De tudj róla, hogyha TAC-et nyitsz és kér a TAC
sh tech-et és látja a configot akkor kvázi azonnal
mondja hogy ezt szépen most leveszed és teszel
bele Cisco SFP-t mert addig nem foglalkozik a
jegyeddel.. mert nem, mert unsupported.[Szerk]: a "nem akarunk erre költenire" a legjobb
válasz az "akkor nem fogjuk supportálni".. főleg
nem SLA-ra.. Egy nagyobbacska kiesés után
mikor kötbérről esik szó mert valaki mondjuk
pont nem tudott elküldeni egy pár igen fontos
megrendelést vagy számlát majd igencsak el
fognak gondolkodni hogy az a pár SFP bizony
megérte volna.....[ Szerkesztve ]
-
crok
Topikgazda
válasz
Wolfy999
#9104
üzenetére
Az 1000Base-T SFP tud 10/100/1000 auto negotiation-t és Auto MDI/MDIX-et.
http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/gigabit-ethernet-gbic-sfp-modules/product_data_sheet0900aecd8033f885.html
Ellenben az 1000Base-T GBIC nem tud:
http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/gigabit-ethernet-gbic-sfp-modules/product_data_sheet09186a008014cb5e.html
https://supportforums.cisco.com/document/16696/how-hardcode-speed-gigabit-interface-converter-gbic-and-small-form-factor-pluggable
Szerinem keverted.
Kis kiegészítés/érdekesség a GBIC mellé:
http://www.microstar.pl/docs/finisar/an-2032.pdf -
crok
Topikgazda
válasz
dzsambo
#9118
üzenetére
Ezt hogy érted? Explicit megadod mi legyen engedve (és kihagyod nyilván a VLAN 1-et) a trönkön vagy allow all után explicit kiveszed remove-al a VLAN 1-et. Attól függ mi az alapfelállás és mi a cél: minden engedve van csak VLAN 1-et akarod tiltani (mert akkor egyszerűbb az allow all után egy remove 1) vagy eleve csak meghatározott forgalmat akarsz engedni (mert akkor meg megadod mi menjen allow-al, felsorolva, "sz't sanyi").
-
crok
Topikgazda
Elég lesz, főleg ha nem lesz QoS. De mivel a sima C2960 architektúrája igen limitált (24 portot szolgál ki egy ASIC 2MB pufferrel) így nagyon sokat azért ne várj, kis csomagokból nem forgat magán át majd ennyit valamint ha burst-ös a forgalom az 2MB puffer kevés is lehet (egész ASIC-ra ennyi.. mert ez egy access layer switch..). De "normál forgalom" (IMIX) mellet tökéletesen elég kell legyen portról portra 50Mbps átforgatására. Egyébként sima 2960, E vagy esetleg X vagy XR? Mert pl. az X-ben már 4MB puffer van..
Olvasnivaló - eléggé el vagyok mélyülve QoS-ben meg architektúrában : D
C2950 Miercom teszt, összehasonlítás több gyártó hasonló eszközével:
http://www.cisco.com/c/dam/en/us/products/collateral/switches/catalyst-2960-series-switches/miercom_report_cisco_catalyst_2960_3750_switches_qos.pdf
C2960 architektúra:
http://d2zmdbbm9feqrf.cloudfront.net/2012/usa/pdf/BRKARC-3437.pdf
https://clnv.s3.amazonaws.com/2015/usa/pdf/BRKARC-1009.pdf
C2960 architektúra és platformspec. hibakeresés:
http://monsterdark.com/wp-content/uploads/Troubleshooting-Cisco-Catalyst-2960-3560-and-3750-Series-Switches.pdf -
crok
Topikgazda
Rosszul értelmezed a debug eredményét:
-ez itt az ARP kérés forrása, nem a keret forrása
IP ARP: sent req src 192.168.20.21 aabb.cc00.0100,
-ez itt az ARP kérés célja, nem a keret célja:
dst 192.168.20.1 0000.0000.0000 Ethernet0/0.Az ARP keret L2 forrása az interface MAC-je, a célja ffff.ffff.ffff.
Ha nincs válasz akkor lehet hogy a másik oldal
eleve nem is válaszol, mert mondjuk a másik
oldal netmask-ja nem /24 hanem pl. /30.. vagy /29.. -
crok
Topikgazda
..és így (elvben) nem kell majd szívnod és minden működni is fog.
De miután tudom hogy ez egy Cisco termék én még így is
fenntartásokkal vagyok az ilyen upgradekkel kapcsolatban ( :
Hisz az elmélet és a gyakorlat közt *elméletileg* nincs különbség..
Sok szerencsét - majd írj hogy örülünk vagy nem örülünk. -
crok
Topikgazda
-
crok
Topikgazda
Melyiket nézted eddig?
Én kettőről tudok, a srácok itt használták már
(bár nem tudom milyen "bonyolult", esetleg
átfedő NAT-olásotok van, én azért a biztonság
kedvéért átnézném az eredményt mindenképp)http://www.tunnelsup.com/nat-converter
http://www.packetbin.com/projects/CiscoASA84NATGenerator
Ja, és egy jó video hogy mire figyelj:
https://supportforums.cisco.com/video/11928931/asa-83-upgrade-what-you-need-know
És a leírás mellé:
https://supportforums.cisco.com/document/48646/asa-83-upgrade-what-you-need-know -
#9013
crok
Topikgazda
Hedgehanter
#9012
crok
Topikgazda
válasz
Hedgehanter
#9012
üzenetére
Ja, hát akkor még most jön az örömboldogságmámor',
10x sávszél - nincs itt még szükség QoS-re : D -
#9011
crok
Topikgazda
Hedgehanter
#9010
crok
Topikgazda
válasz
Hedgehanter
#9010
üzenetére
Ha nincs tumultus nem kell - de ha van filetransfer néha-néha (ami mondjuk nem SMB mert az még jó hálózaton is ritka szarul tud működni..) akkor a közben az uplinken telefonálókat az csúnyán érintheti. De ez mind-mind hálózat- és forgalomfüggő (valamint user- és appfüggő is). De amíg nem fogsz jelölni addig nincs értelme úgyse. Egyébként ha már legalább a voice jelölve van és mellette tumultus van akkor az legalább nem fog sérülni a MOS (de a buffer-ekre és queue-kra nagyon oda kell figyelni és átgondolni mi miben menjen és mennyi). Csak át kell gondolni mit tudnak (hardware-esen és software-esen) az access switchek, mit tudnak distr-ok és a core-ok valamint a routerek ha a "tumultusforgalom" kintről jön vagy kifelé megy.. (mert ha már QoS akkor ugye a forgalomnak két iránya van..)
Egy gyors ötlet hogy van-e tumultus: uplinket valami linuxról vagy Winről snmp-vel kérdezd le félpercenként hogy mekkora a tx-rx byte, mehet Excelbe a byte érték és a a deltából csinálsz egy-egy diagramot TX-RX-re oszt' mehet a manager-eknek a színes-szagos "kell a pénz QoS projektre" email : D -
#9008
crok
Topikgazda
Hedgehanter
#9007
crok
Topikgazda
válasz
Hedgehanter
#9007
üzenetére
Ha nem jelölsz semmit mert úgyis csak "lapos a hálózat" akkor még access szinten is (előre elnézést a kifejezésért meg +18, de) takkkknyosra szopatod magadat vele mert átállítja a buffereket minden queue-hoz de mivel te csak egyet fogsz használni (a CoS 0 / DSCP 0-hoz tartozót) így akár tengig interface-t se tudsz majd kihajtani, gig interface-t se, fa interface-t se.. csak addig ameddig a jelöletlen csomagok queue-ja engedi.. namost ha ezt elképzeled mondjuk 40 ember forgalmán, egy gig uplinkre amin eddig ment a z'internet meg minden 300Mbps-en.. az most úgy fog dobálni hogy az esze elmegy a usereknek ( : NE.. gondold át hogy mit akarsz és akkor majd lesz értelme bekapcsolni.. de csak így, hogy mls qos.. NE ( : Az QoS két élű fegyver.. jó, mert meg tudod mondani hogy mi legyen előrébb, mi kapjon mindenféleképp sávszélt.. de ha nem jelölsz semmit csak mls qos.. beláthatatlan következményi lehetnek, nem ismerem a hálót/traffic profile-t/spec alkalmazásokat/igényeket/telefóniát, de.. NE ( :
-
#8996
crok
Topikgazda
Hedgehanter
#8995
crok
Topikgazda
válasz
Hedgehanter
#8995
üzenetére
Rule #1: plan and create architecture that is easily maintainable and operable. That will save you money and time when expanding and/or troubleshooting.
Rule #2: The "2am test": if you cannot explain your design at 2am at a Friday night it's considered too complex.
Rule #3: plan and create architecture that can be expanded easily up to 3..4 times bigger (network, throughput.. et cetera).
Rule #4: plan and create architecture with clear demarcation points.
Rule #5: Documentation is everything - do it properly: should be easily accessable, readable and self-explanatory, should contain all contacts and should be updated when changes happen.
Na, én ezek szerint csinálom amit csinálok, ezek a saját szabályaim (az ötöst nagyon utálom..) magammal szemben (bár elvárom másoktól is : D ). Ha meg kell szegnem bármelyiket akkor arról az ügyfail tehet és elfogadja. : ) Na oszt' ilyenkor jön a "jóvanazúgy, faszanagyon, halaggyunkmá' " : D
-
#8994
crok
Topikgazda
Hedgehanter
#8993
crok
Topikgazda
válasz
Hedgehanter
#8993
üzenetére
Persze, plusz demarkáció megoldása, hogy lesz megcsinálva hogy eddig az enyém, innen a másé.. aztán ott van még egy esetleges architectural security restriction (pl. az egyik ügyfélnél kifejezetten tiltott, hogy tűzfalon dinamikus routing legyen, ezt mondjuk megértem.. meg BGP-t ASA nem tud valami stabilan, mondjuk a Juniper tudja, de ott is van pár érdekes bug ( : ). De érdekes ASA patkolásokat is láttam már.. hát, sok mindenen múlik ez.
-
#8992
crok
Topikgazda
Hedgehanter
#8988
crok
Topikgazda
válasz
Hedgehanter
#8988
üzenetére
Hacsak nem valamilyen nem-ethernet a link a net vagy bérelt vonal vége akkor simán mehet az ASA.. ha mégis valami nem-ethernet a végződtetés akkor ezt egy 1841 is megoldja neked (bár akkor nem nagyon valószínű hogy tud a technológia 100..200Mbps-t) - már úgy értem végződteti a linkedet és egy pár jól átgondolt ACL-el megoldható hogy a router összekösse a linkedet az ASA-val ekkora sávszélre is. Sok helyen (nem röhög, sokszor látom) switch-en végződtetik a netet/vonalat, pattintanak rá egy-két átgondolt ACL-t, utána meg Juniper tűzval.. Nokia esetleg.. De a C1941 se tud 150Mbps-t ZBFW és/vagy QoS pol-map mellett.. az csak a Fast Switching CEF-ből, de az csak annyi, hogy ennyit tud magán átforgatni ha *semmit* se kell a csomagokkal csinálni routing/switchingen kívül (és a csomagok mindegyike 1500byteos). Ha ISR G1 elég (bár újonnan úgyse igen tudod megvenni) akkor esetleg 7200-as, NPE-G1-el vagy G2-vel (de ugye moduláris, drágaság lesz alapból). Esetleg 4331/4351? De minden attól függ hogy a csomagokat akarod-e szűrni/ellenőrizni, kell-e IPSec, kell-e QoS, max. session szám egy időben.. írtam már itt erről. Itt egy példa white paper amit érdemes elolvasni. [Ja, jótanács: ha NAT-olsz is meg ZBFW is van esetleg akkor ASR felejtő, olyan bugos hogy szavak nincsenek..]
-
crok
Topikgazda
Tőlünk a BT már majd' minden épeszűt behúzott már (Debrecen..) csak azt nem aki kitartó meg hülye (mint én is..).
Közben érdekesség:
teszteszkoz(config)#! VTY ACL teszt konfig..
teszteszkoz(config)#! Szeretnem kommentelni az egyes bejegyzeseket..
teszteszkoz(config)#access-list 1 remark VTY ACL
teszteszkoz(config)#access-list 1 remark Engedek egy management halot
teszteszkoz(config)#access-list 1 permit 1.1.1.0 0.0.0.255
teszteszkoz(config)#access-list 1 remark Engedek egy masik management halot is
teszteszkoz(config)#access-list 1 permit 2.2.2.0 0.0.0.255
teszteszkoz(config)#access-list 1 remark Engedek egy hostot mert megtehetem ezt is
teszteszkoz(config)#access-list 1 permit host 3.3.3.3
teszteszkoz(config)#! ..dehogy tehetem meg.. ez igy fog kinezni..
teszteszkoz(config)#do sh run | i acce.*1
access-list 1 remark Engedek egy hostot mert megtehetem ezt is
access-list 1 permit 3.3.3.3
access-list 1 remark VTY ACL
access-list 1 remark Engedek egy management halot
access-list 1 permit 1.1.1.0 0.0.0.255
access-list 1 remark Engedek egy masik management halot is
access-list 1 permit 2.2.2.0 0.0.0.255..na és erre írj ellenőrző script-et..
-
crok
Topikgazda
válasz
Rocko007
#8812
üzenetére
Ha jól veszem ki a RapidSSL chained cert - a többi
cert pem is benne van abban amit feltöltesz?−−−−−−BEGIN CERTIFICATE−−−−−−
*Device cert*
−−−−−−END CERTIFICATE−−−−−−
−−−−−−BEGIN CERTIFICATE−−−−−−
*Intermediate CA cert *
−−−−−−END CERTIFICATE−−−−−−−−
−−−−−−BEGIN CERTIFICATE−−−−−−
*Root CA cert *
−−−−−−END CERTIFICATE−−−−−− -
crok
Topikgazda
válasz
A_ScHuLcZ
#8844
üzenetére
Jaja, valami hiányzik: a telefonok nem tudnak dual-line-t ( :
no ephone-dn 5 dual-line
ephone-dn 5
number 1005
name Teszt5
!
no ephone-dn 6 dual-line
ephone-dn 6
number 1006
name Teszt6
!
no ephone-dn 7 dual-line
ephone-dn 7
number 1007
name Teszt7
!
no ephone-dn 8 dual-line
ephone-dn 8
number 1008
name Teszt8 -
crok
Topikgazda
-
crok
Topikgazda
válasz
zsolti.22
#8828
üzenetére
Na.
A self zone nem rossz, csak jól át kell gondolni mit akarsz elérni a routeren, mihez kell a routernek kapcsolódnia és mi kapcsolódhat hozzá ( : De amúgy ennyi, a self zone a router saját védelmére van kitalálva security szempontból (túlterhelésre ott a CoPP). Meg lehetőleg legyen backdoor-od mielőtt a self-et piszkálod távolról, mondjuk egy input ACL-ben először explicit engedd be magadat SSH-n ( :
INSIDE-to-OUTSIDE: egyértelmű, ahogy írtad.
INSIDE-to-VOIP: Ha nem lesz SIP forgalom az INSIDE és a VOIP közt vagy eleve csak és kizárólag a WWW felületét akarod csak elérni a telefonnak az INSIDE-ból akkor INSIDE-to-VOIP inspect www-re vagy tcp-re - elég, de igazából minden a security policy-den múlik, hogy mennyire akarsz strict lenni és hogy mi a célod: működő de megfelelően strict elérést biztosítani vagy sz#p&tni magad ( :
VOIP-to-OUTSIDE: Látom SIP-et használsz. Az 5060-as port csak a signaling (SIP), ugye nincs benne maga a voice stream (nyugi, nem para a sok packet, CEF-ből letolja a router, egyébként mondjuk G711-el egy hívás másodpercenként default értékekkel 50db 20ms-es voice stream-et generál ( : ). A STUN a NAT-olást magában megoldja, de ha a VOIP-to-OUTSIDE-ba csinálsz egy policy-t UDP inspectre (esetleg szűkítheted a 16384 - 32767 port-range-re) akkor megoldja azt is - de kell az inspect vagy az oda-vissza pass a OUTSIDE-to-VOIP irányban is, mert téged is hívhatnak és te is akarsz hívni. A SIP-nek kellhet a TCP és/vagy UDP 5060 és/vagy az 5061 port (nem tudom mit használsz pontosan.. így ez lehet TCP és/vagy UDP, az 5060 cleartext, az 5061 crypted SIP). Ezt én csak azért tenném be pass-ra (vagy oda-vissza inspect-be) a VOIP-to-OUTSIDE és az OUTSIDE-to-VOIP zónákba mert tudom, hogy a SIP inspection ritka szarul működik ZBF-ben (klasszikus CBAC inspect-ben is.. ASA-ban is.. PIX-ben is.. FWSM-ben is..). Ha jól működne a SIP inspection akkor csinálhatnál olyat, hogy a VOIP-to-OUTSIDE és az OUTSIDE-to-VOIP zónákba is felveszed inspect-el a SIP-et és az RTP-t is (UDP 16384 - 32767) - így akár kintről hívnak téged, akár bentről hívsz valakit a ZBF mindig megnézné a session-öket és ha nem lenne baj a csomagokkal akkor menne minden.
OUTSIDE-to-SELF: "Vannak olyan forgalmak, ami egy az egyben csak a routernek szól és nem mögöttes eszköznek, ilyen forgalom: az SSH, router órájának szinkonizációja, DDNS, uplink DHCP egyeztetés, DNS lekérdezés (konfigurációban meglévő domain-név feloldása) - ez mind igaz a self zónára, de nem feltétlen az OUTSIDE-to-SELF irányra. A routerre SSH-ni szeretnél - ez OUTSIDE-to-SELF. Óraszinkron, DDNS, DNS: biztos hogy ez OUTSIDE-to-SELF -el a legegyszerűbb? Mi lenne, ha SELF-to-OUTSIDE-ra csinálnád inspect-el? Akkor nem kell szívni a visszaengedéssel és a session-t még ellenőrzi is a router. Az SSH-t meg a DHCP-t a WAN-on egy in és egy out ACL-el eleve engedném (SSH-t kintről a megbízható source-ból, bentről mindenhova, DHCP az IP szerzés és def.route miatt kell kifelé/befelé). Persze megcsinálhatod úgy is hogy amit tutira engednél azt a SELF-to-OUTSIDE és OUTSIDE-to-SELF irányban is pass-ra teszed. Minden más meg vagy drop, vagy drop log, vagy amit szeretnél, akár oda-vissza inspect-elheted, akkor kifelé/befelé is mehet mindenféle forgalom ( :
"És akkor a fentiek tudatában szeretne az ember VPN-t konfigurálni": igen, így kell, ahogy leírod.. de miért érintené az OUTSIDE-to-VOIP zónát? Hiszen le is írod, hogy OUTSIDE-ból jön a public IP-s IPSec forgalmad és a router terminálja az IPSec-et - tehát OUTSIDE-to-SELF-et érinti valamint a SELF-to-OUTSIDE-ot. Azért mindkettőt, mert az IPSec itt most UDP és ESP, amit nem fog tudni inspect-elni a router, pass kell, oda-vissza. Ez az IPSec műkédésére kell - vagy ugye order-of-operation alapján engedheted ACL-el is az IPSec végponti forgalmat kifele/befele.. Aztán meglesz a NAT ha kell.. Aztán a VOIP-to-OUTSIDE és az OUTSIDE-to-VOIP-ban leírsz mindent, ami a telefonok közt meg a SIP szolgáltatóhoz kell, oda/vissza, pass-al vagy inspect-el, ahogy jónak látod.
Ha valami nem tiszta írj, tisztázzuk ( : Csak már én is fáradt vagyok..
Ja igen: IOS függő, de ~15.1 alatt intra-zone interface-ek közti forgalom implicit engedélyezve van (same security level principle..) ám felette explicit módon csinálni kell intra-zone policy-t, ami egyébként ugyan elsőre hülyeség, de ha belegondolsz ez egy plusz védelmi szint is lehet ha kihasználod: mondhatod, hogy INSIDE-to-INSIDE és match+pass mindenre, mint eddig.. de ha mondjuk azt mondod, hogy INSIDE-to-INSIDE match mindenre és inspect.. akkor az azonos zónákban levő interface-ek közti session-öket a router ellenőrzheti is! Vagy csinálhatsz policy-ket, class-okat és ACL-eket, hogy ugyan ZBF szempontból egy zónába eső hálózatok közt is meg tudj valósítani szűrést a routeren keresztül - ami viszont tök jó kis komplex megoldásokat eredményezhet ha okosan használod.
(B#&zkidehusszúlett'..)
-
crok
Topikgazda
válasz
A_ScHuLcZ
#8825
üzenetére
@A_ScHuLcZ: Azért keres még file-okat mert ha nem Skinny-t használsz SRST-vel akkor kell még info a CallManager-el való kapcsolathoz. Ezt ajánlom átolvasni, a books > misc > voice mappát, a Voice_CME_101.pdf-et én írtam, de itt sok könyvet meg segédanyagot megtaláltsz ("online könyvtáram"). A telefonok "tudásához" egy kis segítség: [1] [2] [3]
@Zsoli: szivesen, máskor is. Majd írj, hogy mi lett a vége (aka. megoldás) ( :
[ Szerkesztve ]
-
#8819
crok
Topikgazda
suomalainen
#8809
crok
Topikgazda
válasz
suomalainen
#8809
üzenetére
Ha jól tévedek az ott DMVPN van a leírás szerint: a virtuális routereknek egy interface-e van csak ám több subinterface is - több VLAN taggel, vagyis azonos VLAN taggel rendelkező subinterface-ek egy alhálóban lesznek - és lesz egy NHRP szerver aztán a többi meg ahhoz kapcsolódik (hub&spoke). Ez egy trükk hogy minél kevesebb erőforrásra legyen szükség, meg hogy jól megkavarjon ( : ezt találták ki a régi frame-relay helyett (ahol egyébként ugyan ez volt megvalósítva L3 szempontból).
-
crok
Topikgazda
válasz
zsolti.22
#8815
üzenetére
Nos, ha TCP 80-on szeretnéd elérni a 192.168.20.2-t 192.168.50.2-ről akkor félig-meddig jó, nem tom' nem-e redirect-el HTTPS-re. Plusz ez csak az egyik oldal, így VPN-t troubleshootolni meglehetősen nehéz.
De pl. ehhez nem látok policy-map-et:
zone-pair security VOIP-to-OUTSIDE source VOIP destination OUTSIDE
service-policy type inspect VOIP_TO_OUTSIDE << ilyen policy-map-et nem látokA jövőbeni bővíthetőségre való tekintettel én nem használnék "class-map type inspect match-all"-t hanem match-any-t, hogy utánna hozzáadni egyszerűbb legyen.
Ezek itt lent önmagukban még jók lennének, de vissza nem engedi a forgalmat a ZBF, nem elég a pass mert UDP és "titkos" az IPSec - az IOS sajnos minden PR fogása ellenére se tud inspect-elni ilyen forgalmat és a pass csak egy irányt enged, nincs meg az inspect által adott visszatérő forgalmat engedő ACE:
policy-map type inspect OUTSIDE_TO_VOIP_EXCLUSIONS
class type inspect OUTSIDE_TO_VOIP_EXCLUSIONS_CLASS
pass log
class class-default
drop log
policy-map type inspect OUTSIDE_TO_SELF
class type inspect OUTSIDE_TO_SELF_EXCLUSIONS_CLASS
pass
class class-default
drop logDrop log van a végén - szóval nézz logot, hogy mit dob ha dob egyáltalán (állíts buffert rendesen) de szerintem kéne egy SELF_TO_OUTSIDE amiben engeded az IPSec UDP-t, ESP-t visszafelé.
Aztán ha minden kötél szakad akkor az IOS Order-of-operation miatt én feltennék egy ACL-t az OUTSIDE interface-re amiben a forgalmadat (TCP 80 src 192.168.50.2 dst 192.168.20.2) direktben engedném hogy lássam hogy a VPN vagy a ZBF a hiba.
Ezek után csinálnék Wireshark-ot (mindkét oldalon) ha nem megy - hogy mi merre megy, mi érkezik meg és mi nem.
-
crok
Topikgazda
válasz
A_ScHuLcZ
#8813
üzenetére
Hogyne lenne elég az C1841! Bőven sok is. ( : Egy 1700-as szériás is jó, csak legyen hely a file-oknak és az IOS feature set legyen rendben (ipvoice, spservices, advipservices, entservices vagy adventservices ha 12.4, de 12.2-vel mennek pl. itthon a 1721-eim, simán). Nekem itthon egy 1801 meg két 1721 van, simán megy minden, CME is. Milyen telefonokat akarsz pontosan használni? Milyen file-ok és hol vannak? Konfig mi? Telefon firmware-ek rendben? Jó IP-t kapnak a telefonok (azt értem, hogy TFTP info már van a telefonban gondolom DHCP-n option 150-el)?
-
-
crok
Topikgazda
válasz
FecoGee
#8763
üzenetére
Trohohooo-lololooo.. nos, most ott tartunk, hogy van 2.. már úgy értem van egy egy laborban, van egy éles egy DC-ben. Na, szerintetek ha hozzáadtok egy eszközt és adtok meg un. user defined field-eket is (amolyan custom adatokat, mint pl. helye a rack-ben vagy városnév, cím, ilyesmi..) azt utána tudjátok-e ugyan így exportálni? Igen, talált, *nem*, nem tudjátok.. mert nem - mert csak.. de jó ötlet és javasolták, hogy adjak fel rá feature request-et! W - T - F ? Most van 4500 eszköz a rendszerben.. ne hülyéskedjünk már.. hát js-ben írtunk egy kis import file generáló dolgot és mi azzal Excelből generálunk CSV-t az LMS-nek, de áttenni másik rendszerbe.. neeeeeem.. olyat nem tud.. olyat tud, hogy csinálsz egy backupot és visszaállítod.. de mivel 10 eszközzel is 300MB és a végén úgy nem megy hogy azt írja nem volt hiba ezt inkább passzoltam (volt rá SR nyitva, persze megoldás és bármi használható nélkül le lett zárva annyival, hogy bicsibocsi, biztos rosszul csináltál valamit.. ja, rosszul kattintottam a WebUI-ban). Most az a nagy ötletem van, hogy az inventory report-al csinálok egy custom report-ot, CSV-ben (ja, ez meg annyi, hogy a CSV-ben van egy Word szerű fejléc, amit törölni kell hogy meg is tudd nyitni rendesen.. arról nem is beszélve, hogy nincs kivételkezelés, szóval ha van vessző a field-ben borul a rekord.. a rekordok elemei nincsenek idézőjelben), aztán azzal addig ickázok, míg a js megeszi (vagy a js-t írom át..). Aztán egy-egy Inventory report 4500 eszközre ilyen 15..20 perc, közben persze a böngésző lefagy, aztán ülsz előtte, hogy most akkor megállt vagy csak dolgozik, és lehet, hogy 60 percet ülsz előtte és csak utána omlik össze.. aztán kezded előlről és reménykedsz. A supported böngésző ilyen Firefox 24, de azt is csak egy un. point patch-el tudod megoldani (most 38-nél járunk!) - és még így is előfordul, hogy egy-egy gomb elcsúszik, egy-egy lista nem tölt be (pl. keresésnél ha rákattintasz az "all device" gombra akkor ilyen random számokat ír ki hogy ennyi-meg-annyi van kijelölve, de sose annyi mint amennyi a rendszerben *összesen* van - de ha azt mondom hogy kereséss és * akkor persze ki tudod jelölni mindet az "all"-al..). Nincs még rendes minor upgrade csak maintenance release - de azt sehol nem tudod megnézni, hogy mi van már fent. Amikor a TAC mondta, hogy tegyem fel az Maintenance Release 2-t *nem_tudta_megmondani*, hogy az MR1 patch-ei benne vannak-e (persze hogy benne vannak, hát a leírásában benne van..). Az upgrade-ekhez kell Internet.. (vagy persze kézzel leszedsz mindent és felpatkolod.. nem mókás..) aztán persze security a DC-ben: nem kapsz direkt netet természetesen. Szóval proxy.. ja, hogy proxy-n keresztül nem megy, hiába adsz meg nevet/jelszót.. csak mert nem és kész. megpatkoltam.. HTTP kérések mennek ki de az jön vissza a Cisco-tól hogy rossz a kérés. Namondom' tökömbe már.. aztán kiderült hogy az URL, ami benne van a classes/properties file-okban *hibás* mert igazából HTTPS kellene legyen, szóval megpatkoltam.. aztán kiderül, hogy HTTPS URL-eket meg megintcsak nem a proxy-ra küld - hiába van megadva! - hanem próbálja direktben küldeni.. Akkor pl. baseline compliance check-et ha csinálasz több mint 500 eszközre (amolyan konfig ellenőrzés template alapján, full bugos már az ellenőrzés is FYI) és a hiányzónak vélt konfigokat ha ki is akarod tolni LMS-el akkor bumm, szívtál: kapsz egy darab ablakot egy darab pirossal írt hibakóddal, amit a Cisco TAC se tud értelmezni, nincs benne egyetlen public Cisco.com dokumentációban se - ja, és nem tudják modellezni, mert az marhasok munka hogy 500+ eszközt behúzzanak egy teszt LMS-be és megnézzék ők is.. Akkor a Prime Infrastructure.. nos, abban kb ugyanez ez a helyzet, de annyira unintelligens a rendszer pl. hogy míg az LMS megpróbál a megadott névvel/jelszóval telnettel és ssh-val is belépni majd elmenti, hogy mivel sikerült (preferenciát is tudsz beállítani, hogy ha mindkettő, akkor mi a preferált) addig a Prime Infrastructure ilyet *nem* tud, meg kell adni fixen, hogy telnet vagy SSH - de *nem* jó ha az SSH ver. 1, csak a 2 a jó.. namost rengeteg switch pl. nem tud SSH v2-t, csak v1-et (nem, az 1.99 *nem* v2). Namost 4500 eszköztől beszélünk, nem egyszerű kreálni ilyen listát/CSV-t, valamint itt is igaz, hogy a user defined field-eket *nem* tudja exportálni - annyi csavarral, hogy inventory report-ot se tudsz csinálni amiben benne lenne az összes UDF és a telnet-vagy-ssh beállítás.. Az inventory list-ben a listázás pl. annyira jól működik, hogy nem tudsz WLC-ket listázni, mert nem, mert csak, mert az SQL file szarul van megírva.. de mikor megnézed az SQL-t az egy olyan 6..7 sor megjegyzéssel kezdődik, hogy itt amúgy van egy dokumentált BUG benne.. Aztán megnézed Cisco.com-on és megoldás nincs csak workaround van: contact TAC and will send you the patch.. workaround, ami nem került be a legújabb hivatalos patch-be. Agyrém, 60M forintért.. 12 SR lett eddig nyitva LMS-re.. még 10 az Infrastructure-re és holnap Webex-en beszélhetünk valami Cisco Network Management guruval.. hát' lesz kérdésem..
[ Szerkesztve ]
-
crok
Topikgazda
válasz
zsolti.22
#8591
üzenetére
Ha csak ennyi konfig van fent akkor a "line vty ACL előbb kerül vizsgálatra, mint a ZBF service-policy" se állja meg a helyét teljesen mivel nem látok self zónára vonatkozó policy-t. Ha ZBFW-l szeretnéd megoldani az SSH hozzáférést akkor egy OUTSIDE-to-self-et kell csinálnod, az ACL meg a class maradhat. Mókás ez a ZBFW meg a self zóna.. nagyon mókás.. pl. nem áll össze a HSRP ha nem csinálsz egyértelmű engedélyezést self-re ( :
[Szerk.]
Ezt kihagytam:
show policy-map type inspect zone-pair INSIDE-to-OUTSIDE sessions
..a dropnál látod mennyi volt a dobás, azt persze nem, hogy mi (de azt meg syslogba beteszi..) meg persze az aktív session-öket és a half-open-eket is látod.ZBFW 12.4T:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/12-4t/sec-data-zbf-12-4t-book/sec-zone-pol-fw.html
ZBFW 15M & T:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/15-mt/sec-data-zbf-15-mt-book/sec-zone-pol-fw.html[ Szerkesztve ]
-
crok
Topikgazda
válasz
zsolti.22
#8588
üzenetére
Soha nem is fog jól működni.. a Cisco bizotnsági eszközökben a SIP inspection - de még a sima allow is - egyszerűen szarul van implementálva.. ennyi, sajnos nem tudok jobbat mondani róla, ezer és egy hibajegyünk van, volt és lesz amíg a hálózatban használatban van.. suxx.. olyat tudsz hogy felveszed acl-ben amit tényleg engedni akarsz és ugyan úgy allow-ra teszed.. mert a match proto egyszerűen megbízhatatlan SIP-vel kapcsolatban.. De legalább a ZBFW már megy ( :
-
#8560
crok
Topikgazda
Cyber_Bird
#8558
crok
Topikgazda
válasz
Cyber_Bird
#8558
üzenetére
Több bug mint kolbász ( : Én ma is nyitottam egy SR-t.. Prime LMS 4.2.5-re, kilencedik..
-
crok
Topikgazda
Miért nem mondtad, hogy Prime.. mondtam, hogy most azzal foglalkozom
ne használjátok IOS upgrade-re, mert ha nem volt jó a copy akkor is restartol.. ugyanis felmásolja az IOS-t, megnézi, hogy a file *nagysága* megegyezik-e a szerveren levő IOS nagyságával, restart, visszalép és MD5 hash-t néz.. ami persze kb. már mindegy, mert ha visszajött, akkor jó volt az IOS.. ha nem akkor nem lesz MD5 se (: Egy vicc.. komolyan.. olvass vissza, írtam már róla, és nálunk egyben használunk LMS-t is és Prime Infrastructure-t is. Kuka mind a kettő, többet tudok már a rendszerről mint maga a Cisco, eddig még csak úgy jött vissza SR, hogy a) jó ötlet, adjunk fel PER requestet hogy a dev. team lássa hogy van feature igény; b) ismert bug; c) ismeretlen bug.. -
crok
Topikgazda
válasz
zsolti.22
#8499
üzenetére
Az [1] és [2] syslog együtt jár. Egy nagyobb szegmensben adatot próbál valaki küldeni SMTP-n, ami meghaladja a beállított (vagy default) CBAC Inspect OoO (Out-of-Order) csomag queue-t. Azért mondja hogy unsupported, mert az OoO queue-ba nem fért be a teljes szegmens a vizsgálathoz. Az első log egyébként nem jelent dobást, informális jellegű log, ám a második az OoO queue miatt eldobja a szegmens minden csomagját, mert nem sikerült a feldolgozás/ellenőrzés.
Megoldás: növeld meg a queue.t. -
-
crok
Topikgazda
válasz
FecoGee
#8479
üzenetére
Azért kell kikapcsolni, mert a HSRP Hello csomag L2 multicast így az alapból bekapcsolt IGMP Snooping mellett sose fog menni, mert mindig máshonnan tanulja meg a HSRP multicast címet az eszköz.. Ezerszer láttam már.. főleg úgy jött elő eddig, hogy a non-Cisco termékben (Nortel, Alcatel) volt bekapcsolva a routerek mögött, oszt' persze a ping mindig megy a routerek IP-i közt de a HSRP Hello csak kifelé látszik menni a router debugban, befele semmi.. ha mindenképp kell a HSRP is meg az IGMP Snooping is, akkor meg lehet próbálni a GDA-t nem használni, át kell állítani a HSRP-t hogy a port saját HW címét használja a HSRP csomagokban és az ARP válaszokban (elvileg Helloban is, gyakorlatilag még egy ügyfél se mondta, hogy így csináljuk, inkább kikapcsolta az IGMP Snooping-ot..).
-
crok
Topikgazda
A "No answer" mire van állítva? 226. oldal. Nem lehet, hogy véletlen "Stop hunting" vagy "Try next member, but do not go to next group"? Mert erre tippelnék.. ami neked kellhet, az a "Try next member; then, try next group in Hunt List".
-
crok
Topikgazda
Cisco féle vizsgáztatási módszer alapjaiból ötöst adnék akkor.. UK kollega most lett 3x CCIE (most csinált Security-t..) de januárban bukott.. elég zabos volt mert minden működött, szóval utánament és ugyan minden ment de a Cisco "nem pont úgy kérte ahogy megcsinálta" - ugyan jó volt minden de nem *pont úgy* csinálta meg ahogy ők kitalálták.. no comment..
-
crok
Topikgazda
Hát elég unortodox megoldás a problémára de igen, így (is) működhet amit el akart a tervező érni.
A BGP szerepe pontosan az, amit gondolsz: mivel mindkét VRF-nek van export és import konfigja egymás felé *és* a BGP konfig miatt a connected route-okat beteszed a VRF-ek routing tábláiba így azok valid BGP utak lesznek és az export/import így megindul.. vagyis így egyik VRF-ből a másikba és vica versa átteszi a router a VPNv4 prefixeket. Mivel oda-vissza meg van csinálva így oda-vissza menni is fognak a prefixek és így a forgalom is. Nem kellenek peerek, mert nincsenek használva, csak azt használja ki a konfig, hogy az export/import hogy működik. A red con helyett használhatnál pl. network parancsokat is.. de pl. ha olyat csinálsz, hogy static route úgy, hogy nincs next hop, csak az interface-t adod meg akkor is tökéletesen működni fog (tudom, mert ilyet is csináltam már, workaround volt..).
-
#8177
crok
Topikgazda
Hedgehanter
#8175
crok
Topikgazda
válasz
Hedgehanter
#8175
üzenetére
Direkt írtam msg-body szűrést, így ha a regex-et úgy írod meg, hogy benne legyen mindkettő (vagy bármi.. mármint az IPSec és az ISAKMP üzenetek is, lehet |-al "vagy"-ot megadni) akkor benne lesz (: De ha más nem hát azt még mindig lehet, hogy az eddigi ömlesztett logokat megnézed, hogy mi a mnemonic-ja az általad értékesnek ítélt logüzeneteknek (IPSec és ISAKMP együtt) és megírod a regexet így:
(config)#logging discriminator VPN_FILTER mnemonics includes ?
WORD Specify a regular expression string for message filtering
(config)#logging discriminator VPN_FILTER mnemonics includes ISAKMP|IPSEC..vagy valami hasonló, nem tudom pontosan mit keresel de ez így megy.
-
#8174
crok
Topikgazda
Hedgehanter
#8127
crok
Topikgazda
válasz
Hedgehanter
#8127
üzenetére
Kiderült az ok? Jó a logszűrés?
-
-
#8126
crok
Topikgazda
Hedgehanter
#8121
crok
Topikgazda
válasz
Hedgehanter
#8121
üzenetére
-
#8119
crok
Topikgazda
Hedgehanter
#8118
crok
Topikgazda
válasz
Hedgehanter
#8118
üzenetére
logging discriminator FILTER msg-body includes [regex mit látni akarsz]
logging buffered discriminator FILTER 512000 -
crok
Topikgazda
válasz
zsolti.22
#8115
üzenetére
A switch-en van mls qos valszeg' és a default értékeket vagy nem változtattad meg vagy az alábbiakra illenek: nézd meg, hogy a konfigban van-e wrr-queue bandwidth parancs és hogy az interface-ek alatt van-e WRR parancs.. Ha van ha nincs wrr-queue bandwidth *de van* mls qos akkor él a WRR queuing és lesz csomagdobás az interface-eken (sh ). A TCP meg szépen szabályozza lefelé a window-t és így lesz max 30..35Mbps a forgalom MLS QOS-el és max. ha gigabitre teszed - ugyanis a wrr bandwidth parancs fordított arányt ír le és 100Mbps-nél a default class-ra (CoS 0/DSCP 0) asszem 3-at mond, vagyis 100Mbps/3 tehát 33Mbps.. az bele is illik az eredményedbe.. Nadeha' a gigabit-re kötöd akkor már 1000Mbps/3 tehát 333Mbps, vagyis ki tudod hajtani a netkapcsolatod.. (Egyszer felhoztad volna már ezt és mintha 2950-et írtál volna de 2960 volt, nagy a különbség a konfig módja közt - de az elv ugyan az.)
-
crok
Topikgazda
válasz
Rocko007
#8021
üzenetére
Szia,
Hidd el hogy jól jártál, hogy nem tudtad megcsinálni.. így most tudok szólni, hogy jól megborítottad volna a WLCM-ed és egy drága informatikai hulladék válhatott volna belőle.. Azt hitted, hogy csak úgy, ukmukfuk bármiről bármire upgrade-elhetsz, mint egy IOS-t - de neeeeem, de nem ám.. a WLC-nek különös egy fürdősk#&va a lelki világa, főleg upgrade fronton..
A helyzet a következő: olvass el minden release notes-ot a felteendő software-ekhez. Mindegyikben benne van, hogy miről mire (és a legfontosabb(!), hogy) hogyan tudsz upgrade-elni! Elő fog fordulni, hogy egy (esetleg két) köztes software-t is fel kell majd pattintanod (van, hogy downgrade-elni kell).. így pl. az általad 4.2.209.0-ra az alapul szolgáló 3.2.171.6-ról csak úgy mehetsz tovább (ez alapján), hogy felteszel pl. egy 4.0.206.0 vagy felettit (4.0.207.0 van ami letölthető) és utána 4.2.209.0-t. Ha a végcél a 7.0.250.0 akkor ez alapján 4.0.206.0, majd 4.2.176.0 és (igen, az 5-ös komplett kihagyásával, mert az egy f#s, nem véletlen nincs listázva a "Latest" alatt sem Cisco.com-on..) jöhet a végső 7.0.250.0. A letöltésekben nézd meg, hogy kellhet-e boot software-t cserélned/upgrade-elned! Ha választani kellene én a helyedben - hacsak nincs valami spec. dolog ami mindenképpen kell én nem elérhető egyetlen kompatibilis MD releasben - MD-t tennék fel, tesztelném, hogy minden okay-e és ha igen nem használnék ED-t addig, amíg nincs olyan feature amire nagyon-nagyon szükség van és csak ED-ben van benne. Ha mégis van akkor ED release notes alapos végigkutatása (különös tekintettel az upgrade folyamatra és a bugokra..) majd upgrade.. de inkább húznám, míg egy MD-ben benne lesz. Én a tftpd32-t még megpróbálnám Windows alatt (a Cisco azt ajánlja, linux alatt több olyan tftpd van ami támogatja a 32MB+ nagyságú file-okat, de azért ez is két oldalú: az, hogy a szerver kezeli még nem 100% siker, a cliensnek is tudnia kell kezelni).
[Szerk.: helyesírás..]
[ Szerkesztve ]
-
crok
Topikgazda
válasz
zsolti.22
#8007
üzenetére
Hát' sokszor én is, de inkább a tehetetlenségemen.. hogy egyik bugból a másikba, egyik workaround-ból a másikba, nyakatekert "logikába" futok minden egyes új feature-el.. majd ha már nem fáj lehet írok egy szösszenetet, valószínűleg hasonló stílusban (: hogy csak egyvalamit említsek: teszem úgy döntesz, hogy Win2k8-ra kell ezt feltenned (mert valami nagytudásúnak abban van tapasztalata, linuxban meg paripapipilő sincs) és úgy alakul, hogy a telepítőt pl. magyar vagy UK angol locale-el teszed fel.. BUMM, szívtál, csak US angolra *telepítettel* fogja az LMS telepítő azt mondani, hogy jól van, barátom, az OS jó lesz.. neeem, nem fogja elfogadni, ha átállítod és méééég akár restartolsz is, 2x, 5x, 20x, neeeem.. neki olyan kell ami US English, pont (bocccsánatotkérek' mert Japppán' locale-re telepítve is megy.. húúú, sokat segített). Ha ezzel megvagy (tehát újrahúztad az OS-t) akkor nekikezdhetsz az 1.1GB zip file kicsomagolásának majd az exe elindításának.. de hopppá, BUMM, szívtál, mert neeemámúgymegyaz, hogy 4.2.4-et teszel fel, neeeemám, 4.2 -> 4.2.2 -> 4.2.4 vagyis 2.4GB "alappal" megágyazol, majd egy 1.3GB "javítással" teszel fel lepedőt is és egy utolsó kis 1.1GB-nyi 4.2.4 javításokcska majd paplan lesz ehhez a mó.. és ebben van a 7 oldal known bug meg amibe beleszaladtam még mellé (mert volt és van olyan, ami a release notes-ban nincs benne). Majd rájössz, hogy van még a neten patch amit fel kellene pattintani, de ahhoz a daemon-t le kell lőni, egy perl scriptet lefuttatni, majd elindítani megint.. ja, hogy az alapból 2x20 perc úgy, hogy 10 eszköz van az adatbázisban? Bumm, szívtál.. (: kérdezhetitek, hogy dehát a legfrissebb a 4.2.5, miért nem azt választottam.. azért, mert a gép, amire fel kellett pattintanom még memóriával se rendelkezett.. így egy 15+ VM-et már tartalmazó Xen-re lett felpatkolva, amit csak miattam nem fognak v5-re frissíteni, örülnek, hogy nincs vele baj mert nincs rá support.. szóval a 4.2.5-nek Win2012 kell, azt a jelenlegi Xen v4 nem támogatja (meg nincs is licensz..) szóóóóóóóval ezzel a kis előtelepített Win2k8 "BUMM, szívtállal" kezdődött minden. (:
-
crok
Topikgazda
válasz
zsolti.22
#7995
üzenetére
Takkkknyosra szopat a Cisco Prime Infrastructure 2.2 meg a Prime LMS 4.2.4 - össze kellene raknunk egyet-egyet, 10k-s licensz, 65M JMF a listaára.. de baszki, hogy a release notes-ban 7(!) oldalnyi known bug van.. meg csak a 2 rendszer installálása alatt 5 TAC lett nyitva (eddig!), és van olyan bug aminek a workaroundja egy buggal végződik amire még nincs bugfix, de "a fejlesztők nagy erőkkel dolgoznak a megoldáson".. meg olyan bug, hogy az eszköztörlésnél ha keresel és kijelölsz valamit és törölsz akkor *minden* eszközt töröl.. váááá, nem bug, feature.. [szerk.] arról nem is beszélve, hogy dokumentáció kvázi még nincs is, mert minek lenne ha decemberben adták ki.. ami meg van az konzisztensen inkonzisztens: a HTML oldal fejlécében Prime LMS van, az URL-ben CiscoWorks de a szövegben felváltva 2H képlettel (2x hasadra csapsz és írsz valamit) hol LMS, hol CiscoWorks, hol Prime NCS (mert ez is van).. [\szerk.] mondom én, hogy a cisco (kisbetűvel, igen..) a hálózatok Microsoftja.. csapágyasra hajtottuk a szopórollert, a szopóhám, amivel rögzítve vagyok lassan elszakad, olyan gyorsan hajtjuk azt a rollert.. dús hajunkba tép a sok SR
oszt' ja, írok, kapom a notification email-eket, hogy van történés aztán kell a kis kikapcsolódás (:[ Szerkesztve ]
-
crok
Topikgazda
válasz
zsolti.22
#7975
üzenetére
Gratulálok! Ugye, hogy a TSHOOT a legkönnyebb? (: A "13 of 12" lehet hogy un. dummy volt: a sima kérdések közt is van olyan, amit nem számol a vizsga csak a Cisco nézi (teszteli), hogy milyenek a válaszok, nehéz kérdés-e, túl könnyű-e, van-e megjegyzés - ezzel tesztelik és hozzák be az új kérdéseket.
-
#7927
crok
Topikgazda
Cyber_Bird
#7926
crok
Topikgazda
válasz
Cyber_Bird
#7926
üzenetére
Szerintem jóra sikerült, teljesen érthetően elmondja hogy mi miért és hogy működik.
Ha lehet egy jótanácsom: VLC/SMPlayer-el nézd és gyorsítsd a video-t 1.3-1.5x-re
mert simán érthető és spórolsz vele egy csomó időt - ez igaz szinte minden CBT-re. -
crok
Topikgazda
válasz
FecoGee
#7924
üzenetére
Nem lehet netezni, ha lehetne mindenki min. CCIE Written lenne..
Itt a cégnél itt van PearsonVue központ, zárt rendszer, agyontűzfalazott,
a belépés után el kell venniük minden telefont, lehetséges segédeszközt..
csak azt használhatod amit tőlök kapsz (tehát kb egy toll meg egy lap,
pontosabban nálunk egy letörölhető filc meg egy műanyaglap).
Ja, és nálunk bent ül a vizsgán a "megfigyelő", de a minimum az az, hogy
monitoron néznek egy kamerán át.. Szóval nincs proxy se.. meg a gépen
ha alt+tab-olsz akkor se tudsz kilépni, mert a vizsgaprogram letiltja, de
a program egyébként is fullscreen, nincs lehetőséged se kilépni belőle
csak a vizsga befejezésének árán. Netet a vizsgagép közvetlen nem ér
el, csak egy VPN van helyben, amin keresztül a vizsgaközpont alkalma-
zottja tud belépni és a vizsgát elindítani. -
crok
Topikgazda
válasz
zsolti.22
#7904
üzenetére
Konverter nincs (legalábbis hivatalos) meg nem is mennék bele, mert sokkal összetettebb annál hogy ilyeténképp automatizálható legyen - főleg a Cisco által (: .. ha adsz konfigot (kiheréltet, ohne kunde info, ohne user/pass, pl. pastebin.com-ra vagy valahova felpattintva, esetleg privátban) akkor megnézem mert így leírva kb ezer+1 ötletem volna miért nem jó. Ja, most kint vagyok megint UK-ben 7 csodálatos hétre, szóval ha időm engedi nézzem tovább amit küldtél switching témában? @FecoGee: kalappal!
-
crok
Topikgazda
válasz
zsolti.22
#7842
üzenetére
Azért kaptál encap errort mert nem tudott a cél IP-hez CEF-ben bejegyzést.
Ez egy olyan "hiba" amit egy ARP kérés+válasz megold - és eleve így működik.
Ez normális ha pl. egy subnetben valakinek küldeni akarsz valamit küldeni
akkor ahhoz encap info kell (pl. etherneten MAC) ami egy ilyen interface-re
irányított def.route esetében nincs, hisz nyilván a cél nem lesz a linked másik
oldalán - így fel kell oldani a célt, ekkor jön az ARP kérés, amire senki se
fog válaszolni csak ha a Proxy-ARP miatt a másik oldalon valaki nem válaszol.. -
crok
Topikgazda
Jótanács: *sose* használjatok ilyen static route-ot, főleg ne def.route-ot:
ip route 0.0.0.0 0.0.0.0 fastethernet0/0
*mindig* adjatok meg next-hop-ot broadcast interface-en keresztül,
meg is mondom miért: megfelelően nagy forgalom és megfelelően
nagy uptime esetén ez betölti az ARP tábládat a következőképp:
a routernek def.route-ja van fa0/0-n keresztül, ez neki azt jelenti,
hogy minden, ami nincs a routing táblájában az directly connected
a fa0/0-n keresztül (ez nem serial vagy frame-relay point-to-point
hanem broadcast kapcsolat), így egyfelől csak akkor fog bármi is
működni, ha a linken, a broadcast domain-ben valaki Proxy-ARP-ot
csinál (default tiltani kell nehogy egyszerre ha két routered van
ketten válaszoljanak neked) másrészt minden egyes cél IP címre
lesz egy ARP bejegyzésed a static route-ban meghatározott inter-
face-en keresztül, ugyan azzal a MAC-el csak ugye más-más
cél IP-re, mert hát a router szemszögéből neki minden, amit nem
ismer connected.. ilyet nem szabad csinálni, Proxy-ARP csak
nagyon indokolt esetben engedélyezünk másrészt a static route-
nak mindig adunk next-hop-ot hogy CEF táblába egy bejegyzés
kerüljön, nem cél IP-nként egy (:
ne használjátok IOS upgrade-re, mert ha nem volt jó a copy akkor is restartol.. ugyanis felmásolja az IOS-t, megnézi, hogy a file *nagysága* megegyezik-e a szerveren levő IOS nagyságával, restart, visszalép és MD5 hash-t néz.. ami persze kb. már mindegy, mert ha visszajött, akkor jó volt az IOS.. ha nem akkor nem lesz MD5 se (: Egy vicc.. komolyan.. olvass vissza, írtam már róla, és nálunk egyben használunk LMS-t is és Prime Infrastructure-t is. Kuka mind a kettő, többet tudok már a rendszerről mint maga a Cisco, eddig még csak úgy jött vissza SR, hogy a) jó ötlet, adjunk fel PER requestet hogy a dev. team lássa hogy van feature igény; b) ismert bug; c) ismeretlen bug..
Új hozzászólás Aktív témák
- 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 13 128GB, Akku: 85%, Megkímélt, Kártyafüggetlen, Töltővel, 1 Év Garanciával!
- Eladó digitális fényképezők, objektívek, egyebek számlaadással
- Samsung Galaxy S23 Ultra 12/512GB, Megkímélt, Kártyafüggetlen, Töltővel, Dobozzal, 1 Év Garancia!
- Samsung Galaxy S23 Ultra 8/256GB, Megkímélt, Kártyafüggetlen, Töltővel Dobozzal, 1 Év Garancia!
- Lenovo P12 + Pen 8GB TB370FU Tablet 12,7
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest