nv-l
[Top] [All Lists]

Re: [nv-l] NetView Multicast

To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] NetView Multicast
From: Paul <pstroud@bellsouth.net>
Date: Sat, 13 Dec 2003 11:20:36 -0500
Delivery-date: Sat, 13 Dec 2003 16:36:13 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <42AF0749A8EB7448A661EC423CBE76FA01EDAD89@pbswmu00003.corp.pep.pvt>
References: <42AF0749A8EB7448A661EC423CBE76FA01EDAD89@pbswmu00003.corp.pep.pvt>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3
Scott,
Have you traced netmon(netmon -M -1) to see if he is actually
sending it? It should be a fairly simple process to find I
would think. This just doesn't sound like netmon behavior,
not that netmon doesn't do weird things sometimes, but I
would NOT expect it to send to a mutlticast address without
some human prompting;-) Do you have discovery turned on? Do
you have a limiter in your seedfile?

The reason I ask is I took apart the packet and this it what
I got.

Decoding: 30818a02010004067075626c6963a17d020373a7380201000201003070300e060a2b0601020102020101010500300e060a2b0601020102020106010500300e060a2b0601020102020103010500300e060a2b0601020102020102010500300e060a2b0601020102020107010500300e060a2b0601020102020108010500300e060a2b0601020102020105010500
Integer: 0
StringHex: 7075626c6963 String: public
Block: 0xa17d020373a7380201000201003070300e060a2b0601020102020101010500300e060a2b0601020102020106010500300e060a2b0601020102020103010500300e060a2b0601020102020102010500300e060a2b0601020102020107010500300e060a2b0601020102020108010500300e060a2b0601020102020105010500
   Integer: 7579448
   Integer: 0
   Integer: 0
Block: 0x3070300e060a2b0601020102020101010500300e060a2b0601020102020106010500300e060a2b0601020102020103010500300e060a2b0601020102020102010500300e060a2b0601020102020107010500300e060a2b0601020102020108010500300e060a2b0601020102020105010500
      Block: 0x300e060a2b0601020102020101010500
         ObjectID: .1.3.6.1.2.1.2.2.1.1.1(ifIndex)
         NULL
      Block: 0x300e060a2b0601020102020106010500
         ObjectID: .1.3.6.1.2.1.2.2.1.6.1(ifPhyAddress)
         NULL
      Block: 0x300e060a2b0601020102020103010500
         ObjectID: .1.3.6.1.2.1.2.2.1.3.1(ifType)
         NULL
      Block: 0x300e060a2b0601020102020102010500
         ObjectID: .1.3.6.1.2.1.2.2.1.2.1(ifDescr)
         NULL
      Block: 0x300e060a2b0601020102020107010500
         ObjectID: .1.3.6.1.2.1.2.2.1.7.1(ifAdminStatus)
         NULL
      Block: 0x300e060a2b0601020102020108010500
         ObjectID: .1.3.6.1.2.1.2.2.1.8.1(ifOperStatus)
         NULL
      Block: 0x300e060a2b0601020102020105010500
         ObjectID: .1.3.6.1.2.1.2.2.1.5.1(ifSpeed)
         NULL

This looks like a first run discovery. The busrt of these
you see could be netmon walking the communityNames.conf
file with each community name. If you do not have your
discovery limited, if netmon were to find this address
in say an arp cache, its likely that it would try to
discovery it(I could be mistaken), but this is kind of
what it looks like might be happening to me.

Thoughts.....


Paul


Bursik, Scott {PBSG} wrote:
I don't have any 3rd party products installed. That address is not in the
NetView databases. That address is a broadcast address for local segment.

Scott Bursik
PepsiCo Business Solutions Group
Enterprise Systems Management
scott.bursik@pbsg.com
(972) 963-1400
-----Original Message-----
From: Oliver Bruchhaeuser [mailto:oliver.bruchhaeuser@de.ibm.com] Sent: Friday, December 12, 2003 2:14 AM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] NetView Multicast


Scott,

if NetView is sending "whatever" to 224.0.0.1 the address must be in the
database (maybe as a wrong configured interface).
What is the output of "ovtopodump 224.0.0.1"?

Do you have any other (third party) products installed on the same machine.
I remember some printer management tools are doing "active" discovery.

Kind regards

Oliver Bruchhaeuser
Tivoli NetView EMEA L2 Support



|---------+---------------------------->
|         |           "Bursik, Scott   |
|         |           {PBSG}"          |
|         |           <Scott.Bursik@pbs|
|         |           g.com>           |
|         |           Sent by:         |
|         |           owner-nv-l@lists.|
|         |           us.ibm.com       |
|         |                            |
|         |                            |
|         |           11.12.2003 22:02 |
|         |           Please respond to|
|         |           nv-l             |
|         |                            |
|---------+---------------------------->
---------------------------------------------------------------------------

