You bring up some good points. NetBIOS over TCP with WINS doesn't need to broadcast that much, though. And to reiterate my original point, a GHz CPU doesn't care that much anyway. (Broadcasts are usually tiny packets, so the issue isn't bandwidth usage, it's the interruption of CPUs.)
Here's how I understand broadcasting on Windows networks..... Windows 95/98/ME uses WINS. Windows 2000 uses the Dynamic Domain Name System (DDNS) protocol. DHCP can return the address of the WINS or DDNS server so there's no need to broadcast to find it. (Of course DHCP itself broadcasts, so that has to be in the equation. But DHCP is not very persistent with its broadcasts). If you configure a host to be a point-to-point P-Node it can talk directly to its WINS or DDNS server. To register its own NetBIOS name, a client sends a Name Query frame to the WINS or DDNS server. To find the IP address associated with a NetBIOS name, a client sends a Name Query frame to the WINS or DDNS server. As far as the Browse process, a station broadcasts when it boots to find the master browser. If stations go through a master browser election, then extra broadcasting happens, I think, but you can configure a station to not participate in the election to reduce this. Also, each host that's offering services broadcasts a Host Announcement frame every minute for the first several minutes after booting, and then every 12 minutes thereafter, to keep the master browser's list up-to-date. The subnet master browser sends a copy of the browse list to each backup browser every 15 minutes. Each subnet master browser exchanges browse lists with the domain master browser every 12 minutes. (I don't know if those are broadcasts?) This might all sound bad, but it's really not that bad..... ;-] Funny you should mention it, but I consult for a network that is 10.0.0.0/16. Now, I would not have designed the network that way, but it does work. They have Windows, IPX, AppleTalk, you name it. There aren't really 65,000 nodes (thankfully) but there are about 700. The performance is fine, so far, keep your fingers crossed. On a network that isn't huge to start with and that has fast switches and workstation CPUs, and methods to control the Windows monsters, I'm not convinced that broadcasts are so much of an issue. And, I think that VLANs may be more hassle than they are worth in some situations. Your mileage may vary, of course! The tests that Cisco did (that are the basis for their design guides, etc.) showed that a few hundred broadcasts per second caused noticeable CPU usage. But that's a lot of broadcasts and Cisco did those tests in the early 1990s. The CPUs were slow as molasses back then and the NICs didn't handle multicasts correctly. (Macintosh NICs did, but not PCs.) I don't know if that is fixed or not. Thanks for the discussion! ;-) Priscilla At 08:20 PM 10/24/01, Carroll Kong wrote: >I cut a large portion of this the previous message. My argument >in that is that, we DO have broadcasting monsters. It is known as Windows >based PCs. NetBIOS over TCP/IP, announcing wondrous information and trying >to get information so they can perform their wonderful elections and create >master browsers. Trying to resolve NetBIOS names so they can find their >friendly PDC or BDC of the day. Or how about WINS and it's excellent >method of doing discerning which names goes where. All automagic at the >cost of the network. While what you speak is true, and in a network bereft >of windows mongers, I would agree, I think that in a modern system you can >still run into issues. According to your logic, it seems like you would be >ok with forging a 10.0.0.0/16 network and chaining along switches instead >of breaking them into subnets along with their accused VLANs. I suppose >with enough good 10/100 Switches you are ok. This might be problematic on >a 10BaseT network as the broadcast snowball into huge gobs of bandwidth >draining gunk. (I guess this rolls into the non-modern network though) I >have a client who used some 10 base hubs too, and just band aided it with a >few switches here and there. > NetBIOS over TCP/IP sends broadcasts quite frequently. I almost >dare say within a minute. CPUs can vary, and there is always the aging 486 >on the fringe. > I guess ultimately on a solid 10/100Base Switched network you do >pose a good point. However, do you think that a nasty 10.0.0.0/16 network >might be going a bit too far even with the latest technology? In that >case, we can argue, who really needs routing protocols internally? Just >slap up the good old super flat network and have a default gateway and >rarely call in the big dogs to make changes. Just throw a few statics to >the few other "super" flat networks and we got an enterprise solution. :) > Not trying to pick a bone with you. I agree with you, but I am >curious where do you feel is the threshold? You say until it breaks, but I >want to deploy a better solution before we get to that. > >At 07:52 PM 10/24/01 -0400, Chuck Larrieu wrote: > >hooray for you, PO! you are absolutely correct. > > > >In military science, it is well known that military establishments enter any > >war prepared to fight the previous one. In these days of DSL to the home > >desktop, 100 megabit to the office desktop, ATM backbone WANS, and HTML > >based applications, we networking students study various means of eking out > >another packet or two on 56K links. Anyone here see the point of ISDN backup > >for DS3 links? ;-> > > > >Your forward thinking is commendable. > > > >Chuck > > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > >Priscilla Oppenheimer > >Sent: Wednesday, October 24, 2001 11:51 AM > >To: [EMAIL PROTECTED] > >Subject: Re: MAC address and VLANs [7:23950] > > > > > >The multi-VLAN feature that Leigh Anne mentioned might solve your problem. > >The Cisco switch port could be associated with two VLANs that way. You > >didn't say which switch you have, and this feature may not be available on > >all Cisco switches, though. > > > >Assuming that you don't want to upgrade the little switch to one that does > >802.1Q or ISL, another somewhat radical fix to the problem might be to not > >use VLANs. My philosophy is that once VLANs get to the point of causing > >more problems then they fix, I eliminate them. ;-) > > > >One of the main things VLANs were supposed to fix was excessive broadcasts > >causing too many CPU interruptions on numerous workstations in a large, > >flat, switched network. > > > >Lately I have taken to making the controversial statement that this problem > >doesn't exist on many modern networks. These days workstations have > >amazingly fast CPUs. They are not bogged down by processing broadcasts. > >Also, as we eliminate older "desktop" protocols such as AppleTalk and IPX, > >what is still sending broadcasts? An ARP here or there is not a big > >problem. And ARPs don't actually happen that often. A PC keeps the > >data-link-layer address of its default gateway and other communication > >partners for a long time. > > > >Also, a lot of PC NICs used to be stupid about multicasts and interrupt the > >CPU for irrelevant multicasts for which the PC was not registered to > >listen. I bet that bug has been fixed by now. > > > >VLANs have other benefits (security, dividing up management and > >administrative domains, etc.) But if broadcasts are the issue, one should > >ask: > > > >Which protocol send broadcasts and how often? > >How fast are the CPUs? > > > >And that is my latest harangue against my least favorite LAN technology > >(VLANs!) > > > >Priscilla > > > >_______________________ > > > >Priscilla Oppenheimer > >http://www.priscilla.com >-Carroll Kong ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=24072&t=23950 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
