> > On Sunday 13 February 2005 22:36, David Gilbert wrote: > >> Has anyone considered patching the vlan driver to support altq? I > >> gather that since tun works, so should vlan. > > Well... the issue is several fold. Firstly, the router in question is > talking in trunk mode to a switch which in turn hands out ports to end > user boxes. So the "real" interface could be queue limited, but in > general, it can be assumed that the GigE interface is faster than the > sum of the traffic coming into it. > > Now... you seem to be saying that if the queue is attached to (in this > case) em0, and vlan10 goes through em0, that traffic will be subject > to the queue ... even though it's been tagged ... and from the > perspective of em0 is no longer IP traffic. > > This is certainly not obvious, if it is the case. > > But from a vlan-as-virtual-circuit-replacement standpoint, it makes > sense to note a vlan as a queue entity.
I went through exactly this. I wrote my own patch for if_vlan.c that allowed ALTQ queueing on a vlan interface. I used that patch and ran hundreds of GBs of live customer data a week through the router with those patches. I never saw any problems. Then again, I never managed to figure out queuing on the vlan parent interface either. Both worked as far as I could tell, but I've gone to > Anyways, the _real_ problem is that traditionally, I'd used firewall > rules for accounting as well as security. I've used several varieties of firewall rules to count traffic (count rules, ipfw pipes) and I've switched over to a custom program that sniffs packets via libpcap off the vlan parent, and counts them. It's not fancy, but it does have some certain advantages (like passive MAC address sniffing, which I find quite handy dealing with some of the more "adventurous" clients). _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