---------------------------------------|
  |
|
  |       To:       "'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>
|
  |       cc:
|
  |       Subject:  RE: [nv-l] NetView Multicast
|
  |
|
  |
|
---------------------------------------------------------------------------

---------------------------------------|



I am still working this issue with IBM but I was wondering if any of you
have seen this on your machines? From some of the research I have been
doing, the destination address in the captured packet from below is a
broadcast for the local subnet. This of course means that when NV
broadcasts
the community name of "public" to the entire subnet, I get authentication
traps from any machine on that subnet that isn't configured with "public".
I
find this to be odd behavior.

This is a packet I have sniffed from a machine that is sending the
Authentication Failure traps. He is sending them on intervals of about an
hour and when he sends them he broadcast about 80 of these packets causing
a
nice event storm in the trapd.log.

====( 85 bytes received on interface en0 )==== 10:51:18.040781434
ETHERNET packet : [ 00:02:55:76:27:d6 -> 01:00:5e:00:00:01 ]  type 800
(IP)
IP header breakdown:
             < SRC =   156.81.227.16 >  (netviewserver.fritolay.pvt)
             < DST =       224.0.0.1 >  (ALL-SYSTEMS.MCAST.NET)
             ip_v=4, ip_hl=20, ip_tos=0, ip_len=71, ip_id=19687, ip_off=0
             ip_ttl=1, ip_sum=d5c, ip_p = 17 (UDP)
UDP header breakdown:
             <source port=39803, <destination port=161(snmp) >
             [ udp length = 51 | udp checksum = 69b9 ]
00000000     30290201 00040670 75626c69 63a01c02     |0).....public...|
00000010     0400cda4 fd020100 02010030 0e300c06     |...........0.0..|
00000020     082b0601 02010401 000500                |.+.........     |

Scott Bursik
PepsiCo Business Solutions Group
Enterprise Systems Management


-----Original Message-----
From: Barr, Scott [mailto:Scott_Barr@csgsystems.com]
Sent: Wednesday, December 10, 2003 2:06 PM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] NetView Multicast

To the best of my knowledge you should NEVER see a multi-cast on port 161.
This definately sounds like a bug. If it is, it would explain a problem I
have been working on where my content switches sqwauk about authentication
failures but I Never see a bad packet go out. I havent' been monitoring
broadcast subnet but I will. Results soon.

-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On
Behalf Of Bursik, Scott {PBSG}
Sent: Wednesday, December 10, 2003 1:57 PM
To: Nv-L (nv-l@lists.us.ibm.com)
Subject: [nv-l] NetView Multicast


In an effort to troubleshoot Authentication Trap Failure errors I have
started sniffing one of the machines that is sending these events. I
noticed
a LOT of traps coming in at one time on my NetView box from that machine
and
the below sample is the cause of the Auth. Failure traps. I searched the
archives and see one thread talking about this condition but there was no
resolution and the address showing in packet is the same as that thread.

Here is the thread I read:

http://lists.skills-1st.co.uk/mharc/html/nv-l/1999-08/msg00259.html

Any ideas?


====( 183 bytes received on interface en0 )==== 12:50:21.634682865
ETHERNET packet : [ 00:02:55:76:27:d6 -> 01:00:5e:00:00:01 ]  type 800
(IP)
IP header breakdown:
             < SRC =   156.81.227.16 >  (pbsxsn00001.fritolay.pvt)
             < DST =       224.0.0.1 >  (ALL-SYSTEMS.MCAST.NET)
             ip_v=4, ip_hl=20, ip_tos=0, ip_len=169, ip_id=24043, ip_off=0
             ip_ttl=1, ip_sum=fbf5, ip_p = 17 (UDP)
UDP header breakdown:
             <source port=39803, <destination port=161(snmp) >
             [ udp length = 149 | udp checksum = 4612 ]
00000000     30818a02 01000406 7075626c 6963a17d     |0.......public.}|
00000010     020373a7 38020100 02010030 70300e06     |..s.8......0p0..|
00000020     0a2b0601 02010202 01010105 00300e06     |.+...........0..|
00000030     0a2b0601 02010202 01060105 00300e06     |.+...........0..|
00000040     0a2b0601 02010202 01030105 00300e06     |.+...........0..|
00000050     0a2b0601 02010202 01020105 00300e06     |.+...........0..|
00000060     0a2b0601 02010202 01070105 00300e06     |.+...........0..|
00000070     0a2b0601 02010202 01080105 00300e06     |.+...........0..|
00000080     0a2b0601 02010202 01050105 00           |.+...........   |


Thanks,

Scott Bursik
PepsiCo






<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web