zalezi cemu se rika QoS. Na nekterych zarizenich je QoS jedinym zpusobem jak vyrobit a ovlivnit frontu na portu a jak shapnout rychlost na portu. Takze mam zaply QoS ale ve skutecnosti je to jen shaper, ktery zadne packety neuprednostnuje. Pak RX flow control na portu zpusobi jen to, ze packet pocka ve fronte portu (priority nemaji vliv).
Zda pouzit nebo nepouzit Flow control, zavisi na tom, co mas v siti za zarizeni a co nabizi za moznosti. Nejlepsi ze vseho je samozrejme nemit zadne uzke misto, ktere by neco takoveho jako flow-control vyzadovalo.
Kdyz zapnes flow-control, tak vlastne hazis problem jednoho zarizeni na druhe.
V tom linku, co zminujes, ten tough switch ackoliv ma privlastek Pro, je zrejme switch bez bufferu (nebo spatne nastaveny - UBNT zarizeni krom AF24 neznam), takze nezvladne bursty na rychlosti te AF24 bufferovat pro 100mbps port.
Takze by ten switch musel dostavat flow control od zarizeni za 100M portem (pokud si budeme jeste hrat na to, ze AP nema buffery pred wirelessem) a sam posilat flow control na portu k AF24. Ta by mela mit bud dost bufferu (neverim) nebo zase predat flow control na druhou stranu tak az to propadne na toho Junipera, ktery by to snad mohl byt schopen bufferovat(Junipery neznam ale 2200 nejake moc nizke cislo ve jmene a informace o bufferech jsem nevygooglil, takze spis bych cekal, ze bude problem i tady). Jenze v te chvili Ti bude v bufferech
stat veskery tok tou AF24 linkou na vzdalenou vez. Takze dalsi APcka, byt pripojena 1G portem nedostanou data. Sice se vylepsi spojeni na AP se 100M portem ale vse ostatni si pohorsi.
Tohle je IMHO duvod, proc cisco switche (29xx a pod) vubec nepodporuji TX flow control
Takze by ten typek by mel IMHO vyhodit ten tough switch a pouzit neco, co umozni zafrontovat par set packetu a nepotrebuje zadne flow-control. Pripadne flow control jen mezi 2ma zarizenimi (pomale AP a switch).
A dulezite je o problemu vedet. Tj mit switch, ktery pocita zahozene packety a umoznuje je vycitat v SNMP (OutDiscard).