Re: [nv-l] NetView Multicast

[Paul <pstroud@bellsouth.net>]

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