QoS gebruiken, gaat dit wat uitmaken?

[MADG0BLIN]

Op mijn werk hier zitten we met een klein probleempje.
We hebben een hoofdvestiging waar we een 2mbit SDSL verbinding hebben.
Daarnaast nog een Fast ADSL verbinding voor internet en mail verkeer.
De SDSL wordt gebruikt voor citrix. Daarvoor hebben we 2 windows 2000 servers met Citrix Metaframe XP.
Hierop loggen een aantal andere vestigingen in met in totaal ongeveer 50 gebruikers. Dit is verdeeld over 10 wat kleinere kantoren die verbonden zijn via een VPN verbinding.
Die zijn allemaal verbonden met een basic ADSL lijn. De meesten hebben een business lijn.

Nu is het probleem dat als er bijvoorbeeld geprint/gemaild wordt over de VPN verbinding dan wordt het wat trager, en bij grote opdrachten veel trager. Nu zaten wij te denken om een QoS router aan te schaffen die bepaalde opdrachten voorrang kan geven. Die komt dan op het hoofdkantoor te staan.
Maar op de neven vestigingen staan gewone adsl routers. Gaat dit dan werken? Of moet er dan daar ook een QoS router komen te staan?

[Verwijderd]

MADG0BLIN schreef op maandag 28 november 2005 @ 11:15:
Op mijn werk hier zitten we met een klein probleempje.
We hebben een hoofdvestiging waar we een 2mbit SDSL verbinding hebben.
Daarnaast nog een Fast ADSL verbinding voor internet en mail verkeer.
De SDSL wordt gebruikt voor citrix. Daarvoor hebben we 2 windows 2000 servers met Citrix Metaframe XP.
Hierop loggen een aantal andere vestigingen in met in totaal ongeveer 50 gebruikers. Dit is verdeeld over 10 wat kleinere kantoren die verbonden zijn via een VPN verbinding.
Die zijn allemaal verbonden met een basic ADSL lijn. De meesten hebben een business lijn.

Nu is het probleem dat als er bijvoorbeeld geprint/gemaild wordt over de VPN verbinding dan wordt het wat trager, en bij grote opdrachten veel trager. Nu zaten wij te denken om een QoS router aan te schaffen die bepaalde opdrachten voorrang kan geven. Die komt dan op het hoofdkantoor te staan.
Maar op de neven vestigingen staan gewone adsl routers. Gaat dit dan werken? Of moet er dan daar ook een QoS router komen te staan?

Als er vanaf een vestiging geprint wordt moet er daar natuurlijk ook een QoS systeem draaien, maar dat kan ook wel op een server(als die daar staan)...

[MADG0BLIN]

Verwijderd schreef op maandag 28 november 2005 @ 11:17:
[...]


Als er vanaf een vestiging geprint wordt moet er daar natuurlijk ook een QoS systeem draaien, maar dat kan ook wel op een server(als die daar staan)...

Er wordt vanuit Citrix geprint op de vestigingen ja. Server staat op de hoofdvestiging dus.
Maar ik dacht al dat ik daar ook een router/server zou moeten neerzetten

[Verwijderd]

MADG0BLIN schreef op maandag 28 november 2005 @ 11:22:
[...]


Er wordt vanuit Citrix geprint op de vestigingen ja. Server staat op de hoofdvestiging dus.
Maar ik dacht al dat ik daar ook een router/server zou moeten neerzetten

Dan helpt het denk ik niet zoveel (Al het verkeer is ongeveer Citrix dus), wat zou je dan willen indelen?"
wat elevator zegt dus...

[ Voor 5% gewijzigd door Verwijderd op 28-11-2005 11:32 ]

[elevator]

Je kan via Citrix (als je Clientside printing gebruikt) de bandbreedte knijpen en daarmee de impact van je printverkeer dus beperken. QoS werkt vziw enkel op poort niveau als het ware, waardoor client-side print verkeer (wat in een virtual channel in je standaard ica stream zit) niet onderscheidbaar is van ander traffic.

Een veel gebruikte oplossing voor deze problematiek is overigens een Packetshaper

[MADG0BLIN]

elevator schreef op maandag 28 november 2005 @ 11:25:

Een veel gebruikte oplossing voor deze problematiek is overigens een Packetshaper

Heb je misschien een voorbeeld(en) van een packetshaper? Zijn er nogal veel...

Ik maak trouwens een foutje over dat printen, dat gebeurt helemaal niet client side.
Wordt vanuit een server waarop de printer is gedeeld, rechtstreeks naar de printer op de vestiging gestuurd via VPN.

