Video Screencast Help

GUP Bandwidth

Created: 11 Jan 2013 • Updated: 13 Jan 2013 | 14 comments

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.

 

Discussion Filed Under:

Comments 14 CommentsJump to latest comment

.Brian's picture

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.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Adamster's picture

I have installed wireshark on the GUP itself, GUPs use port 8014 when downloading contents from SEPM or 2967?

.Brian's picture

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.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Adamster's picture

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.

 

.Brian's picture

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.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

pete_4u2002's picture

the bandwidth throttle mentioned in above screen shot is between GUP and SEPM

.Brian's picture

But between gup/clients as well I assume?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Adamster's picture

No, GUP and SEPM only is what I am being told from Symantec.  Below is exactly what Symantec's response is

The bandwidth throttle happens when the GUP downloads content from SEPM. There is no throttling from the client to the GUP as it is assumed it is on the same segment.

To add to that, there is no throttling from the Client to the SEPM.

Which is where I am confused because that contradicts from what I understand of what you said above:

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.

 

 

.Brian's picture

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.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

SebastianZ's picture

Yes, this bandwith trottling setting refers to traffic from SEPM to GUP - please refere to following KB:

http://www.symantec.com/docs/TECH96419

SameerU's picture

Hi

Agreed with Pete @

Regards

 

Ambesh_444's picture

Hello,

Agreed with above..

 

Thank& Regards,

Ambesh

"Your satisfaction is very important to us. If you find above information helpful or it has resolved your issue. Please don't forget to mark the thread as solved."

A. Wesker's picture

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