Pakketab: Hvordan man måler og hvordan man løser dem

Netværk er rygraden i de fleste moderne organisationer. De tillader adgang til data af den, der har brug for det, uanset hvor de måtte være. Men så vigtige og kritiske, som de måtte være, kan netværk også lide af et par problemer. Faktisk er der hovedsageligt tre hovedproblemer, der forårsager langt de fleste af alle netværksproblemer: latenstid, jitter og pakketab. I dag taler vi om sidstnævnte. Vi prøver at se på hvorfor og hvordan pakttab er, men også hvilke værktøjer der kan bruges til at måle det og lokaliser kilden samt kort undersøge, hvad der kan gøres for at reducere, hvis ikke eliminere, det.

Vi starter med at forsøge at definere pakketab, da det er vigtigt, at vi alle starter på den samme side. Derefter undersøger vi de forskellige årsager til pakketab. De faktiske årsager er utallige, men vi har valgt de fem mest almindelige, og vi får et dybere kig på hver enkelt. Derefter skal vi se på nogle værktøjer, man kan bruge til at måle og lokalisere pakketab. Når alt kommer til alt, før vi kan ordne noget, er vi nødt til at vide, at det er der, og vi er nødt til at vide, hvor det er. Og når vi taler om at ordne pakketab, vil det være vores sidste forretningsorden.

Hvad er pakketab

jegn enkle udtryk, pakketab er manglen på datapakker sendt fra en kilde til at nå deres destination. Datapakker, hvis du ikke ved det, er små bunker af data, der transmitteres på computernetværk. Hvert data stykke, uanset dets størrelse, er opdelt i pakker, der sendes sekventielt over netværk, før de samles til meningsfulde data af den modtagende part. Af forskellige grunde, som vi er ved at udforske, sker det, at nogle pakker går tabt under transit. Forestil dig som analogt et brev med flere sider, der vil blive sendt med hver side i en separat konvolut. Det er nøjagtigt, hvordan data overføres over et netværk. I dette eksempel sker tab af pakker, hvis en af ​​konvolutterne går tabt under transit.

Det Årsager til pakketab

Selvom der er mange årsager til pakketab - alt for mange til at dække dem alle, har vi identificeret fem af de mest almindelige.

1. Network Congestion

Netværkstopning er muligvis den primære årsag til pakketab. Det ligner trafikpropper, og det sker typisk, når der er flere data, end netværket kan håndtere. Når det sker, kan netværksenheder, som f.eks. Routere, til sidst droppe pakker, der har været i kø for længe, ​​hvilket resulterer i pakketab.

Nogle WAN-links og internetkredsløb er undertiden båndbredde begrænset af udbyderen. For eksempel kunne de levere 2 Mbps båndbredde på et fysisk kredsløb på 10 Mbps. Hvis du prøver at sende mere end 2 Mbps data på et sådant kredsløb, taber WAN- eller internet routeren ofte den ekstra trafik, hvilket resulterer i pakketab.

Netværkstopning kan også ske, når tjenesteudbydere med vilje overtegner et link. De gør det baseret på den grund, at ikke alle abonnenter på tjenesten bruger båndbredde samtidig. I spidsbelastede perioder, hvor flere mennesker bruger tjenesten og efterspørgslen overstiger dens kapacitet, vil der sandsynligvis være pakketab som følge af overbelastning.

2. Overforbrug af enhed

En anden almindelig årsag til overdreven brug af pakketabsenhed. Det sker, når en enhed kører med en kapacitet, den ikke var designet til. I et netværk kan pakker ankomme til en router hurtigere, end de kan behandles / sendes ud. For at håndtere disse situationer har enheder buffere, hvor de midlertidigt har pakker, indtil de behandles og sendes ud. Disse buffere er dog ikke uendelige og kan til sidst fylde op, hvilket resulterer i, at pakker falder ned.

I mange tilfælde fungerer en enhed på en acceptabel måde under normale (off-peak) driftstider og ruter alle pakker korrekt. I spidsbelastningsperioder kan der dog være en mærkbar stigning i pakkedråber.

3. Problemer med hardware og software

Fejlagtig hardware er endnu en anden årsag til pakketab. Vi har f.eks. Set tilfælde af WAN-routere med 100 Mbps-grænseflader, der ikke var i stand til at overføre mere end 30 Mbps data. Når trafikken var lav, var problemet ikke synligt, men så snart det overskred 30 Mbps, begyndte pakker at blive tabt. At flytte kredsløbet til en anden grænseflade på den samme enhed med nøjagtig den samme interfacekonfiguration løste problemet og bekræftede, at det var et routerhardwareproblem.

