hinwoto wrote: > > Dear Folks and Gurus, > > One of our client LAN are impacted by broadcast / multicast > storm causing > very > severe intermittent and frequent time out.
Are you sure the problem is really related to broadcast/multicast traffic? With the exception of the Ghost disk imaging software you mention below, the other broadcast/multicasts you mention are perfectly normal network traffic that is unlikely to cause a problem. Don't forget that when you collect data with a Sniffer from a switched network, unless you configure SPAN, all you will see is broadcast traffic and traffic for your own port. This will cause Sniffer-like tools to tell you that 90% of your traffic is broadcast and that you have a broadcast "storm" when you really you have perfectly normal traffic. Broadcast storms are rare, despite all the hype about them in networking books. To start with, broadcast packets tend to be very small, usually. For broadcast traffic to use a large portion of your bandwidth you need 2 conditions: * A very high rate of broadcasts per second * Large broadcast packets * Low bandwidth The real problem with broadcasts is that they interrupt the CPU on every device that receives them, which is every device in the switched network of the sender. But look at current CPUs and also the architecture of current NICs, with buffers, etc. How many broadcasts does it really take to bother a 2 GHz processor? The studies that Cisco did that caused millions of pages to be written on the dangers of broadcasts were done on 68000 Macintoshes and 486 PCs, if I recall. One other comment: Cisco's testing was done with PCs that were stupid about multicasts and interrupted the CPU even for multicasts that the PC had not registered to receive. For example, a routing protocol multicast, such as EIGRP Hello, interrupted the PC even though PCs don't need to see this. The problem was with the NIC and its driver. The driver didn't have any way to tell the NIC which multicasts to accept. That problem has been fixed on modern computers and NICs. With that said, I admit there are still lots of old computers and old NICs out there. If your network has a lot of those, then maybe broadcasts and multicasts could cause performance problems. > > Tools used are Cisco Traffic Director, CiscoWorks and Sniffer > to collect > traffic information. > There are several top conversations generated high > broadcast/multicast > > - W2K server with DHCP service generates destination packet > broadcast / > 255.255.255.255 with protocol Bootps (Bootstrap Protocol server > 67/UDP ) DHCP is probably normal network traffic. It's a little strange that the server is sending DHCP as broadcast, but not uncommon. Some client implementations are unable to receive unicast IP datagrams until the implementation has a valid IP address. This leads to a deadlock in which the client's IP address can't be delivered until the client has been configured with an IP address! A client that has this problem sets the "broadcast bit" in the Flags field of DHCP discover and request messages. This tells the server to broadcast messages back to the client. This high rate of DHCP broadcast messages that you are seeing may just be an indication of worksations and possibly IP phones and other devices booting a lot. You might want to find out why they boot so much. > > - Symantec Ghost disk cloning application generate big packets > with > destination packet multicast / 224.77.x.x ( interim solution > we create vlan > / another segment for this application ) Large multicast packets from the Ghost disk cloning application could cause problems. VLANs for this application sounds like a good solution if you can ensure that the recipients are in the same VLAN. Is this used for building new computers? If it's used for all the computers, then it's harder to segregate the traffic. But isn't there a way to tell it not to use multicast? You may want to send a message and ask specifically about this evil abuser of networks. I had a customer who had problems with it too, but I can't remmeber how he solved it. I think he implemented VLANs like you did. > > - EIGRP hello packet / multicast 224.0.0.10 for backbone > routers > communication. > The LAN has 2 edge big routers and each this router generates > accumulative big packet of 224.0.0.10 EIGRP hello packets aren't big. They are 78 bytes. Although they are frequent (every 5 seconds) they are perfectly normal, necessary network traffic. I seriously doubt they are causing problems. Also, they are sent as multicasts. They will not bother a modern workstation with a modern NIC that knows which multicasts to accept and not accept. > > Please can anyone give advise how to put these kind of > broadcast & multicast > conversations safe from LAN, since I am afraid that if there is > an > additional broadcast/multicast load triggered by alien/unknown > application... it is gonna be horrible for connection > reliability... > > We are considering to configure broadcast / multicast > suppression on each > port of core catalyst 6000 and uplink port of cat 3524 > PWR-Inline. However I > get confused when trying to define the right threshold for > those settings. > ARP still uses broadcast address for destination, right... > > Please show us the light how to define this broadcast > suppression properly > and still allow the "good" broadcast ....? Any tools/way to > define the > broadcast/multicast threshload ? Broadcast suppression is not a solution for your problem of perfectly normal, necessary, broadcast traffic such as DHCP and EIGRP hellos! You could wreak havoc with it and cause those necessary functions not to work. Priscilla > > Thanks and looking forward to your help, guys...... > Cheers > Hin > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66869&t=66823 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
