876 Router

[DocZenith 12]

@ wordo:

 

ok, glück gehabt, aber was mach ich falsch? ich bin davon ausgegangen, dass ich die atm schnittstelle anpassen muss, siehe:

 

routername(config-if)#dsl operating-mode ?

adsl2 adsl2 mode

adsl2+ adsl2+ mode

auto auto detect mode

etsi etsi mode

itu-dmt ITU full rate mode

 

 

oder bin ich hier total falsch? benötige hilfe :-)

[Wordo 11]

Mach einfach auto. Sieht bei mir genauso aus ...

[DocZenith 12]

Es steht auf auto, das ist ja das schlimme :-(

 

 

oh...man! ich habs hinbekommen! das atm interface war down! unglaublich, heute ist nicht mein tag, haha!

[Wordo 11]

Poste mal bitte:

 

sh run int atm0

 

und

 

sh dsl int atm0

[DocZenith 12]

Poste mal bitte:

 

sh run int atm0

 

und

 

sh dsl int atm0

 

Vergiss es einfach! Ich habs ja schon hinbekommen, das ATM Interface war einfach nur down, haha. geil! heute ist nicht mein tag :-)

 

aber trotzdem danke für die Hilfe!

 

gruss.

[DocZenith 12]

Hallo,

 

was verbirg sich eigentlich hinter

 

match qos-group 111 bzw. match access-group 111 ??

 

Ich versuch das gerade zu herauszufinden.

 

Gruss.

[Wordo 11]

Die ACL 111?

[DocZenith 12]

ja genau, den aufruf über access-group kannte ich, aber qos-group ist mir neu, ruft er damit die selbe acl auf?

[daking 10]

Hallo,

 

in meinem Fall "markiere" ich am eingangsinterface bestimmten Traffic, den ich nicht via DSCP Remarken will über die QOS Group. Diese "Markierung ist Router intern. Am Ausgangsinterface (hier NAT + IPSEC) kann ich die verschlüsselten Daten dan wieder finden und priorisieren.

 

Ist für die DSL QOS Funktion jedoch uninteressant.

 

 

ciao

[DocZenith 12]

@ daking:

 

kannst du mir das etwas näher bringen? :-)

 

In meinem Fall ist das evtl. auch interesant, da ich über ipsec ne verbindung zum firmencallmanager herstelle. hier am standort hängen mehrere Cisco IP Phones dran.

 

gruss.

[daking 10]

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 12]

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 10]

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 12]

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 10]

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