daking
-
Gesamte Inhalte
595 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von daking
-
-
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
-
Eine Frage, bzw. eure Meinung.
Mir wurde heute von einem Netzwerkadmin gesagt, das VLan-Trunking (802.1Q) im Widerspruch zu Port-Authentifizierung (802.1x) steht.
Ist dem so, und wenn ja warum eigentlich ?
Viele Grüsse
motzel
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:
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
-
-
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
Auslastung Throughput auf 6000 wie prüfen?
in Cisco Forum — Allgemein
Geschrieben
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