classic.ISPforum.cz

Ahoj chlapci potřeboval bych poradit protože už si nevím rady a nevim jestli mi bude pomoci.
Problém je ve ztrátovosti paketů do páteřní vysílací antény od RACOMU

Zapojení je takovéto

Mikrotik CCR <---> Cisco Vlan Switch <---> Racom Ray

Ztratuje to z Cisco Vlan Switch do Racomu Ray

(ztrata je samozrejme i z ccrka do racomu)

zkusili jsme vymenit kabel
jiny switch
jiny racom
cisco v logu nema zadne kolize chyba apod.
pri pingu z cisca
Success rate is 99 percent (9988/10000),

Ztraci 22 paketu z 10 000 je to sice málo ale je to na kabelu což je nepřijatelné.

Aby jsme to nejak vyresili a zjistili co je spatne zapojili jsme mezi cisco switch a racomu ješte jeden rb1100 jako switch takze to zapojeni vypadalo takto

CCR --> Cisco Vlan --> rb 1100 --> racom ray

a ztrata je uplne nesmyslna a divná

CCR - Cisco = neztratuje
CCR - Racom = ztratuje
CCR - rb1100 = neztratuje

Cisco - CCR = neztratuje
cisco - Racom = ztratuje
Cisco - rb1100 = neztratuje

rb1100 - Cisco = ztratuje
rb1100 - Racom = ztratuje
rb1100 - CCR = ztratuje


ping z rb posilam s intervalem 20ms

Jaky je na lince provoz?

Ping na racom opravdu znamena, ze se pingalo na radio (to bliz ne to na vzdalene strane)? CPU v radiu muze nestihat z ruznych duvodu

Už to řeším tak dva týdny a děla to do všech zařízení které jsou na dané lokalitě na střeše (5 racom a 4 mikrotiky)
Tohle jsem uvedl jako modelový příklad..

Vždycky pingám na bližší stranu

Děla to jak při vysokém datovém toku tak i večer kdy je nízký.
Původně jsme tam měli TP-linkový switch tak jsem myslel ze dela problém on potom jsme tam dali Cisco 3750 a průměrné zatížení je 400-500Mbps

Ale nedokážu odhadnout kdy to začalo protože mi volali nezávisle na sobě zákazníci, že jim při hraní her vypadávají pakety.

Jediné kde je zatiženy procesor hodne je ccrko asi na 50%

ztratovost na to radio si umim vysvetlit jen jako nejaky problem toho CPU v radiu (pokud se nejedna o nejaky bug apod), roste ma jinou praci tak na nejake ICMP kasle. To by ale samozrejme packety zakazniku ovlivnovat nemelo.
Pokud si stezuji zakaznici, pak se muze jednat o klasicky problem s (micro)bursty na radiovych trasach. Radio ma 1gbps link na ethernetu, radiova trasa ovsem jen napr 500mbps. Data behaji prumernou rychlosti 300mbps, takze je radio stiha odesilat. Obcas se ale objevi vlacek (burst) packetu nahloucenych za sebou tak, ze kratkodobe je rychlost vyssi nez kapacita radiove trasy. Radio je dostane plonou 1gbps rychlosti a nema dost bufferu na to, aby ty packety ulozilo. Fronta se rychleji plni nez se stiha odesilat. Fronta se zaplni a packety pro ktere neni misto se musi zahodit. A je tu packet loss.

Racomy neznam - mozna maji nekde nejaky counter, ktery rika, ze nejaky packet byl zahozeny kvuli preplnene fronte (at pres SNMP ci dohledove rozhrani). Resit problem se da pomoci TX flow-control na radiu. Pokud ovsem zarizeni, ktere mu posila data (switch) ma RX flow control implementovane a ma dost bufferu na pozdrzeni provozu (pripadne umi peska predat pomoci flow-contorl jeste dal). Ta 3750 IMHO nema dost bufferu ale aspon by mela hlasit dropy/discardy, takze by se dal kreslit graf. U switchu, ktere maji vice bufferu lze nastavit shaping tak, aby data netekla rychleji nez stiha odesilat radio)

Flow control každopádně můžu vyzkoušet. Každopadně podle toho co píšete to vypadá že, je problém jen na jedné jednotce toho racomu.
Protože celá trasa vypadá takto:

CCR -> Cisco A -> racom A -------- racom B -> cisco B

Jak jsem již psal:
z cisca A na cisco B je logicky ztrata
z cisca A na racom A je ztrata

ALE!
z cisca B na racom B ztrata není
a z cisca B na racom A taky ztráta není

mysleli jsme si, že je problém na racom A na ethernetu a tak jsme celou racomu vymenili ale problém přetrval.
Je pravda ..nezkoumal jsem nějakou statistiku na portu racomy ale to zkusim se podivat co to pise.

A jak píšete je divné, že cisco nehlásí žadné chyby na ethernetu a vypis vypadá čistě:

