Here is the scenario , we have a user using ghost to push training updates out to computers , probably 60-70 pc's . He is using directed broadcast mode even though all pc's are on the same subnet . From what I have read directed broadcast gets punted to the CPU which then has to handle all the packets . In our case whenever they do this we see the cpu shoot up to anywhere from 85-99 percent and we can't do anything with the box which is cisco's 6509 with a Sup720 in it . Is there any way to minimize the effect that this has on the cpu . According to the customer they could never get multicast mode to work correctly , which I don't know because this was before we took over responsibility for it for the network . Is my assumption correct on how the cpu handles a directed broadcast and what can be done to minimize it . I think if we try an acl it is probably going to break the application . Any ideas ???
You can suppress unwanted directed broadcast using broadcast storm control feature. If you are aware of the "storm control broadcast" command, try implementing it and check.
If this doesn't solve your problem, then I may need some informations on your network so that I can help you.Send me the sh tech output from your switch. Also, send me the show logging output and debug output while the broadcast is sent.
Try mls ip directed-broadcast command to hardware switch directed-broadcast packets so they won't be punted to the Router, assuming that the RP's CPU is the one getting pegged due to this directed broadcast.
To enable the hardware switching of the IP-directed broadcasts, use the mls ip directed-broadcast command. Use the no form of this command to return to the default settings.
In addition, you can use multicast eventhough the streamer and the clients are in the same vlan, you jsut need an IGMP Querier or enable PIM on the L3 interface of that vlan. That's probably why multicast was not working before because the server and client are in the same vlan - Use the IGMP snooping querier to support IGMP snooping in a VLAN where PIM and IGMP are not configured because the multicast traffic does not need to be routed.
For more multicast information:
Yeah I tried the mls ip directed broadcast command it did nothing . I think because directed broadcasts are dropped at the router . I don't know why the cpu is affected so much other than even though it is supposed to drop directed broadcasts it is being overwhelmed by this program . It is the RP that is getting pegged . As soon as we ran the server in unicast it didn't budge off 2% utilization because all unicast traffic is hardware switched on the dfc cards . They did not like how long it took doing the ghost this way , like 2 hours versus like maybe 30 minutes at most using directed broadcast . Let me run this by you , would putting a ACL on the layer 3 svi denying the server to send to the .255 address block it from hitting the cpu if I turn off ip unreachables ? From what I have read it sounds like it gets dropped in hardware if you turn off ip unreachables and maybe this would stop it from hittinmg the cpu . What do you think ?
ACL might be worth a try but running the Ghost on Multicast is probably the way to go. But if you are going to drop them then how is the application going to work since the application runs on broadcast?
I guess the question becomes does that directed broadcast have to hit the router if all devices are on the same vlan , does not have to routed out to a different vlan .
Maybe we need a distinction between directed broadcast and pure broadcast. As I read your original message, it sounds like it's not directed broadcast as both server and client are in the same subnet.
Directed broadcast for example is a ping from IP 22.214.171.124 in network 126.96.36.199/24 to different net example 188.8.131.52.
If you will ping inside one network to broadcast address this will not be directed broadcast but pure broadcast. example
Ping from IP 184.108.40.206 in network 220.127.116.11/24 to ip 18.104.22.168
This will be send to broadcast address ffff.ffff.ffff and of course punted to CPU as all broadcast are punted in CPU.
So preventing directed broadcast is possible by command:
mls ip directed-broadcast exclude-router.
This will enable HW switching of directed broadcast and prevent putning traffic to RP - this working in both CatOS and IOS.
Whether or not it is a directed broadcast or pure broadcast I'm not sure . Ghost has 3 modes of transmission in the program multicast , directed broadcast and unicast . According to your explanation then it is a pure broadcast because it is going to xxx.xxx.99.255 from server xxx.xxx.99.2 ghost server . I thought I tried the command you suggest and it did not alleviate the high cpu but I may try it again and see . If it is a pure broadcast then I would also think I could block via acl and that might work also . What do you think.
This is not directed broadcast. The all the devices in that subnet can hear this transmit, if you sniff this packet you'll see that it has all ff's in the ethernet packet, so everyone hears it, including the router. L3 ACL that blocks traffic to xxx.xxx.99.255 might work and prevent these packets from reaching the router but with the Ethernet being all ff's, I am not so sure. Let me know if ACL worked. If not I am afraid you're only choise is to run multicast and take advantage of it's transmit nature. Imaging pushing a 5 MB image to 60 -70 PCs in broadcast, what if it's 100 MB?
I also had issues running Ghost on the same subnet. I am using 2 6509's running IOS. Multicast does work fine... My issue was getting the remote PC's on the remote switch to respond to the multicast reply from the Ghost server. All I had to do was enter the following command under the Interface VLAN xxx. IP IGMP SNOOPING MROUTER. This command is like a static route for multicast. it points the multicast traffic to the multicast router. In my case it is the Port Channel to the other switch that has the Ghost server. I would use Multicast in your senario. It works...Hope I helped....