Laten we ons een netwerkapparaat voorstellen met een ingebouwde schakelchip, geconfigureerd om verkeer tussen meerdere poorten te beheren. Om bepaalde poorten van elkaar te isoleren zijn er poorten in het leven geroepen meerdere bruggen.
De functionaliteit van hardware offload op deze bruggen met als doel de prestaties te verbeteren door de switch-chip zelf het verkeer te laten verwerken, in plaats van de CPU van het apparaat te gebruiken.
Aan het einde van het artikel vindt u een kleine proef dat zal je toestaan schatten de kennis die tijdens deze lezing is verworven
configuratie
/interface bridge
add name=bridge1
add name=bridge2
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge2 interface=ether3
add bridge=bridge2 interface=ether4
het probleem
Na het uitvoeren van prestatietests worden aanzienlijke inconsistenties waargenomen in de datatransmissiesnelheid tussen de verschillende bruggen. Terwijl de eerste brug het verkeer met de maximale kabelsnelheid kan verwerken, presteren de volgende bruggen aanzienlijk slechter.
Bovendien ervaren pakketten die moeten worden gerouteerd een aanzienlijk hoge latentie.
Bij het inspecteren van de systeemstatus wordt ontdekt dat de CPU op maximale capaciteit werkt. Uit het controleren van de hardware-offloadstatus blijkt dat deze functionaliteit alleen op de eerste bridge is ingeschakeld.
Dit betekent dat al het verkeer dat door de volgende bruggen gaat, via de CPU wordt afgehandeld, waardoor er een knelpunt ontstaat en de prestaties niet optimaal zijn.
[admin@MikroTik] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
# INTERFACE BRIDGE HW
0 H ether1 bridge1 yes
1 H ether2 bridge1 yes
2 ether3 bridge2 yes
3 ether4 bridge2 yes
De hoofdoorzaak van dit probleem is dat het apparaat in kwestie geen poortisolatie op de switch-chip ondersteunt. Op apparaten die deze mogelijkheid niet hebben, kan slechts één bridge profiteren van de hardware-offload-functionaliteit.
Dit resulteert in een hoog CPU-gebruik voor verkeer dat door de andere bruggen gaat, wat leidt tot verminderde prestaties en latentieproblemen.
Symptomen:
- Afwezigheid van de “H”-vlag (indicator voor hardware-offload) op de havens van volgende bruggen.
- Lage datatransmissiesnelheid op bruggen die niet de eerste zijn.
- Hoog CPU-gebruik.
- Hoge latentie voor pakketten die over bruggen moeten worden gerouteerd zonder hardware-offload.
Het probleem ligt in de beperkingen van het apparaat bij het verwerken van meerdere bridges met hardware-offload ingeschakeld, vanwege het gebrek aan ondersteuning voor poortisolatie.
Dit probleem leidt tot inconsistente en mogelijk onaanvaardbare netwerkprestaties in omgevingen die een hoge mate van isolatie en efficiëntie vereisen.
Mogelijke gevolgen:
1. Inconsistente prestaties:
Het eerste en meest voor de hand liggende gevolg zou inconsistent lage prestaties zijn voor verschillende segmenten van uw netwerk, wat vooral problematisch zou kunnen zijn als een constant prestatieniveau wordt verwacht voor kritieke applicaties of services.
2. CPU-overbelasting:
Een voortdurend hoog CPU-gebruik heeft niet alleen invloed op de prestaties van het verkeer dat door de bruggen gaat, maar kan ook een impact hebben op andere functies en services die op hetzelfde apparaat draaien.
3. Latentieproblemen:
Bij toepassingen of diensten die gevoelig zijn voor latency, zoals VoIP of online gaming, kunnen de gevolgen zelfs nog ernstiger zijn en zelfs zo ver gaan dat deze diensten praktisch onbruikbaar worden.
4. Verborgen kosten:
De noodzaak om de hardware te wijzigen of te upgraden om dit probleem op te lossen, kan leiden tot extra onverwachte kosten. Bovendien vertegenwoordigen de tijd en middelen die worden besteed aan het identificeren en oplossen van problemen andere verborgen kosten.
Voorgestelde oplossingen:
1. Hardwarewijziging:
De meest directe manier om het probleem op te lossen is door over te schakelen naar een apparaat dat poortisolatie op meerdere bridges ondersteunt met hardware-offload.
2. Configuratie-optimalisatie:
Hoewel dit niet ideaal is, kunt u handmatig hardware-offload-functionaliteit toewijzen aan de bridge die het meest kritieke of omvangrijke verkeer afhandelt, waardoor de belasting van de CPU wordt verminderd.
/interface bridge port set [find where bridge=bridge1] hw=no
/interface bridge port set [find where bridge=bridge2] hw=yes
3. Implementatie van VLAN's:
Het gebruik van VLAN's om netwerkverkeer te scheiden kan een efficiënter alternatief zijn voor het gebruik van meerdere bridges, vooral als de huidige hardware meerdere exemplaren van hardware-offload niet ondersteunt.
4. Firmware-/software-update:
In sommige gevallen kunnen firmware- of software-updates extra functies mogelijk maken die het probleem helpen verzachten of oplossen, hoewel dit minder waarschijnlijk is als het een hardwarebeperking is.
5. Monitoring en analyse:
Monitoringtools kunnen helpen knelpunten te identificeren en inzicht te geven in hoe het netwerk opnieuw kan worden geconfigureerd om de prestaties te optimaliseren, hoewel dit het onderliggende probleem niet zou oplossen.
Concluderend
Het beperken van de hardware-offload op meerdere bridges is een serieus probleem dat meerdere negatieve gevolgen kan hebben voor de prestaties en efficiëntie van een netwerk.
Het identificeren en begrijpen van het probleem is de eerste stap bij het vinden van de meest geschikte oplossing, die kan variëren van een eenvoudige herconfiguratie tot een volledige hardwarewijziging.
Korte kennisquiz
Wat vind je van dit artikel?
Durf jij je geleerde kennis te evalueren?
Aanbevolen boek voor dit artikel
Switching en Bridging RouterOS v7 Boek
Studiemateriaal voor de MTCSWE-certificeringscursus bijgewerkt naar RouterOS v7