classic.ISPforum.cz

Zdravím Vás.

Mám problém so spojmi Alcoma ohladom IPTV. TV seka, kockuje atď... Spoje sú licenc 296Mbit. Máme aj Nera (ceragon) a tieto problémy nerobia. Z web mgmt neviem zistiť presný model (má mi to poslať kolega). Nejaké to info o firmware: Application Version 2.9.35v2, Chassis CF08301686. Ide to na 18Ghz. Licence je samozrejme zaplatený. Alcomy boli premerané chlapmi od Alcomi a sú OK podľa nich. Signaly sú ok. Nikdy pred tým som qos neriešil. Vyfotil som aj možnosti nastavenia qos ak to pomôže(viď príloha). Nebude stačiť upgrade firmware? Ďakujem vopred za rady.

Ďalšie prílohy.

Zacal bych tim, ze si priradis QoS prioritu na LAN port kde prenasis IPTV stream, pokud to mas rozdelene na VLANach per port. Ted mas vsude prioritu 0, to je ta nejnizsi a podle toho se k tomu trafficu Alcoma chova. Jinak podle obrazku jsou to ALFy, nikoliv MPcka.

Pozdravujem Vás.

Ďakujem veľmi pekne za odpoveď. SFP som nastavil na priority 7. IPtv máme vo vlan 500. Momentálne som doma, tak neviem vyskúšať či nastala nejaká zmena. Prikladám video z dnešného testu. http://uloz.to/xbqvYYrC/video0076-3gp .

kolik toku tece temi spoji (spicky)?
k cemu jsou ty ALCOMY pripojene?
pouzivas flow-control?

Zdravím Vás. Model je takýto. Connect prichádza cez neru na stožiar. Nera je prepojená s alcomou cez cisco 3400G kde je urobený multicast routing. Tu by som problém, ale nehľadal, keďže pripojený stb v alcome v eth porte na stožiari nesekne ani raz ( ani pri vyššiom trafficu cez neru a cusco) a za spojom alcoma v eth porte už seká. Za alcomou na druhej strane je cisco4500. Viď príloha.

PS: Na ciscu mám flowcontrol receive desired a na alcome mám flowcontrol symetric.
Čo sa týka špičiek tak realne max špičky dude nedokáže zaznamenať, ale tv "zakockuje" aj pri trafficu 80-100Mbit cez alcomu.

ISPfrinet píše:PS: Na ciscu mám flowcontrol receive desired a na alcome mám flowcontrol symetric.
Čo sa týka špičiek tak realne max špičky dude nedokáže zaznamenať, ale tv "zakockuje" aj pri trafficu 80-100Mbit cez alcomu.

co vypise na ciscu povel:

sh flow-control

narustaji pocty RxPause od ALCOMy (muze se dit jen narazove a pri vyssim prutoku)?

Pozdravujem Vás.

Na ciscu3400G, kt. je na stožiari a je to vstup do alcomy tak sú všade nuly (tam to funguje ako som už písal bez seku). Na ciscu 4500 je na vstupe do cisca (výstup z alcomy) RX pause 512 . Cisco má uptime cca 24hodín. Viď príloha.

ISPfrinet píše:Pozdravujem Vás.

Na ciscu3400G, kt. je na stožiari a je to vstup do alcomy tak sú všade nuly (tam to funguje ako som už písal bez seku). Na ciscu 4500 je na vstupe do cisca (výstup z alcomy) RX pause 512 . Cisco má uptime cca 24hodín. Viď príloha.

Bingo ! To muze byt ten problem. Jedna vec je traffic flow a druha jsou bursty. Ty v grafech nebudou videt ale cvici s bufferem v radiu. Je na Ciscu nastaven shaper, ktery by nejak omezil prutok dat ? Predpokladam, ze pres to nejede jen IPTV ale taky internet pro klienty. Mohlo by pomoci napriklad rozdelit provoz na portech Alcomy, prejit na Fast Ethernet rozhrani a pak nastavit QoS prioritu na Alcome tak, aby preferovala IPTV stream. Nebo zvednout rychlost na radiu.

GRFS píše:

ISPfrinet píše:Pozdravujem Vás.

