Dit document biedt een voorbeeldconfiguratie voor Quality of Service (QoS)-functies op de Cisco Nexus 7000 Series switch om te vereenvoudigen hoe classificatie en wachtrij worden bereikt.
Zorg ervoor dat u aan deze vereisten voldoet voordat u deze configuratie probeert:
beschikken over een basiskennis van de configuratie van Nexus 7000 Series-switches
basiskennis van QoS hebben
De informatie in dit document is gebaseerd op de Nexus 7000 Series-switch.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Raadpleeg de Cisco Technical Tips Convention voor meer informatie over documentconventies.
De standaard QoS-parameters op de Nexus 7000-schakelaar zijn toereikend voor de meeste implementaties. U moet echter de beperkingen en configuratiegegevens begrijpen die vereist zijn om een aangepast beleid te maken.
Er zijn twee aspecten die u in overweging moet nemen voor QoS op Nexus 7000 M-Series lijnkaarten:
wachtbeleid
QoS-beleid
Een wachtrij wordt in de hardware uitgevoerd en is ingesteld met behulp van beleid voor modulaire QoS CLI (MQC)-wachtrij. Het QoS-beleid, dat wordt gebruikt om het verkeer te markeren of te controleren, wordt via een MQC-beleid in de exacte indeling gebruikt als een standaard QoS-beleid op andere Cisco-platforms. Bijvoorbeeld, een toegangslijst die wordt gebruikt om verkeer in een class-map aan te geven met een corresponderende beleids-kaart om verkeer in te stellen/te controleren.
Op dit moment voeren M-Series modules wachtrijen uit op basis van de waarde van de serviceklasse (CoS). Daarom moet u eerst begrijpen hoe de CoS-waarde wordt afgeleid. Nadat u weet welke CoS waarde de schakelaar ingaat/verlaat, kunt u zich op de het wachtrij configuratie concentreren om de gewenste QoS voor verschillende verkeerstypen te verkrijgen.
Voor routed unicast-verkeer wordt de CoS-waarde afgeleid van de 3 meest significante bits van de DSCP-waarde (Distributed Services Code Point). Voor overbrugd eenastverkeer wordt de CoS-waarde gekopieerd van de CoS-waarde die in de 802.1q-header wordt ontvangen. Merk op dat er op L2-toegangslinks geen kofferkop is. Daarom, als het verkeer op een toegangpoort wordt ontvangen en overbrugd zal het de schakelaar met CoS 0 binnendringen. De DSCP waarde wordt niet gewijzigd, maar het pakket kan niet de gewenste prioriteit krijgen. U kunt de CoS-waarde handmatig in een beleidskaart instellen via een QoS-beleid dat de CoS- of DSCP-waarde handmatig instelt.
Het is belangrijk om het gedrag ook voor multicast te begrijpen. Routed multicast verkeer leidt zijn CoS-waarde af op dezelfde manier als routed unicast-verkeer. Voor overbrugd multicast verkeer hangt het gedrag af van de L3 staat. Als er geen L3 staat is voor de multicast groep, wordt de CoS afgeleid op dezelfde manier als overbrugd eenastverkeer. Als er een L3 staat is voor de multicast groep, wordt CoS afgeleid op dezelfde manier als routed unicast verkeer. Merk op dat wanneer u Protocol Independent Multicast (PIM) in sparse modus op de switch virtuele interface (SVI) voor het VLAN in welk verkeer wordt ontvangen, er een S,G-ingang wordt gecreëerd wanneer de multicast wordt gezien.
Samengevat wordt het CoS-gedrag voor een type verkeer hier weergegeven:
Type verkeer | CoS-gedrag |
routinematige eenrichter | gekopieerd van 3-MSB van ToS |
bruidsschat | ongewijzigd |
Verrouteerde multicast | gekopieerd van 3-MSB van ToS |
bridge multicast met L3-status voor groepen | gekopieerd van 3-MSB van ToS |
bridge multicast zonder L3-status voor groepen | ongewijzigd |
Neem een voorbeeld waar verkeer op toegangpoort (Eth8/1) wordt ontvangen en op VLAN wordt overbrugd. Standaard is de CoS-waarde van het overbrugde éénastverkeer onveranderd. Als het verkeer op een toegangpoort aankomt, wordt de standaard CoS waarde van 0 toegewezen. In dit voorbeeld wordt prioritair verkeer (DSCP 46) ontvangen op een toegangspoort en zet u de switch ingedrukt terwijl de DSCP-waarde onveranderd is en de CoS-waarde van 0. Hierdoor krijgt het pakket niet de juiste prioriteit.
Een mogelijke ommekeer is om een QoS-beleid te creëren om de CoS-waarde handmatig in te stellen op de ingangspoort.
In het voorbeeld worden alleen pakketten met DSCP 46 van hun CoS waarden bijgewerkt. Als er meerdere DSCP-waarden nodig waren om een goede CoS-waarde te garanderen, zouden er extra class-maps en acties in de beleidskaart moeten worden gedefinieerd.
Een andere optie is om een tabel-map te gebruiken met de actie 'standaard kopie'. Met de tabelkaart kunt u de DSCP opnieuw instellen op basis van de huidige DSCP-waarde. Bijvoorbeeld, als het verkeer werd ontvangen met een DSCP waarde van 40 en u moet ervoor zorgen dat het werd herkend naar een DSCP waarde van 46, kon u een tabelkaart gebruiken met de actie 'van 40 tot 46'.
Een tabelkaart bevat ook een actie voor een 'standaardkopie' die de DSCP-waarde op de oorspronkelijke waarde instelt. Dit lijkt op het maken van een beleidsplan met de classificatie van 'match-dscp-ef' en actie van 'set-dscp-ef'. Logisch gezien is de DSCP-waarde onveranderd, maar met de 'ingestelde DSCP'-actie wordt de CoS-waarde impliciet ingesteld op 3-MSB van de nieuwe DSCP-waarde.
Als u er daarom voor moet zorgen dat de CoS-waarde altijd wordt bijgewerkt naar de 3-MSB van de DSCP-waarde, gebruik dan een tabelkaart met één actie van 'standaard kopie'.
Zodra de CoS-waarde is afgeleid, kunt u de globale wachtrijen class-maps manipuleren om de CoS-to-wachtrij mappings te beïnvloeden. Deze class-maps zijn globaal en hebben invloed op alle modules in alle virtuele apparaten contexten (VDCs) voor dat specifieke een wachtrij type. Denk bijvoorbeeld aan deze standaardinstellingen voor de wachtrij van class-maps voor de M108- en M132-modules (1p7q4t):
class-map type queuing match-any 1p7q4t-out-pq1
Description: Classifier for egress priority queue of type 1p7q4t
match cos 5-7
class-map type queuing match-any 1p7q4t-out-q2
Description: Classifier for egress queue 2 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q3
Description: Classifier for egress queue 3 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q4
Description: Classifier for egress queue 4 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q5
Description: Classifier for egress queue 5 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q6
Description: Classifier for egress queue 6 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q7
Description: Classifier for egress queue 7 of type 1p7q4t
class-map type queuing match-any 1p7q4t-out-q-default
Description: Classifier for egress default queue of type 1p7q4t
match cos 0-4
Standaard wordt CoS 0-4 in de standaardwachtrij geplaatst en KOS 5-7 in de prioriteitswachtrij geplaatst. Deze gaan hand in hand met het standaard wachtrijen beleid voor hetzelfde type:
policy-map type queuing default-out-policy
class type queuing out-pq1
priority level 1
queue-limit percent 16
class type queuing out-q2
queue-limit percent 1
class type queuing out-q3
queue-limit percent 1
class type queuing out-q-default
queue-limit percent 82
bandwidth remaining percent 25
De prioriteitswachtrij is 'prioriteit' met een wachtlimiet van 16%. De standaard wachtrij heeft een wachtrijlimiet van 82% met een standaard resterende gewicht voor bandbreedte. De andere wachtrijen, die niet in gebruik zijn, worden een wachtrijlimiet van 1% toegewezen. Merk op dat q4, q5 en q6 niet vertegenwoordigd zijn in het beleid voor de standaard wachtrij en daarom een nog kleiner limiet en bandbreedtegewicht hebben dat geprogrammeerd is in hardware.
Voltooi de volgende stappen om een aangepast wachtbeleid te maken:
Neem een voorbeeld voor M132-modules met een 1p7q4t wachtrij-architectuur waar alle 8 CoS-waarden in kaart zijn gebracht in een aparte wachtrij. De output toont het aangepaste wachtend beleid samen met de veranderingen in de globale wachtrijen class-maps:
policy-map type queuing 10G_POLICY
class type queuing 1p7q4t-out-pq1
priority level 1
queue-limit percent 10
class type queuing 1p7q4t-out-q2
queue-limit percent 10
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q3
queue-limit percent 5
bandwidth remaining percent 5
class type queuing 1p7q4t-out-q4
queue-limit percent 5
bandwidth remaining percent 5
class type queuing 1p7q4t-out-q5
queue-limit percent 10
bandwidth remaining percent 20
class type queuing 1p7q4t-out-q6
queue-limit percent 5
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q7
queue-limit percent 5
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q-default
queue-limit percent 50
bandwidth remaining percent 40
! voice
class-map type queuing match-any 1p7q4t-out-pq1
match cos 5
! scavenger
class-map type queuing match-any 1p7q4t-out-q2
match cos 1
! transactional
class-map type queuing match-any 1p7q4t-out-q3
match cos 2
! call signaling
class-map type queuing match-any 1p7q4t-out-q4
match cos 3
! video
class-map type queuing match-any 1p7q4t-out-q5
match cos 4
! routing
class-map type queuing match-any 1p7q4t-out-q6
match cos 6
! management
class-map type queuing match-any 1p7q4t-out-q7
match cos 7
! best effort
class-map type queuing match-any 1p7q4t-out-q-default
match cos 0
De laatste stap is het beleid voor een aangepaste wachtrij op elke 1p7q4t-interface toe te passen:
interface Ethernet8/1
service-policy type queuing output 10G_POLICY
Het beleid voor de standaard wachtrijen gaat ervan uit dat CoS 0-4 in kaart wordt gebracht in de standaardwachtrij en CoS 5-7 in de prioriteitswachtrij wordt geplaatst. Daarom zijn de wachtrijen q3, q4, q5, q6 en q7 extreem klein. U kunt de opdracht Show een gebruikersinterface invoeren om de huidige wachtrijgrootte en bandbreedte te valideren die zijn geconfigureerd en in de hardware wordt toegepast.
Neem het voorbeeldbeleid in de voorgaande sectie waar elke CoS-waarde in een specifieke wachtrij werd geplaatst. Aan het eind van het voorbeeld werd het beleid voor wachtrijen op Eth8/1 toegepast. Ga er ook van uit dat er een andere interface 1p7q4t (Eth6/1) is die werd achtergelaten met het beleid voor de wachtrij van een standaard:
N7k# show queuing interface e6/1
<some output omitted>
Configured queue-limit ratios
queue-limit ratios: 78[1p7q4t-out-q-default] 1[1p7q4t-out-q2] 1[1p7q4t-out-q3]
*1[1p7q4t-out-q4] *1[1p7q4t-out-q5] *1[1p7q4t-out-q6] *1[1p7q4t-out-q7] 16[1p7q4t-out-pq1]
* means unused queue with mandatory minimum queue-limit
Thresholds:
COS Queue Threshold Type Min Max
______________________________________________________________
0 1p7q4t-out-q-default DT 100 100
1 1p7q4t-out-q2 DT 100 100
2 1p7q4t-out-q3 DT 100 100
3 1p7q4t-out-q4 DT 100 100
4 1p7q4t-out-q5 DT 100 100
5 1p7q4t-out-pq1 DT 100 100
6 1p7q4t-out-q6 DT 100 100
7 1p7q4t-out-q7 DT 100 100
Uit de bovenstaande output kan je zien dat de wachtrijen q2 en q3 een wachtrijlimiet van 1% hebben terwijl q4, q5, q6 en q7 *1% hebben, wat de minimale verplichte rijlimiet is (met andere woorden aanzienlijk minder dan 1%). Daarnaast kan je zien dat CoS-waarden 1-4 en 6-7 deze zeer kleine wachtrijen gebruiken. De kleine wachtrijmaten resulteren snel in output disards en kunnen de netwerkprestaties verslechteren. Dit wordt nog verscherpt als de standaard traffic CoS 0 aan een van deze kleine wachtrijen wordt toegewezen.
Samengevat, als u een douanewachtend beleid creeert en de globale die klas-maps in de rij veranderen, is het essentieel om het douanewachtend beleid op alle interfaces over het chassis toe te passen die het zelfde het wachtende type delen.
Hier worden ook een aantal behulpzame vervolgopdrachten genoemd: