GUP Bandwidth
Hello,
I have a GUP policy setup in SEPM to only use 256kbs (attached screenshot). I would like to monitor and see if this is infact taking place when SEPM is talking to the GUP or when GUP is downloading content from SEPM. I have already looked at SEP Content Distribution Monitor and also the Traffic Monitor Script . SEP content Distribution Monitor doesn't seem to show traffic (bandwidth) utilized on Server 2012 with SEPM 12 RU 2and Traffic Monitor script doesn't run successfully.
Is there a way to do this? I basically need to show management that SEPM is in fact following the 256kbps limit set in the policy.
I have tried taking the WireShark route (attached screenshot) but I do see traffic on port 8014 rising during content downloads on the GUP.
Comments 14 Comments • Jump to latest comment
You would need to use a third party tool, such as wireshark like you're doing, to see this bandwidth. For GUP traffic, you need to look at port 2967 (port GUPs use), not 8014. Wireshark would need to be installed on either the client or the GUP, ideally the GUP.
There is nothing in the SEPM that will show you this.
SEP Knowledge Base
Endpoint SWAT
I have installed wireshark on the GUP itself, GUPs use port 8014 when downloading contents from SEPM or 2967?
When getting content from the SEPM, the GUP and SEPM will talk over 8014. When the clients get content updates from the GUP, it will take place over 2967.
SEP Knowledge Base
Endpoint SWAT
ok and that is what I am trying to find out.
When gup is getting the contents from SEPM on port 8014, how much bandwidth is it using. Is the bandwidth limitation in the plicy when GUP is transferring the files to clients on port 2967 or when GUP is getting the content download from SEPM. I am pretty sure it is for when GUP is getting the content download from SEPM on 8014. Agree? That is what I am trying see live via the wireshark and just wanted to confirm that there is no Symantec utility to see this.
The bandwidth restriction in the policy will only applies to the GUP/clients. There will be no bandwidth restriction when GUP download content from the SEPM.
Symantec has no tool publicly available that I know of. Not sure if they use something internally.
SEP Knowledge Base
Endpoint SWAT
the bandwidth throttle mentioned in above screen shot is between GUP and SEPM
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
But between gup/clients as well I assume?
SEP Knowledge Base
Endpoint SWAT
No, GUP and SEPM only is what I am being told from Symantec. Below is exactly what Symantec's response is
Which is where I am confused because that contradicts from what I understand of what you said above:
I would take Symantec's word for it. Unfortunately, I cannot find my documentation to back my claim. It was just what I was told during a training course awhile back.Perhaps the instructor was mislead.
If that is what Symantec says than that should be the case.
SEP Knowledge Base
Endpoint SWAT
yes, its between SEPM and GUP. I would also like you to look at this post
http://www.symantec.com/connect/forums/sepm-120-bandwidth-throttling
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Yes, this bandwith trottling setting refers to traffic from SEPM to GUP - please refere to following KB:
http://www.symantec.com/docs/TECH96419
Hi
Agreed with Pete @
Regards
Hello,
Agreed with above..
Thank& Regards,
Ambesh
Please mark your thread as 'SOLVED' with the answer that helps you.
Hi,
Be aware that the Bandwidth limitation on LU GUP Policy settings is expressed in bytes.
Set a value too low can provoke GUP/Clients issue in the situation when the SEP clients need a full.zip defs (and especially when you never allow bypass as the clients will be stuck to out of date defs.
If the value set for the bandwidth limitation is too low, then the GUP will be unable to get a full.zip
It results most of the time on the syling debugging log as HTTP Code 469 TMP. Unpacking error or simply a request failed straight away (10 seconds later the full package has been retrieved).
Indeed, it can result somewhat delay of the client update dispatch compared to your other sites and OUs.
Basically recommended 384kbytes to avoid this type of issue when client need a full.zip (approx 221Mb for SEP 11.X/A bit more for SEP 12.1+).
At least with 256kbytes/sec, it should be fine as longs as the GUP needs to retrieve not big deltas and defs packages. For a full.zip maybe not or if it works, it may take longer time than usual.
Keep in mind that the more new threats coming over the time and the more the definitions size are condamned to increase a bit more over the months, years, ...
Kind Regards,
A. Wesker
Would you like to reply?
Login or Register to post your comment.