Na ciscu3400G, kt. je na stožiari a je to vstup do alcomy tak sú všade nuly (tam to funguje ako som už písal bez seku). Na ciscu 4500 je na vstupe do cisca (výstup z alcomy) RX pause 512 . Cisco má uptime cca 24hodín. Viď príloha.

Bingo ! To muze byt ten problem. Jedna vec je traffic flow a druha jsou bursty. Ty v grafech nebudou videt ale cvici s bufferem v radiu. Je na Ciscu nastaven shaper, ktery by nejak omezil prutok dat ? Predpokladam, ze pres to nejede jen IPTV ale taky internet pro klienty. Mohlo by pomoci napriklad rozdelit provoz na portech Alcomy, prejit na Fast Ethernet rozhrani a pak nastavit QoS prioritu na Alcome tak, aby preferovala IPTV stream. Nebo zvednout rychlost na radiu.

jenze
1) jestli spravne chapu jak je to zapojene tak ty rxPausy jsou na zarizeni za alcoma trasou (blize k zakaznikum). Takze ta ALCOMA nestihala ve smeru do Internetu. To by tok na IPTV nemelo (nutne) ovlivnit.
2) 512 rx Pause neznamena, ze se zahodilo 512 packetu. Je to jen informace o tom, ze bufer v ALCOME se zaplnil na nejakou uroven (dejme tomu 75%). A radio se tim snazi rict: "brzdi nebo budu muset zahazovat packety". A switch ma obvykle vetsi ci mensi vlastni buffer, ktery vyuzije k pozdrzeni packetu na dobu specifikovanou v tom ohlaseni RxPause.
Teprve pokud na switchi zacnou narustat Drops/Discards na danem portu je skutecne problem.

Skutecny zdroj problemu bych ja ale hledal na tom druhem ciscu resp ALCOME blize Inetrnetu. Tam jsou citace RxPause od ALCOMy na nule (pokud chodi tak by se mely zobrazovat (alespon me se to tak chova) i pokud se zarizeni nedohodla na pouzivani Flow Control) . Takze bud ALCOMA ty RxPause neposila nebo switch je neumi zapocitat (uz jsem takovou chybu v IOSu videl).

Zkontroloval bych vypis

show int count err
a

show int x/y

zde bych sledoval jakekoliv vypisy chybovych counteru. Zkusil bych do grafu vynaset In/OutDiscards a Drops. Podival bych se zda dany IOS nezpristupnuje RxPause v SNMP (hledat ve vypisu snmpwalk dot3InPauseFrames). Podival bych se, zda dana verze IOSu nema zname chyby v zracovani/zobrazeni RxPause, zahozenych packetu, pripadne bych upgradnul.

Pokud dany switch ma moznost shapingu/qosu, zkusil bych nastavit rychlost na portu lehce pod maximalku ALCOMY. Pokud ma switch dost pameti na buffery tak se tim vyhladi bursty a ztratovost (pokud je na ALCOME diky tem burstum) zmizi - prevede se na zpozdeni. To je mozne pak u IPTV provozu eliminovat uprednostnenim packetu ve fronte.
Ale jak jsem zbezne koukal na tu ME3400G tak jednak nejdou nastavit libovolne rychlosti v shaping average a jednak asi te pameti nebude dost (je potreba vyssi stovky MB na port - podle rychlosti). My jsme se s podobnym problemem potykali na 3560G a ta ma jen 384kB pameti na jeden ASIC (4 porty) a to na vyhlazeni burstu zdaleka nestaci. Jedine co se stane, je, ze se po zapnuti FlowControl prenesou dropy z ALCOMY na switch a je tak alespon mozne v grafu videt jak moc a kdy to zahazuje packety.

BTW: Pokud nahodou v ceste toho toku na prihodnem miste je nejake zarizeni (lepsi switch, router), ktere ma dostatek bufferu na packety tak je pravdepodobne mozne predshapovat ten tok na nem (pokud se k nemu cestou nepridavaji dalsi toky apod).

PS: V Prerove ALCOMA naznacovala, ze v pristich verzich firmware by se snad mohly objevit statistiky z eth/bridge chipu. Takze pak by snad mohlo jit overovat, jestli dropuje fronta v ALCOME, jestli jsou nejake ethernet chyby a snad i jestli se posilaji rxPause ramce...

Pozdravujem Vás.

