Possible bug in 13

Possible bug in 13

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

This may not be a bug. I am messing with something I do not understand
very well. However, I was able to get an error message when trying to
add a rule to QOS. Steps taken:

1. Add parent class

2. Class: 190, Interface Red0, Priority 1, Guaranteed Bandwidth 325,
Maximum Bandwidth 6514, Burst null, Ceil Burst null, TOS 0, Remark
"Daily Data ssh"

3. Add new port rule, tcp source 54555

4. Add new port rule, tcp destination 54555

Red graph now shows error message
  The image "https://10.111.163.1:444/cgi-bin/qos.cgi?red0?hour" can not
be displayed, because it contains errors"

Anything I should to to investigate? Or, possibly I need to simply wait
until the rrd's are updated, in which case I'd think the error message
should read "updating" or something.

Rod
-- 
R. W. "Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
http://www.dailydata.net
214.827.2170

Re: Possible bug in 13

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

Hey,

firstly, check if the system's clock is set correctly. Normally there is
the NTP server which does the job.

Secondly, wait. The graphs will take some time to show up.

Michael

On Sun, 2012-09-09 at 15:25 -0500, R. W. Rodolico wrote:
> This may not be a bug. I am messing with something I do not understand
> very well. However, I was able to get an error message when trying to
> add a rule to QOS. Steps taken:
> 
> 1. Add parent class
> 
> 2. Class: 190, Interface Red0, Priority 1, Guaranteed Bandwidth 325,
> Maximum Bandwidth 6514, Burst null, Ceil Burst null, TOS 0, Remark
> "Daily Data ssh"
> 
> 3. Add new port rule, tcp source 54555
> 
> 4. Add new port rule, tcp destination 54555
> 
> Red graph now shows error message
>   The image "https://10.111.163.1:444/cgi-bin/qos.cgi?red0?hour" can not
> be displayed, because it contains errors"
> 
> Anything I should to to investigate? Or, possibly I need to simply wait
> until the rrd's are updated, in which case I'd think the error message
> should read "updating" or something.
> 
> Rod

Re: Possible bug in 13

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]

Clock is set to pool.ntp.org, with updates, and it is working correctly.
I verified the system clock being set to now.

I have waited over 24 hours, and the graph is not updated yet; still has
the same error message.

Note that even prior to the problem, I was getting nothing on the RED0
graph even under heavy load. The IMQ map was (and still is, apparently)
working correctly.

Possible external problem: I ported this configuration over from a .62
machine that has been extensively played with, and so it is possible
that I have a bad config coming in (even though the it appeared to work
correctly before). Is there a way of clearing the QOS config completely
and allowing a default to be regenerated. I could then try this with a
known, clean config.

Possible ignorance problem: I really don't know what I'm doing. I noted
that class 1xx were on the red interface, so I created a parent class in
that numeric range (109). However, I noted that many classes were
duplicated in the 2xx range (for imq0, which I assume is vpn), and I did
not duplicate the 109 and create a 209. Would that cause this problem?
Is it simply operator error?

I would love to do some additional troubleshooting but if my ignorance
of this subject is causing the problem, I do not want to take away from
other testing.

Rod

On 09/10/2012 03:17 AM, Michael Tremer wrote:
> Hey,
> 
> firstly, check if the system's clock is set correctly. Normally there is
> the NTP server which does the job.
> 
> Secondly, wait. The graphs will take some time to show up.
> 
> Michael
> 
> On Sun, 2012-09-09 at 15:25 -0500, R. W. Rodolico wrote:
>> This may not be a bug. I am messing with something I do not understand
>> very well. However, I was able to get an error message when trying to
>> add a rule to QOS. Steps taken:
>>
>> 1. Add parent class
>>
>> 2. Class: 190, Interface Red0, Priority 1, Guaranteed Bandwidth 325,
>> Maximum Bandwidth 6514, Burst null, Ceil Burst null, TOS 0, Remark
>> "Daily Data ssh"
>>
>> 3. Add new port rule, tcp source 54555
>>
>> 4. Add new port rule, tcp destination 54555
>>
>> Red graph now shows error message
>>   The image "https://10.111.163.1:444/cgi-bin/qos.cgi?red0?hour" can not
>> be displayed, because it contains errors"
>>
>> Anything I should to to investigate? Or, possibly I need to simply wait
>> until the rrd's are updated, in which case I'd think the error message
>> should read "updating" or something.
>>
>> Rod
> 

