daking

Hola, wie schaut es bei euch mit dem Service aus. Was ist wenn der Switch den Geist auf gibt? => kein Support => keine Ersatzteile......EOS EOL http://www.cisco.com/en/US/partner/products/hw/switches/ps700/prod_eol_notices_list.html Die Aus (Über)lastung des Switches kann durch Analyse der Queue Drops, CPU Statistics und Analyse der Application Response Time der Anwendungen (falls die Server sauber laufen) festgestellt werden. Ciao

tolle Zeichnung

Hola, na ja. hier ein Versuch: der cat2950 kann intern (MAC Adressen des Switches für SPT oder bei L3 Interfaces für VLAN Interfaces) 64 MAC Adressen verwalten, d.h. wenn du über 64 Vlans kommst sind keine MAC Adressen für SPT mehr vorhanden. Du kannst also mit dem "normalen" 802.1D (PVST+) oder etwas neueren 802.1W nur 64 VLANS aktiv im STP haben. Hier die Möglichkeiten für ein Workaround: 1. ohne STP Arbeiten Wenn du eine redundante Infrastruktur (AccessLayer -> Distribution Layer --> opt. Core) hast und die Switche der AccessLayer an Layer 3 fähige DistributionLayer Switches terminieren, könnstest du zwischen den beiden redundanten DistributionLayer Switches ein e routinginstanz konfigurieren und so den ohne STP entstehenden Loopauftrennen: ------------------------------- | ACCESSLAYER | ------------------------------- | | | | L2 | | L2 | | | | HSRP | | HSRP -------------------------- L3 PP -------------------------- | DLayer1 |-----------------------------------| DLayer2 | -------------------------- ------------------------- | | | | to Core to Core => no need for SPT => mit mehr als einen AccessLayer Switch ist dieses Design eher suboptimal, da du dann eine Insellösung erstellst! 2. MSTP (802.1s) Hier kannst du (in diesen Fall) mehrer VLANs zu einer STP Regin zusammenfassen, d.h. z.B. vlan 100 101 und 200 benutzen zusammen eine STP. Nachteil: knallst in einem Vlan werden alle anderen auch gestört => 60s konvergenz bei 802.1D. Solltest also z.B. die SRV VLANs zusammenfassen, da es dort bei einer Verfügbarkeit von 99,999999% im Jahr eigentlich nicht zu Problemen kommen sollte. Hoffe das hilft (werde auch noch ein wenig wegen den 2950 Switches weiter forschen) P.S. Wie willst du eigentlich bei einem "Gummibären Switch" für die AccessLayer mit max 48 Ports mehr als 64 STP Instanzen haben? Dieser Switch ist für den (ich weiß ich wiederhole mich) AcessLayer optimiert! Vielleicht solltest du auch von dem nicht benötigten VTP weg und das Netzwerkdesign etwas tunen! Das Netzwerk sollte dann schon "state of the art" sein! Ciao

Hola, da währe ein one to many NAT aufs ethernet 0/1 interface schon sinnvol. Sonst wird die Gegenseite, in diesem Fall http://www.google.de, den Weg in dein privates Netz nicht finden. ip nat inside source list 15 interface Ethernet0/1 overload access-list 15 permit 192.168.17.0 0.0.0.128 int e0/0 ip nat inside int e 0/1 ip nat outside ip route 0.0.0.0 0.0.0.0 int e0/1 Ciao Ciao

Hola, normalerweise setzen die Endgeräte (Phone/TK...) die DSCP (Layer 3) oder COS Werte (Layer2). In einer Cisco Umgebung wird für RTP Streams Cos 5 oder DSCP 46 gesetzt. Für Signalling Cos 3 und (denke ich) DSCP 26. In der WLAN Umgebung müssen diese Werte jedoch auf Cos 6 umgesetzt werden (das sieht du mit sh controllers int d0). Dafür gibt es ein Feature auf den Aps die diese Umsetzung realisieren. Das 7920 unterstützt nur das Marking der RTP Pakete mit COS 6 + DSCP 46. Mit den Aps funzt nur "Soft QOS", d.h. nur Priorisierung in Richtung 7920 (nicht in Richtung Endgerät). Die "Bible" die dur hier benutzen solltest ist der 7920 Design Guide...(findest du mit Sicherheit auf der Cisco Seite).. Ciao