Skúsim to postupne rozpisat a odpovedať na všetky otázky. Shaper nastevený nemám. Môžem skúsiť nastaviť, ale skor na tom ciscu pred alcomou na stožiari a aj to musim shapovať skor konkrétne Vlany. V podstate tam mám 4Vlany cez, ktoré ide veľky traffic. A to Vlan500 - iptv, Vlan2030 - net klienti na ciscu. Vlan1 net klienti kostol + kamerový systém a Vlan60 je wan(servre, ale tu je traffic väčšinou cca 3Mbps, kým niekto nezačne tahať nejaké FTP, alebo uploadovať). Shapovat by trebalo skôr keď už tak len vlan 1,60 a 2030. Čo sa týka celkového shapu portu v akom pomere by som to mal dať ? Je to 300M rádio a určite nebudem shapovať down na 300M to by bola hovadina. Rozmýšlam, že by som to dal na 80% na down a 20% na up. Poopravte ma ak uvažujem zle. Vlan 1 ma traffic do 60M max, Vlan 2030 je na tom obdobne a vlan 60 by som nastavil do 50M na down nech má rezervu. Tým pádom ak by sa aj stalo, že všetky Vlany by začali ťahať na max tak by som mal traffic cca 170M, čize na iptv by mi ostalo cca 70Mbit. Väčšinou máme na iptv traffic okolo 40-50Mbit. Takáto situácia nastane len málokedy, keďže ftp sa využíva tak dva krát do mesiaca. Nižšie preposielam príkazy show z c4500. A áno tie rx pause sú za spojom alcoma na vstupe do cisca, ktoré už obsluhuje zákazníkov.

"Skutecny zdroj problemu bych ja ale hledal na tom druhem ciscu resp ALCOME blize Inetrnetu. Tam jsou citace RxPause od ALCOMy na nule (pokud chodi tak by se mely zobrazovat (alespon me se to tak chova) i pokud se zarizeni nedohodla na pouzivani Flow Control) . Takze bud ALCOMA ty RxPause neposila nebo switch je neumi zapocitat (uz jsem takovou chybu v IOSu videl)."

Nevyznám sa v tom tak ako vy, ale keďže na tejto strane problém nebol a port nemusel pauzovať žiadne packety, keďŽe to na tejto strane stíhalo aj pri testoch , tak som predpokladal, že tie nuly by boli v poriadku. Až ked by to nestíhalo ani tam, tak by sa napočítali nejaké TX pause, keďze je to z toho c3400G down. Alebo som myslel zle? Skúsim pozrieť tie chyby v danom ios-e (1 16 ME-3400G-12CS-A 12.2(50)SE ME340x-METROIPACCESSK9-M ) . Začal som komunikovať aj s alcomou. Tak skúsime vytvoriť nejaké qos pre prioritu pre IPTV. Port priority som nastavil. Mám pocit, že sa to trochu zlepšilo, ale kockovanie neprestalo. Čo sa týka toho lepšeho switchu. Tak lepši je už asi len ten c4500 za spojom alcoma. Verziu fw v alcome mám tuším 2.9.

GRFS píše:

Bingo ! To muze byt ten problem. Jedna vec je traffic flow a druha jsou bursty. Ty v grafech nebudou videt ale cvici s bufferem v radiu. Je na Ciscu nastaven shaper, ktery by nejak omezil prutok dat ? Predpokladam, ze pres to nejede jen IPTV ale taky internet pro klienty. Mohlo by pomoci napriklad rozdelit provoz na portech Alcomy, prejit na Fast Ethernet rozhrani a pak nastavit QoS prioritu na Alcome tak, aby preferovala IPTV stream. Nebo zvednout rychlost na radiu.

Na časť otázok som už odpovedal vyššie. Shaper nastavený nemám. Môžem to skúsiť. Rozdeliť provoz, na portoch by sa dalo na vstupe do alcomy, keďže tá c3400g ma aj fsp aj eth 1G porty a nastaviť prioritu na vstupe. Čo sa týka rýchlosti na rádiu. Tak je to max čo sa dá momentálne nastaviť. Možno s nejakou inou licenciou, ale neviem či je to ešte možné navýšiť... .




