Intr-un proiect recent de schimbare a topologiei retelei locale in care am folosit switch-uri Cisco Small Business si o retea wireless folosind AP-uri Unifi de la Ubiquiti am intampinat o problema ce afecta clientii wireless pe viteza de upload.

In reteaua respectiva am folosit Ap-uri LR PRO si Lite de la Ubiquiti. Unele switch-uri permiteau PoE, iar la altele SF350 (porturi fast ethernet fara PoE) am avut nevoie de injectoare PoE pentru a conecta antenele wireless. In situatia aceasta in momentul in care am conectat ap-urile acestea au fost adoptate in controller fara probleme si clientii se puteau conecta la reteaua interna si de guest. Din punct de vedere al configuratiei am acoperit tot:

-vlan-urile specifice retelei wifi interna si guest erau definite pe switch-uri
-trunk-urile aveau allow pe vlan-urile respective
-vlan-ul nativ era definit pentru traficul de management al ap-urilor.
-in controller aveam pe ssid configurat vlan-ul specific retelelor si am dezactivat tehnologiile incompatibile pentru clienti

In momentul cand un client se conecta la unul dintre ap-uri si efectua un speedtest la download nu avea nicio problema, ajungand pana la 94 Mbps (portul era 100Mbps Fe), dar la upload ajungea la 10 Mbps cu mici deconectari de la wifi. In logurile switch-ului aparea ca portul flapa in momentul upload-ului:

24-Jun-2020 10:44:09 :%LINK-I-Up: fa4
24-Jun-2020 10:44:06 :%LINK-W-Down: fa4
24-Jun-2020 10:35:12 :%LINK-I-Up: fa4
24-Jun-2020 10:35:09 :%LINK-W-Down: fa4

Negocierea era in regulă. 100Mbps/FullDuplex:

Nu aveam erori pe interfata:

Ceva se intampla in momentul upload-ului. Ma gandeam sa nu fie o problema fizica cu portul, cablul, injectorul sau AP-ul, dar flaparea avea loc pe toate antenele conectate prin injector la FastEthernet într-un SF Cisco. Cand conectam de exemplu intr-un port Gigabit problema nu se mai repeta, configuratia fiind aceeasi. Am dezactivat negocierea automata si am pus manual speed 100 Mbps, iar problema revenea dupa cateva minute de cand antena se restarta. Configuram din nou negociere automata si tot asa. Modelul problemei se repeta si la alte Switch-uri SF fara PoE.

AP Unfi + Injector PoE + FastEthernet SW SF rezulta flaparea portului doar la upload. Deja problema transcede uneia fizice. Intram cumva in domeniul bugurilor enervante? Situatia era grava, iar eu nu puteam sa las clientul in acest impas. Singurul workaround ar fi fost sa conectez ap-urile in porturi gigabit, insa in locatiile unde chiar era nevoie de wifi pentru scannere de produse nu aveam disponibile suficiente porturi gigabit.

Am inceput sa caut in baza de date Cisco pentru buguri exact modelul acesta si am gasit dupa multe cautari CSCvr05487

In descriere citesc ca este vorba de acelasi model de switch (SF350), porturi FastEthernet, ap-uri si flapari la upload. Workaroundul mentionat de ei era sa dezactivam auto-negocierea si sa o reactivăm (aceeasi actiune efectuata si de mine), dar dupa restartarea antenei problema se repeta. In versiunile de firmware afectate observ aceeasi versiune instalata pe switch-urile clientului (2.5.0.83). In lista ap-urilor notate de inginerii Cisco nu apar ap-urile Unifi (poate cu ocazia asta noteaza si vendorul acesta), ci alte modele destul de folosite. Le notez aici pentru cei care le utilizeaza daca intampina probleme asemanatoare:

Ruckus H320
Ruckus R310
Ruckus R500
Ruckus R510
Cambium cnPilot E400
Cambium cnPilot E410
Cambium cnPilot E430W
Cambium cnPilot E500
Cambium cnPilot E600
Nextek NW1870

Panica a aparut in momentul citirii urmatorului ”fix”:

Singura speranta a fost sa instalam cea mai noua versiune de firmware pentru Switch-urile Small Business, poate ”au uitat” sa o noteze la rezolvate. De pe software.cisco.com la data respectiva (22.06.2020) am descarcat versiunea 2.5.5.47 si am actualizat switch-ul, cu toate ca la Release Note nu apare in lista de bugfix-uri si acest bug.

M-am conectat prin browser accesând GUI-ul echipamentului la Administration -> File Management -> File Operation -> Select Update Firmware -> HTTP/HTTPS -> Choose File -> Apply uploadand imaginea prin http/https:

Dupa upload am dat restart la echipament, deoarece in mod automat imaginea a fost setata ca activa după reboot. Verificând prin comanda ”show bootvar” mă asigur dacă versiunea nouă a devenit activă și testez din nou. După 5-6 speedtesturi succesive problema pare rezolvată. Au trecut acum 2 zile de user activity și pot confirma că problema nu a mai revenit. Mulțumim Cisco pentru fix, însă pe viitor vă rugăm să actualizați documentația de bugfix-uri.

–––––––––––––––––––––-UPDATE–––––––––––––––––––-

Problema nu a fost rezolvată. Porturile flapează în continuare dupa restartarea ap-urilor. O sa inaintam problema la Cisco. Workaround temporar este sa dezactivam si sa activam din nou auto-negocierea sau utilizarea porturilor Gigabit. Exista topicuri in care si firmware-ul ap-urilor este acuzat ca avand bug-uri aici. Reclamantul a luat decizia extrema de a folosi un switch chiar de la Ubiquiti. Cam extrem. Astept si parerile voastre.

Articol scris de Bogdan Curduban – Network Engineer