Cisco IOS: Per-Tunnel QoS für DMVPN

DMVPN ist eine der elegantesten VPN-Arten, wenn man eine größere Anzahl von Außenstellen hat, die über das Internet verbunden sind. Leider ist die Konfiguration von Quality of Service (QoS) hierbei leicht eingeschränkt. Vor einiger Zeit habe ich es bei einem ersten Kunden gewagt, Per-Tunnel QoS zu konfigurieren. Gewagt deshalb, weil ich dafür von meinem Lieblings-IOS, 12.4(15)T, auf ein neueres IOS wechseln musste. Im aktuellen Fall hat sich 12.4(22)T5 als stabil und zuverlässig genug herausgestellt. Die vorher getestete Version 12.4(22)T4 hatte massive Speicherlecks und war noch nicht einsetzbar.

Was ist Per-Tunnel-QoS?
Beim DMVPN registriert sich der Spoke-Router per NHRP, um seine (dynamische) public IP beim Next-Hop-Server (NHS) zu registrieren. Dabei kann der Router gleich einen Gruppennamen mitgeben, der in der Per-Tunnel-QoS-Konfiguration verwendet wird. Auf dem Hub wird für jede Gruppe eine QoS-Konfiguration angewendet. Damit lässt sich z.B. für jeden Spoke-Router die Datenrate auf die in der Außenstelle verwendete Downstream-Geschwindigkeit shapen. Wenn in der Hauptstelle eine Internet-Anbindung mit 34 MBit/s vorhanden ist, würde man damit normalerweise fast jede Außenstelle überlasten. Mit Per-Tunnel-QoS lässt sich das individuell runter regeln und wichtiger Traffic kann auch priorisiert werden.

Die Spoke-Konfiguration
Diese beschränkt sich auf eine Zeile in der Konfiguration:

interface Tunnel1
  description DMVPN-Tunnel Internet
  ...
  ip nhrp group SDSL2000-Std
  ...

Der Gruppenname (hier SDSL2000-Std) wird auf der Hub-Seite für die Auswahl der richtigen Policy verwendet. In diesem Beispiel ist die Außenstelle mit einer 2 MBit/s SDSL-Leitung angebunden, in der kein Voice verwendet wird. Die 2 MBit/s-Außenstelle mit Voice benutzt dann z.B. den Gruppennamen SDSL2000-Voice.

Die Gruppen sind auf dem Hub sichtbar:

HUB-Router#sh ip nhrp 
...
10.255.255.8/32 via 10.255.255.8
   Tunnel1 created 2w5d, expire 01:43:49
   Type: dynamic, Flags: registered used 
   NBMA address: 79.x.y.z 
   Group: SDSL2000-Std
10.255.255.9/32 via 10.255.255.9
   Tunnel1 created 20:53:37, expire 01:46:01
   Type: dynamic, Flags: registered 
   NBMA address: 88.x.y.z 
   Group: HSDPA-Std
10.255.255.16/32 via 10.255.255.16
   Tunnel1 created 2w5d, expire 01:54:05
   Type: dynamic, Flags: registered used 
   NBMA address: 80.x.y.z 
   Group: SDSL2000-Std
10.255.255.152/32 via 10.255.255.152
   Tunnel1 created 2w5d, expire 01:29:46
   Type: dynamic, Flags: registered 
   NBMA address: 80.x.y.z 
   Group: ADSL3000-Voice
...

Die Hub-Konfiguration
Auf dem Hub wird als Minimum eine Policy für Shaping konfiguriert, die von der NHRP-Gruppe abhängig ist:

policy-map SDSL2000-Std-Parent
 class class-default
    shape average 2000000
policy-map HSDPA-Std-Parent
 class class-default
    shape average 3000000

Diese Policy-Map wird im DMVPN-Tunnel an die Ziel-NHRP-Gruppe gebunden:

interface Tunnel1
  description DMVPN-Tunnel Internet
  ip nhrp map group HSDPA-Std service-policy output HSDPA-Std-Parent
  ip nhrp map group SDSL2000-Std service-policy output SDSL2000-Std-Parent

Für alle Standorte, die diese NHRP-Gruppen verwenden, wird die ausgehende Datenrate auf zwei, bzw. auf drei MBit/s begrenzt.
Für die Standorte, die auch Voice benutzen, muss innerhalb dieser begrenzten Datenrate aber der Voice-Traffic bevorzugt werden. Dafür wird eine hierarchische Policy-Map konfiguriert:

class-map match-all EF-TRAFFIC
  match  dscp ef 
!
policy-map ADSL3000-Voice
 class EF-TRAFFIC
    priority 256
 class class-default
    fair-queue
policy-map ADSL3000-Voice-Parent
 class class-default
    shape average 3000000
  service-policy ADSL3000-Voice

Hier wird in der Parent-Policy der Traffic auf 3 MBit geshaped. In diesen drei MBit/s wird 256 kBit/s für Voice-Traffic priorisiert. Auch das weitere gewünschte QoS-Verhalten würde in der Child-Policy konfiguriert werden. In dem Tunnel-Interface wird dann auch hier die Parent-Policy an die NHRP-Gruppe gebunden:

 interface Tunnel1
  ip nhrp map group ADSL3000-Voice service-policy output ADSL3000-Voice-Parent

