[2003 Server] RDP werkt niet door MTU setting op routers

[Flyduck]

Bij een klant van ons wordt gebruik gemaakt van VOIP. De klant heeft meerdere vestigingen in een VPN en op het centraal bureau is de voice gateway naar buiten.
Nu is het zo dat het bedrijf voor een goeie kwaliteit van de voice op de ATM interfaces een MTU size van 250 heeft ingesteld.
Dat was nooit een probleem, echter nu het netwerk overgaat op een windows 2003 terminal server omgeving, blijkt dat RDP helemaal niet werkt over de ATM lijnen door deze MTU setting. Je krijgt gewoon een time-out bij het verbinden naar de server.

We hebben heel even getest door de MTU setting van de Cisco routers af te halen, en dan werkt RDP wel, maar dan gaat voice haperen.

Naar een 2000 Terminal server verbinden werkt weer wel, dus het ligt echt specifiek aan het 2003 RDP protocol.

Wie weet raad? Kan ik op de 2003 server iets instellen waardoor deze lagere MTU accepteert?

De enige oplossing die nu werkt is een PPTP verbinding opzetten naar de 2003 server en daarover heen verbinden. maarja dat gaat natuurlijk nergens over.

[pierce]

Volgens mij heb je nog niet echt je best gedaan om te zoeken naar oplossingen, want de eerste hit op google was raak.

Google: http://www.google.nl/sear...erminal+mtu+setting&meta=

1ste Hit:

Q. Sometimes when I connect to my terminal server, I see a black screen. Why does this occur?

A. This typically occurs if there is a device between the client and the server that is receiving packets but not passing them on. One way around this problem is to change the MTU size for the network adapter that is being used as a terminal server connection to clients.

Ethernet uses a maximum MTU size of 1500. You can start with 500 and then slowly move up until you notice the problem to find the correct value to set
http://support.microsoft....spx?scid=kb;en-us;q314825

[ Voor 9% gewijzigd door pierce op 04-05-2005 21:22 ]

[Brahiewahiewa]

Flyduck schreef op woensdag 04 mei 2005 @ 16:05:
...Wie weet raad? Kan ik op de 2003 server iets instellen waardoor deze lagere MTU accepteert?...

't Zou kunnen zijn dat de RDP pakketjes voorzien zijn van het no-fragment bitje.
Kun je oplossen door op de terminal server ook te vertellen dat de MTU 250 is (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MTU of zoiets).

Ik meen me ook iets te kunnen herinneren over een bugje in ICMP in Win2k3 SP1; als jouw routers netjes terugmelden dat het pakketje te groot is om te versturen, zou Windows de pakketgrootte terug moeten schroeven. En dat gaat dus niet werken als ICMP stuk is.

edit:
dat zeg ik: http://support.microsoft....aspx?scid=kb;en-us;898060

OTOH is het zetten van een MTU van 250 op je routers een cheap-ass oplossing. Je degradeert je netwerk performance met ruim 10%. Een serieuzere benadering (maar ook duurder) is een QoS implementatie of packet shaping.

[ Voor 5% gewijzigd door Brahiewahiewa op 04-05-2005 21:01 ]

[Flyduck]

Helaas heeft de MTU setting van 250 in het register van de terminal server niets uitgehaald.
Maar hoe bedoel je precies dat dit een cheap ass oplossing is? Er staat namelijk ook QOS geconfigureerd op de routers...

[Brahiewahiewa]

Flyduck schreef op vrijdag 06 mei 2005 @ 16:24:
Helaas heeft de MTU setting van 250 in het register van de terminal server niets uitgehaald.
Maar hoe bedoel je precies dat dit een cheap ass oplossing is? Er staat namelijk ook QOS geconfigureerd op de routers...

Dan lijkt het me dat QoS niet geconfigureerd is met VOIP in gedachten. Idealiter zou QoS er voor moeten zorgen dat VOIP pakketjes met de hoogste prioriteit door je netwerk gaan (je reserveert er een percentage bandbreedte voor en je zegt dat de pakketjes niet gedropt mogen worden). Het overige verkeer zou je ook nog in klasses kunnen indelen, of alles op een grote hoop "best effort" versturen.
Anyway, wil QoS gaan werken, dan moet je er voor zorgen dat de VOIP pakketjes getagged worden voor de juiste verkeersklasse. Sommige VOIP toestellen kunnen dat; je callmanager kan het ook en anders je routers wel. Maar je moet het wel aanzetten.
Als QoS goed werkt, zou je de MTU beperking moeten kunnen weghalen; gewoon weer 1500 maken.