Are you sure it's not showing 100% idle?
The idle process uses up whatever cpu cycles are not being used by anything useful and is shown by 'top -SH' and opn the System Activity page. E.g.:

[2.0.2-RELEASE][root@pfsense.fire.box]/root(2): top -SH last pid: 58916;  load averages:  0.22,  0.08,  0.02    up 2+13:37:03  12:05:18 101 processes: 2 running, 83 sleeping, 16 waiting CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle Mem: 45M Active, 15M Inact, 66M Wired, 1064K Cache, 59M Buf, 359M Free Swap:  PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND   10 root     171 ki31     0K     8K RUN     59.5H 98.00% idle  262 root      76   20  3408K  1224K kqread   9:36  0.00% check_reload_status   11 root     -32    -     0K   128K WAIT     8:01  0.00% {swi4: clock}   11 root     -68    -     0K   128K WAIT     4:15  0.00% {irq18: em0 ath0+}

A copy of your output will clear this up in seconds.

Steve

I never changed it.  I think its set to 1500?  Dont remember…

Thanks!!!!!    :)

Check the compatibility list at http://www.freebsd.org/releases/8.1R/hardware.html#ETHERNET

VIP settings, after saving those again everything worked

http://doc.pfsense.org/index.php/Installing_FreeBSD_Packages

@dhatz:

I wonder if it's still a problem with the newer FreeBSD 8.3 kernel used by pfsense 2.1-BETA

I have since sold the small WISP business that used the virtualized pfSense system I reported on earlier. However, my new employer (an ISP) asked me to build a vSphere cluster and help them virtualize large parts of their central office. So I will soon be able to do further testing with pfSense in this virtual environment.

Looks like packets pass across the bridge from the Physical OPT at least to the QinQ member vlan.
I have to wireshark on the WAN (QinQ) link to see if packets actually make it onto the wire.

Maybe it's some weird ARP issue?

I will have to recheck that the alix boxes I used had the bridging fix applied. I'm actually not sure cuz they were used in a previous lab setup!

I would suggest the first thing is to agree on a test procedure that will give a useful result. It has to be relatively easy to test to get a good number of people producing numbers. It also has to give results that are meaningful to users (not 'I can get 800Mbps if I use jumbo frames across a 4 NIC LAGG').
Then setup a forum thread where people can post results. Finally ask for edit rights on the wiki and setup a page describing the above.  ;)

A good example of some great testing is here: http://forum.pfsense.org/index.php/topic,27780.0.html

Speak to Jim (jimp) and/or Chris (cmb) who will have a better idea about this than me!

Steve

Ok thanks, and thanks for all the great work :)

I miss his provocative avatar.  :(

Steve

@sdm12:

Then I pointed all vlan 10 traffic to the pfsense.

What is the mechanism you used to do that?

Since your Cisco firewall is on the same VLAN as the guests it will probably be fairly easy for a knowledgeable user to work out how to bypass pfSense.

Thank you for clarification.

Success!!! :D
Okay, after i just realized that WAN/PPPOE actually was on rl0 and not how I assumed the whole time on rl1.
I went looking for the now missing rl1 and could not find it in the system.  I then plugged the "rl1" nic back into the pci slot it has been in before and then it got detected again by pfsense.
So the only problems there really were, were that i am dumb :P and that something is wrong with one of my pci slots :/
WAN, LAN1 and OPT1 are now working as intended! :)

Thanks for all the help!!! <3

I think you are much more likely to have packet loss issues on the WAN side of your pfSense than the LAN side.

Any path with a substantial number of hops on the public internet is likely to include a number of hops which are substantially oversubscribed (that is the hop bandwidth is insufficient for all potential users to be able to be able to obtain their maximum bandwidth). Hence packet loss can be seen in periods of substantial demand.

pfSense keeps some graphs of link "quality" in Status -> RRD Graphs, click on Quality tab and use the pull down to select the appropriate interface. If you have your system configured correctly the graph will give you an indication of congestion on the link to the other end of the VPN. There are probably periods of low ping response times and high response times (indicating congestion). Do the periods of high response times correspond solely to the times of file transfer?

Some things you could try. Do some tests to better understand how tweaking parameters affects the outcome..

1. Do you transfer a number of files concurrently? Reduce the degree of concurrency.

2. Convert WAV files to a compressed audio format and transfer the compressed files.

3. Do the transfers outside "busy" times.

4. Reduce the TCP window size used in the file transfers.

What are your requirements/constraints? Must get all transfers (each a multi gigabyte transfer) to complete simultaneously in under 30s in network peak times and incur no additional costs? :-)

that would work in theory ….

however ... every package on the system could one day be targetted when someone writes an exploit. If this happens, the pfsense team + volunteers try to update the supported packages as soon as possible.

The samba-mount program will not be updated by the pfsense devs, you would have to update it manually if there is ever a security problem with it.

If everyone is connecting via OpenVPN then you can route all networks to the VPN users.
Then you can use the "client specific override" to force a VPN client to always get the same OpenVPN IP/subnet.
This OpenVPN subnet can be used to create firewall rules.

Every OpenVPN connection consits of 4 IPs or a /30 subnet.
This can be used as source IP on the firewall. If you install OpenVPN on pfsense then you get a new tab "OpenVPN" on the firewall GUI.
But forcing all traffic through OpenVPN with good speed will cost more CPU power than without any encryption.

But I am not sure if this will make your firewall ruleset easier/better and give your more conrol on where these hosts can connect to.

For those that are interested, I have updated the script to support the download of the RRD data. It now supports pfSense encryption too. To get the most recent version of the code, you can download it from: http://code.google.com/p/pfsense-backups/