RDP Traffic ueber VPN priorisieren

[Wordo 11]

Hi,

 

ich hab n Performance Problem beim einigen DSL Leitungen die mit DSL1000 angebunden sind, vor Ort ne 836er mit VPN zu einem Server bei mir haben. Die Clients verbinden sich zu einem Terminalserver hinter dem VPN-Gateway, und klicken wild rum. Alles kein Problem bis einer im DSL Standort ne Mail verschickt. Schon geht die RDP Verbindung in die Knie und wird schleppend langsam.

Jetzt hab ich mir gedacht ich mach ein "qos pre-classify" in der crypto map, erstell eine access-liste mit Port RDP, und ne priority-list:

 

[...]

crypto map VPN 10 ipsec-isakmp

set peer X.X.X.X

set transform-set 3des-md5

set pfs group2

match address 100

qos pre-classify

[...]

 

[...]

interface Dialer0

ip address negotiated

ip mtu 1492

ip nat outside

ip virtual-reassembly

encapsulation ppp

ip tcp adjust-mss 1300

dialer pool 1

dialer-group 1

priority-group 1

no cdp enable

ppp authentication pap callin

ppp pap sent-username meinlogin@meinrealm.de password 7 supersicher

ppp ipcp dns request

ppp ipcp wins request

crypto map VPN

[...]

 

access-list 120 permit ip any any eq 3389

priority-list 1 protocol ip high list 120

 

 

So .. mehr bzgl QoS und queues ist nicht konfiguriert. Aber wie kann ich pruefen ob das wirklich funktioniert?

 

show queue dialer 0 <== leere Ausgabe

show queue virtual-access 1 <== 'Show queue' not supported with FIFO queueing.

show queueing:

Current fair queue configuration:

 

Interface Discard Dynamic Reserved Link Priority

threshold queues queues queues queues

BRI0 64 16 0 8 1

BRI0:1 64 16 0 8 1

BRI0:2 64 16 0 8 1

 

Current DLCI priority queue configuration:

Current priority queue configuration:

 

List Queue Args

1 high protocol ip list 120

Current custom queue configuration:

Current random-detect configuration:

VC 1/32 -

VC 1/32: Per VC queueing is FIFO.

Current per-SID queue configuration:

 

 

sh int dialer 0:

Output queue (queue priority: size/max/drops):

high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0

 

 

Da ist nix zu sehn ..

Meine Vermutung ist, da bei der DSL Einwahl automatisch virtual-access1 "generiert" wird und die an dialer 0 bindet ich das da explizit konfigurieren muss, oder ich was vergessen hab? Und gibts vielleicht einen Befehl wie ich mir die Queues anschauen kann?

 

Oder gibts vielleicht ne bessere Loesung?

 

Merci ...

[daking 10]

Hola

 

priority queueing oder "brutal" queueing ist gut für das was man priorisieren will aber schlecht für den anderen Traffic, da nur die high queue abgearbeitet wird. Die anderern zwei queueus werden gnadenlos vernachlässigt.

 

Besser geht es so:

 

class-map RDP

match accesss-goup 120

 

policy-map siteQOS

 

class RDP

priority <pecent> <bandbreite oder prozent der bandbreite>

 

sollte jedoch schon

 

bandwidth <percent> <bandbreite oder prozent der bandbreite>

 

ausreichen.

dann noch

 

class class-default

 

fair-queue

..

 

 

 

int dialer 10

service-policy out siteQOS

 

 

validate:

 

sh policy-map int dialer 10

#

 

=> dann kannst du eine bestimmte Bandbreite für RDP reservieren !

=> du musst unter dem Dialer noch die Bandbreite deiner Leitung angeben!

=> sinvoll ist auch noch ein policing oder shaping des restlichen Traffic von ETH zu WAN um interface drops (tail drops) zu vermweiden.

 

 

 

Ciao

[daking 10]

Hola,

 

falls du doch priority queueing verwenden willst solltest du unter dem Dialer Interface noch

 

priority-group 1

 

hinzufügen..

[Wordo 11]

das steht ja schon drin .. aber ich kann keine wirklich verbesserung/verschlechterung feststellen. vor policy-map's hab ich mich bis jetzt immer gedrueckt, da ich keine bandbreite fest reservieren will.

ich werds mal testen ... merci ..

[rob_67 10]

Hi,

 

 

wie gross sind denn so im schnitt eure mails, damit die eine dsl verbindung dichtmachen? dein qos nützt dir leider nur etwas auf deinem router, wenns im internet noch irgendwo anders klemmt, no chance!

 

gruss

 

rob

[Wordo 11]

Die DSL-Leitung hat nen Upload von 168kbit, also wenn ich da ne 5MB rausschick is fuer 5-10 Minuten die Leitung so gut wie zu, bzw RDP unbenutzbar. Der Server is ueber 100Mbit am Netz und die L2TP Sessions der DSL Leitungen schlagen auch bei mir im Netz (im Rechenzentrum) auf.

[rob_67 10]

Hi nochmal,

 

 

man kann ja die 5 Mbit begrenzen, dass maximal 1 oder 2 Mbit Mails verschickt werden dürfen, ansonsten sollte priority queueing reichen, aber es scheint nicht zu funzen, da die queues leer sind (falls gerade ebensolcher traffic aktiv war), kannst du schauen, ob deine priority acls matchen, vielleicht ziehen die ja gar nicht... und jeglicher traffic landet in der letzten queue...

 

 

gruss

 

 

rob

[Wordo 11]

nene .. da hast du dich verlesen :D Ich verschicke Mails die 5 MB gross sind ueber ne Leitung wo ich nen Upload von ca. 16KB hab, sprich 168kbit .. und bei so ner Bandbreite zaehlt jedes KB, da will ich nicht reservieren, deswegen eben priorisieren ;)

