- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- vrob: Az IBM PC és a játékok a 80-as években
- bambano: Bambanő háza tája
- Tomasz72: Ventilátor upgrade
- Magga: PLEX: multimédia az egész lakásban
- Parci: Milyen mosógépet vegyek?
- eBay-es kütyük kis pénzért
- Mr. Y: Motoros sztorik #06
-
LOGOUT
--- 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
E szerint van benne Bandwidth control. Érdemes lenne definiálni a
torrent forgalmat és korlátozni (pl. beállíŧani korlátozást a LAN-ban
levő minden gép torrent portjára range-el pl.. mert ugye forwarding
úgyis lesz (: Ez is kb. ugyan az TP-Linken mint amit elmondtam
Cisco-ra. Az elv ugyan az lesz. Egy próbát megér, max nem jobb.
[Szerk.] Egyszerre (: -
crok
Topikgazda
A torrent baromi aggresszív tud lenni, lévén tompítatlanul zúgathatja a
forgalmat (erre lett kitalálva: minél gyorsabban minél több helyre jusson
el az adat). A torrentben nem cink a csomagdobás, nem szabályozódik
a sebesség mint egy TCP alkalmazás esetében. Lehet a PPP keepalive
nem fér be vagy DSLAM oldalon eldobódik mert már nem fér be a keret.
Ilyen esetben ADSL-nél a DSLAM oldalon tudnál érdemben kezdeni valamit
egress traffic controllal (police vagy shape).@Ferke: a traffic shape az ügyféloldalon segíthet de csak az upload
irányt tudod így befolyásolni (egyébként se lehet shape-elni csak kifelé).
TCP alkalmazásokra így lehetsz hatással, másra sajnos nem.Amivel hatni tudsz a dologra az az, hogyha csinálsz egy inbound service-
policy-t amiben match-elsz a torrentre (NBAR.. ugye az nem olyan jól
ismeri fel a torrentet, a titkosítottat meg méginkább nem..) és police-
olod mondjuk 8Mbps-re (police-olni tudsz ki- és befelé is). Így talán jobb
a helyzet, ám ha a DSLAM felől (tehát a peer-ektől) mindenképp nagyon
sok a packet akkor ezt is megölheti sajnos de legalbb less likely.. csak
marad az a 2Mbps az interface-eden, ha addig eljut a nem-torrent adat
(pl. PPP keepalive, HTTP, DNS, megamikell'..)akkor minden okay - lehet.
[Szerk.]
Ja igen, IOS upgrade mehet 15-re esetleg, abban az NBAR kicsit már jobb. -
crok
Topikgazda
Túl közel forwardolták egy szingularitáshoz..
-
crok
Topikgazda
válasz
FecoGee #6297 üzenetére
Ha ilyesmit akarok mutatni akkor felnyomom ide: http://pastebin.com/
Linux alá van progi, amibe ha pipe-olsz valamit felnyomja és megadja, hogy mi lett a linkje (: -
crok
Topikgazda
Még csak Cisco Internal bug ("földi halandó" nem tud rákeresni még):
CSCtu36508 IPSLA UDP-Jitter Operation Enhancement for ASR1K
https://tools.cisco.com/bugsearch/bug/CSCtu36508Symptom:
When the ASR 1K is inserted either as a probe source or a responder
a high max RTT/Jitter values is seen for the UDP-Jitter probe.Conditions:
This is a feature bug created to track 'Enhanced IPSLA UDP-Jitter probe".
The enhancements include specifically for ASR1K platform:
- Do time stamping at CPP level to improve the measurement accuracy
of UDP-jitter operationWorkaround:
Do not use ASR 1k for jitterThis issue has been fixed starting from IOS-XE 15.2(4)S.
-------------------
Mi ezt használjuk
/Bugscrub alapján "hibamentes" (persze a NAT ebben is s#&r)/
asr1000rp1-advipservicesk9.03.10.01.S.153-3.S1-ext.bin -
crok
Topikgazda
Én azért kerítenék egy régebbi és/vagy desktop gépet amin van
serial port, nem USB, meg egy új kábel.. esetleg xmodem és
a baud-ot 115200-ra tolod (hogy mégiscsak gyorsabb legyen).
Milyen típus pontosan? L3 esetleg? Lehet TFTP-ről akkor be
lehetne bootoltatni, onnan már kicsit több a lehetőség. I/O error
lehet a puffer hibája is, hogy onnan nem tud a flash-re másolni.[Szerk.] @Gesztiboy: xmodemmel is rossz, nem így a TFTP
dolog nemigen játszik. -
crok
Topikgazda
válasz
Hedgehanter #6210 üzenetére
A networking Microsoft-ja.. akármilyen protokollhoz ha route-map-et
használsz és abban ACL/prefix-list vagy bármiegyéb hasonló van
megadva.. és változtatsz rajta.. a változtatás nem feltétlen triggereli
a routing protokollt hogy legyen szíves eképp/aképp cselekedni.. majd
ha valami változik a routing táblában vagy a protokollban.. majd az.. így
pl. BGP peer-en route-map-ben ACL/prefix-list változtatás után is minden
esetben soft clear "ajánlott" (ja, milyen érdekes, hogy hogy ezt a "soft
clear-t" feature-nek adják el a Cisco-nál, közben meg egy manual work-
around). Ez sajnos így működik. -
crok
Topikgazda
válasz
Cyber_Bird #6197 üzenetére
"Épp aktuális" "különleges" ajánlatunk alapján "csak neked csak most.." XD
-
crok
Topikgazda
válasz
Cyber_Bird #6195 üzenetére
Nah' igen.. higgyétek el: a Cisco-ra 2 dolog igaz:
- a networking Microsoftja..
- money washing machine.. minden szempontból (HW/SW/CERT/et cetera..) -
crok
Topikgazda
válasz
Cyber_Bird #6188 üzenetére
-
crok
Topikgazda
válasz
FecoGee #6183 üzenetére
Ajj, de az is.. design fail.. a felesleges túlbonyolítás.. Internetet oszunk LAN-ba..
"Maximális biztonság" - tegyük VRF-be a LAN subinterface-t és hagyjuk a globál
táblában a Internet interface-ét.. aztán felismerés: nem olyan egyszerű az oda-
vissza routing NAT-olással.. aztán összeszenvedi az architect.. aztán megpróbálja
Zone Base Firewall-al védeni a LAN-t.. aztán rájön, hogy a ZBFW csak akkor
konfigurálható, ha minden interface egyazon VRF-ben van.. aztán otthagyja..
és jön nekem ide a hibajegy.. na az ilyentől kiakadok.. teljesen.. . ):Mindazonáltal istentelen jó megoldás tud ám lenni! Egyébként ami még ennél
is durvább: Juniper-t particinálni "különálló" routerekre, és 2 interface-el meg egy
cross-kábellel (unit-okkal) 4..5 (vagy több!) tagú csillag topológiát csinálni (: -
crok
Topikgazda
Kimeneteid alapján nálam is ez a konklúzió, plusz Peplnjak apánk is megmondta ezen cikk legalján.
-
crok
Topikgazda
Így, hogy nem látom magam előtt a hálód - nehéz. Én most azt csinálnám,
hogy mivel a user-ek .254-et kapnak a szervertől és gyaníthatóan nem megy
a sírás, hogy nem megy azt gondolom valahogy mégiscsak működik. Én
most azt nézném meg, hogy az SVI-ról tudod-e a .254-et pingelni.. vagyis
pontosabban nekem az is mindegy ha nem, csak ARP legyen hozzá. Aztán
megnézném, hogy a MAC-et honnan tanulja, melyik porton esetleg vagy hogy
a chassis sajátja-e a MAC. Aztán mozdulnék tovább az eredmény tükrében. -
crok
Topikgazda
válasz
Gesztiboy #6047 üzenetére
Az mindegy, hogy GigE vagy TenGig vagy FastE.. a lényeg az a sebesség
amire beállt a port. A portok beállt sebességének kell megegyeznie. Szóval
lehet egyik oldalon GigE szembeállítva másikon FastE-vel, ha a beállt sebességek
megegyeznek akkor az összes linket be tudja használni a channel. A mi
esetünkben TenGig SFP+ volt az egyik és GigE SFP a másik link.. így, ugye
mivel a TenGig SFTP+ nem tud GigE sebességet amúgy se így kizárt, hogy
olyan összeállítást hozz össze, amiben mind a két portot tudod használni a
channelben, lévén a két port egyszerűen nem is tud azonos sebességen működni..
AFAIK.. -
crok
Topikgazda
válasz
FecoGee #6042 üzenetére
De az milyen, mikor látod a management rendszerben, hogy a switchek
mennek le, jönnek fel, mennek le, jönnek fel, egyszerre.. mind.. =D@jerry311: van még pár ilyen design fail nálunk is, pl. etherchannel egy
tengig és egy gig interface-ből.. aztán sipákolás, hogy azt mondja az
eszköz, hogy a gig link "suspended".. ki gondolta volna.. =D -
crok
Topikgazda
válasz
FecoGee #6038 üzenetére
Hú, apám, volt egy "architektünk", aki konzekvensen minden általa
összerakott switch uplinkjét portfastra de minden access portot simára
konfigurált, de állandóan.. szerencsére már nincs köztünk.. mennyi, de
mennyi hibajegyet okozott a sok TCN miatti learn folyamat.. link up/up
de semmi kommunikáció, az ügyfél IP telefonjai megsüketülnek (akár
ugye hívás közben..), a gépeken minden hálózatos app legfagy, megáll.. -
crok
Topikgazda
-
crok
Topikgazda
válasz
FecoGee #6033 üzenetére
Simán megeshet, hogy ez okozza. Ugyan Focus Produts-ban nincs
benne de sok eszközünk ment már RMA-ban vissza amire ez volt a
Cisco TAC válasz.. Lehet szériahiba is. Portugáliában úgy jártunk,
hogy bárki, bármilyen cég vitt ki nekünk egy időben c1841-es routert
mindnek - literálisan - rossz volt az NVRAM-ja, azt mondta mentette
a konfigot de backuptest/restarttest után mind megállt mint a szeg,
volt ami ROMMON-ban (confreg 0x0..) vagy azt mondta nincs konfig.. -
-
-
crok
Topikgazda
válasz
FecoGee #5971 üzenetére
Kicsit utánanéztem ennek/annak..
Na, ennyire én inkább használnék C7600-at.. fa#zajó, megbízható,
kiforrott hardware, "még vasból van", ha érted hogy hogy mondom.Nem tudom mekkora a budget, mert ha meg van $$$ akkor viszont
a lifetime miatt maradnék az ASR1002-nél. Csak tudja az ember, hogy
mi a vége (tehát ha tervezel bele növekedést akkor érdemes már most
nagyobbacskát venni). Ha maradsz ennél, akkor egy sima ASR1002
elég (csak abban lesz 3 kihasználatlan SPA hely.. esetleg egy
ASR1002-F, de az EOL/EOS sajnos, pedig 1 SPA hely, kisebb és
olcsóbb; ASR1002-X meg licenszel tud magasabb áteresztést, mint
a sima ASR1002.. de szerintem azt nem használod majd ki), ahogy
látom a topológiát max. 2xGigE lesz hajtva, amit a beépített RP1 simán
kihajt, IPSec-el. Ehhez már csak SFP-k kellenek majd max. meg táp
és egy ESP (a legkisebb az 5Gbps-t tud).
Az ASR1002-F teljesítette volna azt, amit leírtál és ebbe kellett volna
a legkevesebb dolgot még rendelni (ugyan az, mint az ASR1002 kb,
integrált az RP, integrált az ESP, legkisebb licensz mellett is tud
2.5Gbps átvitelt produkálni, tudott volna neked IPSec-et csinálni és
QoS is megoldott, rendelni meg csak SFP-t kell bele meg tápot.)Így viszont marad az ASR1002 + táp + SFP-k + a min. 5Gbps áteresztést
biztosító ESP (de legalább SIP nem kell, mert az integrált 10G-t tud,
ami itt bőven elég lesz). De kapsz minimum még 3 SPA helyet, ha
kellene.. annyi, hogy bukod az egyéb testreszabhatóságot (nem
upgrade-elhető az RP1, se a memória, nem kivehető (úgyértem nem
FRU) a flash se (viszont van USB támogatás 8GB nagyságig!)) és nincs
hardware-es RP redundancy-ra lehetőség.Kérdés: most akkor azt mondod hogy R1 és R2 mindkét interface-e
GigE? És IPSec kell? Akkor küztük most mi lesz? 1Gbps Internet?
Vagy 1Gbps bérelt üveg? De akkor minek az IPSec?[Szerk.] Lemaradtak a linkek:
Az ASR széria leírása
Az ASR-ek összehasonlító táblázata
Rendelési tanácsadó
Beépítés[link] -
crok
Topikgazda
Ja, és nagyon fontos lenne, hogy mennyi időre és milyen skálázhatóságra kell
tervezni, úgy értem időben és átvitelben is. Mert a c7600 már nem mai, az
ASR1k2 meg fúdecsillivilliújésgyors.. mondjuk ehhez képest ASR1k2-t NVRAM
hibával RMA-ztatni 3 hónap után.. meg 6 hónap után ventilátor csere..
(Azt tudtátok, hogy EoS/L-be tették az egyébként nem is olyan régi c2900 PSRE (ISR G2)-t?) -
crok
Topikgazda
válasz
zsolti.22 #5968 üzenetére
Nah hát arról annyit, hogy bakker, az milyen már, hogy egy etherchannel-re
ahhoz, hogy menjen az MQC QoS úgy, ahogy azt te megírtad (és ne azt
mondja, hogy suspended..) ahhoz egy ilyen parancs kell, hogy "port-channel
load-balancing vlan-manual" hát komolyan.. persze sehol nincs dokumentálva..
talán már javítva is van az újabb IOS-ekben.. de akkor is..
[Szerk.]Ezért kérdeztem a traffic profile-t, mert lehet jobb megoldás lenne egy
c7600-S IPSec Service Module-al (IPSec SPA-val) meg Sup720 supervisorral
mint a csoda ASR1k2.. -
crok
Topikgazda
válasz
FecoGee #5758 üzenetére
Na, összeszedtem pár hasznos dolgot 3G/UMTS/HWIC-3G-HSPA ügyben:
! Profilt így tudsz csinálni - az interface mindenhol Ce0/0/0:
cellular 0/0/0 gsm profile create 16 AP_NAME chap USERNAME PASSWORD IPv4
!
conf t
controller Cellular 0/0
! Itt tudod beállítani pl. a SIM PIN-t így:
gsm sim authenticate <PIN>
! egyébként kézzel is fel lehet oldani így:
! #cellular 0/0/0 gsm sim unlock <PIN>
!
interface Cellular0/0/0
description *** 3G ***
ip address negotiated
encapsulation ppp
load-interval 30
dialer in-band
dialer string gsm
dialer-group 1
async mode interactive
ppp chap hostname <username>
ppp chap password <password>
no shut
!
dialer-list 1 protocol ip permit
!
ip route 0.0.0.0 0.0.0.0 Cellular0/0/0
!
end..valami ilyesmi.
3G/UMTS/Cellular hibakeresés:
sh cellular 0/0/0 net
sh cellular 0/0/0 radio
sh cellular 0/0/0 profile
sh cellular 0/0/0 securityEgyébként:
...#cellular 0/0/0 gsm sim ?
change-pin Change CHV1 code
lock lock SIM card
unblock Unblock SIM card using PUK
unlock unlock SIM card
(PIN változtatás előtt törölni kell a konfigból a PIN-t.)Ha minden kell kimenetet egyszerre akarsz látni, akkor:
sh cellular 0/0/0 allHa beragadna a modem és restartolni kell, akkor:
microcode reload cellular 0 0 gsm modem-provision
Ha restartolni akarod de más (mondjuk flash-re mentett firmware-el):
microcode reload cellular 0 0 gsm modem-provision flash:<filenév>...#sh cellular 0/0/0 security
Card Holder Verification (CHV1) = Disabled
SIM Status = OK << működőképes a SIM, használatbavehető
SIM User Operation Required = None
Number of CHV1 Retries remaining = 3 -
crok
Topikgazda
Neked nem "12.2.58-SE2" switched van, hanem Cisco 2960-od és
"12.2.58-SE2" IOS-ed. A helyzet az, hogy olyan 15-ös IOS-t teszel
fel, amilyet akarsz (feltéve, hogy a memória (RAM/Flash) kritériumok
a switchedre nézve megfelelőek. Igazából ettől meg attól függ, hogy
milyen feature-öket akarsz használni. Van Feature Navigator, amivel
rá tudsz keresni. Nem tudom mire akarod használni, hogy egyáltalán
kell-e neked 15-ös IOS valamint hogy lesz-e hozzá licenszed egyáltalán.
De szerintem ami téged érdekel most az >ez<. -
crok
Topikgazda
válasz
FecoGee #5953 üzenetére
Azért meg kell említeni, hogy ez az érték (mármint a 38.40Mbps) 64byte-os,
csak IP csomagokra vonatkozik (max. 75,000pps mellett) és csak CEF
által továbbítva, tehát se NAT, se NBAR alapú beállítások, se egy ACL,
se egy service-policy, se IP Inspection/ZBFW nincs a továbbítás újtában.
Tehát teljesen elméleti érték. De itt már írtam sok egyéb adatot is. -
crok
Topikgazda
válasz
FecoGee #5913 üzenetére
+1, pontosan ez történt.
Ilyenkor szokás egy fallback subinterface-t csinálni ha lehet és azon
elérhető marad neked a közvetlen kapcsolódo uplink eszközről. Nem
kell route-olni, csinálhatod úgy is, hogy egy /30-as subnet legyen, pl.
1.1.1.1 és 1.1.1.2.. gyakorlatilag mindegy, csak te érd el másik oldalról. -
crok
Topikgazda
válasz
PumpkinSeed #5768 üzenetére
Esetleg ha kombó portra gondolsz, akkor interface konfig alatt media type
SFP-vel megadhatod, hogy a kombó SFP portját akarod használni (persze
az SFP is lehet réz..). -
-
crok
Topikgazda
válasz
zsolti.22 #5672 üzenetére
Kb. amit fentebb írtam és kellene a c2960 mls qos konfigja, esetleg a port
konfigja amin a kliensed lóg.Kezd ezzel mindkét eszközön - nem tudom ismered-e:
terminal exec prompt timestamp
(minden kimenet elé betesz egy timestamp-et meg egy load értéket =)
conf t
int <ISP felé a portod>
load 30
int <switched felé a portod>
load 30
endElőször is ezeknek a kimenete kellene a switchről:
sh run | i mls
sh run int <a gép portja>
sh run int <az uplink port>Tesztletöltés alatt (ami ~10 percig tartson min.) ezeket add ki a switchen:
1, Teszt előtt és után ezek kimeneteit kérném:
sh mls q int <a gép portja> buff
sh mls q int <a gép portja> que
sh mls q int <a gép portja> stat
sh mls q int <az uplink port> buff
sh mls q int <az uplink port> que
sh mls q int <az uplink port> stat2, Teszt közbeni időből ezeket a kimeneteket kérném percenként a routerről:
sh proc cpu so 5s | e 0.00
sh proc cpu so 1m | e 0.00
sh int <ISP felé a portod>
sh int <switched felé a portod>
sh cef not-cef-sw
sh ip nat stat
sh ip inspe statNem lesz kevés kimenet.. szóval szerintem pastebin-re tedd =)
-
crok
Topikgazda
válasz
jerry311 #5670 üzenetére
Engedhetné, ha a default queue kiosztásban lenne elég memória a queue
kiszolgálására wirespeed-en. De nincs, pont azért nincs, mert a QoS arról
szól, hogy megfelelő jelöléssel mindenféle forgalomnak adsz helyet/teret
élni. De ha mindenfélék vannak beállítva de te _nem_ használod ki.. jelölés
nélkül megy minden egy darab queue-ban.. ott pont megölöd a teljesítményt.
Sok koncepció van, nem mondta még, hogy pont mi van beállítva. -
crok
Topikgazda
válasz
Cyber_Bird #5666 üzenetére
NE! 50000+ entry után elkezdi dobálni őket meg nem kreál újat de nem
is törli az elévülőket.. BugID még nincs, annyira nem követtem a dolgot,
én csak lejelentettem, a design team nagyon haladni akart (szűkös idő)
így c3945 lett belőle, ami egyébként remekül üzemel. Az IP SLA se
működik rendesen, a qvantum processzorra nem lett optimalizálva az
IP SLA program, így előfordul, hogy falsan ugyan de ilyen 200..400ms
jittereket jelent.. az meg nagyon cinkes. Nekünk már csináltak egy IOS-t
de még nincs publikálva.. 1.8 évig szüttyögött rajta a Cisco. -
crok
Topikgazda
válasz
zsolti.22 #5663 üzenetére
=D na látod itt kezdődik a baj: veszel sok pénzért egy ASR-t, és hiába a TenGig
akkor se fog mennimert az ASR _nem_ arra való, amire használni akarod =D
Aggregál, az rendben, iszonyat mennyiségű forgalmat tud _forwardolni_ de nem
feldolgozni, CBAC, NAT, ZBFW, L2TP.. ha ilyesmit is csinálnál vele akkor oda
service module is kell hogy ne öld meg a qvantumprocesszort =) A design csapat
itt is belefutott ilyenbe.. aztán szóltunk nekik, hogy nem arra való az a vas.. ilyen
melóra ISR-t kell venni. (Plusz az ASR1k IOS-ben van egy csúnya nagy NAT bug).
Az ISR-t erre találták ki: ZBWF, NAT és forwarding. Mindent arra használjunk
amire való =) Így dől el a jó design =)A másik kérdés: mind a NAT, a CBAC és az L2TP is vesz el a processzorből
erőforrást. egy kiadott "sh proc cpu so 1m | e 0.00" majd megmondja, hogy
mennyi erőforrást emészt fel a forwarding és mennyit a processek és (mik azok).Harmadik: c2950, de milyen pontosan? Jó lenne tudni, mert abból tudnám milyen
fabric van benne (mekkora a forwarding capacity) és az se mindegy melyik
portból melyik portba folyik a forgalom, egy ASIC-on van-e vagy a GigE uplinket
használod-e, mert forwarding szempontból nem mindegy valamint tudnom kellene
azt is, hogy MLS QoS parancsokat miket használ a switch, milyen portbeállítások
vannak (az is beállítás, ha default!) mert legtöbbször az emberek azzal tolják el,
hogy bekapcsolják az MLS QoS-t és nem csinálnak utána semmit. Az QoS
önmagában nem csodafegyver, nem oldja meg a dolgaidat sőt, jól el is tolhatja,
mert beállít queue-kat, súlyozást. .és ha nem jelölöd a kereteket/csomagokat
akkor csúnyán ráfázol és jön a hibajelenség/hibajegy - ismerni kell a hardware-t
mert csúnya dolgokba nyúlhat az ember gyermeke. -
crok
Topikgazda
válasz
McSzaby #5656 üzenetére
Akkor jó mélyen kell a zsebedbe nyúlni =D Mert ez bizony így van, routereknél
mindenképp. Switchekre is igaz abban az értelemben, hogy ha mondjuk 8:1
oversubscription van akkor ugyan az ASIC-on levő interface-ek közt megy oda-
vissza a gigabit.. nade a buszhoz/switchfabrichoz ha az ASIC-nak csak 1Gbps
uplinkje van (internal) akkor ott lesz drop.. Ez inkább az ISR-ekre igaz. Az ASR
pl. más.. nade a $$$ kategória is más, meg a felhasználás módja is más - másra
való. FYI: itt Redditen összeszedtem pár cheat-sheetet. Abban az értelemben
ki tudja használni a gigabitet, hogy a jelzésrendszere képes gigabitre, tud(hat)
forwardolni, de nem lesz elég buffer a csomagokhoz, nem fogja tudni érkeztetni
a csomagokat az interface.. sh buffers-ben megjelennek a dropok.. et cetera.. -
crok
Topikgazda
válasz
zsolti.22 #5646 üzenetére
Tesztletöltés alatt (ami ~10 percig tartson minimum) ezeket add ki:
uplink interface configjába ezt tedd be: load 30
majd ezen kimeneteket kérném mondjuk pastebin-re:
- ezt párszor: sh proc cpu so 5s | e 0.00
- ezt párszor: sh proc cpu so 1m | e 0.00
- ezt párszor: sh int [uplink portod]
- sh cef not-cef-sw
..ezen felül:
- NAT van-e?
- IP Inspect vagy ZBFW van-e?
- Mögötte hogy csatlakozol? Valamelyik LAN 100-as porton?
Azokon a portokon sh int kimenetet adsz?
Vagy LAN 100-as porton Wifi AP? A/B/G/N?
Valamint a Cisco hivatalosan 15Mbps-re ajánlja a 89x-et (ami úgy értendő,
hogy bekapcsolt "szolgáltatásokkal", de csodát ne várj. Az, hogy Gigabit-
és FastEthernet a link az még nem jelenti, hogy az ASIC-ok egymással
tudnak is ilyen szinten kommunikálni.. óriási tévedés, ez csak marketing). -
crok
Topikgazda
válasz
FecoGee #5628 üzenetére
Az átlag ZBFW konfigunkban van vagy 4+self zóna, majd' mind minddel csinálhat valamit.. akkor talán 20 zone-pair.. So I know that feel, bro' =) Viszont.. nagyon hiányoltam egy olyan egyszerű kimenetet, mint CBAC mellett a "sh ip inspect sess" hogy lássad má' hogy ki merre megy épp.. de most miért kell megbonyolítani egy ilyennel, hogy "show policy-map type inspect zone-pair <pair neve> sess" ..ehh..
-
crok
Topikgazda
Mivel én napi szinten dolgozom wifivel így a felkészülés nekem annyi volt,
hogy elolvastam a certguide-ot. Annyi a cink, hogy van pár olyan kérdés,
hogy a WLC melyik menükében találod ezt-meg-azt, vagy olyan, hogy
tudd meg, hogy mi van beállítva a WLC-n (kis tshoot) de az nem annyira
cink, mert kvázi csak azok a menüpontok élnek amiket használnod kell.
(Ez egyébként igaz a CCNA Security-re is). Szerintem könnyű volt.
Esetleg ha a számolások nem mennek azt nézd át alaposan (dBm, dBi,
meg mi minek a hányszorosa, mihez mit adsz hozzá/vonsz ki..) -
crok
Topikgazda
válasz
FecoGee #5447 üzenetére
Többek közt. Szerintem nagyon jó. Csak van pár "hozzáértő" akik
a fórumban nagyon sokat kérdezgetnek, többnyire inkább csak
trollkodnak.. nem követik a leírásokat és nem működik nekik a dolog,
ezzel elveszi mások kedvét a használatától. Pedig tényleg jó. -
crok
Topikgazda
válasz
FecoGee #5445 üzenetére
Szoktam néha hegeszteni. Én nagyon szeretem. Akarok majd
írni egy apró scriptet, ami GNS3 .net-ből IOU netmap file-t csinál.
Bár én sima IOS+GNS3 alatt is futtatok Intel Core i3 alatt
4G RAM + SSD mellett is tudok 20+ routert futtatni úgy,
hogy simán olvasok+google chrome youtube, et cetera.. -
crok
Topikgazda
válasz
Cyber_Bird #5370 üzenetére
A legviccesebb, hogy telecom családból származom és kedvenc
területem a voice - de mindennél jobban utálok telefonálni :] -
crok
Topikgazda
válasz
FecoGee #5364 üzenetére
Inkább a call routing
Meg a licenszelés... az undorító. A QOS hibákat kiszűrni
nem nehéz, csak jelölésellenőrzés kell hop-by-hop, azt a routereken NetFlow-al,
switcheken kézzel a portokon meg MLS Netflow-al meg lehet nézni gyorsan. Akkor
cink ha nagyon sok a hop, elvesz némi időt, de ha ésszerűen csinálod (mint egy
looptest-et E1/T1-en..) akkor hipp-hopp megvan a ludas. Voice-nál a tervezés ha
jó és nem retardáltak változtatnak a design-on (értsd: nincs eszetlen telepítés,
nincs eszetlen feature bevezetés, nincs "alátervezve" a sávszél, új eszközök
bevezetése (pl. bővítés) esetén _mindenhol_ utánaállítják a sávszélességeket,
et cetera) akkor nem kell hozzányúlni a dolgokhoz tán' sose.. de azért tudok én
is érdekes eseteket felhoznimindig minden azzal kezdődik, hogy a "CUCM
és minden kapcsolódó szerver már kétszer le lett ellenőrizve, tuti minden jó,
tuti hálózati a probléma"Meg ami még cink: a sok call feature használata
és bevezetése ész nélkül.. extension-öket hunt-groupba teszegetni, de mindet
különbözőbe.. egyedülCallparking mellett nem configolni timeout-ot se meg
limitálatlan retry hogy tuti elvesszen a hívás.. After hour call blocking-ban rossz
patternt megadnijajjjdeimádtam. Overlay vonal esetén rosszul kiosztani az
agent-ek közt a preference értékeket, így van, aki 100 hívást kap időegység alatt
más meg 2-tja, és emellé _nem_ letiltani a huntstop-ot, külön móka, a hívók
azt hiszik hogy minden vonal foglalt, közben meg 30 agent várja a telefonokat,
de max. 4 kap hívásokat, 26 egy darabot seMeg a PSTN Gatewayen analóg
telefonok.. mikor az agent nem akarja, hogy hívást fogadjon és melléteszi a
kézibeszélőt aztán sokáig nem csinál semmit de timer hiányában a VG nem
szakítja meg az áramkört és sorban égnek ki az analóg végfokokMeg E1
PSTN kapcsolat mellett arra rájönni, hogy te úgy tudod, hogy 30 B csatornád
van 6 számmal, majd rájössz, hogy 4 szám a tied és persze hogy nem esik
be hozzád hívásmeg az se rossz, mikor 24 a max kimenő/bejövő B csatorna
és sh isdn stat -al meglátod, hogy a szolgáltató letiltott 6-ot és ezért meg a
megemelkedett hívásszám miatt kapnak az agent-ek a callcenterben busy
signalt már a kézibeszélő felemelésekor. Persze mind-mind a network guynak
van jelentve és ő is mondja meg hogy a-aa, nem network, hanem voice a téma
és ittmegottmegamott kellett _volna_ megnéznetek.. csodás élmények
[Szerk. I]
Oh, mégegy ami eszembejut: IP telefonok voice mail gombja csak 12..15 sec
múlva alszik ki miután a voice mail-t meghallgattad. Persze ez is network issue.
Aztán mikor már én kérek a telefonokról call statisztikát (persze mobiltelefonnal
fényképezettet kapok..) és nézem a jitter/loss értékeket hogy hátha van _valami_
és rájövök, hogy a calltrace a CUCM-ről meg a képen látható idő a telefonon
nem egyezik, mert a CUCM nincs NTP-vel szinkronban, ám a telefonok a TFTP
szervernek használt VM-et használják NTP-re is.. és a CUCM a gombok
beállításait NTP alapján szinkronizálja, tehát lehet, hogy te már a voice mailt
meghallgattad és a CUCM meg is kapja a notification-t a voice mail szervertől
hogy xyz sorszámú voice mail meg lett hallgatva, ám a CUCM csak utólag -
mikor eléri azt az időpontot az órája - fogja a telefont is értesíteniPriceless..
[Szerk. II]
lol mégegy: Megnövekedett agent forgalom miatti CUCM memórianövekedés
és swapolás miatti lassú call routing lejelentve network hibára, hogy egy-egy
telefonbeszélgetés felépítése 6..8 másodpercbe is beletelik és biztos a call
signaling csomagok jelölése miatt van ilyen delay - aztán annak aki ebben
100% biztos magyarázd el, hogy a világban nincs olyan szolgáltatás ami
ilyen nagy delay-t megeszik gond nélkül (értsd: a hívások felépülnek, a
telefónia minőségével nincs gond) így a szerver lesz a ludas.. de neeem,
hajtja az igazát, de amikor megnézi a CUCM VM-jét tátva marad a szája
hogy 950%-osan átlagostól eltérő a hívásszám és a CPU 89%-on a swapo-
lással van elfoglalva, a maradék meg call routing folyamat XD -
crok
Topikgazda
Csatorna nem lesz lényeges, SSID se ha roamning van (hisz akkor ugyan az).
Ami kérdés: titkosítás típus/jelerősségek az AP és a host közt/antennadirekciók/
csatlakozások/gaining (úgy értem nincs-e a 3 működő túlhúzva vagy az egy nem
működő lehúzva a WLC-n?)/a-b-g-n wifi?/mind tudja is azt amit használni akarsz?
(úgy értem: abgn de engedélyezve is van meg működik is a rádió a szabványhoz?
Ha a tablet látja mind a 4 AP-t valami miatt csak _nem_ választja ki azt az egyet.
(Androidra van app, amivel meg tudod nézni a BSSID/jelerősség/capabilities
kombókat, de hogy Win8-ra, tabletre.. nem tudom, nem értek a lovakhoz..) -
crok
Topikgazda
válasz
FecoGee #5305 üzenetére
Nem tudom, milyen ember vagy, miből tanulsz jobban/könnyebben..
Én programozásban jobban szeretem az "írott szót" - sok próbálgatással.
Én innen tanultam meg [szerk.] meg sok ? használatávalPacketlevel - ezt egyébként is ajánlom!!!
Routing tábla monitorozása
ipSpace-en külön tag van rá
IPExperten is van egy jó példa
Cisco Community - ez talán a legjobb hely példákra
INE szájbarágósan
Cisco Support - EEM Basics and sample configs
Cisco EEM Best practices
Command ref. I.
Command ref. II.
Command ref. III. -
crok
Topikgazda
válasz
kristofkax #5202 üzenetére
Konkrétan semennyivel se, csak a loadshare módja változik.
-
crok
Topikgazda
Megosztanék valamit. Jártatok már úgy, hogy tech a helyszínen és
fogalma nincs merre van arccal, melyik eszköz micsoda? Vagy a
helyi erő egy titkárnő, nem ismeri a ledek jelentését, max. azt tudja
megmondani, hogy hanyadik led és hogy világít? Nos, van egy site,
ahonnan ebay-re tesznek fel képeket (eladásra szánt eszközökről)
és a listájuk eléggé bő. De a lényeg: majd' minden Cisco eszközről,
modulról, SFP-ről, kiegészítőkről van kép. Így meg tudod könnyíteni
a saját és a lokál erő munkáját is. [link] [link] [link] -
crok
Topikgazda
válasz
FecoGee #5196 üzenetére
Azért az erős lenne - per-packet loadshare miatt kikapcsolnád a CEF-et?
A megoldás: az interface-ekre "ip load-sharing per-packet" kell [referencia].
Ha VoIP-ot is használsz akkor nem ajánlom egyébként.. -
crok
Topikgazda
válasz
jerry311 #5152 üzenetére
Én arra leszek kíváncsi, hogy a 3 director package mellett lesz-e
CEO package :] De a te kérdésed is jó.. bár a kisfilm alapján a
közösségi alap ötlete is maga a közösség volt - hogy a GNS3
maradjon közösségi de lehessen jobb. Azért a marketing is jóra
sikerült, meg kell hagyni :] -
crok
Topikgazda
válasz
FecoGee #5120 üzenetére
Mi 3-an összeálltunk a csapatban és befizettünk egy $75-s csomagra :]
[Szerk.] Kár, hogy nincs a $75 és a $1000 közt valami átmenet.. többet is
adtunk volna, de az 1000 vagy 5000 azért az még 3-nak is sok.. De nem
gyenge egyébként, hogy cca. 1.5 nap alatt most épp $115,879... -
crok
Topikgazda
A gond a config: amit te írtál az megenged még 13MB burst byte-ot
és 20MB max burst byte-ot.. ami borzasztósok, lévén, hogy egy E3-
ról beszélsz. Neked ez kell, ha 10-re akarod limitelni:rate-limit input 10000000 5000 5000 conform-action transmit exceed-action drop
rate-limit output 10000000 5000 5000 conform-action transmit exceed-action drop -
crok
Topikgazda
válasz
jerry311 #5057 üzenetére
Err.. itthon, labban is összeraktam.. pont ugyan ezt csinálja..
először GNS bugnak gondoltam, de lehet IOS "limitáció"..
Mondjuk nem is "normál felhasználás". Kérdés: jól gondolom,
hogy az ip nat inside|outside nem mozdítható és eleve ott van,
valamint hogy nem írható át ip nat enable-re csak úgy? -
crok
Topikgazda
válasz
jerry311 #5051 üzenetére
Nekem ezzel van bajom:
"192.168.1.72 a külső oldalon, tehát ip nat inside felőli részen van."Ha külső IP-t úgy forgatsz belsőre, hogy az egy alhálóban van a belső
hálóval, akkor onnan a válaszcsomag hogy fog kijutni? Sehogy, hisz
a belső host azt fogja mondani, hogy küldök ARP kérést, egy hálóba
esik velem, lesz ARP-om és direct válaszolok (kellhet proxy-ARP..).A 10.10.10.x címek majd válaszolnak a 192.168.1.72-nek, de azt ki
fogja átírni 20.20.20.230-ra? A Unicorn Farts felhő? Mert a NAT-oló
routerig el se jut majd a forgalom, max akkor, ha Unicorn Farts-nak
van egy /32 static route-ja 20.20.20.230-ra next-hop 192.168.1.60-al
(miközben van egy /24-es connected route-ja 192.168.1.0-ra)...de ha már mindenképp így kell csinálni (mert inherited legacy háló)
akkor jó, akkor megnézem majd a felállást megint. De az elgondolás
jónak tűnik, a VRF kicsit ugyan megbolondítja a dolgot, de jó lesz. -
crok
Topikgazda
válasz
kristofkax #5047 üzenetére
A VRF ebben az esetben "nem szentírás" és "kiléphetsz"
belőle úgy, megadod az interface-t és a next-hop-ot. Akár
a globálban akár egy másik VRF-ben levő interfacet is meg-
adhatsz. Ez egyfajta (static) route-leaking, az IOS megengedi
és ha oda-vissza megcsinálod - ekkor 2 VRF közt is csinál-
hatsz forgalmat. Így oldottuk meg sok helyen a (nem VRF
aware IOS-ek alatt) a NetFlow csomagok küldését VRF-
ben levő source interface-t használva a globál táblában (és
ott elég egy static route, mert UDP, nem vár választ): static
route-ot vettünk fel a VRF-ben a flow-export destination-re
úgy, hogy a globálban van a next-hop IP és interface is.
Ú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!
- ÚJ BONTATLAN iPad Air 6 13 méretben iPad Air 13 512GB Wi-Fi+Cellular Azonnal Átvehető DEÁK Térnél.
- MSI Thin A15 B7VF 15.6" FHD IPS Ryzen 7 7735HS RTX 4060 16GB 512GB NVMe magyar vbill gar
- TUF A17 FA706IU 17.3" FHD IPS Ryzen 7 4800H GTX 1660 Ti 16GB 512GB NVMe gar
- Lenovo Thinkpad X13 Gen4 - AMD R5 7450U/32GB/1TB
- ELADÓ - LENOVO LEGION SLIM 7i 16IAHV - 40GB RAM, 1.5 TB SSD
- REFURBISHED és ÚJ - Lenovo ThinkPad 40AS USB-C docking station (akár 3x4K felbontás)
- Geforce GTX 1050, 1050 Ti, 1060, 1650, 1660 - GT 1030 - Low profile is (LP)
- Samsung Galaxy A54 128GB, Kártyafüggetlen, 1 Év Garanciával
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
- KATONAI ÜTÉSÁLLÓ!!! Getac S410 i5-6300u, G3: i5-8365u, G4: i5-1145G7
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged