#9370
-
Gesamte Inhalte
140 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von #9370
-
-
Am Ethernet eigentlich nicht. Du könntest mit "rate-limit" oder Policing arbeiten. Bei seriellen Verbindungen (mit DCE/DTE Kabeln) kannst du die BB vorgeben, was die sinnvollere Variante ist. Dort gibt es aber nur kBit/s und wenige MBit/s.
#9370
-
Falls das Log auf dem Switch aufgedreht ist, dann steht der Grund da drinnen (show logg). Ansonsten "logging buff 8000" am Switch konfigurieren und den Test noch einmal durchführen.
#9370
-
Hast du einen Trunk zum Switch? Dann könntest du Subinterfaces konfigurieren - jedes VLAN ist ein Intf. Ansonsten secondary Netze auf dem Interface. Da wird aber das dhcp nicht mitspielen.
Config mit Subinterfaces:
interface e0/0.1
ip address
encap dot1q 1
interface e0/0.2
ip add
encap dot1q 2
...
-
Check mal, ob die Firewalls ICMP unreachables durchlassen. Wenn das überall erlaubt ist und die Endgeräte darauf reagieren, sollte das DF Bit kein Problem mehr sein.
edit: Wordo war schneller.
-
Die Config müsste irgenwie so ausschauen (Ich habe jetzt gerade keinen Router zum Testen):
Die class-map Namen bei deinem letzten Post passen nicht zusammen.
class-map citrix
match access-group 150
policy-map policy1
class citrix
priority percent 50
class class-default
! fair-queue -> weglassen wenn nicht unterstützt; sollte nichts machen
interface Tu10
service-policy output policy1
Zu deiner anderen Frage: Wenn du Queue für die Default Klasse kleiner machst, dann können bei Last weniger Daten übertragen werden -> die anderen Queues haben mehr Bandbreite.
Du gibst der Priority Queue 95% der Bandbreite und der Default Queue 192kbps. 5% von 2MBit/s sind aber weniger als 192kBit/s.
Der Default Klasse wird normalerweise keine Bandbreite zugeordnet -> sie bekommt dann nur den Rest. Dann braucht man nicht herumrechnen.
-
Command Reference und Config Guide findest du auf CCO:
Catalyst 6500 Series Command Reference, 8.5 [Cisco Catalyst 6500 Series Switches] - Cisco Systems
Die einzige Plattform, die CatOS verwendet und noch nicht EoS ist, ist der Cat6k. Da kann man sich jetzt schon für IOS entscheiden.
-
Die strict priority Queue zieht, wie man in den show Ausgaben sehen kann. Du solltest das PPP LFI, wie von tom12 beschrieben, probieren.
Hast du LLQ auch in der Zentrale konfiguriert? Ein weitere Problem kann der Provider sein, da dort das Netz sicher überbucht ist und du keinen garantierten Service hast.
-
@ wordo: Das pre-classify wird bei VTIs nicht benötigt
@ maho: Beim 2. Link, den ich angegeben habe ist eine kurze Beispielconfig für LLQ und VTI ganz am Ende. Die muss nur auf Citrix angepasst werden.
Noch eine Frage: Wird eigentlich Citriy auch zum drucken verwendet, oder geht das über ein anderes Protokoll?
edit: die aktuelle Config wäre sehr hilfreich
-
was brauchst du da genau? Config Guide, Command Reference? Übersicht über Switching Technologien? Ein CatOS Buch fällt mir eigentlich nicht ein. Es gibt ein älteres LAN Switching Buch von Cisco Press, das sich mit IOS, CatOS und Grundlagen befasst.
#9370
P.S.: CatOS wird nicht mehr weiterentwickelt.
-
Ich würde da das Problem eher bei den Leitungen suchen. Für wichtigen, zeitkritischen Verkehr ist das Internet nicht die beste Wahl.
Eine andere Frage: Warum hast du für Citrix 95% Bandbreite konfiguriert? Ich kann auch die verschachtelten policy-maps nicht nachvollziehen. Ebenso wäre LLQ für zeitkritische Applikationnen die bessere Wahl. Wenn du wirklich 95% Citrix Verkehr hast, dann nützt nur noch ein Bandbreitenupgrade.
Vielleicht helfen folgende Links weiter:
-
am Switch muss nur eine RO Community angegeben werden. Das MRTG macht das dann automatisch. Du musst dir nur die gewünschten Interfaces aussuchen.
-
Im Normalfall kommst du mit älterer Hardware aus.
-
Das fin Timeout hat mit den Unterbrechungen sicher nichts zu tun, da zu dem Zeitpunkt die Verbindung schon regulär abgebaut wurde, nur werden die FINs nicht richtig oder zeitgerecht gesendet.
Wie schon von wordo gesagt: Welche IP Adressen stimmen?
Rein von den Logs würde ich auf ein anderes Problem tippen - Die Firewall bietet sich nur immer als Sündenbock an. Du könntest auch das capture Feature zum Fehlereingrenzen benutzen.
#9370
-
1) sollte mit jedem Switch funktionieren -> Einfach Portstatistik per snmp auslesen und den Rest erledigt MRTG. Achtung! Funktioniert nicht bei VLAN Interfaces!
2) irgendein CSS11xxx. Möglicherweise oversized.
#9370
crypto map mit 2 IPs
in Cisco Forum — Allgemein
Geschrieben
Auszug aus der Doku:
The default Keyword
If there are multiple peers and you specify the default keyword, the first peer is designated as the default peer.
If dead peer detection (DPD) detects a failure, the default peer is retried before there is an attempt to connect to the next peer in the peer list.
If the default peer is unresponsive, the next peer in the peer list becomes the new current peer. Future connections through the crypto map will try that peer.
#9370