Cisco QoS

Quality of Service är användbart om en länk eller interface går fullt och viss trafik är viktigare än annan. Man kan klassificera och markera paket som man vill att intermediate systems ska prioritera och skicka iväg i första hand. IP/ATM/Frame Relay-headers har fält som kan användas för detta, t.ex. IP DSCP (RFC 3260). QoS är endast aktivt när det är överbelastat. QoS går att ha time based genom att matcha mot time based ACLer.

Non-IP Marking
Alla enheter kanske inte har möjligheten att kolla på L3-headern, t.ex. en LSR (se MPLS) ser endast labels. Det man kan göra är att låta ingress LSR föra över QoS-klassificeringen till MPLS-headern som har ett 3-bitars fält för detta (EXP).

MQC

Modular QoS CLI togs fram för att skapa en homogen syntax för QoS på IOS-enheter. Man kan även använda en route-map för att sätta markeringar på paket men det är inte det rekommenderade sättet.

• Class Map – Definiera typer av trafik
• Policy Map – Definiera vad som ska göras med trafiken, t.ex. sätta QoS-markering
• Service Policy – Definiera interface och riktning

Class, man kan bl.a. matcha på ACLer/MAC-adresser/QoS-markeringar/protokoll. Det går att välja mellan AND-logik (match-all) eller OR-logik (match-any) om man behöver flera match-statements. Det går även att använda nested class-maps för mer avancerad logik.

class-map CLASS-MAP
 match access-group name <ACL>
 match cos <cos>
 match mpls experimental
 match not destination-address mac

show class-map

Policy

policy-map POLICY-MAP
 class CLASS-MAP
  set ip dscp <0-63>

show policy-map

Interface

interface Gi0/0
 service-policy input POLICY-MAP

show run | i interface|service-policy

Om service-policy rejectas kan det bero på avsaknad av CEF på enheten.

NBAR

Vill man matcha på ett visst protokoll i sin class-map kan man använda Network Based Application Recognition som finns inbyggt i IOS. Det finns väldigt många fördefinierade protokoll.

class-map NBAR
 match protocol ?

Behöver man lägga in ett nytt protokoll får man ladda ner en PDLM-fil från Cisco och ladda upp till IOS-enheten och aktivera.

ip nbar pdlm name

AutoQoS

AutoQoS är ett macro man kan använda för att smidigt slå på fördefinierad QoS-konfiguration utifrån Ciscos rekommendationer. Man kan använda det för VoIP och Enterprise. VoIP är gjort för video och voice och finns både på routrar och switchar. Man slår på det per interface men det genererar konfiguration både på interface och globalt. På accessportar används CDP för att kolla om det finns telefoner och ställer då in QoS, finns ingen telefon blir det DSCP 0. På trunkar litas det på DSCP och COS värden som kommer in. Ingress och egress köer konfigureras på interfacen samt class-maps och policy-maps enableas. Känd trafik som voice, video, real-time, routingprotokoll och BPDUer prioriteras av AutoQoS voip.

interface Gi0/0
 auto qos voip

Uplink

 auto qos voip trust

Verify

show auto qos interface
show mls qos

Enterprise gäller VoIP plus andra applikationer och kräver att interface bandwidth är konfigurerat samt att CEF är på. NBAR används för trafikigenkänning.

interface Gi0/0
 auto discovery qos

Discovery bör stå på ett tag så att NBAR hinner samla in information om paketen som går över interfacet. Sedan slår man på QoS och då skapas lämpliga class-maps och policy-maps.

 auto qos

Verify

show auto discovery qos
show auto qos

Queueing

Köer som skapas på interface av queueing tools kallas software queues och håller det paket som inte kan skickas iväg på en gång. När sedan paketen kan skickas iväg flyttas de till en liten FIFO queue i hardware, denna kallas Tx ring/queue. När ett paket har lämnat Tx ring kan nästa encodas och skickas iväg utan software interupt till CPU, detta möjliggör full användning av interfacets bandbredd. Det sista använder alltid FIFO-logik och kan inte påverkas av IOS queuing tools. Det som händer när man använder queuing tools är att hardware queue minskas lite för att ge mjukvaran mer utrymme att spela med eftersom mer trafik då hamnar i software queue.

show controllers

Features

• Classification: Kolla packet headers och bestämma kö
• Drop policy: Regler för vad som ska droppas när det går fullt
• Scheduling: Logiken som bestämmer vad som ska skickas härnäst
• Number of queues: Unika klasser av paket för queueing tools
• Queue length: Maximala antalet paket i en enskild kö

CBWFQ

Class-Based Weighted Fair Queueing är skapat från legacy-metoderna PQ och CQ. Det fungerar som WFQ fast man har mer flexibel flow classification med MQC syntax. CBWFQ reserverar bandbredd för varje kö för att sedan använda WFQ för paket i default-kön. Default-kön finns alltid och behöver inte konfigureras, där hamnar paket som inte matchar någon class-map. Finns det tomma köer kan den bandbredden användas av andra klasser sålänge det inte går fullt.

class-map match-all R2
 match access-group name R2
policy-map CBWFQ
 class R2
  bandwidth percent 5
interface Gi 0/1
 bandwidth 1000
 service-policy output CBWFQ

Verify

show policy-map

LLQ

