Cisco 3640, 2MBit, QoS für VoIP

[daking 10]

Hola,

 

nein da muss nichts dahinter.

 

was sagt sh ip cef (denke %cef is not running).

global: ip cef

auf dem interface: ip route-cache cef

 

Vielleicht hast du auf den Interfaces auch no ip route-cache configuriert => process switching

 

Ciao

[merlinab 10]

Hi Daking,

 

super, durch das "ip cef" und "ip route-cache cef" hat er nun auch das "ip nbar protocol-discovery" auf dem Ethernet gefuttert ;)

 

Nun muss ich mal schauen wie sich die Leitung bei Last reagiert. Kann ich irgendwie kontrollieren was so in der Que hängt? Ich hab schon etwas "show queue Serial1/0" gefunden, aber so recht schlau werde ich da jetzt nicht ;(

[daking 10]

Hola,

 

mit sh policy-map int ser 1/0 kannst du dir hits anzeigen lassen.

 

Ciao

[merlinab 10]

Hi daking

 

super danke dir vielmal. Und das soll jetzt wirklich bewirken, dass der VoIP-Traffic voran hat und sich so verhält als wäre die Leitung frei?

[daking 10]

Hola,

 

nach xxxxx VoIP Installation mit ein wenig mehr Komponenten. sollte das klappen.

nbar musst du noch checken => sh ip nbar proto (..discovery).

 

=> sollten dann hits bei rtp sein (wenn in der policy-map hits sind dann auch dort!)

 

Danach solltest du mit Qcheck noch mal die Verbindung prüfen (Jitter,Delay;Packet Loss => MOS or R Value) => besser noch mit NetIQ Chariot!!

 

Ciao

[daking 10]

FYI

 

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094660.shtml

 

Ciao

[merlinab 10]

Mit QCheck habe ich schon etwas rumgespielt und es ist etwas komisch da in der Regal alles top ist und der delay immer so unter 40ms aber manchmal gibt es unerklärliche Paketverluste und beim Telefonieren hab ich irgendwie ab uns zu mal unangenehmes knacken ;(

 

Kann ich mit QCheck auch ein MOS testen? Ist Chariot auch free?

 

Schade ist nur, das QCheck nur unter Win läuft. Ich bin hier dabei nen Asterisk aufzusetzen (und bin echt begeistert) und der läuft nun mal auf Linux so das ich nur so ungefähre Tests machen kann.

Was setzt du denn ein, klassisches Cisco Skinny?

 

Aber "show ip nbar proto" ist ja klasse - sowas hab ich schon wirklich gesucht um endlich herrzufinden was da eigendlich für der Traffic drauf geht ;-)

Aber irgendwie scheint da nur RTP bis jetzt eingekommen zu sein. Muss ich mal schauen, was morgen während des Tages abgeht:

Input Output

Protocol Packet Count Packet Count

Byte Count Byte Count

5 minute bit rate (bps) 5 minute bit rate (bps)

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

rtp 731 0

70971 0

0 0

 

Bei der Police-map sieht das schon gar nicht so schlecht aus:

Class-map: VoIP-RTP (match-all)

729 packets, 63503 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: protocol rtp

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 33 (%)

Bandwidth 509 (kbps) Burst 12725 (Bytes)

(pkts matched/bytes matched) 126/10923

(total drops/bytes drops) 0/0

 

Nun muss ich mal schauen was morgen so abgeht und hoffen das ich das auf auf der anderen Seite realisierbar ist. Wahrscheinlich brauche ich da erstmal nen neues IOS für die schwache 1600 auf dieser Seite ;-((

[daking 10]

Hola,

 

1600 ist eher suboptimal für QOS! Musst mal schauen wie die CPU Auslastung unter Last sich verhält (no CPUHogs!) => Vorsicht! wenn es hier Probleme gibt wird auch der Datentraffic beeinflusst => service-policy runter!

In diesem Fall könntest du auf dem 1600 auch mal ip rtp priority <base udp> <range ports> ausprobieren.

Wenn du ein Knacken ohne Delay hasst muss das an Paketverlust liegen.Im Normallfall sollte das Endgerät dies durch ein Silence Paket (BFI = Bad Frame Interpolation) ausgleichen.Welche Endgeräte benutzt du.

Das Qcheck läuft auch auf Linux. Du musst dir den Endpoint von NetIQ für Linux herunterladen.

Steuern kannst du die Messung dann über das Qcheck Frontend (musst eben dann die Linuxserver als Enpoints eintragen). Mit Qcheck kannst du denke ich keine MOS oder R Value messsen. Chariot ist leider nicht frei und sehr teuer.

 

Für das Monitoring der QOS Werte kannst du auch den Cisco SAA hernehmen. Musst dann über SNMP (z.B. Mrtg) abfragen und kannst graphen über delay,jitter usw. erzeugen.

 

Engesetzt habe ich SIP,Skinny,UAUDP,H323,MGCP.... und nicht nur die *

 

Ciao and a nice Day

[daking 10]

Hola,

 

MOS Basics:

 

http://www.google.de/url?sa=t&ct=res&cd=4&url=http%3A//www.dpo.uab.edu/%7Ekalyan/MOS%2520Calculation.doc&ei=o2gmQ4fcI5yiQYD12OwN

 

Network parameter Good Acceptable Poor

Delay 0-150 ms 150-300 ms > 300 ms

Jitter 0-20 ms 20-50 ms > 50 ms

Loss 0-0.5 % 0.5-1.5% > 1.5%

 

And don't forget the effect of echo!

 

Ciao

[merlinab 10]

Hi,

Du bist auch Tag und Nacht Online ;-) Ich musste leider heute Vormittag zum Kunden...

 

Also wir haben folgende Kontelation: TK-Anlage von Agfeo --> Asterisk-Server --> Cisco Catalyst --> Cisco 3620 bzw 3640 --> 2MBIT --> 1600er --> dedizierte Standleitung nach Frankfurt --> 6 MBit DSL+Fastpath --> FirtzBox 7050 --> 2x ISDN-Telefone

 

Ich fahre zu mindestens auf unseren 3620/3640 Staitstiken via rrd über Mem und CPU der Ciscos und da ist denke ich noch ne menge luft. Wie das auf der 1600er aussieht muss ich erfragen. Solange die CPU der 1600er aber nicht am Limit ist - sollte das doch kein Problem geben, oder?

 

Mit "ip rtp priority" aktiviere ich doch ein Pririty Queing bei dem alle RTP-Pakete erst übertragen werden bevor irgendwas anderes dran kommt und wenn es viele RTP-Pakete gibt kommt eben nix anderes durch die Leitung, oder? Ist das CPU-Schonender?

 

Was meinst du mit Cisco SAA? Zurzeit monitore ich die Ciscos klassisch den Traffic mit MRTG und CPU/Mem mit RRD-Tools. Schön wäre wirklich ne nette RRD-Statistik über Infos wie: Delay, Packet Dropt, wieviel ist davon HTTP, SMTP, FTP, RTP, SIP, etc. Geht das mit SSA?

 

Ich glaube dann haben wir echt ein Problem mit Paketverlusten. Ich dachte immer so 1-2% wären OK. Im Ping habe ich eigendlich nur minimale Paketverluste zu verzeichnen aber ein Ping ist ja auch nicht soo auschlaggeben. Gibt´s ne bessere Methode?

[daking 10]

Hola,

 

bin wieder im Lande.

 

1. SAA + MRTG und NBAR + SNMP

http://www.cisco.com/en/US/partner/tech/tk869/tk769/technologies_white_paper09186a00801b1a1e.shtml

http://www.cisco.com/en/US/products/ps6616/products_white_paper09186a0080110040.shtml

 

zu nbar habe ich nichts detailiertes gefunden. Solltest einfach den CISCO-NBAR-PROTOCOL-DISCOVER-MIB ins mrtg mit einbeziehen!

 

=>Da geht einiges.

 

2. ip rtp priority

ist älter als CBWFQ + LLQ. Denke sollte auch auf dem 1600 besser funktionieren => ausprobieren.

 

3. packet loss

 

du musst herausfinden wo der packet loss passiert. Vielleicht gibt es irgendwo probleme mit Duplex/Speed Mismatch. Ist eigentlich der häufigste Fehler. Am besten mal einen Sniffertrace machen und die Werte überprüfen (Ethereal->Statistics->RTP->Show all streams). Dort siehst du, ob der Packet Loss nur in eine Richtung auftritt oder es Probleme mit Delay bzw. Jitter gibt. Vielleicht gibt es auch Probleme mit der De-/Kodierung (law,coder intervall..) zwischen den Komponenten (siehst du im Sniffertrace). Sinnvoll ist hier ein Gespräch an beiden Enden (* und FritzBox) aufzuzeichen.

 

Ciao

[merlinab 10]

zu 1)

Erste Link hat leider nen PW drauf - du hast das nicht zufällig als PDF oder so ;)

 

