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.

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
• 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. Det finns väldigt många fördefinierade.

class-map CLASS-MAP
 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 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å NBAR hinner samla in information. Sedan slås QoS på 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 tillfälligt.

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 bandbredden 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 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 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