En tæt beslægtet årsag til pakketab er buggy-software, der kører på en netværksenhed. Netværksenheders firmware er computerprogrammer, og som sådan udsættes de for programmeringsfejl. De er stadig mere komplicerede stykker software, og det er ofte umuligt for deres udviklingshold at fange alle fejl i firmware til netværksenheder.

4. Ondsindet handling

Ondsindet handling - hovedsageligt i form af angreb på Denial of Service (DoS) - er en anden almindelig årsag til tab af pakker. Det er dog en, som vi ofte har ringe kontrol over. Det sker, når ondsindede brugere oversvømmer en netværksenhed med nok trafik, til at den ikke længere kan udføre sine opgaver og begynder at tabe pakker.

Da vi ikke har kontrol over disse situationer, da de er arbejde fra en tredjepart, er den bedste måde at undgå dem helt. Der findes flere tjenester, der hævder at beskytte dit netværk mod DoS-angreb. Nogle af dem gør et ret godt stykke arbejde, selvom de har tendens til at være lidt dyre. Men hvis de kan beskytte dig mod et angreb, som du ellers vil være forsvarsløs, kan det være værd at investeringen.

5. Konfigurationsfejl

Menneskelig fejl skyldes ofte i mange situationer, og pakketab er ikke anderledes. Enhedskonfigurationsfejl er en anden af ​​de mest almindelige årsager til pakketab. For eksempel kan grænsefladehastighed og duplex-misforhold føre til pakketab. Det sker for eksempel når den ene ende af et link er indstillet til fuld dupleks, mens den anden er indstillet til halv dupleks. Når det sker, forekommer kollisioner med det resulterende pakketab. Netværksudstyr bliver mere og mere kompliceret, og det er let at lave fejl. Konfigurationsstyringsværktøjer kan hjælpe dig med at sikre, at dine konfigurationer er fejlfri ved at implementere standardiserede konfigurationselementer.

Effekten af ​​pakketab

Pakketab er almindeligt, og det sker på de fleste netværk. Det har sjældent en mærkbar effekt, indtil den når kritiske niveauer. Når det sker, kan det forårsage forskellige fejl. Filoverførsler—der bruger den forbindelsesorienterede TCP-protokol - er relativt upåvirket, da der er en vis fejlkorrektion indbygget i de fleste protokoller, og en manglende pakke kan videresendes. Det er mere problematisk med overførsler i realtid eller nær realtid -som i stedet bruger den forbindelsesløse UDP-protokol - sådan som streaming af video eller lyd eller Voice over IP (VoIP), hvor det kan forårsage spring og huller, billedfrysning eller uforståelig tale.

Nogle værktøjer til at måle og lokalisere pakketab

Hvis du vil reducere eller eliminere pakketab, er den første ting, du skal gøre, at måle, hvis dit netværk oplever noget og, hvis det er, hvor det sker. Som vi sagde tidligere, er pakketab normalt og vil være til stede på de fleste netværk. Det skal dog forblive under en bestemt tærskel for at sikre, at der ikke observeres nogen dårlige virkninger. Cisco Systems anbefaler for eksempel, at pakketab på VoIP-trafik - muligvis den type trafik, der er mest berørt af den - skal holdes under 1%. Ved videostreaming skal det forblive mellem 0,05% og 5% afhængigt af videotypen.

Da VoIP-trafik er den type trafik, der er mest påvirket af pakketab, kommer den ikke som en overraskelse at de fleste af de værktøjer, vi har fundet til at måle og lokalisere det, primært er VoIP-netværksovervågning værktøjer.

SolarWinds har lavet nogle af de bedste netværksadministrationsværktøjer i de sidste 20 år eller deromkring. Dets flagskibsprodukt, Network Performance Monitor, scorer konsekvent blandt de bedste SNMP-netværksovervågningsværktøjer. Virksomheden er også berømt for sine gratis værktøjer, der er lavet til at imødekomme specifikke behov hos netværksadministratorer. Disse gratis værktøjer inkluderer produkter såsom TFTP Server eller den Avanceret Subnet Calculator.

Det SolarWinds VoIP og netværkskvalitetschef er et dedikeret VoIP-overvågningsværktøj, der er fyldt med fantastiske funktioner. Dette værktøj kan bruges til at overvåge VoIP-opkaldskvalitetsmål, herunder pakketab, men også latenstid, jitter og MOS. Det kan hjælpe med at fejlfinde VoIP-opkalds ydeevne ved at korrelere opkaldsproblemer og netværksydelse. Værktøjet inkluderer også realtid WAN-overvågning bruger Cisco IP SLA-teknologi. Værktøjets sporingsfunktion for VoIP-opkaldssti giver dig mulighed for at se og fastlægge opkaldsproblemer langs hele netværksstien.

