and can't speak for TAC, take it
for what it is worth.
Jim
-Original Message-
From: cisco-nsp On Behalf Of Nick Hilliard
Sent: Tuesday, October 13, 2020 7:04 AM
To: Tim Rayner
Cc: cisco-nsp
Subject: Re: [c-nsp] EOBC0/0 ifInErrors
Tim Rayner wrote on 13/10/2020 10:48:
> If the EOBC
Tim Rayner wrote on 13/10/2020 10:48:
If the EOBC0/0 interface that you're seeing runts on is running as full
duplex, and the interface that it connects to is running at half duplex,
that would do it, but EOBC is an internal interface which is h/d by
default. I'm not sure if it's even
Eugene Grosbein wrote on 12/10/2020 20:28:
> It seems so:
[...]
>Tx Errors/State:
> One Collision Error = 306656 More Collisions = 1209541
[...]
> Input Errors = 28517
> Output Drops = 0Giants/Runts = 0/28517
> uh, obviously
Eugene Grosbein wrote on 12/10/2020 20:28:
It seems so:
[...]
Tx Errors/State:
One Collision Error = 306656 More Collisions = 1209541
[...]
Input Errors = 28517
Output Drops = 0Giants/Runts = 0/28517
uh, obviously
13.10.2020 2:18, Nick Hilliard wrote:
> Eugene Grosbein wrote on 12/10/2020 20:11:
>> I'm not sure how and where I can get counters for errs-in/runts-in of
>> EOBC0/0.
>
> "show platform eobc all" - see the "Giants / Runts" counters.
Another box show similar picture:
Counters collected at
13.10.2020 2:18, Nick Hilliard wrote:
> Eugene Grosbein wrote on 12/10/2020 20:11:
>> I'm not sure how and where I can get counters for errs-in/runts-in of
>> EOBC0/0.
>
> "show platform eobc all" - see the "Giants / Runts" counters.
>
>> Also, I have another similar 7606 box with two excactly
Eugene Grosbein wrote on 12/10/2020 20:11:
I'm not sure how and where I can get counters for errs-in/runts-in of
EOBC0/0.
"show platform eobc all" - see the "Giants / Runts" counters.
Also, I have another similar 7606 box with two excactly same RSP
modules and its SNMP counters for EOBC0/0
12.10.2020 23:12, Nick Hilliard wrote:
> Eugene Grosbein wrote on 12/10/2020 10:07:
>> Forgot show show that moment:
>>
>> http://www.grosbein.net/cisco/eobc0_0-inc.png
>>
>> Both graps show same value, upper graph shows maximum over an hour, lower
>> (blue) is an average over an hour.
>>
>>>
Eugene Grosbein wrote on 12/10/2020 10:07:
Forgot show show that moment:
http://www.grosbein.net/cisco/eobc0_0-inc.png
Both graps show same value, upper graph shows maximum over an hour, lower
(blue) is an average over an hour.
Today at 12:16 another one (now inactive) RSP module was
12.10.2020 15:59, Eugene Grosbein wrote:
> You have dual supervisor on this box.
> Can you do a failover to the secondary and see if that stops the input
> errors?
> This will localise the problem
Do I need to disable NSF (non-stop forwarding) to localise the problem?
02.10.2020 15:00, Eugene Grosbein wrote:
>>> 01.10.2020 17:49, Nick Hilliard wrote:
>>>
You have dual supervisor on this box.
Can you do a failover to the secondary and see if that stops the input
errors?
This will localise the problem
>>>
>>> Do I need to disable NSF
02.10.2020 15:22, Nick Hilliard wrote:
> Gert Doering wrote on 02/10/2020 09:16:
>> Well, if the now-active RSP is the one with the faulty EOBC link,
>> this is what would happen - by removing the standby RSP, you removed
>> a lot of traffic on the EOBC bus (session sync etc).
>
> i.e. next
Gert Doering wrote on 02/10/2020 09:16:
Well, if the now-active RSP is the one with the faulty EOBC link,
this is what would happen - by removing the standby RSP, you removed
a lot of traffic on the EOBC bus (session sync etc).
i.e. next step: re-insert the standby rsp, fail over to it and see
Hi,
On Fri, Oct 02, 2020 at 03:00:05PM +0700, Eugene Grosbein wrote:
> Instead, error rate decreased significantly but not ceased (12:25 was the
> moment):
> http://www.grosbein.net/cisco/eobc0_0-day.png
Well, if the now-active RSP is the one with the faulty EOBC link,
this is what would
02.10.2020 15:00, Eugene Grosbein wrote:
You have dual supervisor on this box.
Can you do a failover to the secondary and see if that stops the input
errors?
This will localise the problem
>>>
>>> Do I need to disable NSF (non-stop forwarding) to localise the problem?
>>> I
02.10.2020 12:24, Eugene Grosbein wrote:
>> 01.10.2020 17:49, Nick Hilliard wrote:
>>
>>> You have dual supervisor on this box.
>>> Can you do a failover to the secondary and see if that stops the input
>>> errors?
>>> This will localise the problem
>>
>> Do I need to disable NSF (non-stop
02.10.2020 12:16, Eugene Grosbein wrote:
> 01.10.2020 17:49, Nick Hilliard wrote:
>
>> You have dual supervisor on this box.
>> Can you do a failover to the secondary and see if that stops the input
>> errors?
>> This will localise the problem
>
> Do I need to disable NSF (non-stop forwarding)
01.10.2020 17:49, Nick Hilliard wrote:
> You have dual supervisor on this box.
> Can you do a failover to the secondary and see if that stops the input errors?
> This will localise the problem
Do I need to disable NSF (non-stop forwarding) to localise the problem?
I guess both RSP should
01.10.2020 17:49, Nick Hilliard пишет:
> this looks interesting:
>
>> Counters collected at Idb:
>>Input Errors = 3199810 Output Drops = 0
>> Giants/Runts = 0/3199810
>
> runts are packets which smaller than the minimum packet size, i.e. this
Eugene Grosbein wrote on 01/10/2020 09:58:
http://www.grosbein.net/cisco/eobc.txt
this looks interesting:
Counters collected at Idb:
Input Errors = 3199810
Output Drops = 0Giants/Runts = 0/3199810
runts are packets which smaller than the
01.10.2020 15:36, Nick Hilliard wrote:
> Can you post the output of "show eobc"?
>
> eobc is the ethernet out-of-band connector and is the main control plane
> communication mechanism between the sup and the line cards. If you're seeing
> errors on the link, then this probably means that
Eugene Grosbein wrote on 01/10/2020 03:23:
This 7606 is the core router of our network, it runs for many years
without visible problems and current uptime's over 1 year. It would
be hard doing such things with the core without any evidences other
than some counter increasing.
At the moment, all
01.10.2020 3:03, Nick Hilliard wrote:
> Aaron wrote on 30/09/2020 20:11:
>> He is suggesting reseating all cards. Starting with the Supervisor.
>
> correct. power down the box, carefully reseat all cards, power up, see if
> that fixes it.
>
> If it doesn't fix it, then open a TAC case. If the
you could deduce if it is a line card or by adding 1 line card at a time.
On Wednesday, September 30, 2020, Nick Hilliard wrote:
> Aaron wrote on 30/09/2020 20:11:
>
>> He is suggesting reseating all cards. Starting with the Supervisor.
>>
>
> correct. power down the box, carefully reseat all
Aaron wrote on 30/09/2020 20:11:
He is suggesting reseating all cards. Starting with the Supervisor.
correct. power down the box, carefully reseat all cards, power up, see
if that fixes it.
If it doesn't fix it, then open a TAC case. If the unit isn't under
support, then you have a
You may need to ask TAC. Unfortunately I do not know.
He is suggesting reseating all cards. Starting with the Supervisor.
On Wed, Sep 30, 2020 at 10:14 AM Eugene Grosbein wrote:
> 30.09.2020 19:03, Nick Hilliard wrote:
>
> > Eugene Grosbein wrote on 30/09/2020 05:14:
> >> Yesterday I've
30.09.2020 19:03, Nick Hilliard wrote:
> Eugene Grosbein wrote on 30/09/2020 05:14:
>> Yesterday I've created mrtg graph for the counter and it shows steady rate
>> in a range of 16-32 per second.
>
> I'd say that is sup + line card reseating territory.
What does it mean?
Eugene Grosbein wrote on 30/09/2020 05:14:
Yesterday I've created mrtg graph for the counter and it shows steady rate in a
range of 16-32 per second.
I'd say that is sup + line card reseating territory.
Nick
___
cisco-nsp mailing list
29.09.2020 20:44, Aaron wrote:
> sharp increase recently (weekly, daily, hourly). I'd be more concerned with
> daily and hourly (or less).
> How frequently do you see them and what is the amount?
Yesterday I've created mrtg graph for the counter and it shows steady rate in a
range of 16-32
sharp increase recently (weekly, daily, hourly). I'd be more concerned
with daily and hourly (or less).
How frequently do you see them and what is the amount?
On Tue, Sep 29, 2020 at 9:41 AM Eugene Grosbein wrote:
> 29.09.2020 18:56, Nick Hilliard wrote:
>
> > Eugene Grosbein wrote on
29.09.2020 18:56, Nick Hilliard wrote:
> Eugene Grosbein wrote on 29/09/2020 10:08:
>> Walking SNMP ifTable for Cisco 7606/RSP720-3C-GE I've found that virtual
>> interface EOBC0/0 (Ethernet out-of-band channel) has increasing counter
>> IF-MIB::ifInErrors.
>> No visible problems with the box,
Eugene Grosbein wrote on 29/09/2020 10:08:
Walking SNMP ifTable for Cisco 7606/RSP720-3C-GE I've found that virtual
interface EOBC0/0 (Ethernet out-of-band channel) has increasing counter
IF-MIB::ifInErrors.
No visible problems with the box, though.
Should I worry about this ifInErrors growth?
Hi!
Walking SNMP ifTable for Cisco 7606/RSP720-3C-GE I've found that virtual
interface EOBC0/0 (Ethernet out-of-band channel) has increasing counter
IF-MIB::ifInErrors.
No visible problems with the box, though.
Should I worry about this ifInErrors growth?
33 matches
Mail list logo