[Verwijderd]

MADG0BLIN schreef op maandag 28 november 2005 @ 11:42:
[...]


Heb je misschien een voorbeeld(en) van een packetshaper? Zijn er nogal veel...

Ik maak trouwens een foutje over dat printen, dat gebeurt helemaal niet client side.
Wordt vanuit een server waarop de printer is gedeeld, rechtstreeks naar de printer op de vestiging gestuurd via VPN.

Dus niet via Citrix? dan is QoS packet filtering wel weer handig...

[StevenK]

Heb je niet eens QoS voor nodig; op bijvoorbeeld een Cisco kun je met traffic-shaping ook zorgen dat je ICA sessies voldoende bandbreedte krijgen.

[MADG0BLIN]

Ok, dat dachten wij dus ook, maar dan rest de vraag moet er ook op de remote vestigingen een QoS router komen? Ik dacht van wel, collega dacht van niet namelijk.
En traffic-shaping, kom het woord telkens vaker tegen, maar wat is het exacte verschil met QoS?

[StevenK]

MADG0BLIN schreef op maandag 28 november 2005 @ 11:52:
Ok, dat dachten wij dus ook, maar dan rest de vraag moet er ook op de remote vestigingen een QoS router komen? Ik dacht van wel, collega dacht van niet namelijk.
En traffic-shaping, kom het woord telkens vaker tegen, maar wat is het exacte verschil met QoS?

QoS is een protocol waarbij end-to-end het er sprake is van kwaliteitsgaranties en dus *alle* onderliggende apparatuur en netwerken dat moeten ondersteunen. Voor QoS moet je niet alleen QoS ondersteuning in je routers, maar ook in je switches enzo hebben.

Trafficshapen zorgt binnen de Cisco dat op een specifieke verbinding aan specifiek verkeer ( op basis van ip-adressen/poorten) bandbreedte gegeven wordt.

[Verwijderd]

StevenK schreef op maandag 28 november 2005 @ 11:55:
[...]

QoS is een protocol waarbij end-to-end het er sprake is van kwaliteitsgaranties en dus *alle* onderliggende apparatuur en netwerken dat moeten ondersteunen. Voor QoS moet je niet alleen QoS ondersteuning in je routers, maar ook in je switches enzo hebben.

Trafficshapen zorgt binnen de Cisco dat op een specifieke verbinding aan specifiek verkeer ( op basis van ip-adressen/poorten) bandbreedte gegeven wordt.

Hij legde volgens mij net uit dat het printen via het VPN om de cisco zooi heen liep, dus dan zou ik toch voor QoS kiezen en het cisco verkeer meer prioriteite geven.

[MADG0BLIN]

StevenK schreef op maandag 28 november 2005 @ 11:55:
[...]

QoS is een protocol waarbij end-to-end het er sprake is van kwaliteitsgaranties en dus *alle* onderliggende apparatuur en netwerken dat moeten ondersteunen. Voor QoS moet je niet alleen QoS ondersteuning in je routers, maar ook in je switches enzo hebben.

Trafficshapen zorgt binnen de Cisco dat op een specifieke verbinding aan specifiek verkeer ( op basis van ip-adressen/poorten) bandbreedte gegeven wordt.

Laat ik mijn vraag anders stellen:
Via VPN gaan een aantal protocollen over de lijn waaronder citrix, printverkeer en email.
We willen citrix voorrang geven boven de anderen. We dachten dit op te lossen door op de hoofdvestiging een QoS router neer te zetten. Het pakket komt aan bij de QoS router met daarin een bestemmings poort, 1494 voor Citrix, dit heeft dan toch niets te maken of de switch dit bijvoorbeeld ook ondersteunt? De router geeft het toch prioriteit?

[StevenK]

Verwijderd schreef op maandag 28 november 2005 @ 11:58:
[...]


Hij legde volgens mij net uit dat het printen via het VPN om de cisco zooi heen liep, dus dan zou ik toch voor QoS kiezen en het cisco verkeer meer prioriteite geven.

Nee, hij zegt dat er niet via ICA geprint wordt. Zou het printen wel via ICA gaan, dan zou traffic shaping juist geen optie zijn. Als hij buiten zijn netwerk om zou printen, zou het printen geen problemen veroorzaken

En mijn ervaring is dat een packetshaper juist handig is om het verkeer te analyseren, maar in verhouding met traffic shaping veel te uitgebreid en daardoor te duur is, wanneer het om het relatief éénvoudige prioriteren van enkele protocollen gaat.

[StevenK]

