Have you browsed the available packages?

Have you considered SNMP?

You could send your VOIP traffic through a queue then monitor the queue's bandwidth through the GUI or SSH/command-line.

Yeah, the lack of a shared download queue is preventing us from setting up multiple LANs in our office.

As Harvy66 has suggested a virtual interface of sorts would solve this issue, but I don't think there is a way to do this even with stock FreeBSD.

@Ryu945:

I am not entirely sure what to search for and my current search results aren't giving me anything fruitful.  My current thought is to look how traffic prioritization works and see if I can find an answer in there.  What kind of information did you mean.

Look up firewall rules first. You need to have a firewall rule that catches the traffic before you can begin shaping/policing the traffic. The traffic must differ from other traffic in some way that the firewall can catch.

For example, if your "certain program" connects to arbitrary hosts/IPs on common ports and uses encryption, it may not be possible to isolate it's traffic.

Regarding what information you/we could find useful; protocol (UDP/TCP), source IP/port, destination IP/port, name of application, whether encryption is used.

Alright, thanks for the info. I take it there are long-term plans to add it? In the mean time I can probably just use the burst functionality to give new connections a brief speed boost.

~repne

Forget the wizard.

Just create 2 PRIQ queues on the WAN. A default queue for all unclassified traffic, and another queue for exclusively VOIP.

Then setup a floating rule in the firewall that directs all VOIP traffic into the proper, prioritized queue.

I don't think you can fix this.  From what I understand, you can only shape traffic leaving an interface.  When Squid makes an HTTP request on your behalf, the requested data enters the WAN interface at whatever rate your ISP provides you.  Squid will download via WAN at full link speed to its cache and then dribble the data out to you on LAN based on whatever shaping rules you may have.

@dpa:

where does Squid reside on that diagram above?

Who cares?  :P

So we are still seeing these random traffic spikes and high queues but are unable to track down the source.

Can anyone suggest a way to track the source of traffic in the queues?

My RRD graphs are attached if it helps.

status_rrd_graph_lan.php.png
status_rrd_graph_lan.php.png_thumb
status_rrd_graph_wan.php.png
status_rrd_graph_wan.php.png_thumb
status_rrd_graph_admin.php.png
status_rrd_graph_admin.php.png_thumb

My understanding is that traffic shaping only works with logical interfaces and there is no good way to do traffic shaping in a way that multiple interfaces work as a single traffic shaping group.

What are your traffic shaping settings(categories, algorithm, settings for each)? some actual values, not what you think you set them to

What interface is that on?

How much bandwidth do you have?

Did you rate limit your port?

Hi,

Thank you for your replies - Sorry doktornotor, you've probably never been a newbie  ;) I thought shapping would happen before encryption for LAN sent traffic.

Initially, I wanted to sent DATA and VoIP through VPN. according to your replies, I think I'll try to do my configuration like this :

DATA through VPN VoIP through WAN without encryption, but with use of shaping, that should work?

Following your advice Derelict, I shoud shape sent traffic at both ends, OpenVPN server and client sides?
My goal is to connect 4 remote sites to a main sites, hosting Alcatel OXO and Data server.

Thks,

Thomas

Also, incoming UDP packets cannot be rate-limited because UDP has no congestion control. Only TCP has congestion control which can be leveraged to control bandwidth. This is one reason why UDP flooding was/is a popular denial-of-service method.

It depends on what the actual bug is. There have been some fixes after 2.2 for the wizard for a similar issue, it could be related to this one or the same one.

Does it work when you remove the limiter?

Did you even try to do any research or searching before asking?

@Harvy66:

My understanding is that if you want Diffserv to be honored, it must be set before reaching the firewall. Traffic shaping is set at the time the connection is made. Because you have Squid running inside the firewall, the diffsrv is being set after reaching the firewall.

Ok thanks.

So there is no way a rule on LAN can tell which traffic passing thru is from cache.

They're physically "sub" interfaces, but logically, they are all completely separate.