Low Latency Queueing fungerar som CBWFQ men utökar det med priority queues även kallat low-latency queues. Det som behandlas först är paket i prio-köerna. LLQ förhindrar även starvation av övriga köer eftersom den prioriterade köns bandbredd förutom garanterad minimum också är policed max-bandbredd. Har man flera klasser som är prioriterade är det FIFO som gäller eftersom det finns en intern prio-kö. Fördelen med detta är att man kan styra så att man kan ha flera prioriterade klasser men ingen kan ta upp all bandbredd. LLQ används endast när hardware queues går fulla!

class-map http
 match protocol http
class-map voice
 match protocol rtp

policy-map VOICE_PRIO
 class http
  bandwidth percent 20
 class voice
  priority percent 50

Verify

show policy-map

WRED

När en kö är full har inte IOS plats för paket utan de droppas och det påverkar nätverksprestandan. TCP skickar så mycket som möjligt tills paket droppas eller delay/RTT ökar och då sänks sending rate lite. När transmit buffer (egress) fylls blir det tail drop. Detta får påverkan på annan trafik som också blir droppad. För att förhindra trafikspikar som leder till att många paket droppas hjälper det att droppa några paket när en kö börjar bli full för att göra så att TCP sänker sending rate tidigare. Detta ökar overall throughput. Cisco har utvecklat Weighted Random Early Detection som håller koll på köerna. För att avgöra när paket ska börja droppas används average queue depth som mäts mot minimum och maximum queue threshold och agerar sedan utifrån det. Ligger average queue depth under minimum droppas ingenting, ligger det mellan minimum och maximum droppas en viss procent av paketen på random och ligger det över maximum droppas alla nya paket. Eftersom WRED tittar på köer måste det konfigureras ihop med en kö och alla kömekanismer har inte stöd för WRED.

Fysiskt interface (allt blir en FIFO på interfacet)

interface gi0/0
 random-detect

Cisco 3560

Cisco 3560 har köer både för input och output. Det finns två köer för input och scheduler använder Shared Round-Robin (SRR) för att skicka paketen till internal switch fabric. För att bestämma discard thresholds för varje kö används Weighted Tail Drop (WTD) när QoS slås på. Weight för respektive kö är konfigurerbart med relativa värden, dvs ratio. Default när man slår på QoS hamnar paket med COS 5 i kö 2 och övrig trafik i kö 1. Kö 2 har även 10% bandbredd reserverat. När man ska prioritera trafik konfigurerar man den ena kön för det. Ingress QoS konfigureras globalt så det gäller alla interface.

mls qos srr-queue input priority-queue 2 bandwidth 30

Kö 2 kommer att få 30% av bandbredden och resterande delas mellan köerna.

show mls qos input-queue

Man kan dela på resterande bandbredd med en ratio, default är 4:4.

srr-queue input bandwidth 4 4

Man kan mappa annan trafik till kö 2, t.ex. COS 6.

mls qos srr-queue input cos-map queue 2 6

Verify

show mls qos maps cos-input-q

Egress
Cisco 3560 har fyra köer för egress per interface och man kan mappa COS/DCSP, använda weight och sätta drop thresholds per kö. SRR används för att undvika queue starvation om man har en prio-kö. Egress QoS konfigureras per interface med undantag buffers och WTD som görs globalt. Det finns Sharing och Shaping, båda fungerar lika bra när det finns paket i alla köer och servar eventuell prio-kö direkt när Tx är ledigt. Men Shaping sätter rate-limit på köerna så att de inte överstiger tilldelad bandbredd.

Per interface, ratio mellan fyra köer

interface Gi2
 queue-set 1
 srr-queue bandwidth share <1> <2> <3> <4>
 srr-queue bandwidth shape <1> <2> <3> <4>
 priority-queue out

Buffer och WTD

mls qos queue-set output 1 buffers <1> <2> <3> <4>
mls qos queue-set output 1 threshold 2 <1> <2> <3> <4>

Verify

show mls qos interface Gi2 queueing

Shaping

Traffic shaping förhindrar bit raten på de paket som lämnar ett interface från att överstiga konfigurerat värde. Shaping monitors håller koll på det som skickas och om det överskrider gränsvärde så hålls paketen kvar i en shaping queue och släpps iväg över tiden för att på så sätt ge en viss rate. Därför är shaping alltid outbound. Routrar skickar bits enligt den fysiska kapaciteten/frekvensen på sina interface, för att kunna ha en lägre bandbredd måste routern medvetet växla mellan att skicka och att vara tyst. Ett sådant tidsinterval kallas Tc och mäts i millisekunder. Under Tc får det endast skickas en viss mängd bitar, denna mängd kallas commited burst (Bc). Har man varit tyst ett tag kan man bursta lite extra, denna bitmängd kallas Be (excess burst). I äldre IOS-versioner användas Generic Traffic Shaping (GTS), det är grundläggande och man kan styra vad som ska shapeas med ACL. Det rekommenderade sättet är att använda class-based shaping som finns i IOS 15. Då skapar man class-maps och policy-maps med MQC vilket ger mer granulär kontroll över shaping.

policy-map SHAPE
 class CLASS
  shape average 500000  #BW

interface Gi2
 service-policy output SHAPE

Man kan välja att shapea average, adaptive eller peak.

Verify

show traffic-shape
show traffic-shape queue