MADG0BLIN schreef op maandag 28 november 2005 @ 12:04:
[...]


Laat ik mijn vraag anders stellen:
Via VPN gaan een aantal protocollen over de lijn waaronder citrix, printverkeer en email.
We willen citrix voorrang geven boven de anderen. We dachten dit op te lossen door op de hoofdvestiging een QoS router neer te zetten. Het pakket komt aan bij de QoS router met daarin een bestemmings poort, 1494 voor Citrix, dit heeft dan toch niets te maken of de switch dit bijvoorbeeld ook ondersteunt? De router geeft het toch prioriteit?

Nee, juist voor QoS moet je hele netwerk het ondersteunen. QoS is niet het prioriteren op een deel van het netwerk, maar juist het bieden van netwerkgaranties van begin tot eind van de verbinding. Wil je puur dat protocol prioriteren dan is bijvoorbeeld een cisco met traffic shaping of een packeteer de oplossing.

[ Voor 11% gewijzigd door StevenK op 28-11-2005 12:07 ]

[Verwijderd]

StevenK schreef op maandag 28 november 2005 @ 12:06:
[...]

Nee, hij zegt dat er niet via ICA geprint wordt. Zou het printen wel via ICA gaan, dan zou traffic shaping juist geen optie zijn. Als hij buiten zijn netwerk om zou printen, zou het printen geen problemen veroorzaken

En mijn ervaring is dat een packetshaper juist handig is om het verkeer te analyseren, maar in verhouding met traffic shaping veel te uitgebreid en daardoor te duur is, wanneer het om het relatief éénvoudige prioriteren van enkele protocollen gaat.

Oke...denk dat een plaatje wel op zijn plaats is nu zodat we kunnen zien hoe het verkeer loopt

[StevenK]

Verwijderd schreef op maandag 28 november 2005 @ 12:07:
[...]


Oke...denk dat een plaatje wel op zijn plaats is nu zodat we kunnen zien hoe het verkeer loopt

Eensch is.

[MADG0BLIN]

Op veler verzoek:


Hoop dat het wat duidelijker is.

De QoS router zou dan in plaats van de SDSL en ADSL router komen.

[ Voor 14% gewijzigd door MADG0BLIN op 28-11-2005 12:22 ]

[StevenK]

MADG0BLIN schreef op maandag 28 november 2005 @ 12:21:
Op veler verzoek:
[afbeelding]

Hoop dat het wat duidelijker is.

De QoS router zou dan in plaats van de SDSL en ADSL router komen.

Dat heeft dus geenweinig zin, omdat dan nog geen invloed hebt op het hele netwerk. Een packetshaper of een traffic shaping op een cisco wel.

[ Voor 18% gewijzigd door StevenK op 28-11-2005 12:30 ]

[MADG0BLIN]

StevenK schreef op maandag 28 november 2005 @ 12:29:
[...]

Dat heeft dus geenweinig zin, omdat dan nog geen invloed hebt op het hele netwerk. Een packetshaper of een traffic shaping op een cisco wel.

Wat voor Cisco zou ik moeten hebben? Dan kan ik daar eens naar kijken hoe dat precies gaat.

[StevenK]

MADG0BLIN schreef op maandag 28 november 2005 @ 13:00:
[...]


Wat voor Cisco zou ik moeten hebben? Dan kan ik daar eens naar kijken hoe dat precies gaat.

Eerlijk gezegd heb ik geen flauw idee wel dat wel en niet ondersteunen. Kun je dat niet bij je cisco-leverancier navragen ?

[elevator]

Je moet je afvragen waarom je niet clientside printing gebruikt - zeker als je MPS4 gebruikt heeft dat qua compressie gewoon erg veel voordelen

Een PacketShaper is een productnaam van Packeteer - www.packeteer.com

StevenK schreef op maandag 28 november 2005 @ 12:06:
En mijn ervaring is dat een packetshaper juist handig is om het verkeer te analyseren, maar in verhouding met traffic shaping veel te uitgebreid en daardoor te duur is, wanneer het om het relatief éénvoudige prioriteren van enkele protocollen gaat.

Bwah - Citrix is per definitie geen eenvoudig protocol, met een PS kan je namelijk in je ICA protocol op je diverse virtual channels gaan prioritiseren. Dan verdient een PS zich behoorlijk snel terug

[StevenK]

elevator schreef op maandag 28 november 2005 @ 19:04:
Je moet je afvragen waarom je niet clientside printing gebruikt - zeker als je MPS4 gebruikt heeft dat qua compressie gewoon erg veel voordelen

