Kurze Frage, wegen QoS Werte im Router

[DocZenith 12]

Hi!

 

Kurze Frage, ich hab schon gegoogelt, aber auf die schnelle nicht wirklich ein Ergebnis gefunden.

 

Habe in einem vorhandenen Router folgende QoS Werte eingetragen wegen VOICE QoS:

 

!

!

policy-map QoS

class VOICE

priority 200

class class-default

police cir 300000 bc 5000

conform-action transmit

exceed-action drop

fair-queue

!

!

 

Meine Frage, für was steht unter class class-default der Wert/Befehl police cir 300000 bc 5000 ??

 

Kann ich die Werte irgendwie auf die vorhandene DSL Bandbreite berechnen, meine Bandbreite wäre hier 3000 bzw soll auf 16.000 aufgestockt werden.

 

 

schonmal danke.

 

Gruss.

[daking 10]

Hallo,

 

du benötigst keinen policer in der default klasse um voip zu realisieren.

Warum willst du in der default klasse via policing die bandbreite begrenzen?

 

ciao

–

Hallo,

 

das police kommando begrenzt den Traffic in der Default Klasse auf 300Kbit/s.

Dies wird für VoIP QOS nicht benötigt.

 

Auf welchem interface aktivierst du die SP? auf einem ATM oder Fa/ETH Interface?

 

 

 

 

ciao

[DocZenith 12]

Guten Morgen!

 

Danke für die schnelle Antwort. Ich habe die Config so nicht aufgestellt. Es war ein Kollege lange Zeit vor mir, und habe das Projekt jetzt übernommen und versuche es nur zu verstehen. Der Kollege muss sich doch damals etwas dabei gedacht haben. Ich dachte es hätte mit QoS für Voice zu tun.

 

Kann ich die Werte denn jetzt auf 16.000 anpassen oder ist der police Befehl eher komplett unnötig?

 

Die SP wurde auf das Dialer1 Int gelegt. -> service-policy output QoS

 

Gruss.

[daking 10]

Hola,

 

das police kommando ist eigentlich überflüssig. Scheinbar sollte die CIR der class-default beschränkt werden. Dies wird im Normalfall nicht benötigt, da für Voice 200Kbit/s in der LLQ reserviert sind. Falls nun kein RT Traffic da ist, kann der non RT Traffic (class-default) die 200K nutzen. Mit dem Policer wird dies verhindert.

 

Das Dialer Interface ist ein virt Interface und weiß meistens nicht sehr viel über das HW Interface. Vielleicht hat das QOS auch nicht funktioniert (nicht gezogen), dann wäre die Verwendung des Policers ein guter Weg, um die Fehlkonfiguration "scheinbar" zum Laufen zu bekommen. Die VoIP Daten werden dann durch den policer geschützt ==> das CBWFQ wird niemals ziehen, da keine Überlast entsteht (:-). Die gewünschte Eigenschaft LLQ wird nicht angewendet...

 

Welches HW INteface zeigt Richtung DSL? ATM oder ETH?

QOS ist immer outgoing ==> Richtung DSL (Upload)

Hast du wiklich auch 16Mbit/s Upload? (:-)

 

brgds

[DocZenith 12]

Hallo Daking!

 

Langsam verstehe ich das besser! ATM Int zeigt Richtung DSL. Ich habe ADSL 16.000. SDSL wäre ein Traum :-)

 

Und nochmal auf die Police zurück, was bedeuten denn jetzt die Werte 300000 bei CIR und 5000 bei BC? Warum gerade 300000 und 5000?? Das bezieht sich doch bestimmt auf die verfügbare Bandbreite? Damals lag an dem Anschluss ADSL 3000.

 

Gruss.

 

