Jump to content

daking

Members
  • Gesamte Inhalte

    595
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von daking

  1. Hallo, wenn du die policy-map auf dem physikalischen Interface auf vlans matchen läßt und so die DSCP Werte setzt sollte das klappen. Wie schauts mit einer route-map mit set tos aus? Ciao
  2. Hola, das QOS funktioniert nicht auf SubInterfaces , da diese keine Überlsat erkennen. Du kannst jedoch auf dem physikalischen Interface bei (sehr) aktuellen IOS Versionen match vlan machen... Das Klassifizieren solltest du Eingangseitig machen. Wie schaut die Config aus? Ciao
  3. daking

    3750 und VRF

    na ja wenns spaß macht....
  4. daking

    3750 und VRF

    Hallo, wie hast du virtuelle RIBs und FIBs physikalisch vernetzt? Die IPS in einem Subnet kannst du nicht pingen, wenn diese in verschiedenen VRFs sind (dabei gehts bei vrf). Jede VRF generiert einen eigenen ARP /FIB /RIP usw. Table. .. Ciao
  5. Hallo, Available Bandwidth 6720 kilobits/sec ==> maximal kannst du 75 % (max-reserve-bandwidth) für das queueing verwenden. Die Ausgabe sollte dir die Restbandbreite, die du noch für Queueing verwenden kannst anzeigen. Das von Dir konfigurierte QOS wird jedoch nie funktionieren, da 1. Der Dialer ein virtuelles Interface ist und keine Überlast merkt. 2. Du eigentlich 100Mbit zur Verfügung hast (FastEthernet) und diese nie auslasten wirst (Das ADSL Modem ist der Flaschenhals) ==> Das Bandwidth Kommando setzt nur einen Wert mit dem gerechnet wird. Das hat nichts mit der eigentlichen Bandbreite zu tun. ==> Hier mußt du ein hierachisches Qeueuing konfigurieren! policy-map Shape_first shape average 16000000 service-policy QOS ! policy-map QOS class VoIP priority percent 33 class Upload --> Uploadrate anpassen police xxx class Web bandwidth xx class class-default fair-queue ! int dialer 1 service-policy output Shape_first ! Cisco IOS Quality of Service Solutions Command Reference, Release 12.3 - Quality of Service Commands, 12.3: show queue through vc-hold-queue [Cisco IOS Software Releases 12.3 Mainline] - Cisco Systems ==> nun kann der Dialer Überlast erkennen! Ciao
  6. daking

    3750 und VRF

    Hallo, die Konfiguration ist etwas komisch. Was wolltest du da pingen? Eigentlich solltest du nur die IPs in der Test1 vrf instanz pingen können (untereinander). Die anderen haben keine Routen und kennen sich nicht. Grundsätzlich kannst du nur durch route leaking zwischen den einzelnen VRFs / Kunden routen. Auch die OSPF Prozesse der VRFs sind unabhängig und sollten sich (ohne gebastel) nicht untereinander sehen, denke du hast ein IOS benutzt, dass nicht OSPF vrf-aware ist.. Wie hat die gesamte config ausgesehen?
  7. Hallo, so stellt sich das Cisco vor: CAT2970(config)#mls qos map policed-dscp 0 24 46 to 8 ! Excess traffic marked 0 or CS3 or EF will be remarked to CS1 CAT2970(config)# CAT2970(config)#class-map match-all SOFTPHONE-VOICE CAT2970(config-cmap)# match access-group name SOFTPHONE-VOICE CAT2970(config-cmap)#class-map match-all SOFTPHONE-SIGNALING CAT2970(config-cmap)# match access-group name SOFTPHONE-SIGNALING CAT2970(config-cmap)#exit CAT2970(config)# CAT2970(config)#policy-map SOFTPHONE-PC CAT2970(config-pmap)#class SOFTPHONE-VOICE CAT2970(config-pmap-c)# set ip dscp 46 ! Softphone VoIP is marked DSCP EF CAT2970(config-pmap-c)# police 128000 8000 exceed-action policed-dscp-transmit ! Out-of-profile SoftPhone VoIP is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class SOFTPHONE-SIGNALING CAT2970(config-pmap-c)# set ip dscp 24 ! Call-Signaling is marked DSCP CS3 CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Out-of-profile SoftPhone Signaling is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class class-default CAT2970(config-pmap-c)# set ip dscp 0 CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT2970(config-pmap-c)# exit CAT2970(config-pmap)#exit CAT2970(config)# CAT2970(config)#interface GigabitEthernet0/1 CAT2970(config-if)# service-policy input SOFTPHONE-PC CAT2970(config-if)#exit CAT2970(config)# CAT2970(config)#ip access-list extended SOFTPHONE-VOICE CAT2970(config-ext-nacl)# permit udp any any range 16384 32767 ! VoIP ports CAT2970(config-ext-nacl)# CAT2970(config-ext-nacl)#ip access-list extended SOFTPHONE-SIGNALING CAT2970(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP ports Ciao Thomas
  8. Hallo, setze ich keine prio queue, so würden die shaped u. shared werte der ehemaligen prio-queue wieder in die aufteilung mit einbezogen werden, richtig? ==> richtig nehmen wir mal an, ich hab für jede der 4 Queues Traffic parat, auch so das jede ausgelastet wäre, dann käme die bandbreitenaufteilung in kraft, wie ich sie mit "srr-queue bandwidth share 10 10 50 30" konfiguriert habe. ==> fast richtig. ist jedoch keine bandbreitenaufteilung sondern "nur" custom queueing. Die Werte bestimmen, wie oft x Bytes aus der Queue genommen werden dürfen. Alle Queues werden somit x mal abgearbeitet ==> TCP Sessions werden nicht ganz runter gezogen. Du kannst jedoch nicht sagen, dass die Q3 50% der Bandbreite bekommt. tritt nun der fall ein, das queue 1 keinen entsprechend für sich klassifizierten traffic erhält, bleibt ihr trotzdem die zugesicherte bandbreite (srr-queue bandwidth shape 10 0 0 0) erhalten, passiert das analog mit q2,3 oder 4, stellen die ihre nicht genutzt bandbreite zur verfügung. so hätte ich das verstanden. ==> (fast) richtig. Falls keine Überlast vorhanden ist und alle verschiedenen Classifier erfüllt werden, werden jedoch keine Queues angezogen ==> es gibt keinen Grund QOS zu verwenden, da nichts gepuffert werden muss. Falls Überlast vorhanden ist und in einer Q nichts vorhanden ist, werden die weights aufgeteilt. Mit dem shape kommando wird keine Bandbreite reserviert oder Streams priorisiert. Hierbei wird der Traffic nur gebremst (shaping). Das Shaping erzeugt künstlich eine Überlast bei 90% der Bandbreite. Die Q1 würde früher die QOS Mechanismen aktivieren als die anderen Q. Diese Konfiguration ist mit VoIP ohne spq absoluter Schwachsinn (hier. nicht bei DSL verbindung ==> hierachisches Queueing). und zu den policers: gibts denn da erfahrungswerte ohne ähnliches? ab welcher rate oder burst-size würde man voip sprach-paketen "sagen" ihr seid out-of-profile, und ich werte sie ab? in meinen augen bringt das insofern keinen vorteil, da die pakete nun einen noch größeren risiko ausgeliefert sind "zu spät" anzukommen oder gar nicht. ==> wenn du LLQ mit Cisco Routern konfigurierst wird alles über der priority bandwidth durch den integrierten policer gedroppt. Die Bandbreite muß somit sauber kalkuliert werden. Der Einsatz eines Policer wird nie Pakete verzögern. Wenn die max Bandbreite überschritten wird, werden die Pakete gedropped oder neu markiert. Für VoIP ist ein remarking durch eine policer nicht sinnvoll, da Delay, Jitter und PKT Loss Werte stabil seien müssen. Da sollen eher andere Anwendungen (non udp) leiden ==> managing the unfairness.. Sinnvoll ist der Einsatz von Policern mit Softphones ==> da sind einige Networkers 2005 Präsentationen interessant... dann dazugehörige policy map, wo ich diesen traffic nochmal explizit mit den dscp werten markiere, sie jedoch herabstufe wenn rtp-traffic werte von 320.000bps und 8000byte burstsize überschreitet. (analog dazu voice control traffic nur 32.000bps). ==> die kalkulierten Werte können nicht überschritten werden, da sonst falsch kalkuliert wurde (WAN). Da solltest du eher die Thresholds der Queues anpassen, um schon vor der Entstehung des Probelms (kann bei konfigurierter spq eh nicht passieren) die uninteressanet Q präventiv droppen lassen ((W)RED). Im LAN Umfeld ist die Reservierung von Bandbreite für VoIP eher uninteressant, da durch das geringe Queueing und Serialization Delay (GBit/10Gbit) der Einsatz von Strict Priority Queueing (spq) keine Probleme macht. Bei einer Neuinstallation müssen so oder so vorher die vorhandenen Backplane, Uplink Bandbreiten mit den angeschlossenen Komponenten + VoIP überprüft werden. QOS bringt nur in guten Designs etwas (was passiert in Extermfällen ==> Virus..). ==> Only use QoS to make a good situation better. Never use QoS hoping to improve a poor or marginal situation to “good enough.” Ciao
  9. Hola @ fu123: stimmt! thanks! Ciao
  10. Hallo, sehe ich auch so. Selten (gar nicht), dass in den endlosen Cisco Regalen daheim ein GE Book auftaucht… Ciao
  11. Hallo, was soll optimiert werden? wo ist das Problem? Ciao
  12. Hallo, gibt es da eine Übersicht über die Werte und was die genau machen? Thanks Ciao
  13. Hallo, natürlich, so ist die Definition. Hier wird dieses Feature jedoch nur für Redundanz "vergewaltigt"... Diese Lösung funktioniert jedoch nur für nicht bidirektionales PIM. Hier die Lösung für bidir PIM (Phantom RPs) ==>" eine bidir RP muss nicht physikalisch oder logisch vorhanden sein" ==> ?? (;-) hier mit statischen Routen: RTR1: ------------------ ip multicast-routing ! interface Loopback0 ip address 192.168.1.1 255.255.255.255 ip pim sparse-mode ! ip route 1.1.1.1 255.255.255.255 loopback0 ip pim bidir-enable ip pim rp-address 1.1.1.1 RTR2: ------------------ ip multicast-routing ! interface Loopback0 ip address 192.168.1.2 255.255.255.255 ip pim sparse-mode ! ip route 1.1.1.1 255.255.255.254 loopback0 ip pim bidir-enable ip pim rp-address 1.1.1.1 Ciao
  14. Hallo, #nur mal 1 Beispielport an dem ein nicht Cisco IP-Phone hängt, vorausgesetzt, das #Telefon unterstützt CoS, ansonsten wäre trust dscp wohl ==> das Phone muss 802.1Q Tagging unterstützen, um eine Trust Boundary zu erzeugen,da sonst jeder PC mit DSCP 46 in die SPQ kommen würde. #oder doch besser trust cos auf den gigabit ports? ==> nach cisco design guides ist auf uplinks trust dscp besser. Bei einigen Switches gab es auch Probleme mit trust cos (3750). #ist ne Prio-Queue überhaupt ratsam? und mit dem Threshold u. Puffer Werten bin ich mir #auch nicht wirklich sicher. gibts denn irgendwelche erfahrungswerte bzw berechnungen, #wie man sowas optimal aufteilt? ==> die input queues benutzte ich nicht, da die phones einen integrierten policer haben sollten, der das "Überleben" des Phones sichern sollte. Ich habe auch keine Messungen mit angepassten Inputqueues durchgeführt. #arbeitet Queue 1 nun nur im shaped Mode oder in beiden Modi (shaped und shared), #wenn ja, würde Q1 nun doch mehr als 10% der Bandbreite bekommen, falls die anderen #Queues leer sind? bin aus cisco guide nich so recht schlau geworden ==> Das gesamte Queueing zieht nur wenn Überlast auf der Schnittstelle entsteht, sprich gepuffert werden muss. Das shaping und sharing (custom-qeueing) zieht in Q1 nur , wenn priority-queue out nicht gesetzt ist. Falls du nur zwei Datentypen hast (Voice und Data) zieht das custom-qeueuing nicht, da nur eine Klasse in diesem Modus betrieben wird. Falls du zwei Datentypen hättest. Teilt sich die Gewichtung der Queues auf (eine wird dann nicht benutzt). Falls du Shaping aktiviert hast wird die Queue auch bei nicht vorhandenen Traffic in den anderen Queues delayed (10 = 90 Teile der Bandbreite der Queue ==> ist bei dem 3(5/7)xx Series sehr ungenau. #und noch prio-schlangen zugeordnet (Q1 wird hier Prio Queue), auch hier die Frage, ist #das sinnvoll? ==> Für VoIP ist ein xPxQxT (wichtig ist das P) Vorraussetzung zu Beitrag 2 Teil1: class und policy-maps machen bei Softphones sinn, da dort 1. keine Trust Boundary gebildet werden kann und 2. andere Daten ein wenig gebremst werden können. mls qos trust device cisco-phone ==> richtig! Falls IPP CDP Pakete sendet wird dynamisch ein Trust Cos generiert. Ciao
  15. Hallo, es ist eine Multicast Domain. Hier nur mit Loadbalancing. Ciao
  16. Hola, Configuring a Rendezvous Point [iP Multicast] - Cisco Systems gleiche ips = kein problem (zwar Insellösung. wird jedoch über msdp synchronisiert). Ciao
  17. Hola, geht nicht ohne routing. da gibts noch ein paar andere Netze. danke ciao
  18. Hola, da sind patton smartnodes 2300 gut. ciao
  19. Hola, nein. ohne geht autorp nicht, da der RP (der nur virt ist) von autorp überschrieben werden soll. der wird nur falls alle rp weg sind genutzt, um fallback auf dense mode zu verhindern.. Warum sollte es da probleme mit routing geben ? Wenn du eine saubere Konfiguration haben willst, mußt du mit autorp mehr konfigurieren (mit älteren ios. dm-fallback..) Ciao
  20. Hola, sollte dann eigentlich seit 05 gefixt sein...CSCej50923.. Cioa
  21. Hallo, nun der zweite Versuch. Am WE habe ich das Heim/Testnetz auf IPv6 umgestellt, jedoch gibt es nun kleinere Probleme. Um das WLAN Interface des 867W Routers mit dem LAN zu verwenden habe ich eine bridge-group definiert. Die Konstellation funktioniert mit ipv4 ohne Probleme, da dort der Befehl bridge xxx route ip verfügbar ist ==> gibts jedoch kein bridge xxx route ipv6 (sollte es jedoch). ipv6 unicast-routing ipv6 general-prefix HOME xxxx:xxxx:xxxx::/64 ipv6 cef ipv6 multicast-routing interface Bvi xx ipv6 address HOME ::1/64 ipv6 address HOME ::100/64 anycast ipv6 enable no ipv6 redirects no ipv6 unreachables ! ipv6 route ::/0 Dialer100 .... ==>das Home pref wird an alle Clients verteilt ==>intern ist alles erreichbar ==> nur das BVI nicht (ist eigentlich klar da route ipv6 nicht da ist) ideas? erfahrungen? Hat schon jemand 6to4 Nat getestet? ipv6 nat v6v4 source list toNat6 interface Dialer100 overload ipv6 access-list toNat6 permit ipv6 xxxx:xxxx:xxxx::/64 any deny ipv6 any any TIA brgds Ciao
  22. hmm looks like. na ja dann noch mal.. ja das stimmt. so geht es bei einen Ausfall im ms Bereich ohne Fallback auf dense mode: 1. Anycast + AutoRP ******rtr1-rp******************************* interface loopback 1 decsription Anycast RP 1 ip address 192.168.99.1 255.255.255.255 ip pim sparse-dense-mode <neues-ios: ip pim sparse-mode> ! interface loopback 99 decsription MSDP Tunnel Source ip address 172.16.100.1 255.255.255.255 ip pim sparse-dense-mode <neues-ios: ip pim sparse-mode> ! ip pim send-rp-announce loopback 1 scope <TTL> group-list <flt-acl-nr> ip pim send-rp-discovery loopback 1 scope <TTL> <ip pim accept ...> ip msdp peer 172.16.100.2 255.255.255.255 connect-source loopback 99 ip msdp peer origin loopack 99 ****************** ******rtr2-rp******************************* interface loopback 1 decsription Anycast RP 1 ip address 192.168.99.1 255.255.255.255 ip pim sparse-dense-mode <neues-ios: ip pim sparse-mode> ! interface loopback 99 decsription MSDP Tunnel Source ip address 172.16.100.2 255.255.255.255 ip pim sparse-dense-mode <neues-ios: ip pim sparse-mode> ! ip pim send-rp-announce loopback 1 scope <TTL> group-list <flt-acl-nr> ip pim send-rp-discovery loopback 1 scope <TTL> <ip pim accept ...> ip msdp peer 172.16.100.1 255.255.255.255 connect-source loopback 99 ip msdp peer origin loopack 99 ****************** nun noch auf allen Routern das dm Fallback aktivieren: <altes ios: all int in ip pim sparse-dense-m> ip pim rp-address 1.1.1.1 10 <nicht vorhanden> access-list 10 deny 224.0.1.39 access-list 10 deny 224.0.1.40 access-list 10 permit any ==> ohne ACL geht auto rp nicht mehr. <neues ios: all int in ip pim sparse-m> ip pim autorp-listener no ip pim dm-fallback ==> Die Loopbacks müssen ins routing übernommen werden ==> MC Informationen werden zwischen beiden RPs über den MSDP Tunnel ausgetauscht. ==> bei bidirektionalen PIM klappt das so nicht.. (Phantomas) Ciao
  23. Hola, Verhalten mit SupplicantMode=1: |Time | Cisco_12:0c:1a | Spanning-tree-(for-bridges)_03| Ibm_2d:50:31 | |1,075 | Request, Identity [ | |EAP: Request, Identity [RFC3748] | |(0) ------------------> (0) | | |7,234 | | Response, Identity |EAP: Response, Identity [RFC3748] | | |(0) <------------------ (0) | |7,243 | Request, MD5-Challe | |EAP: Request, MD5-Challenge [RFC3748] | |(0) ------------------> (0) | | |7,246 | | Response, MD5-Chall |EAP: Response, MD5-Challenge [RFC3748] | | |(0) <------------------ (0) | |7,264 | Success | | |EAP: Success | |(0) ------------------> (0) | | ==> 7 Sekunden! BIG THAKS to fcernik ==> Hervorragend! Ciao Thomas
  24. Hola fu123, da hast du recht. MCAST kann sehr nervig sein. Folgende debugs sollten da hilfreich sein: debug ip mrouting (rpf-event|group) debug ip pim ... mtrace mrinfo sh ip rpf x.x.x.x sh ip mroute count hast du HSRP im Einsatz (PIM DR = höchste IP)? TTL zu klein? Mit BSR hast du (mit normalen timern) eine Umschaltzeit von 3Mins. Mit Auto-rp ohne Anycast RP auch sehr hohe Umschaltzeiten und die gefahr, dass die Gruppen ein fallback auf dense mode machen (mußte denke ich ip sparse-sende mode konfigurieren). So kann man das verhindern aktuelles IOS: no ip pim dm-fallback altes IOS (Fallback RP): ip pim rp-address <lokales_Loopback> 10 access-list 10 deny 224.0.1.39 access-list 10 deny 224.0.1.40 access-list 10 permit any ==> Falls nun der durch auto RP gewählte RP ausfällt wird das lokale Loopback zum RP und nichts wird geflooded (dann geht natürlich auch nichts mehr) ==> muß jedoch auf jedem Router konfiguriert werden. ==>doch lieber Sparse-Mode mit redundanten Anycast RPs (non bidir) ==>falls bidir redundante Phantom RPs Ciao
  25. Hallo, denke, dass keiner der Kurse das gibt was du haben willst ==> einen auf deine Fragen optimierten Workshop/Kurs ==> wir bieten so was an.. Ciao
×
×
  • Neu erstellen...