port za spojom alcoma :
GigabitEthernet5/3 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 1cdf.0f06.7642 (bia 1cdf.0f06.76 42)
Description: Privod_Alcoma
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 4/255, rxload 23/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLH
input flow-control is on, output flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 90009000 bits/sec, 8563 packets/sec
5 minute output rate 16484000 bits/sec, 4204 packets/sec
1191617073 packets input, 1608282676442 bytes, 0 no buffer
Received 510873520 broadcasts (509657818 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
395752506 packets output, 108074968313 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Hranovnica#show int count err

Port CrcAlign-Err Dropped-Bad-Pkts Collisions Symbol-Err
Te5/1 0 0 0 0
Te5/2 0 0 0 0
Gi5/3 0 0 0 0
Gi5/4 0 0 0 0
Gi5/5 0 0 0 0
Gi5/6 0 0 0 0
Fa9/1 0 0 0 0
Fa9/2 0 0 0 0
Fa9/3 0 0 0 0
Fa9/4 0 0 0 0

cisco c3400g pred spojom alcoma: port na vstupe alcomy je gi0/14

Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Gi0/1 0 0 0 0 0 0
Gi0/2 0 0 0 0 0 0
Gi0/3 0 0 0 0 0 0
Gi0/4 0 0 0 0 0 0
Gi0/5 0 0 0 0 0 0
Gi0/6 0 0 0 0 0 0
Gi0/7 0 0 0 0 0 0
Gi0/8 0 0 0 0 0 0
Gi0/9 0 0 0 0 0 0
Gi0/10 0 0 0 0 0 0
Gi0/11 0 0 0 0 0 0
Gi0/12 0 0 0 0 0 0
Gi0/13 0 0 0 0 0 0
Gi0/14 0 0 0 0 0 69
Gi0/15 0 0 0 0 0 0
Gi0/16 0 0 0 2 0 0

Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Gi0/1 0 0 0 0 0 0 0
Gi0/2 0 0 0 0 0 0 0
Gi0/3 0 0 0 0 0 0 0
Gi0/4 0 0 0 0 0 0 0
Gi0/5 0 0 0 0 0 0 0
Gi0/6 0 0 0 0 0 0 0
Gi0/7 0 0 0 0 0 0 0
Gi0/8 0 0 0 0 0 0 0
Gi0/9 0 0 0 0 0 0 0
Gi0/10 0 0 0 0 0 0 0
Gi0/11 0 0 0 0 0 0 0
Gi0/12 0 0 0 0 0 0 0
Gi0/13 0 0 0 0 0 0 0
Gi0/14 0 0 0 0 0 0 0
Gi0/15 0 0 0 0 0 0 0
Gi0/16 0 0 0 0 0 0 0

#show int gi0/14
GigabitEthernet0/14 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is b414.89e9.990e (bia b414.89e9.990e)
Description: Alc_Dub_Hra
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 25/255, rxload 4/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLX SFP
input flow-control is desired, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 69
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 17559000 bits/sec, 4687 packets/sec
5 minute output rate 101253000 bits/sec, 9834 packets/sec
82865315096 packets input, 24180037044285 bytes, 0 no buffer
Received 291823412 broadcasts (262830281 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 262830281 multicast, 0 pause input
0 input packets with dribble condition detected
172809820362 packets output, 219540648944407 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

Mě jenom překvapuje, že ačkoliv kolegovi byl nabídnut support od nás, tak hledá spíše pomoc na fóru. Ale to je věcí každého. Určitě platí, že víc hlav víc rozumu.
Jinak předávám odpověď našeho specialisty, třeba se bude hodit i někomu jinému:

ok1vaw píše:Mě jenom překvapuje, že ačkoliv kolegovi byl nabídnut support od nás, tak hledá spíše pomoc na fóru. Ale to je věcí každého. Určitě platí, že víc hlav víc rozumu.
Jinak předávám odpověď našeho specialisty, třeba se bude hodit i někomu jinému:

Pozdravujem Vás. Nehľadám skôr pomoc tu, ale hľadám ju všade kde je pomoc ponúknuta a áno viac hláv viac rozumu. Alcomu riešim s p. Langerom, ale tu sa nerieši len alcoma, ale aj možnosť dopomocť alcome aj ciscami, keďže Váš technik mi žial v tejto oblasti neporadí. Nechcem teda nijako odmietať pomoc alcomy, len sa to snažím vyriešiť čo najrýchlejšie a najefektívnejšie.

Ospravedlnujem sa, ale dnes som nemal čas na cisca. Bol som celý deň v teréne.

Prosím Vas. Vie mi niekto pomocť ako otagovat IPTV na ciscu? Manuály od cisca som si pozrel, ale som z toho blbý...Respektíve som tomu nepochopil, ale je to asi tým, že neviem skvelo po ang.

PS: priorita portov je žial v tomto prípade nepodstatná, kedže všetok trafit aj s IPTV tečie do alcomy cez jeden port. Nemám možnosť sa dostať kedykoľvek na stožiar na to aby som to mohol rozdeliť. Skúsim naplánovať cestu v piatok a ozvem sa.



Ďakujem

Dalibor Toman píše:2) 512 rx Pause neznamena, ze se zahodilo 512 packetu. Je to jen informace o tom, ze bufer v ALCOME se zaplnil na nejakou uroven (dejme tomu 75%). A radio se tim snazi rict: "brzdi nebo budu muset zahazovat packety". A switch ma obvykle vetsi ci mensi vlastni buffer, ktery vyuzije k pozdrzeni packetu na dobu specifikovanou v tom ohlaseni RxPause.
Teprve pokud na switchi zacnou narustat Drops/Discards na danem portu je skutecne problem.

Ano 512 RX pause znamena, ze do Cisca poslala Alcoma 512 pauza ramcu. Tedy 512x ramec dlouhy 64byte s informaci v interaktivnim prekladu: "vole nestiham, pockej chvili". A jestlize je to na RX LAN portu Cisca, tak to znamena, ze Alcoma nestiha zpracovat to, co ji posila TX z LAN portu Cisca, jak pravis. Coz neni celkem divu, kdyz negociovana linkova rychlost LAN interfejsu je 1Gigabit a ta Alcoma ma radiove "jen" 170Mb.

Jinak se obavam, ze pro nas pripad, kdy je pres jedinou L1 trubku prenasen kombinovany traffic, vcetne IPTV streamu, je aktivni flow control, pri nereseni shapingu a priorizace provozu, vzdy zdrojem lagu, nebot se taha za dratky v bufferech a to zpusobuje zmenu latence, coz je pro IPTV kriticka vec. Proto je nutne mit nastavene shapery tak, aby v zadnem pripade nedochazelo k pretoku dat + QoS prioritu, aby Cisco zahazovalo vsechno predtim, nez sahne na IPTV traffic. Napriklad s pomoci P-bitu. S default priority se ke vsemu chova stejne, coz je dalsi problem.

ISPfrinet píše:Prosím Vas. Vie mi niekto pomocť ako otagovat IPTV na ciscu? Manuály od cisca som si pozrel, ale som z toho blbý...Respektíve som tomu nepochopil, ale je to asi tým, že neviem skvelo po ang.

PS: priorita portov je žial v tomto prípade nepodstatná, kedže všetok trafit aj s IPTV tečie do alcomy cez jeden port.

Viz vyse. Otagovani provozu je otazka hlavne znalosti konkretni topologie site a zpusobu, jakym se jednotlivy typ provozu do site dostava, coz nikdo z nas netusi. Vlastni nastaveni je pak prace s parametry switchport access a switchport trunk v ramci 802.1Q specifikace a prirazeni do konkretnich C-VLAN. Jinak ohledne konfigurace Cisca doporucim inspiraci napr. zde: http://www.samuraj-cz.com/clanek/cisco- ... -vlan-vtp/

ISPfrinet píše:Je to 300M rádio a určite nebudem shapovať down na 300M to by bola hovadina. Rozmýšlam, že by som to dal na 80% na down a 20% na up.

Ve svete FDD spoju je kapacita vztazena vzdy k obousmernemu symetrickemu prenosu. 300Mb je agregovana kapacita radia, nebo full duplex ? Pokud FD pak je to 300 tam a 300 zpet. V takovem pripade neni shaping 300 down uplne hovadina. Pokud tim udajem 300 byla myslena agregovana rychlost (= soucet rychlosti up+down), tak je to 150 dolu a 150 nahoru, podle toho je treba uvazovat parametry traffic limiteru (shaperu).