Mir ist heute noch etwas aufgefallen! Habe den Router heute mal "live" gestellt, und die IP Phones und ATAS, die im Netz hängen, haben über den Tag verteilt immer mal wieder "Fallbacks" gehabt. Auf dem CCM kamen dann folgende Fehler, dass die Geräte unregistriert sind :-( :

 

Error: DeviceUnregistered - Device unregistered.

Device name.: ATA000DBC979EA2

Device IP address.: 10.101.110.44

Device type. [Optional]: 12

Device description [Optional].: ATA HAM 60

Reason Code [Optional].: 8

App ID: Cisco CallManager

Cluster ID: CALLMANAGER1-Cluster

Node ID: 194.140.1.2

Explanation: A device that has previously registered with Cisco CallManager has unregistered. This event may be issued as part of normal unregistration event or due to some other reason such as loss of keepalives.

Recommended Action: No action is required if unregistration of this device was expected..

 

 

Falls einer eine Ursache weiß, oder Idee hat.

 

Gruss.

[daking 10]

Hallo,

 

der policer soll eine Rate von 300K erlauben. Im default wird BC auf 9375 kalkuliert. Durch 5000 werden weniger Tokens erlaubt ==> der policer verwirft schneller / ist agressiver.

 

Trotzdem nochmal. Das Problem ist generell, dass das QOS nicht funktionieren wird da:

 

1. die Konfiguration so Schwachsinn ist.

2. auf Dialer interfaces mit ATM Int SPs nicht unterstützt werden.

 

==> die SP muss auf das ATM Interface.

==> Die SP muss neu aufgesetzt werden.

 

Vorsicht: Wenn du die SP vom Dialerinterface nimmst sollte das Interface auf shut / no shut gehen ==> die Verbindung wird kurz getrennt.

 

Folgende Aufgaben sind nun offen:

 

--> Wie viele Calls sollen möglich sein (welcher Codes / welches Framing)?

--> Wie viele Phones/Atas sind onsite (auch der Sig Traffic muss geschützt werden ==> soll nach wählen einer Nummer nicht x s dauern bis vermittelt wird - auch dein beschriebener Fehler sollte nicht die ganze Zeit kommen.)

--> Der TCP Sig Traffic kann nicht in die LLQ

 

IP Phones oder ATAs deregistrieren sich / werden als "verloren" definiert, wenn:

 

==> TCP Sig Session wird getrennt.

==> TCP / Skinny Keepalives kommen nicht an. Können nicht beantwortet werden.

 

ciao

[DocZenith 12]

Hi!

 

habe das sp auf das atm int gelegt. jetzt muss ich mir noch einen kopf machen wegen der der service-policy, kompliziert kompliziert...

 

--> Wie viele Calls sollen möglich sein (welcher Codes / welches Framing)?

 

denke mal das maximal drei calls gleichzeitig möglich sein sollen. codec ist G.711a-law. was meinst du mit framing?

 

--> Wie viele Phones/Atas sind onsite (auch der Sig Traffic muss geschützt werden ==> soll nach wählen einer Nummer nicht x s dauern bis vermittelt wird - auch dein beschriebener Fehler sollte nicht die ganze Zeit kommen.)

 

Im LAN sitzen stehen drei bis vier IPP, ein ATA.

 

 

 

--> Der TCP Sig Traffic kann nicht in die LLQ

 

IP Phones oder ATAs deregistrieren sich / werden als "verloren" definiert, wenn:

 

==> TCP Sig Session wird getrennt.

==> TCP / Skinny Keepalives kommen nicht an. Können nicht beantwortet werden.

 

Wie kann ich hier gegenwirken? Auch mit einer Definition in der Service-Policy?

 

Danke + Gruss.

[daking 10]

Hallo,

 

--> Generell

 

-bei einer 16M ADSL Leitung solltest du ein upload von ca. 927Kbit/s haben (:-).

==> diese Bandbreite kann in verschiedene klassen aufgeteilt werden.

 

--> Calls und Framing.

 

Du muss die Bandbreite der LLQ berechnen. In der LLQ (priority command) ist ein integrierter policer, der pakete die über die angegebene rate verwirft. Ist die Bandbreite in der LLQ zu knapp kalkuliert oder nicht an das CAC des CCM angepasst werden pakete verworfen und die Sprachqualität wird schlecht.

Der verwendete Codec bestimmt die benötigte Bandbreite pro Call. Auserdem ist das Framing wichtig;sprich wie oft werden Pakete/Samples erzeugt. Bei G.711a sollte mit dem CCM 20ms Framing default sein ==> alle 20ms wird ein Paket erzeugt ==> 50pps

 

Nun kann die Bandbreite für DSL berechnet werden:

 

------------DSL-------------------------------

PPPOE HEADER = 8 Byte

AAL5 HEADER = 10 Byte

AAL5 TRAILER = 8 Byte

ETHERNET = 14 Byte

- -----------IP--------------------------------

IP HEADER = 20 Byte

UDP HEADER = 8 Byte

RTP HEADER = 12 Byte

VoIP PAYLOAD = 160 Byte (G.711a)

20 Byte (G.729a)

- ---------------------------------------------

 

ATM Bandbreite = AUFRUNDEN(Packetsize /48 (byte)) * 53 (byte) * 8 * framing (pps)

 

Beispiel G.711a 20ms Framing (50pps)

 

240 Byte Paket / 48 = 5 (für ein RTP Paket werden 5 Zellen benötigt)

5 * 53 * 8 * 50 /100 = 106 kbit/s on wire

 

==> Ein Call benötigt 106kbit/s aus ATM Sicht.

==> Das CBWFQ+LLQ wird vor dem Generieren von Zellen durchgeführt.

 

"IP" Bandbreite ..

 

240 * 8 * 50 = 96kbit/s ( das sollte passen)

 

Der Cisco zeigt folgendes auf der ATM Schnittstelle an:

G.711A(10ms) 30 second offered rate 124000 bps, drop rate 0 bps

G.711A(20ms) 30 second offered rate 94000 bps, drop rate 0 bps

G.711A(30ms) 30 second offered rate 84000 bps, drop rate 0 bps

----------------------------------------------------------------------

G.729A(10ms) 30 second offered rate 69000 bps, drop rate 0 bps

G.729A(20ms) 30 second offered rate 38000 bps, drop rate 0 bps

G.729A(30ms) 30 second offered rate 28000 bps, drop rate 0 bps

----------------------------------------------------------------------

 

==> nun kannst du die Bandbreite für Sprache berechnen..

 

--> Signalling

 

SCCP ist TCP basierend und sollte in einer eigenen Klasse transportiert werden.

!

policy-map xy

class Voice

priority xxx kbit/s

class SCCP

bandwidth xxx kbit/s

class class-default

fair-queue

set dscp default

!

 

Für Sig sollte 5% der Bandbreite erst mal ein guter Einstieg sein..

 

-->ATM Tuning

 

interface ATM

pvc 1/32

vbr-nrt x x

tx-ring-limit x

 

==> der pvc sollte als no realtime mit variabler bitrate konf sein (vbr-nrt)

==> hier muss noch die aktuelle upstream PVC Bandbreite rein

==> Falls sich die Bandbreite beim Sync ändert ... (;-)

==> Die Reaktionszeit des Queueings kann über den tx-ring gesteuert werden.

==> kleiner tx-ring = schnelles Queueing

==> kleiner tx-ring = weniger Delay

==> kleiner tx-ring = mehr arbeit für den router..

==> Für Voice sollte 3 optimal sein.

 

 

Ciao

 

Hope this helps

[DocZenith 12]

 

Für Sig sollte 5% der Bandbreite erst mal ein guter Einstieg sein..

 

-->ATM Tuning

 

interface ATM

pvc 1/32

vbr-nrt x x

tx-ring-limit x

 

==> der pvc sollte als no realtime mit variabler bitrate konf sein (vbr-nrt)

==> hier muss noch die aktuelle upstream PVC Bandbreite rein

==> Falls sich die Bandbreite beim Sync ändert ... (;-)

==> Die Reaktionszeit des Queueings kann über den tx-ring gesteuert werden.

==> kleiner tx-ring = schnelles Queueing

==> kleiner tx-ring = weniger Delay

==> kleiner tx-ring = mehr arbeit für den router..

==> Für Voice sollte 3 optimal sein.

 

 

 

Hallo Daking!

 

Danke für deine Infos. Du schreibst, dass ich non realtime vbr einstellen sollte. Wird hier der maximale Upload bei meiner DSL Leitung genommen? Habe den Wert im Test wiefolgt eingetragen:

 

router(config-if-atm-vc)#vbr-nrt 967 967

 

oder doch anders? Ist alles leider etwas Neuland für mich.

 

 

 

Bezüglich des SCCP Signaling, hier habe ich jetzt eine extra Klasse angelegt. Allerings wenn ich mir das auf dem Int anschaue, landet nichts in der Klasse. Sie scheint nicht zu arbeiten. Kann das daran liegen, dass die Pakete vom IPP bzw. CCM nicht markiert werden? Kann ich das entsprechend einstellen?

 

 

Gruss.

[daking 10]

Hallo,

 

hier wird die max brutto rate des VCs eingetragen. mit ? nach vbr-nrt siehst du die aktuelle max rate.

 

wie sind die class-maps konfiguriert? Wird hier IPSEC VPN einegsetzt?

Ist beim ADSL Zugang eine Zwangstrennung aktiv?

 

 

ciao

[DocZenith 12]

Guten Morgen!

 

Ja, IPSec VPN und die Zwangstrennung nachts um zwei Uhr, beides wird verwendet. Liegt das wohl am IP Sec Protocol, dass die markierten Pakete nicht erkannt werden? Heute morgen gab es wieder Fallbacks der IPPs, hab ATM konfiguriert wie du geschrieben hast. Es läuft denke ich nur im Zusammenspiel mit den QoS Klassen richtig.

 

Gruss

[daking 10]

Hallo,

 

bei IPSEC muss du die Kalkulation der Bandbreite pro Call nochmal überdenken, da mehr IPSEC Overhead.

 

Wie klassifizierst du die VoIP / SCCP Pakete?

Poste mal deine class-map config.

 

ciao

[DocZenith 12]

Hallo Daking,

 

ich habe mir nochmals den Thread von damals durchgelesen ( http://www.mcseboard.de/cisco-forum-allgemein-38/876-router-133453.html ), da haben wir auch schon lange über das QoS diskutiert, im Prinzip dasselbe. Daraufhin habe ich jetzt eine Teilconfig zusammengestellt. Wäre super, wenn du ein Feedback gibst.

 

class-map match-all SKINNY

match access-group name VOICE

match dscp cs af31

match protocol skinny

class-map match-all VOICE

match access-group name VOICE

match dscp ef

!

class-map match-all RTP

match protocol rtp

!

policy-map MARK

class RTP

set dscp ef

class SKINNY

set dscp af31

!

policy-map QoS

class VOICE

priority 300

class SKINNY

bandwidth 49

class class-default

fair-queue

set dscp default

!

interface Tunnel1

description vpn-ipsec aussenstelle - zentrale

bandwidth 967

qos pre-classify

service-policy output QoS

...

...

!

interface Vlan200

description daten-lan

ip tcp adjust-mss 1300

load-interval 30

service-policy in MARK

...

...

!

 

Ziel ist hier, die Pakete intern im Router zu markieren, am LAN Int, also über mein VLAN. Dann danach bewerten am externen Int, also ATM oder Tunnel Int. Wie siehts denn hier aus, sollte ich die service-policy auf das Tunnel Int legen? Desweiteren hast du das Signaling angesprochen, also wenn das fehl schlägt, dass die IPPs ins Fallback fallen (deregistriert werden im CCM), dafür gabs einen Ansatz einer SCCP Klasse. Kann ich hier auch Skinny nutzen? Oder hier getrennt halten? Ich frage wegen der festgelegten Bandbreite in der Skinny Klasse ==> Bandwidth 49.

 

Frage nebenher, wie könnte ich prüfen, ob der CCM oder das IPP die Pakete mit RTP oder Skinny markiert? Wireshark oder ähnliches an einem Spiegelport?

 

Gruss.

[daking 10]

Halllo,

 

- die Config denke ich passt so.

- SP aufs phy interface legen (ATM).

- skinny kannst du verwenden. (Skinny = SCCP)

==> normalerweise sollte rtp traffic schon mit ef ankommen.

==> normalerweise sollte SCCP/SKINNY Traffic mit af31 oder cs3 ankommen.

- qos pre-classify wird nicht benötigt.

- Falls hier H.323 verwendet wird muss die beachtet werden.

 

 

Analyse DSCP

 

--> Auf der Input Policy nach DSCP matchen und die counter der SP auslesen.

--> Spiegelport + Wireshark

--> Sniffertrace auf dem Router (ab 12.4.11T) + Wireshark

==> Router IP Traffic Export Packet Capture Enhancements [Cisco IOS Software Releases 12.4 T] - Cisco Systems

--> Netflow

 

Ciao

[DocZenith 12]

Halllo,

 

- Falls hier H.323 verwendet wird muss die beachtet werden.

 

Ciao

 

Was muss ich dir beachten? Woran erkenne ich das H.323 genutzt wird?

 

Gruss.