I’m getting a different interesting
result with authentication traps. NV 7.1.4 FP03 RH 3
TCPDUMP shows me problems where the
community string is not present in the request, the packet is flagged as having
a bad ucp checksum and the router end sends in traps and log entries claiming
it’s an authentication failure. Sometimes I get flagged with a bad upd
checksum even when there is a community string.
The visible result is that the map
turns red because the particular cisco 6000 series device is not successfully
polled. This happens intermittently; every couple days as a rule. Here’s
a sample:
22:08:24.225152
goshawk2.41186 > A0346K2.snmp:
{
SNMPv1 C=CommString { GetRequest(33)
R=1221173957
interfaces.ifTable.ifEntry.ifAdminStatus.341[|snmp]}
}
(DF)
(ttl 64, id 0, len 445)
22:08:24.227560
A0346K2.snmp > goshawk2.41185:
{
SNMPv1 C=CommString { GetResponse(33)
R=1221173956
interfaces.ifTable.ifEntry.ifAdminStatus.1=1}
}
(ttl
255, id 22797, len 421)
22:08:24.229023
goshawk2.41187 > A0346K2.snmp:
{
SNMPv1 C=CommString { GetRequest(33)
R=1221173958
interfaces.ifTable.ifEntry.ifAdminStatus.224[|snmp]}
}
(DF)
(ttl 64, id 0, len 331)
22:08:24.230614
A0346K2.snmp > goshawk2.41186:
{
SNMPv1 C=CommString { GetResponse(33)
R=1221173957
interfaces.ifTable.ifEntry.ifAdminStatus.341=0}
}
(ttl
255, id 22798, len 425)
22:08:24.231945
A0346K2.snmp > goshawk2.41187:
{
SNMPv1 C=CommString { GetResponse(33)
R=1221173958
interfaces.ifTable.ifEntry.ifAdminStatus.224=1}
}
(ttl
255, id 22799, len 316)
22:08:42.085860
goshawk2.35443 > A0346K2.snmp: [bad udp cksum
51e3!]
{
SNMPv1 { GetRequest(27) R=104669
interfaces.ifNumber.0}
} (DF) (ttl 64, id 15988, len 70)
22:08:45.441257
goshawk2.35443 > A0346K2.snmp: [bad udp cksum
51e3!]
{
SNMPv1 { GetRequest(27) R=104669
interfaces.ifNumber.0}
} (DF) (ttl 64, id 16057, len 70)
22:08:47.728274
goshawk2.35443 > A0346K2.snmp: [bad udp cksum
51e3!]
{
SNMPv1 { GetRequest(27) R=104669
interfaces.ifNumber.0}
} (DF) (ttl 64, id 16090, len 70)
22:11:40.500053
goshawk2.35443 > A0346K2.snmp: [bad udp cksum
f7e0!]
{
SNMPv1 { GetRequest(27) R=105016
system.sysObjectID.0}
} (DF) (ttl 64, id 16358, len 70)
22:11:42.510787
goshawk2.35443 > A0346K2.snmp: [bad udp cksum
f7e0!]
{
SNMPv1 { GetRequest(27) R=105016
system.sysObjectID.0}
} (DF) (ttl 64, id 16359, len 70)
22:11:44.509804
goshawk2.35443 > A0346K2.snmp: [bad udp cksum
f7e0!]
{
SNMPv1 { GetRequest(27) R=105016
system.sysObjectID.0}
} (DF) (ttl 64, id 16360, len 70)
22:11:46.518786
goshawk2.35443 > A0346K2.snmp: [bad udp cksum
d38b!]
{
SNMPv1 C=CommString { GetRequest(27)
R=105016
system.sysObjectID.0}
} (DF) (ttl 64, id 16364, len 72)
22:11:46.520002
A0346K2.snmp > goshawk2.35443: [udp sum ok]
{
SNMPv1 C=CommString { GetResponse(36)
R=105016
system.sysObjectID.0=E:cisco.1.400}
} (ttl 255, id 24865, len 81)
22:11:46.521230
goshawk2.35443 > A0346K2.snmp: [bad udp cksum
cf8c!]
{
SNMPv1 C=CommString { GetRequest(27)
R=105020
system.sysDescr.0}
} (DF) (ttl 64, id 16365, len 72)
22:11:46.521964
A0346K2.snmp > goshawk2.35443:
{
SNMPv1 C=CommString { GetResponse(33)
R=105020
system.sysDescr.0="C"}
} (ttl 255, id 24866, len 336)
22:11:46.522574
goshawk2.35443 > A0346K2.snmp: [bad udp cksum
ce88!]
{
SNMPv1 C=CommString { GetRequest(27)
R=105021
system.sysName.0}
} (DF) (ttl 64, id 16366, len 72)
22:11:46.523144
A0346K2.snmp > goshawk2.35443:
{
SNMPv1 C=CommString { GetResponse(37)
R=105021
system.sysName.0="A0346K2.nm"}
} (ttl 255, id 24867, len 92)
22:11:46.523689
goshawk2.35443 > A0346K2.snmp: [bad udp cksum ca8c!]
{
SNMPv1 C=CommString { GetRequest(27)
R=105022
ip.ipForwarding.0}
} (DF) (ttl 64, id 16367, len 72)
These
periods of missing community strings are always associated with reported
(false) router critical states. I’ve been capturing tcpdump and netmon
traces with an eye to opening a PMR. Any ideas or similar symptoms from a
different cause?
-----Original Message-----
From: owner-nv-l AT lists.us.ibm DOT com
[mailto:owner-nv-l AT lists.us.ibm DOT com] On
Behalf Of Glen Warn
Sent: Tuesday, August 30, 2005
2:40 PM
To: nv-l AT lists.us.ibm DOT com
Subject: [nv-l] Authentication
failure traps from Windows clients
Running 7.1.4 FP3 on Redhat AS2.1
I am being bombarded with auth
failure traps from some of my Windows 200x servers (not even a
majority). Odd part is I can do a demand poll and run a sniffer
trace at the same time. I see the poll run successfully (using
the appropriate RO community string) then the same server issue an auth
failure trap back to Netview (I have all my servers set to do this so I can
detect rogue queries) None of my traces reveal any other boxes trying to
run queries (what I had assumed in the beginning)
I think this has been happening for
a long time (all along?) but just became aware of a big problem because I
accidentally hidden from myself thru event configuration (setting to
"Don't display or Log") that I used a long time ago to debug
something but never reverted.
Any ideas? I have tried
changing the comm strings to something basic, put in a host specific snmp
config, etc. The devices are scattered across 5 different companies and
dozens of subnets.
In the mean time, I believe this
flood of traps is severely hampering Netviews ability to process other traps
(because there are so many coming in non-stop)
Glen Warn
PEMCO Corporation Computer Services
(PCCS)
glen.warn AT pemcocorp DOT com
206-628-5770
