876 Router

[daking]

Hallo,

am Eingangsinterface setzt du via service-policy die QOS Group:

class meine
set qos-group 500

==> am Ausgangsinterface kannst du dann das Queueing nach qos-group 500 machen. (Kann man sich wie einen IOS internen DSCP Wert vorstellen)

In deinem Fall sollten die relevanten Pakete schon mit den richtigen DSCP Werten versehen sein (falls CCM richtig konfiguriert). Da nach IPSEC Standard der DSCP Wert in den nächsten Header übernommen (falls tunnel mode) wird ,musst du dir keinen Stress machen. Ein Klassifizieren nach DSCP Werte sollte in dieser Konstellation reichen. Falls du natürlich nach IP Adressen + DSCP Werte am Ausgangsinterface klassifizierst, sollte man sich gedanken machen wann QOS passiert und ob die richtigen IP Adressen für das CBWFQ noch sichtbar sind...

ciao

[DocZenith]

Hi Daking!

aktuell habe ich die Config mal so aufgestellt:

class-map match-any VoIP
match dscp ef
match access-group name VOICE
class-map match-any VPN
match protocol citrix
match protocol pcanywhere
match dscp af31
!
policy-map QOS
description CE QOS Policy
class VPN
bandwidth 150
set dscp af31
class VoIP
priority 150
set dscp ef
class class-default
fair-queue
set dscp default
police cir 300000 bc 5000
conform-action transmit
exceed-action drop
!

match access-group name VOICE

Die oben genannte VOICE ACL bezieht sich auf die IP Phones. Die sind in einem separaten IP Netz und haben nur Zugriff auf entferntes Voice Gate und CCM.

Eine Ausgabe von sh policy-map int at0 zeigt mir, dass match access-group VOICE greift aber der rest nicht. die service-policy ist zurzeit NUR am atm0 definert:

ATM0: VC 1/32 -

Service-policy output: QOS