Hola, mir deiner Frage kann ich leider nichts anfangen? Vielleicht kannst du deine Frage ein wenig technischer formulieren. Danke Ciao

Hola, my Setup: Smartbits für Last NetIQ Chariot zum simulieren von VoIP Calls oder Video Streams Ciao

Hola, @IWS-Germany was meinst du mit alte running-config löschen? eher alte startup-config löschen! wenn du die "alte" "aktuelle " Config im Speicher (DRAM) löscht ist das Device platt => bis zum Reboot (da die NVRAM Config ja noch da ist). Merged Config gibts in diesem Fall (startup überschreiben) nicht. Nur bei Copy n Paste Helden passiert das. => mmuelleh so solltedas klappen, falls die config vorher getestet wurde! Ciao

Hola, die FritzBox sollte G.729 und G.723 unterstützen: http://www.nwlab.net/rev/fritzboxfon/ du kannst es nur nicht auf der FritzBox Seite einstellen. Wenn du jedoch an der Asterisk z.B. nur G.729 oder G.723 freigibst, dann muss/sollte sich die FritzBox fügen! Ciao

Hola, PING: --> bei keiner Last keinen Paket Verlust --> bei hoher Last (Überlast) viel Paket Verlust ==> ping ist kein Tool zum Feststellen der Qualität der Leitung. Nur zum Testen von Erreichbarkeit der Komponenten. Da sollte mit Windows Boardmittel pathping besser sein! 1. packet size 214 Bytes = 20ms Coder Intervall 294 Bytes = 30ms Coder intervall (denke ich) =>FritzBox auf 20ms umstellen!? (sollte vielleicht bei Advanced sein) =>Asterisk=>Various clients support variable sample periods / packetization. Asterisk only supports 20ms packetization in RTP-based protocols like SIP and MGCP, so you should configure your client to use this!! 2. LAW PCM<A> =Alaw PCM<U> = Mulaw beide Seiten gleich? Ciao

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

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

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

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

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

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

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

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

Hola, auf beiden seiten ist sinnvoll. sonst einseitig schlechte kommunikation.. Ciao

Hola, welche hardware? was sagt sh log sh dialer usw. was heißt nicht mehr einwählt? (L1/L2/L3?) => debug isdn q931/q921 =>debug dialer =>andere IOS SW ausprobieren =>andere Hardware ausprobieren Ciao

Hola, ist einfach zu konfigurieren: ------>*------->fa0/1------>ser0----->wan auf dem fa0/1 aktivierst du nbar mit: ip nbar protocol-discovery ! anstatt match ip dscp ef einfach match protocol rtp angeben => fertig Ciao

Hola, 40KByte/s = 320 Kbit/s 1 flow G.711 mit 20ms coder intervall für ppp = 162,6 (für duplex kommunikation) => sehr knappe zwei gespräche... => 1 flow G.711 mit rtp header compression für ppp = 132,8 = 2 Gespräche => G.729 mit 20ms bei ppp + rtp header compression => 23,4 => 13 Gespräche Ciao

Hola, TOS = 8 Bit DSCP = 6 Bit 101110 = 46 = DSCP 10111000 = 184 = TOS Der RTP Traffic muss mit DSCP 46 kommen, dass er priorisiert werden kann. Die Signalisierund sollte mit DSCP AF32 = Assured Forwarding 31 ankommen. so sollte das mit iptables klappen iptables -A OUTPUT -t mangle -p udp -m udp --dport 5060 -j DSCP --set-dscp 0x68 iptables -A OUTPUT -t mangle -p udp -m udp --sport 10000:20000 -j DSCP --set-dscp 0xB8 nbar: Das Cisco nbar Feature kennt mehrere Protokolle (auch rtp). Dann kannst du in der class-map anstatt match ip dscp 46 z.B. match protocol rtp angeben. Ciao

Hola, don't forget: wenn du die Variante mit DSCP nimmst, müssen die zu priorisierenden Komponenten diese Werte auch setzen (normalerweise 46 für RTP)! ausserdem könntest du auch nbar konfigurieren, dann kannst du nach Protokollen priorisieren. Ciao

Hola, nachdem du die Config generiert hast, kannst du das Queueing mit QCheck (free!!) http://www.netiq.com/qcheck/default.asp überprüfen. Ciao