daking

Hallo, Mtu Size Problem ? versuch mal ping -l <Byte>. Welche maximale Pkt Größe geht durch. Ciao

Hola, just for Info: in dieser Konstellation sollte OER auch hot sein! (geht jedoch auch erst ab 1700). sample: key chain key1 key 1 key-string oer oer master logging mode route control max prefix total 100 backoff 90 3000 300 border 10.10.10.1 key-chain key1 interface Ethernet1/0 internal interface Ethernet2/0 external --> Provider 1 max-xmit-utilization absolute 1000 --> wie viel Traffic hier interface Ethernet3/0 external --> Provider 2 max-xmit-utilization absolute 300 --> wie viel Traffic da learn throughput delay monitor-period 1 periodic-interval 0 oer border logging local Ethernet1/0 master 10.1.100.1 key-chain key1 --> der lokale Router interface Ethernet1/0 desc LAN ip address 10.1.100.1 255.255.255.0 interface Ethernet 2/0 desc Provider A load-interval 30 interface Ethernet 3/0 desc Provider B load-interval 30 ==> so sollte das in der Theorie klappen (;-) Ciao

Thanks! (war aber auch nicht in deiner geposteten Config (;-)) Ciao

Hola, nachdem Klingeln und dem Abheben ist der MediaChannel aufgebaut, d.h. die Sprachdaten werden via RTP mit übertragen. VPN Verbindungen erzeugen Overhead und somit auch Delay. Auch der Packet Loss Jitter steigt über öffentliche Netze. Über welche Umgebung sprechen wir hier (Bandbreite, Codec, VPN Typ , Framing, Anbindung).. welche Probleme (Hall/Echo, abgehackt, Walky-Talky, immer, nur am Anfang des Gesprächs..)? Ciao

Point-to-Multipoint TE •Increasing demand to support multicast flows with: High-rate sources (e.g., video/TV distribution) Network optimization (not all traffic on shortest path) QoS guarantees Fast restoration •This has led to demand for point-to-multipoint TE •Solutions currently being developed and standardized ==> •Point-to-multipoint Simple extensions to point-to-point RSVP-TE Support “provisioned” multicast with TE capabilities ==> das war die Übersicht der Networkers 2006 ==> habe keine Roadmaps gefunde ciao

Hallo ebenfalls ein gutes und (noch) erfolgreicheres Neues Jahr! Für SIP mußt du eigentlich nichts besonderes beachten. Sinnvoll ist hier zusätzlich Bandbreite in der LLQ zu reservieren (falls du die Daten hier behandeln willst). Natürlich solltest du die Daten richtig klassifizieren (DSCP 46 oder nbar match proto sip). Du kannst auch eine eigene Queue (ohne LLQ = bandwidth) für SIP reservieren (DSCP 24). ==> wie skinny, uaudp, h323, mgcp, cornet... Mit den aktuellen IOS Versionen kannst du auch NAT mit SIP (H323) machen (==> cool) Ciao

Hallo, okay 10 Mbit und für Voice 6 ms Delay für Voice. wie kommst du auf diese Werte (warum willst die haben?). Werden in deiner Config nicht voll ausgefüllte Zellen mit anderen Daten gefüllt oder entsteht hier Overhead (Padding)? Ciao

Hola, auf Ethernet usw. Interfaces hat das bis jetzt noch keine Probleme gemacht (LLQ ==> außer die IOS Sw war *****. siehe vrf). Denke, dass das LLQ scheinbar nicht auf ATM Interfaces in der aktuellen HW funzt (habe das gleiche Problem mit den kleinen 87x Routern und DSL Interfaces). QOS wird nur benötigt, wenn ein physikalisches Interface die Bandbreite nicht mehr handeln kann, sprich Packete in den Speicher geschrieben werden müssen und dort unterschiedlich behandelt werden können (LLQ..CQ..WFQ.PQ). Auf dem tx ring geht das nicht mehr! wie groß ist der bei dir? welche bandbreite hat dein interface? hast du schon mal ohne percent gearbeitet? Mit welchen Tools hast du das validiert (Netiq + SmartBits?) Ciao

hallo, http://256.1.1.23/index.pdf auch keine Verbindung?! brgds

@Fu: danke für den Tipp!!! cool!! gleich auf dem Server aktiviert! IP/IPv6/MPLS alles funzt ==> krank! Ciao

Hola, non supplicant authentication ist auch mit cisco möglich.. Catalyst 2960 Switch Software Configuration Guide, 12.2(25)SEE - Configuring IEEE 802.1x Port-Based Authentication [Cisco Catalyst 2960 Series Switches] - Cisco Systems Using IEEE 802.1x Authentication with MAC Authentication Bypass ==> Das Delay sollte jedoch relativ hoch sein (ca. 30s) ==> DHCP könnte da Probleme haben.. Automatische Vlan Zuweisung klappt auch. Ciao

Hallo, mit Cisco hast du mit zwei links Ausfallsicherheit und load-balancing. load-balancing: Die Frage ist nun wie der Channel die Aufteilung auf die Links macht: Native(config)# port-channel load-balance ? dst-ip Dst IP Addr dst-mac Dst Mac Addr dst-port Dst TCP/UDP Port src-dst-ip Src XOR Dst IP Addr src-dst-mac Src XOR Dst Mac Addr src-dst-port Src XOR Dst TCP/UDP Port src-ip Src IP Addr src-mac Src Mac Addr src-port Src TCP/UDP Port falls dest-ip: ==> hättest du nur einen Server würde alle Anfragen über einen Link gehen. Die Antworten würden dann aufgeteilt werden. Ausfallsicherheit. Falls ein Link abgezogen wird, übernimmt der andere. Die aktuell auf dem Link vorhandene Verbindung würde verloren gehen. Alle neuen Session werden dann über den noch vorhandenen Link gesendet. Die Überlastsituation bei Ausfall eines Links müsste dann mit QOS abgefangen werden. Ciao

