Nathan,
yes, "sysUpTime" wraps after 496 days. However, "snmpEngineTime"
should not wrap before 68 years(or 135 years according to Cisco
documentation). However, my issue is that they both seem to wrap at
the same time.
Chuck,
I think I have this bug:
https://quickview.cloudapps.cisco.com/quick
On 06/04/17 17:01, Martin T wrote:
Or is it simply a buggy "snmpEngineTime"
implementation which wraps with the "sysUpTime" because to be more
precise, then according to "sh ver" switch has been up for 6 years, 11
weeks, 2 days and 8 hours which is roughly 196243200 seconds so it
could have wrapp
I'm not sure if the snmpenginetime wrapping would increment the
snmpEngineBoots, but it would make sense that it would. If that is the
case, there are definitely bugs from a 8 or so years ago where devices
didn't update their snmpEngineBoots counter upon reload. So you'd reboot
switch, snmpEngine
> How to explain this behavior? Is it likely some kind of SNMP agent
I may not have this totally right, but I believe sysUpTime is a 32-bit
value, which will only go out about 400 and some odd days before it
wraps to 0.
___
cisco-nsp mailing list cisco-
Hi,
if someone is interested in debugging a SNMP agent related issue on
more than a decade old switch, then I have a WS-C2924-XL with IOS
12.0(5)WC14 with an uptime of more than 6 years, but with
"snmpEngineTime" of 280 days. In fact, both "sysUpTime"(unit is
centiseconds) and "snmpEngineTime"(uni
Hi,
A cursory look appears to suggest that your configuration is incorrect. The
example from the Support Forum link you referenced seems to corroborate that?
ipv4 access-list abf-1
10 permit ipv4 any 100.100.100.0/24 nexthop1 VRF RED ipv4 1.1.1.1 nexthop2 VRF
BLUE ipv4 2.2.2.2 nexthop3 ipv4
Hi All,
I have a ASR9K1 with IOS XR 4.3.2 . Yes i know it is an old image, but
rock stable in our environment.
Today a made a source based routing: if the source packet is comming
from 1.1.1.0/24 range the nexthop have to be 2.2.2.2
The config is this:
RP/0/RSP0/CPU0:asr01#sh run interface
