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 ???
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
cpu load on 6509 Sup 720
- Thread starter vipergg
- Start date
jneiberger
Technical User
no ip directed-broadcast" would most certainly break the application. Make them use multicast mode. That should lower the CPU usage dramatically.
vipergg said:
"He is using directed broadcast mode even though all pc's are on the same subnet"
how will that break the application?
Also if you do go to multicast mode, make sure you set a TTL of more than 1.. If its 1 then it will get processed switch and kill your box still..
BuckWeet
"He is using directed broadcast mode even though all pc's are on the same subnet"
how will that break the application?
Also if you do go to multicast mode, make sure you set a TTL of more than 1.. If its 1 then it will get processed switch and kill your box still..
BuckWeet
jneiberger
Technical User
The PCs are on the same subnet but I guess I was assuming that the Ghost server was on a different subnet. If the server and the PCs are on the same subnet then directed-broadcast isn't even an issue. That only applies when a device on one subnet tries to send a directed broadcast to a different subnet.
That's a good tip about the TTL. I wasn't aware of that.
That's a good tip about the TTL. I wasn't aware of that.
You can also set up broadcast suppression on a per interface basis.
jneiberger
Technical User
Broadcast suppression would break the Ghost application if the original user didn't switch to a different mode.
- Thread starter
- #9
Hi , the no ip directed broadcast is on by default but this is still killing the processor . I'm not sure if it just just can't keep up with just dropping the packets or what . It is setup as 500 meg per minute in the ghost setup . We tried multicast mode but that hung the machines we were testing on , is there specific parameters that must be enabled on the switches in order for multicast mode to work correctly. The answer is yes the ghost server and the pc's are in the same vlan (subnet) but trunked between multiple different switches . During our testing he was just ghosting to like 8 machines and it sent the cpu to over 90% until he was done . Find it amazing that one device can bury a 720 like this , must be every packet is being process switched as opposed to hardware switched . Is that the way ghost works with directed broadcast every packet has to be looked at by the cpu ? You could get into control plan policying but don't really want to get into something that complicated if it can be avoided. This traffic must be getting punted to the CPU because otherwise it would be hardware switched down on the dfc3 cards and it would never see the cpu . We are going to try and rate limit the output on the app itself next go round and see what happens . Any other ideas appreciated .
jneiberger
Technical User
500 MB per minute is only 66 Mb per second, which any switch can handle, so something else must be going on. If you're going to use multicast mode, make sure IGMP snooping is turned on.
Are you subscribed to the Cisco NSP mailing list? This would be a perfect question for those guys. Lots of extremely smart people with gobs of experience, including many Cisco employees, some of which are engineers on this very product.
Are you subscribed to the Cisco NSP mailing list? This would be a perfect question for those guys. Lots of extremely smart people with gobs of experience, including many Cisco employees, some of which are engineers on this very product.
- Thread starter
- #11
I just found this command which appears you can put on the layer 3 SVI . On the 720 you can add "mls ip directed-broadcast exclude router" . Anyone use this before ? This supposedly turns on hardware switching of directed broadcasts and I wonder if this will fix my problem ?
jneiberger
Technical User
If all of the devices in question are on the same subnet then directed broadcasts are not the problem. A directed broadcast occurs when a subnet broadcast is sent from a device on a different LAN.
For example, let's say I have a device on the 10.1.1.0/24 subnet. If it sends a subnet broadcast to 10.2.2.255, for example, that is a directed broadcast to all the devices on the 10.2.2.0/24 network. A packet sent to 255.255.255.255 is simply a broadcast, not a directed broadcast.
I would imagine that since the Sup 720 has an address in the same LAN, it is having to process all of those broadcasts, as do all LAN devices. By ghosting these PCs using broadcast mode, you're basically allowing this guy to pelt your switch's administrative address (or whatever address is on that LAN) with approximately 66 Mbps of traffic.
I think you mentioned CPP earlier. I haven't played around with that but it might be something to try. The solution, though, is not to let him do this in broadcast mode by finding a way to make multicast mode work. We use multicast mode all the time here and don't have a problem with it.
For example, let's say I have a device on the 10.1.1.0/24 subnet. If it sends a subnet broadcast to 10.2.2.255, for example, that is a directed broadcast to all the devices on the 10.2.2.0/24 network. A packet sent to 255.255.255.255 is simply a broadcast, not a directed broadcast.
I would imagine that since the Sup 720 has an address in the same LAN, it is having to process all of those broadcasts, as do all LAN devices. By ghosting these PCs using broadcast mode, you're basically allowing this guy to pelt your switch's administrative address (or whatever address is on that LAN) with approximately 66 Mbps of traffic.
I think you mentioned CPP earlier. I haven't played around with that but it might be something to try. The solution, though, is not to let him do this in broadcast mode by finding a way to make multicast mode work. We use multicast mode all the time here and don't have a problem with it.
- Thread starter
- #13
Yeah I have tried everything I can think of to try and make directed broadcast mode work right without burying the cpu , no avail. We then did another test where he ghosted using unicast , as you might have guessed this didn't even nudge the cpu because all unicast traffic is hardware switched down on the dfc cards . And the the 3 or 4 we tested , the user said it didn't take much longer than normal , even though its more traffic it would be better if he can make this work . The user is supposed to see if unicast mode is usuable . Is there anything that would need to be done on the switches if they wanted to use multicast ???
jneiberger
Technical User
Turn on IGMP snooping if you want to use multicast. That's about it since you won't be doing any multicast routing. If the origin of the traffic ends up being on a different LAN then you'll want to turn on PIM, as well.
- Status
Similar threads
- Locked
- Question