-- 
R. W. "Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
http://www.dailydata.net
214.827.2170

Re: Possible bug in 13 -- FIXED

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

Ok, something very basic and stupid. I stopped, then started the QOS
service and magically the red0 graph started showing up.

It appears the service must be restarted after making changes.

Sorry for the false report.

Rod

On 09/10/2012 03:17 AM, Michael Tremer wrote:
> Hey,
> 
> firstly, check if the system's clock is set correctly. Normally there is
> the NTP server which does the job.
> 
> Secondly, wait. The graphs will take some time to show up.
> 
> Michael
> 
> On Sun, 2012-09-09 at 15:25 -0500, R. W. Rodolico wrote:
>> This may not be a bug. I am messing with something I do not understand
>> very well. However, I was able to get an error message when trying to
>> add a rule to QOS. Steps taken:
>>
>> 1. Add parent class
>>
>> 2. Class: 190, Interface Red0, Priority 1, Guaranteed Bandwidth 325,
>> Maximum Bandwidth 6514, Burst null, Ceil Burst null, TOS 0, Remark
>> "Daily Data ssh"
>>
>> 3. Add new port rule, tcp source 54555
>>
>> 4. Add new port rule, tcp destination 54555
>>
>> Red graph now shows error message
>>   The image "https://10.111.163.1:444/cgi-bin/qos.cgi?red0?hour" can not
>> be displayed, because it contains errors"
>>
>> Anything I should to to investigate? Or, possibly I need to simply wait
>> until the rrd's are updated, in which case I'd think the error message
>> should read "updating" or something.
>>
>> Rod
> 

-- 
R. W. "Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
http://www.dailydata.net
214.827.2170

Re: Possible bug in 13 -- FIXED

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

Okay,

that looks like qosd, the daemon that is collecting the data for the
graphs, did not start properly.

It would be nice if you could keep an eye on that after reboots. If that
happens again, we need to check what we can do.

I have never had any problems with this.

But still, thank you very much for doing the investigation. :D

Michael

On Mon, 2012-09-10 at 13:51 -0500, R. W. Rodolico wrote:
> Ok, something very basic and stupid. I stopped, then started the QOS
> service and magically the red0 graph started showing up.
> 
> It appears the service must be restarted after making changes.
> 
> Sorry for the false report.
> 
> Rod
> 
> On 09/10/2012 03:17 AM, Michael Tremer wrote:
> > Hey,
> > 
> > firstly, check if the system's clock is set correctly. Normally there is
> > the NTP server which does the job.
> > 
> > Secondly, wait. The graphs will take some time to show up.
> > 
> > Michael
> > 
> > On Sun, 2012-09-09 at 15:25 -0500, R. W. Rodolico wrote:
> >> This may not be a bug. I am messing with something I do not understand
> >> very well. However, I was able to get an error message when trying to
> >> add a rule to QOS. Steps taken:
> >>
> >> 1. Add parent class
> >>
> >> 2. Class: 190, Interface Red0, Priority 1, Guaranteed Bandwidth 325,
> >> Maximum Bandwidth 6514, Burst null, Ceil Burst null, TOS 0, Remark
> >> "Daily Data ssh"
> >>
> >> 3. Add new port rule, tcp source 54555
> >>
> >> 4. Add new port rule, tcp destination 54555
> >>
> >> Red graph now shows error message
> >>   The image "https://10.111.163.1:444/cgi-bin/qos.cgi?red0?hour" can not
> >> be displayed, because it contains errors"
> >>
> >> Anything I should to to investigate? Or, possibly I need to simply wait
> >> until the rrd's are updated, in which case I'd think the error message
> >> should read "updating" or something.
> >>
> >> Rod
> > 
>