zu 2)

Hab leider noch nix von unserem Partner gehört - hoffe das das spätestens morgen was gibt

 

zu 3)

Jeap werde ich direkt mal testen. Was meinst du denn mit Duplex/Seed Mismatch?

Ich hab jetzt mal nen Testgespräch mitgedumpt und mit Ethrereal Analysiert. Ich wusste gar nicht, dass Ethereal auch so gut mit RTP klar kommt. Gefällt mir immer besser das Proggi ;)

Auf die forward ist alles top in ordnung (auch keine Kunst, hab das auf dem * mitgeloggt) und auf dem rev-Kanal 3463 RTP-Paketen 21 verluste und 8 seq fehler. Diesmal waren nur wenig, aber hörbares Knacken dabei... Jitter bleibt immer unter 0,00x und max delay ist 0,24 - klingt doch eigendlich gut, oder?

Aber ist schon erschreckend, wie easy man daraus ein .au File machen kann ;)

Ich denke ich werde morgen mal die FritzBox tauschen lassen...

Auf der anderen Seite (FritzBox) kann ich wohl nix mitdumpen da der Linux ja hinter der Fritzbox steht ;((

[merlinab 10]

Mist nbar via SNMP wird von meinem IOS c3620-ik9o3s7-mz.123-1a.bin nicht unterstützt, jedenfalls laut http://tools.cisco.com/Support/SNMP/do/MIBSupport.do?mibname=CISCO-NBAR-PROTOCOL-DISCOVERY-MIB

;-) - Schade wäre ja auch zu schön gewesen.

 

Weiß du eigendlich, ob ich das IOS von einer 3620 auf eine 3640 kopieren kann ohne probleme?

[daking 10]

Hola,

 

hörst du das knacken auch im .au file?

sind die G711 RTP Pakete gleich gross?

ist die law (alaw vs. mulaw) gleich?

hören beide seiten das knacken?

hörst du unter der kommunikation ein leises rauschen/brummen?

 

 

zu 1. richte dir einen cisco account ein => denke das doc sollte auch für CCO Accounts ohne Contract funzn => sonst noch mal melden.

 

IOS von 3620 auf 3640 kopieren sollte nicht klappen, da es dort jeweils eigene Images gibt.

 

Nach einem Duplex Mismatch oder Speed Mismatch hört sich das nicht an => dann sollten mehr pakete verloren gehen sollten.

 

 

device 1 device 2 real link state

1 auto–negotiation auto–negotiation 100–FULL

2 100–FULL auto–negotiation 100–HALF

3 100–HALF auto–negotiation 100–HALF

4 10–FULL auto–negotiation 10–HALF

5 10–HALF auto–negotiation 10–HALF

6 100–FULL 100–FULL 100–FULL

7 100–FULL 100–HALF 100–HALF

8 100–FULL 10–FULL no link

9 100–FULL 10–HALF no link

10 100–HALF 100–HALF 100–HALF

11 100–HALF 10–FULL no link

12 100–HALF 10–HALF no link

13 10–FULL 10–FULL 10–FULL

14 10–FULL 10–HALF 10–HALF

15 10–HALF 10–HALF 10–HALF

 

 

Ciao

[merlinab 10]

In diesem Beispiel waren relativ wenig Knacken drinne. Im AU File höre ich es wesendlich geringer als im Telefon (meine ich). Ich muss das aber morgen noch mal testen wo mehr Knacken auftritt - ich denke das ist nicht 100% represenatativ.

 

Interessanterweise sind die RTP-Pakete von der FirtzBox mit 294 Bytes größer als die von dem * mit 214 Bytes. (Ein paar dutzen überflogen)

 

Ja nen leichtes Rauschen hört man, aber das ist nicht besonders störend. Ich denke das ist extra so, damit es keine Totenstille gibt, oder?

 

Ob das ein A oder U Standard ist sehe ich hier leider nicht. Steht nur als Payload-Type: ITU.T G.711 PCMA (8)

 

Ja das Knacken ist auf beiden Seiten nur verhäuft auf der FritzBox Seite - deswegen auch der Verdacht das die ne Macke haben könnte, wobei ich glaube das wäre nur ein teil denn die Paketverluste versuche ich jetzt mal mit 24 Dauerpings zu beobachten...

 

Achso, ich dachte dafür muss man blechen oder nen Zertifikat haben um da rein zu kommen. Muss ich mal schauen ob die mir nen Login geben ;)

 

Also meinst du mit dem Dubley-Mixmatch also, das das Ethernet-Interface z.B. auf fulldublex läuft und der Switch das nicht packet?