Die Wirkung der QoS-Implementierung kann man dann mit “show dmvpn detail” und “show policy-map multipoint” überprüfen:

HUB-Router#sh dmvpn detail 
...
    1 80.x.y.z     10.255.255.16    UP 20:38:56    D     10.255.255.16/32
NHRP group: SDSL2000-Std
 Output QoS service-policy applied: SDSL2000-Std-Parent

    1  80.x.y.z    10.255.255.152    UP     2w5d    D    10.255.255.152/32
NHRP group: ADSL3000-Voice
 Output QoS service-policy applied: ADSL3000-Voice-Parent
HUB-Router#sh policy-map multipoint 

Interface Tunnel1  80.x.y.z

  Service-policy output: ADSL3000-Voice-Parent

    Class-map: class-default (match-any)
      3643772 packets, 1136319199 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 
      Queueing
      queue limit 750 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 3744389/1409612078
      shape (average) cir 3000000, bc 12000, be 12000
      target shape rate 3000000

      Service-policy : ADSL3000-Voice

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1046668/312237672

        Class-map: EF-TRAFFIC (match-all)
          1045840 packets, 242902872 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match:  dscp ef (46)
          Priority: 256 kbps, burst bytes 6400, b/w exceed drops: 0
          

        Class-map: class-default (match-any)
          2597932 packets, 893416327 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any 
          Queueing
          queue limit 686 packets
          (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
          (pkts output/bytes output) 2697721/1097374406
          Fair-queue: per-flow queue limit 171
...

Verbleibende potentielle Probleme:
Auch Per-Tunnel QoS löst natürlich nicht alle Probleme. Wenn man z.B. mehrere Hubs hat, die Traffic zu den Spokes senden, dann weiß Hub1 nicht, wieviel Traffic Hub2 sendet. Auch haben die Hubs keine Information, ob die Spokes evtl. durch lokalen Internet-Traffic oder aber durch Spoke-to-Spoke-Kommunikation überlastet sind. Trotzdem kann die Kommunikation mit diesem Modell in vielen Fällen optimiert werden.

Zusätzlich werden einzelne Pakete durch das Shaping evtl. länger zurückgehalten, wodurch sich die Reihenfolge der IPSec-Pakete ändern kann. Der Replay-Buffer der Router muss also deutlich vergrößert oder der Replay-Check gar komplett ausgeschaltet werden:

crypto ipsec security-association replay window-size 1024
no crypto ipsec security-association replay window-size

6 Replies to “Cisco IOS: Per-Tunnel QoS für DMVPN”

  1. Hey,

    genau so etwas habe ich gesucht. Wenn Sie erste Erfahrungen mit der Technik gesammelt haben, können Sie mir vll. folgende Frage beantworten:

    Wie sieht es bei einer Überbuchung der Bandbreite aus? Wenn z.B. bei einer 100Mbit-Leitung drei Clients mit Shaping-Parametern von z.B. 50 Mbit eine Verbindung aufbauen wollen. Hat Cisco daran gedacht und regelt das (irgendwie 😉 ) oder können sich dann nur zwei Clients verbinden?

    Haben Sie irgendwelche Erfahrungen damit gemacht?

    Auf jeden Fall ein sehr interessanter Artikel! Ich werde an der Sache dranbleiben 😉

    Gruß Martin Wicher

    1. 3*Shaping auf 50 MBit/s bei 100 MBit ist kein Problem. Zu jedem der Clients kann man dann halt nicht mehr als 50 MBit/s senden. Anders sieht es aus, wenn mehr Reservierungen erfolgen sollen als Bandbreite zur Verfügung steht. Das muss ich selbst noch testen.

      1. In diese Richtung ging meine Frage, und zwar was passiert wenn drei Clients mit je 50Mbit/s “geshaped” werden und diese auch ausnutzen wollen. In der Summe käme man ja theoretisch auf 150Mbit/s, was aber rein physikalisch nicht möglich ist.

        Wenn dann jeder einfach weniger Bandbreite bekommt, dürfte es Probleme mit dem QoS, beziehungsweise einigen QoS-Klassen kommen.

        Das sind so meine Gedankengänge. Wenn es dazu Erkenntnisse gibt, bitte mitteilen!

        1. Das hat dann aber nichts mehr mit dem Shaping zu tun, denn das begrenzt nur die Bandbreite. Was dann gebraucht wird ist eine richtige Queuing-Konfiguration (CBWFQ bzw. LLQ). Was aber passiert, wenn auf einmal mehr Spokes kommen und dadurch die verfügbare Bandbreite überbucht wird, das muss ich noch herausfinden.

  2. Schicke Anleitung, dass kann ich uU auf mal benutzen.

    Danke für solche hilfreichen Dokus.. (schreibst Du solche Einträge eigentlich auf dem iPad)?

    1. Das meiste schreibe ich schon noch auf dem Notebook. Aber z.B. die Networkers-Beiträge habe ich auf dem iPad angefangen, und dann auf dem Notebook weitergeschrieben.
      Insgesamt ist es natürlich mit dem iPad nicht so komfortabel, vor allem wenn es darum geht, mehr als reinen Text zu erfassen. Das Einfügen von Bildern z.B. geht auf dem iPad so ziemlich überhaupt nicht.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.