Class-map: VPN (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: protocol citrix
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol pcanywhere
0 packets, 0 bytes
30 second rate 0 bps
Match: dscp af31 (26)
0 packets, 0 bytes
30 second rate 0 bps
Queueing
Output Queue: Conversation 41
Bandwidth 150 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
QoS Set
dscp af31
Packets marked 0
Class-map: VoIP (match-any)
275 packets, 57908 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
0 packets, 0 bytes
30 second rate 0 bps
Match: access-group name VOICE
275 packets, 57908 bytes
30 second rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 150 (kbps) Burst 3750 (Bytes)
(pkts matched/bytes matched) 271/57268
(total drops/bytes drops) 0/0
QoS Set
dscp ef
Packets marked 2
Class-map: class-default (match-any)
59122 packets, 11312899 bytes
30 second offered rate 25000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 32
(total queued/total drops/no-buffer drops) 0/0/0
QoS Set
dscp default
Packets marked 113
police:
cir 300000 bps, bc 5000 bytes
conformed 113 packets, 20508 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps


Sicherlich gibt es hier noch Fehler. Ich finde Sie nur nicht, bin ich aber seit einiger Zeit schon am reinlesen, weil ich dies und das noch nicht so ganz verstehe. Ich frag mich aktuell halt, warum dscp ef und af31 nicht matchen

[daking]

Hallo,

die VoIP Klasse sollte denke ich erst mal match-all sein ==> also DSCP 46 UND die ACL und nicht match-any DSCP 46 ODER die ACL.

In der Klasse VoiP matched die ACL aber nicht die DSCP 46 regel ==> dscp 46 ist eine zeile höher als die ACL ==> d.h. falls die IPPs dscp 46 senden würden solte es umgedreht sein.

==> IP Phones checken
==> Switches checken (mls qos trust ...)

Für VoIP mit Cisco ist es sehr wichtig den Skinny Traffic in einer eigenen Klasse zu transportieren (Skinny = TCP ==> in der LLQ mit Policer = schlecht!)
==> Skinny kaputt von Normalen Traffic = schlecht

!
class match-all skinny
match dscp cs3 af31
!

wie sieht die ACL VOICE aus? wird hier verschlüsselt?

AF31(CS3) siehe DSCP 46 (switch / port trust..)
==> mit match-any klaut natürlich die ACL Zeile das Af31 von VPN

[DocZenith]

Zitat von daking Hallo, ==> IP Phones checken ==> Switches checken (mls qos trust ...) wie sieht die ACL VOICE aus? wird hier verschlüsselt?

Servus! Danke für deine Hilfe und Bemühungen!

Also Switches brauch ich nicht groß zu prüfen. Hab hier bisher nur ein Lab aufgebaut mit 876er und vier IPPs (7911er).

Wegen den ACL VOICE, die sieht so aus, keine große Kunst:

ip access-list extended VOICE
permit udp 10.161.110.0 0.0.0.255 x.x.x.x 0.0.255.255
permit tcp 10.161.110.0 0.0.0.255 x.x.x.x 0.0.255.255
permit udp 10.161.110.0 0.0.0.255 host 10.20.30.1
permit udp 10.161.110.0 0.0.0.255 host 10.20.30.2
permit udp 10.161.110.0 0.0.0.255 host 10.20.30.3
permit udp 10.161.110.0 0.0.0.255 host 10.20.30.4

Wie sieht das denn mit dem internen Interface aus? auf dem 876er habe ich ja nur diesen integrierten Mini-Switch, hier kann ich die einzelnen Ports ja nicht wirklich konfigurieren, mache das zurzeit mit einem VLAN, der den Ports zugewiesen ist. In dem Vlan habe ich noch keine Service-Police eingetragen.

Das Telefonproblem ist, dass das erste Gespräch sauper läuft, bis ein zweites IPP ein Anruf aufbaut, dann wird die Qualität schnell schlecht! Nutze im meinem Lab ganz normales DSL 3000.

Gruss.

[daking]

Hola,

welchen Codec verwendest du (G.711 / G.729 / G.723) --> Coderintervall?(20ms / 30ms)
welche Upload Bandbreite hast du?

test#sh dsl int atM 0 | inc Speed
Speed (kbps): 3456 0 448 0
test#

==> 3456 kbit/s down / 448 kbit/s up
==> 448 ist hier interessant

Hier die Kalkulation der benötigten Bandbreite pro Call (Beispiel G.711a - 20ms)

Overhead:

[IP Overhead]
Voice Payload ==> 160 Byte
RTP Header ==> 12 Byte
UDP Header ==> 8 Byte
IP Header ==> 20 Byte
Ethernet Header ==> 14 Byte

[IPSEC] falls vorhanden tunnel / transport

tunnel IP Header ==> 20 Byte

ESP IV ==> 8 Byte
ESP Header ==> 8 Byte
ESP PAD
ESP Auth ==> 12 Byte
IPSEC Header ==> 20 Byte

[ATM / PPPOE]

PPPOE Header ==> 8 Byte
AAL5 Header ==> 10 Byte
AAL5 Trailer ==> 8 Byte

= 308 Byte Packet Size

==> wie viel ATM Zellen? ==> 308 / 48 Byte = 6,41 ==> let's pad ==> 7
==> 7 Zellen pro VoIP Paket
==> 7 * 53 ( 53 Byte Zellen mit overhead) ==> 371 Byte


==> Nun 20 ms Coderinterval ==> 50 pps
==> (371 *8) * 50 pps / 1000 ==> 148,4 kbit/s

Mit 448 kbit/s sollte das kein Problem sein.
Das Problem könnte unter Last das Delay sein (kleiner 784kbit/s Delay issue)

==> tune mss
==> tune per vc tx-ring (minimal 3)
==> check service-policy LLQ Bandbreite und Drops
!
int atm0
pvc x/y
tx-ring-limit 3
!

!
interf dialer 100
ip tcp adjust-mss 592
!
==> die class-maps solltest du natürlich ebenfalls anpassen (match-all)

ciao
–
Hola,

falls du ingress Klassifizieren willst

class-map match-all RTP
match protocol rtp
!
class-map match-all Skinny
match protocol skinny
!
policy-map MARK
class RTP
set dscp ef
clas Skinny
set dscp af31
!
interface vlan xxx
service-policy in MARK
!

==> die CCM Config muss RTP und Skinny markieren...

ciao

[daking]

Hola,

wie siehts nun aus? zwei calls sollten hier mit schlechter TCP Performance klappen. Die Frage ist nur was man plant und designt. Im optimalen Fall sollte der RT Traffic "nicht" den Datenverkehr "beeinflussen". 3M zu 500Kbit/s ist eher die Notlösung..

brgds

//

[DocZenith]

Moin!

@ Daking:

Das Projekt steht bei mir gerade still, wegen nem kurzfristigen anderen Problem. Ich werde erst in 3 Wochen weiter machen können :-(

Erst dann weiß ich weiter, und hab die ersten Ergebnisse beim Voice. Werde dich informieren.


Danke + Gruss.