Hello all. I created a "plug and play" kind of solution for bridge-based QoS LAN-WAN traffic shaping. Based on the LEAF bering-uClibc branch, I''m calling it ''QBox'' and the project site for now is located at: http://content.cs.luc.edu/projects/comp412/q-box I''m interested in any feedback you might have. This is based off of experience I have over the last couple years maintaining custom QoS builds shaping video, citrix, and VoIP all at one site (plus regular internet etc). The current build takes about 2.5 MB on CF and I should have that paired down further before long. Havn''t had the chance to do any stress testing yet, but the manufacturer of the board claims that you can get 50Mbps routed through it. Once I add Layer 7 filtering I doubt we''ll be able to sustain that though. Thanks, -Ron
> This looks really neat! I considered building something similar in the > past but never got around to. Have you considered adding MRTG or > Cricket for graphing?Great suggestions. I definitely want to include monitoring tools. I have used ntop before, but ran into performance issues even on a T-1 link (Pentium Pro proc) -- but come to think of it I was also doing some heavy monitoring of the queues. MRTG and Cricket look to be much lighter weight. Do you have experience with which one would require less CPU? Thanks, -Ron
Ron Senykoff wrote:> > Hello all. > > I created a "plug and play" kind of solution for bridge-based QoS > LAN-WAN traffic shaping. Based on the LEAF bering-uClibc branch, I''m > calling it ''QBox'' and the project site for now is located at: > > http://content.cs.luc.edu/projects/comp412/q-boxThe qboxWhitepaper.pdf paragraph 2.1 is chopped off. Neat idea. I intend to try it out. Thanks! -- gypsy
On 11/4/05, gypsy <gypsy@iswest.com> wrote:> > The qboxWhitepaper.pdf paragraph 2.1 is chopped off. > > Neat idea. I intend to try it out. Thanks!Thanks for letting me know about the chopped off paragraph. I''m putting out v0.2 now which will fix a reboot issue (I forgot to set the watchdog timer up correctly on my last build) and add the parameter for defining the gateway in the networking configuration file. Everything else has been rock solid for me over the last couple weeks. Let me know if you have any questions. -Ron
Ron Senykoff wrote:> MRTG and Cricket look to be much lighter weight. Do you have > experience with which one would require less CPU?I think that a SNMP daemon would require the least CPU, letting the user do his own graphing using MRTG, Cricket or any other product he might already be using to monitor other appliances. Otherwise, if you want to include graphs in your web interface, MRTG and Cricket consume pretty much the same (usually negligible) CPU, as they both use RRDTool as a backend to collect and graph data. Toby -- UNIX is a lever for the intellect. -John R. Mashey