I try to do some traffic shapping for a server to control the traffic used by this server over internet, generally this was easy done over our old netscreen/juniper FWs
when i tried to figure it out over our PA 2020, i passed throught a not that the shaping is done only over egress port of the FW.
and there are a document here that explain some senarios when a user is downloading from external server and we want to control the download speed . it explained that the policy should be linked to the local interface for the user as this is the egress interface in case of download. what i don't understand is how the traffic shaping will work as already the packet are received by the ingress interface facing internet and droped at the local egress interface facing the user to shape the traffic, the internet bandwidth in this case will be consumed anyway as shapping happening after packets already received by the FW? or i am missing something !!!
what you describe will happen in case of UDP traffic as there is no congestion mechanism. If the traffic is TCP then the different mechanisms in TCP will make the connection slower in the end and it will occupy less bandwidth - it will work as expected.
In both cases Juniper FW worked almost exactly the same - the traffic shaping took place after data arrived to the firewall.
The point here is that the receiving firewall/switch/router (unless its proxybased) cannot choose or inform in which order the sending device (like the internetrouter your firewall is connected to) should send its packets.
So you must happily accept the order of which the packets arrives on your uplink.
What you are in charge of is in which order your packets will leave your firewall which gives that you can either delay outgoing packets or drop them all together (the later is often least demanding on the device which will perform the QoS and is part of RED shaping - randomly early detection).
So to get the best effect when a user wants to download stuff is to not only delay/drop incoming packets (the actual download) but also the outgoing ack's sent back by the client to the server. When TCP is being used the algoritms at both client but in this case mainly server will adjust the windows being used and also how many packets will be allowed "in transit" (in plain english - the server will slowdown the speed in which the file is being sent at). More advanced QoS engines can alter windowsizes and other stuff to slow down a specific flow in order to not be forced to drop packets on the road.
For the best effect of using QoS you should apply the very same rules in ALL your network equipment - also in the endnodes (the clients and servers themselfs) if possible.
This way prioritized traffic will be prioritized at every hop while traffic you have choosed to prioritize down will only use whats left of the current links.
Of course not all equipment can do QoS based on content so in PA's case you can tag outgoing packets with various QoS classes (DSCP or TOS) so that your switches and routers (who doesnt know if the flow is youtube which you want to prioritize down) will act on the DSCP/TOS fields in each IP packet instead and still be able to prioritize the traffic correctly through your infrastructure.
PS. This subforum is mainly for question regarding the supportportal itself, the proper location for PA question is in KnowledgePoint DS.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!