Een PacketShaper is een productnaam van Packeteer - www.packeteer.com


[...]

Bwah - Citrix is per definitie geen eenvoudig protocol, met een PS kan je namelijk in je ICA protocol op je diverse virtual channels gaan prioritiseren. Dan verdient een PS zich behoorlijk snel terug

Yep, dan wel. Maar wanneer het gaat om http vs. ica vs. LPR verkeer, dan vind ik de packetshaper een overkill. Een paar jaar geleden was ik verantwoordelijk voor een redelijk groot WAN (60 locaties) en daar gebruikten we de packeteer echt alleen als meettool; daarna gebruikten we traffic shaping om dat te bereiken wat we wilden bereiken.

[Verwijderd]

Gebruik thinprint en limiteer die bandbreedte op 128 of 256k
Voor de gebruiker is het alleen een stukje langer wachten op een printje, who cares =)

thinprint gebruikt ica protocol, en stuurd de printjes gecompressed (33%) naar een lokale printserver, die ze vervolgens weer doorstuurd naar lokaal aangemaakte queues, erg goed voor remote locatie's met bandbreedte problemen. Google op thinprint en je zal genoeg handige info vinden.

[ Voor 49% gewijzigd door Verwijderd op 21-01-2009 16:53 ]

[Verwijderd]

Had je ook een thinprint op je 'Verstuur bericht' knop zitten?

[Verwijderd]

Er is een aantal keren gezegd dat QoS end-to-end moet worden geconfigureerd en dat klopt ook. Maar
vergeet niet dat je op gegeven moment het Internet op gaat en je dus ook QoS bij de provider moet afnemen!
Je kunt nog zo mooi iets markeren en prioriteit geven, maar deze markeringen worden door de provider
gewoon weer op nul gezet. Daarnaast moet je gaan werken met pre-tunnel classificaties om te voorkomen
dat je de classes in de VPN tunnel kwijtraakt. Een device kan namelijk niet meer in de encrypted tunnel
kijken, daarom wordt er met pre-tunnel classificaties een extra header gebruikt aan de buitenkant van de
VPN.

Ik zou daarom ook even de provider vragen wat de mogelijkheden zijn hiervoor, maar in 99% van de gevallen
is QoS een dienst, en daar betaal je goed voor.

[Bl@ckbird]

Voordat je het Citrix verkeer de IPSec tunnel in stuurt moet je prioriteit aan het verkeer hangen. (Traffic shaping)
QoS, ook met support vanuit de ISP, over de hele tunnel kan je vergeten. (Daar betaal je idd. dik voor.)

Bovendien zit je met:
- Prioriteit van Citrix verkeer ten opzichte van ander verkeer.
- Prioriteit van printopdrachten binnen Citrix verkeer.

Je moet dus verkeer dieper inspecteren dan de standaard Klasse.
Bij Cisco heb je een feature genaamd NBAR. Je zou hiermee kunnen testen of je dit onderscheid kunt maken.
( Dus tussen algemeen verkeer, Citrix verkeer en Citrix printopdrachten. )

Een Packetshaper kan het. Punt!
Hiermee kan je bijvoorbeeld ook binnen
HTTP verkeer MIME type: JPEG (=plaatjes) een andere prioriteit geven dan standaard HTTP verkeer.

Packeteer is overgenomen door Bluecoat. Er zijn verschillen modellen.
Het 900 model sluit denk ik het beste aan. ( Tenzij je de verbinding in de toekomst wil opschalen. Je neemt dan een grotere Packetshaper met een 2 Mbps licentie, wat je later, licentie technisch, kan verhogen.)

Voor UDP verkeer heb je twee Packetshapers nodig. (UDP is connectionless)
Voor TCP heb je maar 1 Packeteer nodig. (Packetshaper gebruikt o.a. de window size om verkeer te throttelen. En TCP is connection oriented. )

Een Packetshaper laat je een weekje draaien om te kijken welk verkeer op het WAN langs fietst. (En te ontdekken dat de Administrator het meeste via P2P download )

Vervolgens geef je aan welk verkeer prio heeft (zoals VoIP, Citrix, ERP), welk verkeer bulk is en welk verkeer ongewenst is. (Zoals Youtube en/of Flash video, P2P verkeer, wormen)

Met een SDSL lijn met alleen Citrix verkeer is dit makkelijker in te regelen. Maar misschien wil je de SDSL lijn ook gebruiken voor VoIP verkeer. Met een Packetshaper kan je bijvoorbeeld ook compressie tunnels bouwen. Maar bij Citrix verkeer heb je hier niet zo veel aan.