• GRATIS PRØVEVERSION: SolarWinds VoIP og netværkskvalitetschef
• Download link:https://www.solarwinds.com/voip-network-quality-manager/registration

Dette værktøj kan udføre overvågning i realtid af WAN-ydelser fra sted til sted, og det har også alarmeringsfunktioner, der giver dig besked om enhver unormal situation. Det kan hjælpe med at sikre, at WAN-kredsløb fungerer som forventet ved at bruge Cisco IP SLA-målinger, syntetisk trafikprøvning og tilpassede ydelsesgrænser og alarmer.

Men SolarWinds VoIP og netværkskvalitetschef overvåger ikke kun dine WAN-kredsløb, det kan også vise brugen og ydeevne-målingerne for dine VoIP-gateways og PRI-trunks. Det kan hjælpe med kapacitetsplanlægning ved at give dig mulighed for at evaluere stemmekvalitet, når du planlægger nye VoIP-implementeringer.

Priser for SolarWinds VoIP og netværkskvalitetschef start $ 1 615 for op til 5 IP SLA-kildeenheder og 300 IP-telefoner. Andre licensniveauer - inklusive en enheds-ubegrænset licens - er også tilgængelige. En gratis 30-dages prøveversion er tilgængelig hvis du ønsker at tage produktet til en testkørsel.

2. PRTG Network Monitor

Det PRTGNetværk Monitor fra Paessler er et multi-purpose netværksovervågningssystem. Gennem brug af sensorer, som kan sammenlignes med tilføjelser, selvom de er inkluderet i produktet, PRTG kan bruges til at overvåge mange forskellige parametre for netværk og systemer. Værktøjet kan overvåge stort set ethvert system, enhed, trafik og anvendelse i din IT-infrastruktur.

Med det formål at måle og lokalisere pakketab foreslår PRTG ikke mindre end tre forskellige sensorer. Du kan bruge Ping-sensoren til at måle tilgængeligheden af ​​dine enheder og til at beregne pakketab i procent. Servicekvaliteten giver dig mulighed for at overvåge hele netværksstier og derved måle og lokalisere den. Endelig kan Cisco IP SLA-sensoren bruges til at måle pakketabshastigheden på dine Cisco-enheder. Du kan vælge at blive underrettet via e-mail, SMS eller push-meddelelser på en mobilenhed, når tærsklen overskrides, så du kan træffe passende forholdsregler.

Det PRTG Network Monitor er super nem og hurtig at installere. Værktøjets auto-discovery system scanner netværkssegmenter og genkender automatisk en lang række enheder og systemer. Det opretter derefter sensorer fra foruddefinerede enhedsskabeloner. Specifikke VoIP-sensorer skal undertiden konfigureres manuelt bagefter, hvilket gør installationen lidt længere, men dette er stadig et af de hurtigste værktøjer, der skal konfigureres.

Det PRTG Network Monitor fås i en gratis version med fuld funktion, der er begrænset til 100 sensorer. Bemærk, at enhver enkelt overvåget parameter tæller som en sensor. For at overvåge mere end 100 sensorer har du brug for en licens. Priserne varierer med antallet af sensorer og starter ved $ 600 for 500 sensorer op til $ 14 500 for ubegrænsede sensorer. En gratis enheds ubegrænset 30-dages prøveversion er tilgængelig.

3. ManageEngine OpManager With VoIP Monitor

Det ManageEngine OpManager er et andet fremragende værktøj til overvågning af netværk. Det vil overvåge de vitale tegn på dit udstyr og advare dig, så snart noget er ude af specifikationerne. Værktøjet har en intuitiv brugergrænseflade, så du nemt kan finde de oplysninger, du har brug for. Det har også en fremragende rapporteringsmotor sammen med nogle forudbyggede og brugerdefinerede rapporter. For at færdiggøre pakken er produktets advarselsfunktioner også meget omfattende.

Når det kommer til overvågning for jitter, ManageEngine OpManager’s VoIP-skærm kan proaktivt overvåge og rapportere om din infrastrukturs kapacitet til at håndtere VoIP-opkald. Værktøjet bruger Cisco IP SLA til kontinuerligt at overvåge kritiske serviceparametre for VoIP-netværk. De overvågede VoIP-parametre inkluderer pakketab, forsinkelse, jitter, den gennemsnitlige opfattelsesscore (MOS) og Round Trip Time (RTT).