[rob_67 10]

ich meine, dass der mailserver ja z.b. bei mails größer als 1 oder 2mbyte sind, diese nicht senden darf, das spart bandbreite und zwingt die user zum komprimieren und nicht sinnlos bandbreite verschwenden

 

meine zweite frage zielte aber auf die access-listen, ziehen diese (priority queue)?

[Wordo 11]

Der Mailserver steht ja auch im Rechenzentrum und das limitieren kommt eigentlich nicht in Frage, der Server wird ja nur bei uns gehostet, alles andere Regeln die selbst.

Ob die Lists treffen kann ich jetzt nicht sagen .. Freitags um 16:30 arbeitet da keiner mehr ;)

 

Merci ..

[Wordo 11]

Sorry, habs doch noch testen koennen .. also die ACL's greifen nicht. Ich hab jetzt in die ACL sowohl Hin- als auch Rueckpakete eingetragen und die priority-group auf dialer 0 und eth 0 gelegt. Nur Rueckpakete haben gematched :(

 

Meine Vermutung ist:

 

Router#sh int dialer 0

Dialer0 is up, line protocol is up (spoofing)

Hardware is Unknown

Internet address is 81.24.55.55/32

MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 127/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

DTR is pulsed for 1 seconds on reset

Interface is bound to Vi1

Last input never, output never, output hang never

Last clearing of "show interface" counters 4d00h

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: priority-list 1

Output queue (queue priority: size/max/drops):

high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0

5 minute input rate 28000 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

1207650 packets input, 548370445 bytes

1046389 packets output, 185060840 bytes

Bound to:

Virtual-Access1 is up, line protocol is up

Hardware is Virtual Access interface

MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec,

reliability 255/255, txload 50/255, rxload 104/255

Encapsulation PPP, LCP Open

Open: IPCP

PPPoE vaccess, cloned from Dialer0

Vaccess status 0x44, loopback not set

Keepalive set (10 sec)

Interface is bound to Di0 (Encapsulation PPP)

Last input 00:00:00, output never, output hang never

Last clearing of "show interface" counters 23:54:16

Input queue: 0/75/29/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 23000 bits/sec, 5 packets/sec

5 minute output rate 11000 bits/sec, 4 packets/sec

288615 packets input, 175009836 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

233665 packets output, 44722667 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

 

 

Vi ist an dialer 0 gebunden und das wiederrum benutzt FIFO. Direkt konfigurieren kann ich Vi1 aber nicht, da meckert er rum und sagt ich soll n virutal template verwenden. Jemand ne Idee wie ich das umgehen kann?

 

Merci ..

[tom12 10]

Hi,

 

Priority Queuing ist prinzipiell das beste um Traffic zu priorisieren... Also müsste das mit der Priority-list 1 passen.

 

Versuch statt dem Dialer Interface ein Virtual-Template, so ca. :

interface Virtual-Template2

ip address negotiated

ip mtu 1492

ip nat outside

ip virtual-reassembly

encapsulation ppp

ip tcp adjust-mss 1300

priority-group 1

no cdp enable

ppp authentication pap callin

ppp pap sent-username meinlogin@meinrealm.de password 7 supersicher

ppp ipcp dns request

ppp ipcp wins request

crypto map VPN

 

Achtung, ohne:

dialer pool 1

dialer-group 1

 

und am ATM Interface:

interface ATM0

pvc x/y

encapsulation aal5snap

protocol ppp Virtual-Template2

 

 

 

Es noch ein weiteres Problem (welches eigentlich mehr bei VOIP interessiert): "Serialization Delay"

Denn die Bits eines Paketes mussen nacheinander aud den physischen Link. Bei 168kbit/s braucht ein 1500byte Paket ca. 70 ms.

Auch wenn du Priority Queuing machst wird ein PAket (z.B. SMTP, FTP zu 1500byte) vor den priorisierten Paketen versendet, falls dieses schon beim übertragen ist. Da beim Versenden die Queue ja scon abgearbeitet wurde.

 

Lösung:

ppp fragmentation (bin mir nicht mehr 100% sicher ob das dei gegenstelle auch machen muss...)

oder drastisch:

mtu 300

 

Versuchs einfach mal.

 

Oder sonst mach einfach ein CAR auf smtp von 128kbit/s. Eine mail kann im Normalfall auch mal 30 sek. länger brauchn um versendet zu werden...

 

Die beste Lösung ist im Endeffekt immer

Grüsse

Thomas

[tom12 10]

....die Bandbreite zu erhöhen

[Wordo 11]

das werd ich auf jeden fall mal testen .. aber per remote muss ich dann wohl n ntba auftreiben damit ich die aenderungen remote auch machen kann ohne das es mich raushaut.

 

merci dir ..

[Alex_K._aus_M. 10]

Ich hatte ein Ähnliches Problem wie du. Ich spiele gerne Shooter im Internet und da kommt es auf gute Pings und eine gesicherte Bandbreite an. Mein Problem, -> meine Freundin verschickt gerne große Mails :) während ich Spiele. Und da geht gar nichts mehr!

Ich habe dann auf dem Router CBWFQ konfiguriert, mit Erfolg! Ich kann trotz einer großen E-Mail noch mit Pings zwischen 60-90 ms (FastPath) spielen.

Mit den Werten in der "policy-map" musste ich ein Weilchen rumspielen bis ich das optimale Ergebnis hatte.

 

Anmerkung. Klar ist dennoch das eine Priorisierung keine Bandbreite ersetzt. Du solltest das Verkehrsverhalten der Außenstelle analysieren und ggf. über eine Erhöhung der Bandbreite nachdenken

 

Gruß