I found the documentation on what the last byte of a NetBIOS name means. 
Though it's not very "user friendly," here it is:

 redirector name
 main user name
 alias name
 server name

This leads me to believe that RND is a workstation running a 
redirector, which is normal. I think it is quite odd, however, that the 
CDTOWER server sends a datagram to the RND workstation as a broadcast.

If the server were using port 137, which is often used for naming 
announcements, then it wouldn't be weird. But it's using port 138. NetBIOS 
ports are:

137 Name Service
138 Datagram Service
139 Session Service

So what might cause CDTOWER's TCP/IP stack to think that 192.65.2.255 is a 
broadcast? (What might have caused the stack to tell the data-link layer to 
send the frame to the broadcast address?) CDTOWER's own IP address is 
192.65.2.192.

We can't tell the subnet mask from the frames, but anyone have any 
theories? It's good practice in bit-twiddling. There are many possibilities.

How CDTOWER got the IP address for RND to start with is another (harder) 
mystery....

Priscilla

At 04:09 PM 6/26/01, Priscilla Oppenheimer wrote:
>2100 broadcasts in 30 minutes might be OK, actually. Can you tell us how
>much bandwidth they are using? Can you tell us what percentage of the
>packets are broadcasts? A rule of thumb that Cisco teaches is that no more
>than 20% of your packets should be broadcasts. The main problem with
>broadcasts is that they interrupt station CPUs, but with the high-speed of
>CPUs these days, that is less of an issue.
>
>You seem to be running NetBT, which is NetBIOS over TCP/IP. (NetBEUI is
>NetBIOS running directly on a data-link, which is not what you are
>running.) NetBIOS sends lots of broadcasts. In this example, the server
>CDTOWER is sending a broadcast. You need to find out if that is necessary
>on your network or not. It seems a bit odd that CDTOWER is sending the
>frame directly to RND at the NetBIOS layer but to a broadcast address at
>the network and data-link layers. Sometimes a subnet mask misconfiguration
>can cause such a problem. Check CDTOWER and RND's configs.
>
>The last byte of a NetBIOS name tells you what kind of device it is.
>CDTOWER ends with x20, which means server, if I remember correctly. RND
>ends with 0x0 and I have forgotten what that means and my NetBIOS
>documentation is packed away. But you could find this somewhere on the Net
>or one of our esteemed colleagues probably knows.
>
>I don't recognize the other broadcast packets. They have an 802.3 length
>field of 0 even though there's data in the packet. It sounds like a bug?
>Would it be possible to find the station sending them (0:8:c7:d2:4a:ab) and
>check its configuration?
>
>Priscilla
>
>At 05:20 AM 6/26/01, Ramesh c wrote:
> >I did a kind of traffic study on my network and here it goes....
> >
> >1)I get about 2100 broadcast packets in 30minutes.Does that sound a alarm
in
> >my network?
> >
> >---------------------------------------------------------------------
> >2)Most of the Broadcast of this type...
> >57   0.03870  10.65.2.192 -> 10.65.2.255  NBT Datagram Service Type=17
> >Source=CDTOWER[20]
> >
> >ETHER:  ----- Ether Header -----
> >ETHER:
> >ETHER:  Packet 57 arrived at 14:44:47.57
> >ETHER:  Packet size = 266 bytes
> >ETHER:  Destination = ff:ff:ff:ff:ff:ff, (broadcast)
> >ETHER:  Source      = 0:60:b0:b6:b2:62,
> >ETHER:  Ethertype = 0800 (IP)
> >ETHER:
> >IP:   ----- IP Header -----
> >IP:
> >IP:   Version = 4
> >IP:   Header length = 20 bytes
> >IP:   Type of service = 0x00
> >IP:         xxx. .... = 0 (precedence)
> >IP:         ...0 .... = normal delay
> >IP:         .... 0... = normal throughput
> >IP:         .... .0.. = normal reliability
> >IP:   Total length = 252 bytes
> >IP:   Identification = 22165
> >IP:   Flags = 0x0
> >IP:         .0.. .... = may fragment
> >IP:         ..0. .... = last fragment
> >IP:   Fragment offset = 0 bytes
> >IP:   Time to live = 64 seconds/hops
> >IP:   Protocol = 17 (UDP)
> >IP:   Header checksum = 091c
> >IP:   Source address = 192.65.2.192, 192.65.2.192
> >IP:   Destination address = 192.65.2.255, 192.65.2.255
> >IP:   No options
> >IP:
> >UDP:  ----- UDP Header -----
> >UDP:
> >UDP:  Source port = 138
> >UDP:  Destination port = 138 (NBDG)
> >UDP:  Length = 232
> >UDP:  Checksum = 0000 (no checksum)
> >UDP:
> >NBT:  ----- Netbios Datagram Service Header -----
> >NBT:
> >NBT:  Datagram Packet Type = 0x11
> >NBT:  Datagram Flags = 0x0a
> >NBT:  Datagram ID = 0xb367
> >NBT:  Source IP = 192.65.2.192
> >NBT:  Source Port = 138
> >NBT:  Datagram Length = 0x00d2
> >NBT:  Packet Offset = 0x0000
> >NBT:  Source Name = CDTOWER[20]
> >NBT:  Destination Name = RND[0]
> >NBT:  Number of data bytes remaining = 142
> >NBT:
> >
> >Is this a normal behaviour or do I need to remove netbeui protocol?
> >--------------------------------------------------------------------
> >
> >3)Another type od Broadcast packet
> >509   0.28533            ? -> (broadcast)  ETHER Type=0000 (LLC/802.3),
size
> >= 110 bytes
> >510   1.54573            ? -> (broadcast)  ETHER Type=0000 (LLC/802.3),
size
> >= 110 bytes
> >511   0.72617            ? -> (broadcast)  ETHER Type=0000 (LLC/802.3),
size
> >= 110 bytes
> >
> >ETHER:  ----- Ether Header -----
> >ETHER:
> >ETHER:  Packet 511 arrived at 14:51:52.90
> >ETHER:  Packet size = 110 bytes
> >ETHER:  Destination = ff:ff:ff:ff:ff:ff, (broadcast)
> >ETHER:  Source      = 0:8:c7:d2:4a:ab,
> >ETHER:  IEEE 802.3 length = 96 bytes
> >ETHER:  Ethertype = 0000 (LLC/802.3)
> >ETHER:
> >
> >What is this broadcast packet trying to do?Or how do i debug this for more
> >info.
> >
> >Any help would be appricated
> >
> >Cheers
> >Ramesh
>
>
>________________________
>
>Priscilla Oppenheimer
>http://www.priscilla.com
________________________

Priscilla Oppenheimer
http://www.priscilla.com




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=10012&t=9944
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to