Hola, ok - config ist auf der ersten seite.. Klappts ohne die vrf config? Ciao

Hola, wie ist das setup. vpdn benötigst du oft (kannst du nicht konfigurieren) nicht.. Ciao

Hola ich hoffe du hast die prio runter und nicht hoch gesetzt... Ciao

Hallo, Qos schon xmal validiert..

Hallo, config? Thanks brgds

Hallo, auf welcher HW hast du das wie konfiguriert? Welches IOS ==> mehr Infos==> weniger diskussion! Ciao

Hallo, mehr infos wären nicht schlecht (was ist die gegendeite? bierkasten?) ==> route-maps falls cisco. ciao

Hola, ok. sorry. Ciao

Hola, Aha! und was für eine Sprachqualität ist denn bei 0,9% Packetloss zu erwarten? ISDN-Qualität, Analog, HIFI? Das kannst du doch gar nicht beantworten, anhand einer Messung mit Wireshark. ==> ist auch uninteressant, da es bestimmte Grenzwerte gibt um Sprachverbindungen zu bewerten. Interessant wäre hier der MOS der Verbindung der durch die fehlende Jittermessung (RFC 1899 nicht maximum Jitter) nicht berechnet werden kann. Jedoch ist es im Fehlerfall (das Problem ist eingegrenzt) möglich Probleme zu erkennen (PKT Loss, Delay). Auch kann der aufgezeichnete Stream abgespielt werden und mit dem Analystenohr ausgewertet werden. Nach ITU G.107 sollte der PKT Loss kleiner als 1 % sein. In LAN / WAN Umgebungen mit optimierten queueing muss der PKT Loss 0 % ==> wird mit Wireshark PKT Loss gemessen, ist etwas suboptial konfiguriert / designed. Mit Wireshark + Cooledit können zum Beispiel perfekt Echo Messungen gemacht werden. Ob das HIFI oder ANALOG ist kann die NetIQ, AVISO.. auch nicht beantworten. Schon gar nicht ist eine Prognose möglich (mittagszeit alles tolll - morgens um 10 voll b.... nachmittags mittelmässig). ==> Mag richtig sein, da die Datenmenge sehr groß werden würde. Hier würden sich IP Qos tickets (Alcatel) oder CDR (Cisco) oder... anbieten. Grundsätzlich muss bei derartigen Fehlern ein schlechtes Design zu Grunde liegen. In der Konzeptphase müssen SPQ/LLQ fähige Komponenten ausgewählt werden und die benötigte Bandbreiten für VoIP kalkuliert/definiert werden. Oder kommt da etwa noch der Komprimierungscodec ins Spiel? Macht die VoiP Anlage G729 oder G.723 ....? Und was bedeutet das dann für die o.g. Variablen? ==> Bei G.723 geht bei Paketverlust durch das 30 ms Framing mehr Sprachinformation verloren ==> schlechtere Sprachqualität (vielleicht kein Knacken da PLC) Bei G.729 / G.711 mit 20 ms Framing (sollte so eingestellt werden) weniger Informationsverlust. Gundsätzlich kann man sagen, dass bei Komprimierung die MOS schneller sinkt als bei unkomprimierten Codecs, da die maximalen möglichen MOS niedriger ist: G.711 => max MOS 4.4 G.729 => max MOS 4.07 G.723 => max MOS 3.69 Die Grenzen liegen bei: Toll Quality (MOS > 4,3) – Very satisfied Users - Prozentualer Paketverlust < 1 % - Verzögerungszeit Ende zu Ende < 150 ms - Jitter < 20 ms Near Toll Quality (4,0 < MOS <4,2) - Satisfied Users - Prozentualer Paketverlust < 3 % - Verzögerungszeit Ende zu Ende < 400 ms - Jitter < 50 ms Best Effort (MOS < 4,0) – not recommended - Prozentualer Paketverlust < 5 % - Verzögerungszeit Ende zu Ende < 600 ms - Jitter < 75 ms ...Genau! ==> hier richtig Ciao

Hola, @123meins: für solche Messungen (Audit VoIP) solltest du dann doch die Profis antreten lassen (;-). Ciao

Hallo, Und wer davon kann Aussagen über Delay, Jitter und ähnliche Variablen treffenb, die man übersichtlich sieht (in einem RTP Stream im Wireshark wohl kaum).... ==> Falsch ==> Außer Jitter ist mit Wireshark alles (Delay, Pkt Loss) sehr gut zu analysieren. Was willst du denn aus einer Aussage wie "Ich habe 5 % Packet Loss bei RTP Streaming" für einen Schluss hinsichtlich der zu erwartenden Sprachqualität machen ==> Ist eigenltich sehr einfach. Nach ITU P.800 / P.862 oder ITU G.107 Rec sollte der Paketverlust kleiner als 1% sein. Die Sprachqualität wird somit keine Toll-Quality erreichen. Nebeneffeckte wir abgehackte, oder leise Spracheverbindungen (bei Bad Frame Interpolation) sind zu erwarten. Falls du eine optimale Messung haben willst, benutze NetiQ Chariot! Ciao

Hola, ..:: vs ::.. [Volker Semken]. Ciao

Hallo, das hat nichts mit Routing zu tun. Mit dem spt cost Befehl kannst du die Layer 2 Topologie verändern, d.h welcher Link auf blocking geht ==> welchen Weg der traffic in einem L2 Segment mit Loops nimmt. Ciao