Det ManageEngine OpManager prissættes baseret på antallet af overvågede enheder. Priserne spænder fra $ 715 for 25 enheder til $ 14 995 for 1000 enheder. Det VoIP-skærm option tilføjer $ 125 per enhed, der kræver det. En gratis 30-dages prøveversion er tilgængelig, så du kan prøve produktet og se, hvordan det passer til dine specifikke behov.

4. VoIPmonitor

VoIPmonitor er en open source-netværkspakkesniffer med en kommerciel frontend til overvågning af de fleste VoIP-protokoller. Det kører på Linux og er designet til at analysere kvaliteten af ​​igangværende VoIP-opkald baseret på netværksparametre, såsom pakketab og jitter i henhold til ITU-T G.107 E-model. Opkaldsoplysninger sammen med deres målinger gemmes i en database. Hvert opkald kan gemmes i en pcap-fil til yderligere analyse med eksterne værktøjer som Wireshark.

VoIPmonitor kan også afkode tale og afspille den over dens webbaserede GUI samt gemme den på disken som en .WAV-fil. Uden for kassen understøtter produktet G.711 alaw og ulaw-codecs og kommercielle plugins tilføjer support til G.722, G.729a, G.723, iLBC, Speex, GSM, Silk, iSAC og OPUS. VoIPmonitor er også i stand til at konvertere T.38 FAX til PDF.

Det VoIPmonitor GUI-frontend er tilgængelig enten som en lokalt hostet server til priser, der spænder fra $ 42 / måned for 10 kanaler til $ 917 / måned for 6 000 kanaler eller som en skybaseret service med priser, der varierer fra $ 20 / måned for 3 kanaler til $ 200 / måned for 200 kanaler. Begge versioner er tilgængelige i en gratis og ubegrænset 30-dages prøveperiode.

Fastgørelse af pakketab

Måling og placering af pakketab, hvis det første trin i at løse det. Ethvert af værktøjerne gennemgået ovenfor vil hjælpe dig med det. Normalt vil årsagen til pakketab være indlysende, når du lokaliserer, hvor det sker, og det er en simpel sag at løse problemet.

Hvis netværket er overbelastet, er det det indlysende svar at øge dens båndbredde, så du kan skubbe mere trafik igennem. Du kan også overveje at anvende QoS-funktioner (Quality of Service). Det kan muliggøre, at visse typer trafik - f.eks. VoIP - får prioritet i forhold til anden trafik, der ikke er så følsom over for pakketab eller kritisk for operationer.

Hvis pakttab skyldes overudnyttelse af enheden, kan den eneste løsning være at opgradere til en enhed med højere ydeevne. I nogle tilfælde er det muligvis kun en komponent på enheden, der skal opgraderes. For eksempel kan du undertiden erstatte en routergrænseflade på 100 Mbps med en 1 Gbps.

Defekt hardware kan adresseres ved at udskifte det eller, hvis det er mere praktisk, ved at bruge en anden ikke-defekt komponent på den samme enhed. For eksempel, hvis en routergrænseflade er defekt, kan du måske blot bruge en anden grænseflade på den samme enhed. Selvom dette på ingen måde er en god løsning, er det tilstrækkeligt til test eller til at levere en midlertidig løsning, indtil enheden kan udskiftes.

Trådløse netværk er ofte mere tilbøjelige til tab af pakker på grund af radiointerferens. Skift til en kabelforbindelse kan være en måde at løse denne type problemer, selvom det ikke altid er muligt. Hvis den berørte enhed f.eks. Er en håndholdt bærbar IP-telefon, understøtter den muligvis kun en trådløs forbindelse. I disse situationer kan det at skifte til en anden kanal eller bruge en anden frekvens forbedre situationen eller endda løse problemet helt.

Hvis pakketab er forårsaget af ondsindede aktiviteter, skal du afbøde angrebet så hurtigt som muligt. Dette kan være så simpelt som at bruge en adgangskontrolliste til at blokere angriberen's IP-adresse (hvis statisk og kendt). I mere komplekse tilfælde kan du bruge funktioner som ekstern udløst sort hulruteing.

Du skal også kontrollere, at din konfiguration ikke forårsager pakketab. Sørg for, at dupleksindstillinger stemmer overens i hver ende af en forbindelse. Jeg har personlig tendens til at holde mig væk fra indstillingerne for automatisk hastighed og dupleks, da det har fået mig i flere problemer. Jeg foretrækker meget at tvinge hastigheden på hver interface og indstille den til full-duplex. Der er i dag ingen tvingende grund til at bruge halvduplex alligevel. Og hvis du har konfigureret QoS på dine netværksenheder, skal du sørge for, at din buffers størrelse er nok. Ellers risikerer du bufferoverløb, hvilket fører til pakketab.