-
Fototrend
--- 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
-
crok
Topikgazda
Na, csak bepréseltem még az évbe egy certet, igaz csak CCNA Voice (: most néztem, hogy mióta irogatok ide megcsináltam a CCNA Sec-et, CCNA Wireless-t, a JNCIA-t, a JNCIS-ENT-t meg most a CCNA Voice-t.. mostmár elkezdem rendesen a voice vonalat végre.. esetleg egy CCIE written (meg lab ha lesz időm az elkövetkező 2 évben, de mivel most kezdtem egy architect munkát.. majd meglátjuk..).
-
crok
Topikgazda
válasz
FecoGee
#7768
üzenetére
Ha a Tunnelben is akarsz class-okat, esetleg nested MQC-t akkor oda is felteheted (ekkor ha pl. több tunnel is van egy fizikai interface-re akkor minden tunnelt egyesével police-olhatsz, shape-elhetsz és tunnelenként csinálhatsz CBWFQ-t) de Tunnel konfigban "qos pre-classify" parancsal "kimásolod" a tunnelben továbbított csomag jelölését és így azt felhasználhatod a fizikai interface alatti QOS konfigban is. (Nem tom' mennyire volt érthető, de átgondolom és átírom ha nem.)
-
crok
Topikgazda
válasz
zsolti.22
#7758
üzenetére
Egyáltalán nem arról van szó, hogy jobb lett volna csöndben maradnod (: csak megjegyeztem, hogy a hasonlat nem ideális ahhoz amit mondani akartál - de egyetértek, van, amikor igaza van: miért kerül többe, ha nincs több adott érték és nem változott a környezet se (nincs többlet költsége az előállítónak.. ilyesmi..).
-
crok
Topikgazda
válasz
zsolti.22
#7755
üzenetére
Ha egyetértenék mindketten tévednénk (: A hasonlat nem pontos.. ha a TV előfizetéshez (, amit eddig használtam/néztem) új szolgáltatást akarok akkor fizetek érte és ha az internethozzáférés sebességét növelni akarom, akkor fizetek érte többet.. ha egy eddig nem meglevő dolgot akarok bevezetni és az egy ilyen változó dolog és így folyamatos, hozzáértő módosításra van szükség akkor azért fizetni kell, pont. A víruskereső egy _pont_ ilyen dolog.. napi 30000 új vírus van minimum.. ki kell fizetni a vírusfelismeréshez használt pattern fejlesztők munkáját, pont. Természetesen ha nem fizetsz akkor is marad valami védelem ez eddig ismert vírusokkal szemben mint ahogy egy egyszeri torrentszűrő kiépítése/konfigurálásánál is szűri azt amit "addig ismert". Na *ez* ilyen.. [Szerk.] A vírusfelismeréshez használt pattern matching egy olyasmi eljárás mint az NBAR egyébként (:
-
#7751
crok
Topikgazda
Cyber_Bird
#7750
crok
Topikgazda
válasz
Cyber_Bird
#7750
üzenetére
Jahj, igen, ismerős: minden kell de ingyen - vagy olcsóbban (:
-
crok
Topikgazda
válasz
zsolti.22
#7747
üzenetére
Tapasztalat: szart se ér se az NBAR se az NBAR2 torrent ellen.. egy tick és titkosított.. amivel lehet ellene küzdeni az az, ha NBAR/NBAR2-vel meg MQC QOS-el class-t csinálsz neki és dropolod, teszel fel ZBFW-t, abban class-t és ott is drop-olod (sajnos valahogy az a tapasztalat, hogy van, amit az egyiken, van, amit a másikon fog meg az IOS :\ ) plusz teszel fel mindkettőbe egy-egy olyan class-t, amiben egy ACL van, amiben meg az ismert bittorrent bootstrap node-ok vannak felsorolva (DHT miatt, ugye piratebay meg egyebek, van ilyen lista a neten, persze állandóan változik) meg az ismert zárt oldalak tracker-ei (ncore, microbit, bithumen, gigatorrents.. et cetera, szintén váltohat bármikor, plusz tiltanám a torrent weboldalak frontend IP-it is) és a class-t dobatod.. mind a QoS mind a ZBFW policy-map-ben. Ezeket kifelé és befelé egyaránt meg kell valósítani.. Ekkor már egész jó "hatásfokkal" megfogható a torrent: megfogja azt is ami piratebay, isohunt, demonoid meg mittoménegyébtorrenteket meg a zárt oldalakat is (amennyire jól írod meg az ACL-t amit írtam..). De a bootstrap a torrentben hálistennek' DNS alapú, tehát bármikor átállhatnak az IP-k.. ez ellen is lehet tenni, pl. úgy, hogy a router legyen a DNS szerver (ami persze plusz CPU, oda kell figyelni..) és beállítani, hogy a router az OpenDNS-t használja (vagy egyszerűen a router DHCP-n ossza ki a DNS szervert és legyen ez a 208.67.222.222 és a 208.67.220.220) és ott beregeled a publikus IP-det (ha nem fix akkor mindig utánaállítod, ez nem nagy ügy) viszont ott lehet kérni, hogy bizonyos DNS kéréseket ne oldjon fel (: van direkt "P2P" szűrés, Family friendly browsing ha érted hogy mondom (: Ez egy véget nem érő harc, állandóan naprakészenk kell lennie az ACL-eknek meg a protocol pack-nek. De az operáció frissíthet bármikor, havi rendszerességgel mondjuk (: Az egyszeri user-ek ellene működik ez egész jól.. de folyamatos karbantartás szükséges. (Na megint hosszú lett, mondjuk legalább valamelyest működik.)
-
crok
Topikgazda
válasz
zsolti.22
#7745
üzenetére
Két dolog:
- ha protocol pack akkor az már NBAR2. Az NBAR nagyon messze
van attól a felismerési sikerességtől amit az NBAR2 nyújtani tud - viszont
NBAR2 meg nincs ISR G1-re, csak G2-re, és protocol pack-ot se tudsz
frissíteni csak (emlékem szerint) 15.2(2) felett - alatta csak az IOS-ben
levő protocol pack él (de az is csak 15.1 felett tudja), oszt' sanyi.- igen, "intelligens" az NBAR: pont az a működés lényege, hogy un. pattern-t
keres a data-ban, nem feltétlenül kell pl. a 80-as porton mennie egy HTTP
forgalomnak hogy az IOS NBAR/NBAR2 felismerje.Az NBAR2 óta ezt nem is így hanem AVC-nek (Application Visibility
and Control) hívja - ugyan azt a metódust használja a WLC is mint
az IOS (minnnnnndent mindennel összemos a Cisco mostanában..).- "Unify everything" -
/Rövid voltam remélem (: /
-
#7730
crok
Topikgazda
Cyber_Bird
#7729
crok
Topikgazda
válasz
Cyber_Bird
#7729
üzenetére
Bárki bármikor bármilyen vizsgát letehet - a recommendation arra vontkozik, hogy mi kell ahhoz, hogy a cert-et megkapd, postázzák. Ez money washing machine, a Perason VUE vizsgacenterek és a Cisco oldaláról is, és évek óta remekül működik (:
-
crok
Topikgazda
válasz
zsolti.22
#7697
üzenetére
Sok cseresznyét! (:
Közben egy kis scripting - írtam egy olyat, ami nagyban hasonlít a Cisco CLI "section" parancsára. Abban lehet segítségére az ember fiának/lányának, hogy offline, mentett configban gyorsan keressen (linux vagy windows+cygwin alatt pl..) . Itt megtaláljátok a leírást.
-
crok
Topikgazda
Sikeresen belefutottunk egy eddig még ismeretlen Cisco bugba (:
CSCus03707 - "SPF stub route not installed in the RIB with overlapping subnets"
Annyi a lényeg, hogy overlapping subnetek vannak a hálónkban egy helyen, és
az OSPF nem teszi be a RIB-be a more specific utakat.. mert nem.. (:
Sajnos még nem public, egyelőre mi 6500-on látjuk csak de más platformot is
érinthet. A Cisco megoldása az, hogy *ne* használjunk overlapping hálókat (:
..vagy várjuk meg a codefix-et. Hát annyit toltam rá vissza, hogy lol -
crok
Topikgazda
válasz
FecoGee
#7678
üzenetére
Új feature: CSHNE (: Cisco Self-Healing Network Element (:
Mi a CSCNE-t szoktuk még használni, Cisco Self-Configuring
Network Element - rendszerint arra használjuk ha a change
control több energiát emészt fel mint a tervezés+implementálás (:
Más - olyan idióta bugba futottunk bele, hogy az ember esze elmegy:
statikus NAT a running konfigból eltűnik, ha olyan traffic jön be, ami
match-el erre a NAT konfigra akkor bizony a static NAT eltűnik a run-
ning konfigból (a startból nem..) ám a NAT bejegyzés bent marad a
NAT táblában.. mliyen jó, ha valaki véletlen ráment a konfigra így,
mert mondjuk volt egy tervezett konfigváltoztatása.. mókás.. -
#7645
crok
Topikgazda
Cyber_Bird
#7644
crok
Topikgazda
válasz
Cyber_Bird
#7644
üzenetére
Akkor marad a stílus.. (: lehet túlmagyarázom néha.. szoktam oktatni ha kell - lehet innen a stílus.. meg azért ís írom le néha így mert sok téma ami itt feljön máshol egyszerűen nincs leírva vagy egyszerűen nem találja meg az ember sehol (se learaningnetwork és hasonlók, se networkingforum, se reddit, se juniper fórumok, se google/bing/yahoo nem találja..) nem hogy magyarul.. angolul se.. vannak dolgok amiket nem tanítanak hanem ugye jön az évekkel.. meg a bugok ugye (: sokan nem szívesen osztják meg ezeket, mert ugye a saját konkurenciáját látja el az ember hasznos infoval - én szívesen megosztom, ez amolyan -hacker- szabály, hogy amit egyszer valaki megcsinált azt más ne csinálja meg mégegyszer hanem használja fel azt ami már egyszer meg lett csinálva (:
-
-
#7560
crok
Topikgazda
Hedgehanter
#7559
crok
Topikgazda
válasz
Hedgehanter
#7559
üzenetére
Ezen vagyok épp (:
-
#7556
crok
Topikgazda
Cyber_Bird
#7555
crok
Topikgazda
válasz
Cyber_Bird
#7555
üzenetére
Könnyűnek nem mondanám semmiképp (:
-
#7554
crok
Topikgazda
Hedgehanter
#7553
crok
Topikgazda
válasz
Hedgehanter
#7553
üzenetére
Nem-nem.. első nap: itt van egy mindmap, hogy milyen technológiákat használunk felsorolásszinten, van 4 heted átrágni magad rajta.. (Routing (CEF/FAST/Process path, RIP, OSPF, EIGRP, BGP, mindhez hogy mit és hogy lehet szűrni, jelölni, tag-elni, community string-ek, AS_Path módosítás, metrikák állítgatása, distribute-list, prefix-list-ek, ACL-ek route-filtering-re, reverse route injection, redistribution, route-map-ek, summarisation, et cetera..); Switching (STP minden formája, channels, CatOS, igen, van.. sajnos..L2 security, mint DHCP snooping, Dyn. ARP inspection, storm control, 802.1x, port security..); MPLS (klasszikus és IPSec értelemben is!), Security (IPSec meet-in-the-middle, IPSec over GRE, DMVPN, Site-to-Site, SSL VPN, PKI, tűzfalak úgy is mint ASA/PIX/Checkpoint/JuniperSSG de van FWSM is - sajnos ismerni kell, mert rajtunk keresik azokat a hibákat is amik a tűzfalakon vannak.. IOS tűzfalmegoldások, mint CBAC, ZBFW, ACL-ek, uRPF, mgmt plane security, DoS támadások elleni védelmek, itt van pl. remotely triggered blackhole routing is.. AAA, 802.x); Enterprise Wireless (WLC, autonóm és LW AP, RADIUS auth, LWAPP/CAPWAP, mobility, AF/RF groups, roaming, NAC, WCS/NCS Prime.. ja, nem csak Cisco.. van Motorola Symbole is..); QoS - technikák, WRED, WRR/SRR/LLQ, CBWFQ, classification, policing, shaping, nested MQC, VoWLAN; FHRP: HSRP/GLBP/VRRP.. mind van..; DHCP; SNMP akár kézzel is.. úgy értem mass poll scriptelés, mass config módosítás.. IP SLA, EEM scriptek, Netflow (akár CLI-ben is, ugye, szegény ember wireshark-ja..; WAN, minden mennyiségben: ADSL, serial p2p, frame-relay p2p, p2mp, ppp, pppoe, pppoa, metro ethernet, cwdm, DC megoldások, C6500, ACE/CSM modulok - load balancing, Nexus) éééééééés ehhez *mindhez* hardware architektúra, hibakererés minden szinten.. aztán jön az ügyfélháló megismerése mondjuk 3 hétben.. amit említettem 1mx1.5m kis rajz alapján..aztán a többi ügyfél megismerése ugyanígy.. az összes szolgáltatástípus leírásának áttanulmányozása, példák átrágása, site-ok megismerése rajzon, belemélyedés az eszközök belső világába.. megoldott jegyek kivesézése, emberek megismerése a szervezetben, a folyamatok megismerése az organizációban.. és bumm, 2 hónap eltelt és ügyeletes vagy (:
-
#7550
crok
Topikgazda
Hedgehanter
#7549
crok
Topikgazda
válasz
Hedgehanter
#7549
üzenetére
Nos, a héten lett kész egy olyan rajz, amin a DC-k vannak rajta sematikusan, a szolgáltatástípusok szerint mindenből egy site kiépítve, valamint a külsős elérések kiépítése és a "szolgáltatások" (de van, ahol pl. egy komplett external DC csak egy-két eszköz/felhő által van reprezentálva..). Draw.io-n csináltuk és - kapaszkodj - ez a tényleg minimál sematikus ábra most jelenleg egy minimálisan 1mx1.5m nagyságú lapra férne el úgy, hogy már így is kicsit kicsinyítve van. (:
-
#7544
crok
Topikgazda
Hedgehanter
#7542
crok
Topikgazda
válasz
Hedgehanter
#7542
üzenetére
Jajjdehogynincs... (:
-
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
Juteszembe: amúgy erre találta ki a Cisco a max-reserved-bandwidth-et: ez az érték 75% alapértelmezetten, vagyis 25%-a a linknek alapvetően csak routing update-re, STP-re, satöbbi hasonlóra van fenntartva (75% loadnál kezdődk az a jelenség, mikor az input queue-ban megjelenik a flush (ami "torlódásmegelőző dobás" és a reserved bandwidth-nél kezdődik). Ha nincs más megadva akkor az MQC class based weighted fair queue meg az összes MQC "fancy QoS" feature is eddig a 75%-ig használhat sávszélt (amolyan beépített védelem az ellen, ha nem csinálnál külön "network class"-t). Akkor gyanítom, hogy nálatok nincs ilyen CBWFQ és abban külön network class (vagy nincs jól jelölve a forgalom?) és/vagy a max-reserved-bandwidth is meg van piszkálva 100-ra,
-
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
Csináltam egy ilyet magunknak (lentebbi szinteknek) "hogyan találj meg switchloopot gyorsan" címmel. Angol a feliratozás mert céges belső cucc de nincs benne semmi céges egyáltalán. Lehet megkövezni vagy bármi de eddig még mindig működitt az eljárásom (: Ha esetleg módosítani akarja valaki akkor ezt a png-t be lehet tölteni és szerkeszteni a draw.io oldalon. Just FYI..
-
-
#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. -
#7280
crok
Topikgazda
Hedgehanter
#7279
crok
Topikgazda
válasz
Hedgehanter
#7279
üzenetére
Na, nálunk most kezdtek rájönni erre - és mostmár bevonnak minket is a kiválasztási folyamatba, kb. az elejétől.
-
#7277
crok
Topikgazda
Hedgehanter
#7276
crok
Topikgazda
válasz
Hedgehanter
#7276
üzenetére
Sajnos ez egy nagyon rossz HR-es gyakorlat.. ):
-
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
válasz
zsolti.22
#7228
üzenetére
Nem ajánlom hacsak nincs service module-od erre, mert CPU-ból kellene megoldania mindent - egyszerűen nem erre való a router, nincs is hol tárolnia (cache) a proxy-zott anyagot. A Cisco IOS-ben az SSH sajnos nem tud dynamic port forwarding-ot, de még ha tudna is nagyon-nagyon szűk keresztmetszet a CPU. Egyébként AnyConnect VPN a routerre, aztán trükközés a webvpn group policy-ban a routing-al, a splittel, PBR is kellhet, local auth-hoz userek.. játszótéren kipróbálni jó, de produktívan kismértékben se ajánalnám, inkább egy webproxy egy régi vasból és static NAT.. de ami mégjobb, hogy régi vas SSH-val, dinamikus portforward-al static NAT-olva és kaptál egy titkosított SOCKS 5 proxy-t..
-
crok
Topikgazda
-
crok
Topikgazda
válasz
stafidani
#7212
üzenetére
Durván összetett azért ahhoz, hogy egyszerűen a+b=c legyen (:
Megpróbálom a minimumot/legegyszerűbbet összerakni (nem életszagú).
Egyetlen ethernet keret layer 1-en (MTU 1500, VLAN tag nincs):
Alatta leírom mennyi kell belőle.
-----------------------------------------------
12byte Ethernet gap + 8byte Ethernet preamble
-----------------------------------------------
-- Ethernet Frame:
----------------------------------------------
--Ethernet header:
--6 byte dest addr
--6 byte src addr
--[4 byte 802.1q VLAN Tag ha van..]
--2 byte length/type
-------------------------------------------------
------ IP Packet
--------------46-1500 byte data (payload)----------
----20byte IPv4 header:
----1byte Version; 1byte IHL; 1byte ToS; 2byte Length;
----2byte Identification; 3bit Flag; 13bit Fragment offset
----1byte TTL; 1byte Protocol; 2byte Header Checksum;
----4byte dest addr; 4byte src addr
----8byte Options (ha van, mert az IHL több, mint 5 (5x32=20byte))
---------------------------------------------------
-------- TCP segment
-----------------------------------------------------
--------20byte TCP header
--------2byte src port; 2byte dst port;
--------4byte sequence number
--------4byte acknowledge number
--------4bit data offset;
--------3bit reserved; 9bit flag (syn;ack;psh;rst;...)
--------2byte window size
--------2byte checksum; 2byte URG pointer
--------(Ha a data offset 5-nél nagyobb akkor az Options rész is
--------tartalmaz adatot- nagyságát az 5-nél magasabb offset
--------határozza meg (5x32=20byte a header alapból, ha nincs
--------az Options alatt semmi akkor 0-val van feltöltve 4byte-ig de
--------úgyis lesz egy kevés, mert kell pl. SYN-ben az MSS..))
-----------------------------------------------------
-----------------
-----------------
----------------- A HTTP adat, ami a végén 1MB-ot fog kiadni.
-----------------
-----------------
----------------- Csomagonként 1460byte a maximum..
-----------------
-----------------
-----------------------------------------------------
--------
---------------------------------------------------
------
----------------------------------------------
--4 byte Ethernet FCS
-----------------------------------------------
4byte Ethernet trailer
-----------------------------------------------
Na, ekkor jön egy olyan, hogy 3way handshake miatt egy SYN, egy
SYNACK és egy ACK. => 3x Ethernet frameben IP csomag 0 payload-al.
Kell egy HTTP GET, ami minimum ennyi:
GET / HTTP/1.0[ENTER] \
[ENTER] |-- 17 byte összesen
[ENTER] /
..amire a szerver válaszol egy "üres" ACKel és tolja az 1MB file-t:
Tekintsük a TCP receive window-t a maximumnak: 65536byte (nincs
specifikálva se az kliens OS, se a szerver, se a szerver OS; az
életben TCP receive window 17.5KB lenne mondjuk egy "átlagos gépnél").
Így (1024*1024byte)/65536byte = 16 TCP full window lenne az átvitel
ideális esetben de mivel az ack is kell és 1460byte egy csomag, így
ideális (csomagvesztés nélküli) esetben kell 16 ACK csomag is és a
data 44.89 tehát 44db 1460byte-os valamint egy 1296byte-os csomag
lesz egy teljes TCP window. Ehhez jön még window-nként egy ACK.
Majd a végén a lezárás (nem az "elegáns" Windows Serveres RST,
hanem) egy rendes, FINACK a klienstől +ACK a szervertől.
Durvaélet kihagytam valamit, de tippre a tanár már így is többet kap
mint amire számít. Ha nem lenne itt nézhető, akkor vagy kijelölöd és
átteszed notepad-be (vagy fix széles karakterekkel nézed meg) vagy
feldobtam pastebinre: http://pastebin.com/c5rBrzU4 -
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 -
crok
Topikgazda
válasz
FecoGee
#7135
üzenetére
Röviden? Sehogy (: Kifejtve annyi, hogy a latency-t igazából nem tudod
"nagyon" változtatni (a fizika az fizika, a jelnek el kell jutnia A-ból B-be,
ám persze van lehetőséged javítani egyes dolgokon és nyerni pár ms-et).Így ami marad az max. az, ha a CE-hez közel választasz PE-t. Ha site-
to-site bérelt vonalad van akkor adott az út, adott a fizikai korlát. Amit
lehet változtatni és a latency része az a feldolgozási idő, queuing.. Erre
való a QoS pl. (: A backbone-okban nagy SP-nél úgyis MPLS lesz és
úgyis lesz rá policy, hogy mely utakat hol érsz el gyorsabban (TE). Az
SP hasra nem fog leírni dolgokat a szerződésbe, természetesen van
amit nem lehet megoldani, pl. kb. 180ms-nél kisebb latency-t nem tudsz
tartani EU és Malajzia közt, mert egyszerűen fizikailag nem lehet, ennyi
idő kell míg a jel eljut oda. Azzal lehet trükközni, hogy azt mondod hogy
210ms és erre vállalsz garanciát - és reménykedsz, hogy a legrövidebb
általad bérelt tengeri kábelt nem fogka elvágni megint a szomáliai kalózok
hajójának vasmacskája - nem röhög, együttérez, évente 2x megtörténik -
és tudod tartani.. ha nem és beüt a sz#r akkor rerouting Afrikát megkerülve
-> 240ms minimum.. persze hibajegy, kötbér, et cetera.. na így megy ez.
De ameddig nincs sz#r addig kapja az SP a vaskos pénzködeget a vonalért.
Szóval a szerződésben már valami kialkudott érték lesz amibe belement
az ügyfél (ha nem ment volna bele aláírt volna egy másik szolgáltatónál,
akinek esetleg más az infra- struktúrája, más tengeri kábelt használ, et
cetera..). Na, ettől függ. Ezeket ajánlom még:
Bandwidth-delay product
Miért nem tud az ember egy másik földrészen levő szerverről csövön letölteni
ha egyébként 1G uplinkje is van az ISP-jéhez -
crok
Topikgazda
-
-
crok
Topikgazda
-
crok
Topikgazda
Akkor most megosztom veletek az én online library-met.
Sok-sok év alatt gyűjtögettem mindentfélét bele, CCNA
szinttől CCIE-ig, routing/switchingtől QoS-ig, telekommu-
nikációs alapoktól utcai kábelezésig, security-től doom
day-ig sokminden. Próbálom minden részét karban tartani,
ez persze nem mindig sikerül így se 100% up-to-date se
100% teljes soha nem lesz, de azért aki szeretné az itt
elérheti >>Cr0k's online library @MEGA.co.nz<< -
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.) -
crok
Topikgazda
válasz
FecoGee
#6814
üzenetére
Azért kell, hogy az access switch ne lehessen lehetőleg semmiképp se
traffic transzfer switch (emígyen mesterségesen elrontja a port cost-ot a
feature és megakadályozza ezt, persze ahogy előttem írta tusi_ átírhatod,
csak bukhatod az STP topológiádat). A továbbiakban meg azért jó, mert
pl. az "új" uplinken dummy keretekkel "megtanítja" a "backup" switch-el
a CAM táblát. (Leírás). Mint mindent ezt is okosan kell használni. (: -
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.. (: -
crok
Topikgazda
válasz
FecoGee
#6731
üzenetére
Ne keseredj el, ez (mint már írtam) money washing machine..
Nálunk minden iskolában úgy álltak hozzánk, hogy mindig
van egy olyan kérdése a tanárnak amire nem tudunk válaszolni.
Az, hogy a ping megy még sajnos nem minden.. nem _úgy_
ment ahogyan azt ők látni szerették volna.. mittomén' aszim-
metrikus volt a routing, valami hülye route-map nem úgy ment
ahogy _kellene_ (mert igyen, bugok is vannak..) Szóval..Ez ilyen.
Ne keseredj el, ha a célod a CCIE akkor ki kell tartani!
Mindenesetre még így is azt mondom: gratula, ott voltál! (: -
crok
Topikgazda
Az a leírás Linux Mint 64bit-re van írva plusz szerintem a coredue opció
is felesleges. Te is linux alá vagy Windows alá szeretnéd összehozni?
Itt mindent megtaláltsz egyébként (én szedtem össze, fix, hogy megy).
(Most, hogy nézem nálam nincs különbség a Win/Linux setup közt..)
Ú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!
- OLED TV topic
- One otthoni szolgáltatások (TV, internet, telefon)
- Revolut
- iPhone topik
- Mielőbb díjat rakatnának a görögök az olcsó csomagokra az EU-ban
- Synology NAS
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Kormányok / autós szimulátorok topikja
- Apple iPhone 16 Pro - rutinvizsga
- További aktív témák...
- Microsoft Surface Laptop 3 - 15 col - Fekete
- BESZÁMÍTÁS! 860W Fractal Design ION + 2 Platinum tápegység garanciával hibátlan működéssel
- BESZÁMÍTÁS! GIGABYTE H77-DS3H H77 chipset alaplap garanciával hibátlan működéssel
- Bomba ár! HP EliteBook 840 G2 - i5-5GEN I 8GB I 256GB SSD I 14" HD+ I Cam I W10 I Garancia!
- Dixit 4 Eredet (bontatlan, fóliás kártyacsomag)
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged