glady 10 Geschrieben 19. Januar 2007 Melden Teilen Geschrieben 19. Januar 2007 Hallo, Kunden melden sporadisch Tastaturverzögerungen über ihre Citrixsessions. Die Umgebung sieht folgendermaßen aus: In der Zentrale VPN-Router mit VPN-VTI-Konfiguration, 34Mbit Internetanschluss Aussenstelle C876 mit VPN-VTI-Konfiguration, Internetanschluss theoretisch 6Mbit Download/660Kbit Upload, tatsächlich 2,7Mbit Download/395 Kbit Upload (sh dsl interface atm0). Ich lasse einen Dauerping von der Zentrale auf das Router-Lan-Interface mit Timestamp laufen. Die Antwortzeiten sind gut. Mit FTP Down- und Upload zur Aussenstelle wird ca. 70-75% der tatsächlichen Bandbreite erreicht. Hat jemand eine Idee woran die Tastaturverzögerungen im Citrix liegen könnte bzw. wie man die Routerkonfiguration tunen könnte? Grüße Glady Zitieren Link zu diesem Kommentar
glady 10 Geschrieben 19. Januar 2007 Autor Melden Teilen Geschrieben 19. Januar 2007 Passt die Konfiguration? version 12.4 service timestamps debug datetime localtime service timestamps log datetime localtime service password-encryption ! hostname xxx ! boot-start-marker boot-end-marker ! logging buffered 40000 debugging enable secret xxx ! no aaa new-model ! resource policy ! clock timezone MEZ 1 clock summer-time MESZ recurring last Sun Mar 1:00 last Sun Oct 2:00 no ip source-route ip cef ! ! ! ! ip tftp source-interface Loopback0 no ip domain lookup ip host tftp xxx ! ! isdn switch-type basic-net3 ! key chain key1 key 1 key-string xxx ! ! username xxx password xxx ! ! ! crypto isakmp policy 10 encr 3des authentication pre-share group 2 lifetime 3600 crypto isakmp key xxx address xxx no-xauth crypto isakmp key xxx address xxx no-xauth crypto isakmp key xxx address xxx no-xauth ! ! crypto ipsec transform-set 3dessha esp-3des esp-sha-hmac ! crypto ipsec profile P-3dessha set transform-set 3dessha ! ! ! ! ! interface Tunnel10 bandwidth 2000 ip address xxx 255.255.255.252 delay 15 tunnel source Dialer1 tunnel destination xxx tunnel mode ipsec ipv4 tunnel protection ipsec profile P-3dessha ! interface Tunnel20 bandwidth 2000 ip address xxx 255.255.255.252 delay 10 tunnel source Dialer1 tunnel destination xxx tunnel mode ipsec ipv4 tunnel protection ipsec profile P-3dessha ! interface Loopback0 ip address xxx 255.255.255.255 ! interface BRI0 description backup bandwidth 64 no ip address encapsulation ppp dialer pool-member 10 isdn switch-type basic-net3 isdn point-to-point-setup ppp authentication chap ! interface ATM0 no ip address ip mtu 1492 no atm ilmi-keepalive pvc 1/32 pppoe-client dial-pool-number 1 ! dsl operating-mode auto ! interface FastEthernet0 ! interface FastEthernet1 ! interface FastEthernet2 ! interface FastEthernet3 ! interface Vlan1 ip address xxx 255.255.255.0 ip helper-address xxx ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 key1 ip tcp adjust-mss 1452 ip policy route-map Clear-DF ! interface Dialer1 ip address negotiated ip access-group internet_in in ip mtu 1492 encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer-group 1 no cdp enable ppp authentication chap pap callin ppp chap hostname xxx@qsc-tdsl.de ppp chap password xxx ppp pap sent-username xxx@qsc-tdsl.de password xxx ! interface Dialer10 description eigene rufnummer xxx bandwidth 64 ip address xxx 255.255.255.252 encapsulation ppp dialer pool 10 dialer remote-name xxx dialer idle-timeout 300 dialer string xxx dialer caller xxx dialer hold-queue 30 dialer-group 1 no cdp enable ppp authentication chap ppp multilink ! router eigrp 1 passive-interface default no passive-interface Vlan1 no passive-interface Tunnel10 no passive-interface Tunnel20 network xxx 0.0.0.0 network xxx 0.0.0.0 network xxx 0.0.0.0 network xxx 0.0.0.0 distribute-list route_list_in_allow in Tunnel10 distribute-list route_list_in_allow in Tunnel20 no auto-summary ! ip route 0.0.0.0 0.0.0.0 Dialer1 Zitieren Link zu diesem Kommentar
glady 10 Geschrieben 19. Januar 2007 Autor Melden Teilen Geschrieben 19. Januar 2007 no ip http server no ip http secure-server ! ip access-list standard route_list_in_allow remark default permit xxx 0.0.3.255 permit xxx 0.0.0.255 permit xxx 0.0.7.255 permit xxx 0.0.255.255 ! ip access-list extended internet_in permit icmp any any administratively-prohibited permit icmp any any echo permit icmp any any echo-reply permit icmp any any packet-too-big permit icmp any any time-exceeded permit icmp any any traceroute permit icmp any any unreachable permit esp xxx 0.0.0.127 any permit udp xxx 0.0.0.127 any eq isakmp deny ip any any ip access-list extended routemap-clear-df permit ip xxx 0.0.255.255 any permit ip any xxx 0.0.255.255 ! logging trap debugging access-list 10 permit xxx 0.0.0.255 access-list 10 permit xxx 0.0.0.255 access-list 10 permit xxx 0.0.0.255 access-list 10 permit xxx 0.0.0.255 access-list 10 permit xxx 0.0.255.255 access-list 10 permit xxx 0.0.255.255 access-list 10 deny any log access-list 120 deny udp any eq syslog any access-list 120 deny udp any eq snmp any access-list 120 deny udp any eq snmptrap any access-list 120 deny udp any eq ntp any access-list 120 deny udp any eq netbios-dgm any access-list 120 deny udp any eq netbios-ns any access-list 120 deny udp any eq netbios-ss any access-list 120 deny udp any range snmp snmptrap any access-list 120 deny udp any range bootps bootpc any access-list 120 deny tcp any eq 137 any access-list 120 deny tcp any eq 138 any access-list 120 deny tcp any eq 139 any access-list 120 permit ip any any dialer-list 1 protocol ip list 120 snmp-server community xxx RO no cdp run ! ! ! route-map Clear-DF permit 10 match ip address routemap-clear-df set ip df 0 ! ! control-plane ! ! line con 0 password xxx login no modem enable line aux 0 password xxx login line vty 0 4 access-class 10 in exec-timeout 300 0 password xxx login ! scheduler max-task-time 5000 ntp clock-period 17179558 ntp source Loopback0 ntp server xxx end Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 19. Januar 2007 Melden Teilen Geschrieben 19. Januar 2007 Bei spontanen Verzoegerungen kann das z.B. mal ne dicke ausgehende Mail sein. Dafuer wuerde sich dann QoS anbieten (sofern es an ausgehenden Verbindungen liegt). Zitieren Link zu diesem Kommentar
glady 10 Geschrieben 19. Januar 2007 Autor Melden Teilen Geschrieben 19. Januar 2007 Ausser Drucken, Citrix-Session und Ping geht nichts über die Leitung. Mail, usw. geht alles über die Citrix-Session. Wie könnte QoS aussehen, um die Citrix-Sessions Vorrang gegenüber Drucken zu geben? Habe eine neue Erkenntnis. Gegenüber einer FTP-Übertragung habe ich bei der Datenübertragung über die Windows-Freigabe 45% schlechtere Perfomance (Download) und 30% beim Upload. Woran liegt das? Vielleicht ist das auch der Grund für die Verzögerungen bei den Citrix-Sessions. Zitieren Link zu diesem Kommentar
mr._oiso 10 Geschrieben 24. Januar 2007 Melden Teilen Geschrieben 24. Januar 2007 Hi glady, ich bin ja hoch erfreut zu sehen, dass andere auch mit solchen Tricks arbeiten. :D Ich denke auf Grund dieser Konfiguration wusste da schon jemand welche Probleme Citrix oder generell Terminal Server Anwendungen auf VPN/Wan Leitungen machen. Ich befürchte in Deinem Fall eher ein "Fragmentation" Problem. Allein die Tatsache, dass Du hier die route map Clear-DF bit integriert hast bedeutet, dass eventuell jemand wusste das der Terminal Server das DF-Bit bei seinen ausgehenden Packeten zum Client gesetzt hat. Dieses ist in der Regel auch normal. Path-MTU-discovery ist standardmäßig unter Windows aktiv. Jedoch gibt es ein White-Paper von Citrix, in der einiges über die richtige MTU-size nachzulesen ist. Nun kenn ich natürlich nicht die Serverumgebung, und weiß auch nicht ob der Citrix Server auf einem Windows Server System läuft. Zusätzlich hast Du die IP Adressen aus der Config entfernt. Sollte aber diese Liste: ip access-list extended routemap-clear-df permit ip xxx 0.0.255.255 any permit ip any xxx 0.0.255.255 Deine Problemzone sein, so deutet alles darauf hin. Eventuell bringt es schon etwas wenn Du mit ip tcp adjust-mss an Vlan 1 den Wert weiter nach unten drückst. Überprüfen solltest Du auf jeden Fall mal, wo die MTU Werte vom Server liegen, und ob adjust-mss auch arbeitet. Das bedeutet, der Server muss vom Router die Info bekommen (ICMP code 4) Fragmentation Needed and DF Set ! Solche Informationen werden oft gerne von Firewall Systemen/Anwendungen verworfen. Auch hier sehe ich in Deiner Config die notwendigen permit's icmp any any packet-too-big icmp any any unreachable Auf jeden Fall sieht es wohl so aus, dass der Server die Bildinfo's nicht schnell genug rüber bringt (Packet zu groß, -> verworfen) (ist noch normal) Tastaturverzögerung aus meiner sicht - Ich tippe ein "A" und sehe es erst sekunden später. Das bedeutet eventuell, zu viele, zu große Packete = kein Path MTU discovery Fragmentierungsfehler zwischen Server und Router. Vieleicht hilft es auch einfach nur zu überlegen, was in der letzen Zeit am System geändert worden ist. z.B. Citrix Patch, Firewall konfigurationen, etc. Ich hoffe notwendige Anregungen zur Fehlerbehebung beitragen zu können. greez Mr.Oiso Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 25. Januar 2007 Melden Teilen Geschrieben 25. Januar 2007 Hi Oiso! Schoen mal wieder von dir zu lesen :) Wir arbeiten auch mit clear DF-bit :D Bei uns aber erst seit einer unserer Upstream Provider auf Juniper umgestellt hat, die machen da anscheinend ordentlich Zicken. Und QSC wird die Tage wohl auch nachziehen :( Ich wuerd auch mal adjust-mss auf 1300 setzen, hm, und den MTU Wert auf ATM0 kannste auch rausnehmen. Zitieren Link zu diesem Kommentar
glady 10 Geschrieben 25. Januar 2007 Autor Melden Teilen Geschrieben 25. Januar 2007 Danke für die ausführlichen Infos Mr. Oiso! Ohne das DF-Bit haben sich die Citrix-Sessions und auch alles andere was mit Windows zu tun hat aufgehängt, eine Kommunikation war nicht möglich. Mit dem entzug des DF-Bits hatten wir diese Probleme nicht mehr. Später habe ich rausbekommen, dass man das DF-Bit auch im Windows in der Registry rauskriegt. Wenn auf Server und Client Seite das entsprechende ICMP freigegeben ist, warum können die sich dann nicht trotzdem einigen? >Überprüfen solltest Du auf jeden Fall mal, wo die MTU Werte vom Server liegen, und ob adjust-mss auch arbeitet. Wenn ich vom Client zum Server pinge mit den Optionen -f -l, dann kommt bei 1472 Bytes eine normale Antwort. Ab 1473 kommt dann die Meldung "Paket müsste fragmentiert werden". Was hat das nun auszusagen? Und wie prüfe ich, ob adjust-mss arbeitet? @Wordo Was meinst Du mit "Upstream Provider"? Und was wird QSC nachziehen? Ich dachte das tcp adjust-mss muss man MTU-Size -40 setzen. Bei einer MTU-Size von 1492 wären das also tcp adjust-mss 1452 Danke für eure Antworten! Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 25. Januar 2007 Melden Teilen Geschrieben 25. Januar 2007 Das war an Oiso gerichtet, das mit QSC ist fuer dich uninteressant. Fuer RDP Sessions z.B. wird ein Wert von 1300 empfohlen. Ich glaub das steht sogar in nem MS KnowledgeBase Artikel. Die ICMP Kommunikation von Client zu Server ist fuer das "Aushandeln" der MTU Werte nicht wichtig. Eher ICMP von Gateway zu Client. Uebrigens gilt adjust-mss nur fuer TCP Verbindungen, da bringt dir der ping mit "-l" nicht viel ;) Zitieren Link zu diesem Kommentar
glady 10 Geschrieben 25. Januar 2007 Autor Melden Teilen Geschrieben 25. Januar 2007 >Die ICMP Kommunikation von Client zu Server ist fuer das "Aushandeln" der MTU Werte nicht wichtig. Eher ICMP von Gateway zu Client Wo muss ich dann in so einer Umgebung prüfen: Server-MLS-Firewall-Firewall-VPN-Router1<-Internet->VPN-Router2-Client Was ist beim DF-Bit lsöchen der Unterschied zu diesem Verfahren: Cisco IOS Security Configuration Guide, Release 12.4 - DF Bit Override Functionality8 with IPSec Tunnels [Cisco IOS Software Releases 12.4 Mainline] - Cisco Systems Da steht folgender Hinweis: Performance Impact Because each packet is reassembled at the process level, a significant performance impact occurs at a high data rate. Two major caveats are as follows: •The reassemble queue can fill up and force fragments to be dropped. •The traffic is slower because of the process switching. Was habt ihr für Erfahrungen? Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 25. Januar 2007 Melden Teilen Geschrieben 25. Januar 2007 Bei dem Link stehts ja da: The DF Bit Override Functionality with IPSec Tunnels feature allows customers to specify whether their router can clear, set, or copy the Don't Fragment (DF) bit from the encapsulated header. A DF bit is a bit within the IP header that determines whether a router is allowed to fragment a packet. Some customer configurations have hosts that perform the following functions: •Set the DF bit in packets they send •Use firewalls that block Internet Control Message Protocol (ICMP) errors from outside the firewall, preventing hosts from learning about the maximum transmission unit (MTU) size outside the firewall •Use IP Security (IPSec) to encapsulate packets, reducing the available MTU size Customers whose configurations have hosts that prevent them from learning about their available MTU size can configure their router to clear the DF bit and fragment the packet. Du hast doch alle Router unter deiner Kontrolle oder? Dann musst du Punkt 2 loesen. DF-bit clearen ist halt nicht sauber. Wenn du den Client dazu bringst kleinere Pakete zu senden sparst du dir Performance weil der Router nicht fragmentieren muss (oder eben nicht das DF-bit clearen muss) Zitieren Link zu diesem Kommentar
#9370 10 Geschrieben 25. Januar 2007 Melden Teilen Geschrieben 25. Januar 2007 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. Zitieren Link zu diesem Kommentar
glady 10 Geschrieben 25. Januar 2007 Autor Melden Teilen Geschrieben 25. Januar 2007 ICMP ist zwischen Client und Server definitiv freigegeben. Zwischen welchen Bereichen muss das noch freigegeben werden? Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 25. Januar 2007 Melden Teilen Geschrieben 25. Januar 2007 •Use firewalls that block Internet Control Message Protocol (ICMP) errors from outside the firewall, preventing hosts from learning about the maximum transmission unit (MTU) size outside the firewall ... Internet Control Message Protocol (ICMP) errors from outside the firewall ... Zitieren Link zu diesem Kommentar
glady 10 Geschrieben 26. Januar 2007 Autor Melden Teilen Geschrieben 26. Januar 2007 Muss ich auf der Firewall icmp any any freigeben? Man muss das doch hinkriegen, mit einer gewissen Einschränkung. Wäre toll, wenn mir da jemand Licht ins Dunkle bringen könnte. Danke! Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.