30 second input rate 15722000 bits/sec, 9425 packets/sec
30 second output rate 152074000 bits/sec, 15392 packets/sec
3443756661 packets input, 670223994536 bytes, 0 no buffer
Received 14885209 broadcasts (4637340 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 4637340 multicast, 0 pause input
0 input packets with dribble condition detected
5192255656 packets output, 6590329313626 bytes, 0 underruns
0 output errors, 0 collisions, 2 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

Ted jsem se dival do statistiky portu na racom

Muže znamenat můj problém:

The Longest Drop: 104695
??
In All Errors: 34939773

In All Packets: 882471195
In Unicast Packets: 866611004
In Multicast Packets: 3294317
In Broadcast Packets: 12565874
In All Errors: 34939773
In Dropped Packets: 17047025
In Crc Errors: 17892748
Out All Packets: 3445592927
Out Unicast Packets: 3430666530
Out Multicast Packets: 4641298
Out Broadcast Packets: 10285099
Out All Errors: 0
Out Dropped Packets: 0
Out Collisions: 0
Statistics Cleared: 1463921030
Statistics Period: 970807
Uptime: 970738
Downtime: 69
Reliability: 99.9928
The Longest Drop: 104695
Number of Drops: 29

ale vyčistim statistiku protoze po pokusech co se tam delaly muze byt zkreslene

Takže po vyčištění logu hned naskakuje..:

In All Errors: 5034
[b]The Longest Drop: 105612
[/b]
ted prijit na to co se mu nelibi..

A na protejsi strane nejsou:
In All Errors : 0
ale za to
The Longest Drop: 105313

to je jasný, nelíbí se mu že kabel do racomu jede na gigu a radio z racomu pryč už jede 5x pomaleji. Pár mikrobustrů a zaplní se mu buffer a pak dropne. Je jedno co se kde nastaví. Vždy dropne. Už jsme to před lety řešili s ceragonem a jinde se switchem. Typicky větší počet tcp spojení nebo vydatnější udp.

A co teda pomohlo ?

starej ceragon se nahradil alcomou mp600 na max speed a switch nomanaged se nahradil managed switchem.

No a hlavně se to už nesleduje. Pokud na jedno spojení ve špičce protahnu nějakou rozumnou rychlost úměrnou spoji, seru na to.

Ja mám ted nastavenou rychlost spoje 300Mbps

Trafic je ted o pulnoci nejakych 70Mbps

ale i pres to je proste z 1000 paketu ztraceno 12 tak nevim co s tim mam robit...

Kaslat se mi na to nechce....protoze ta ztrata jde poznat..

Teď jestli lze In Crc Errors: 17892748 připsat dropování kvůli těm burstům ... Tohle jsou prostě vadné pakety. A je jich nějaké 2 %

racom neznam ale google rika, ze:

the longest drop je nejdelsi cas po ktery nejela linka. Tedy zrejme se rozpada radiove spojeni
In Crc Errors Počet přijatých poškozených paketů (špatné CRC). Většinou indikuje problém na Eth kabelu nebo konektoru.

http://www.racom.eu/cz/products/m/ray17/config.html


Takze myslim, ze je na case vymenit/opravit kabel k jednotce 'A'. Napovida to mu i to, ze z cisca B se na racom A neztraci data. Tim by se zrejme odstranil nejhorsi problem a pak by se videlo, zda je treba resit to rozpadani radioveho spojeni, pripadne jeste ty bursty.
Nevim jak kvalitni tam mas kabel/konektory,pripadne jak je kabel dlouhy, zda nehrozi nejake ruseni (soubeh s 230V, nejake ruseni vykonnejsim RF vysilacem v tesne blizkosti atd)

S kabelem jsme si taky užili.
Původně cat 5e stíněny díky výpadkům jsme vyměnili kabel za cat 7.

Jjsme na střeše kde má t-mobile několik svých vysílačů. Nevím sice jakým
výkonem ono vysílají, ale je možné, že tak velkým aby se na kabelech indukoval nějaký bordel?
Ten kabel je dlouhy cca 25 m

Možná by jsme mohli vyzkoušet do dat do nějaké pružné kovové chráničky..

Co te týče kvality radiové linky a rádia jedná se Racom Ray 17 GHz s kapacitou max 360Mbps
A současné naladění je:

Bandwidth [MHz] 56 MHz TO 56 MHz TO
TX channel [GHz] L8 | 17.128000 U33 | 17.215500
RX channel [GHz] U33 | 17.215500 L8 | 17.128000
TX modulation QAM256 ACM / QAM256 QAM128 ACM / QAM256
TX power [dBm] 5 ATPC / 5 5 ATPC / 5
Net bitrate [Mbps] 358.85 309.01
Max. net bitrate [Mbps] 359 359
RSS [dBm] -55.1 ATPC / -54 -54.6 ATPC / -54
SNR [dB] 28.4 ATPC / 30 32.8 ATPC / 30
BER [-] 0.00e+00 0.00e+00
Link uptime 1 days, 16:30:28

Je to spoj na CCA 3.5 kilometru na 40cm parabolách