I kinda like that idea. Maybe a Comcast business-class connection for HTTP and use our 3mb connection for everything else. I think pfSense has a module for this.
Chris Steven S. Critchfield wrote: > With the advanced routing stuff, yes. Anything you can identify with > firewall rules can be placed in buckets, and then you can prioritize > that to make it better. But like I said, and others too, this only > helps the outbound congestion. Inbound would still be out of his > control. This is why I also mentioned the idea of a second less > expensive async network connection and the ability to route > based on the type of traffic to certain netowrks. You could easily > route all you download intensive apps to the async network and > keep the sync network for the symetrical or higher upload intensive > applications. Since then you could better control your congestion. > > ----- "Mark J Bailey" <[EMAIL PROTECTED]> wrote: > >> Would he be able to shape RTP somehow on its Type of Server (TOS) >> designation of 0xba (dec 184)??? >> >> --On Thursday, September 11, 2008 11:18 AM -0500 "Steven S. >> Critchfield" >> <[EMAIL PROTECTED]> wrote: >> >> >>> ----- "Chris McQuistion" <[EMAIL PROTECTED]> wrote: >>> >>>> Bill Butler suggested that if we could prioritize RTP, over >>>> >> everything >> >>>> else, that may be enough by itself. Unfortunately, neither >>>> >> Untangle, >> >>>> nor our internal firewall/router (a Sonicwall Pro 3060) have the >>>> ability >>>> to prioritize RTP. They only have rules for TCP, UDP, ICMP, etc. >>>> >>>> I have tried pfSense, but I'm not having much luck getting it to >>>> >> do >> >>>> traffic shaping, in both directions, when it is in transparent >>>> >> bridge >> >>>> mode. >>>> >>>> Anyone have any ideas or know of somewhere you can point me? >>>> >>> RTP is a type of traffic like HTTP. RTP is usually found inside UDP >>> packets because some dropped audio is better than the lag that a >>> >> TCP >> >>> connection could cause. >>> >>> Another thing to know, you can't really traffic shape what you >>> >> receive. >> >>> By the time the bits have crossed the wire to you and you see them, >>> >> they >> >>> have already contributed to your congestion. You can only really >>> >> effect >> >>> your outbound portion. And in effect, that will help shape your >>> >> inbound. >> >>> Specifically if you throttle some streams, then the otherside will >>> >> slow >> >>> as well. >>> >>> I would suggest maybe reading the Linux advance routing and traffic >>> control howto. >>> http://lartc.org/ >>> >>> You might even be able to put the information from here into place >>> >> on >> >>> your untangle box. The part I think you need to look at specifically >>> >> is >> >>> chapter 9: Queueing Disciplines for Bandwidth Management. >>> >>> When reading the lartc docs, it took quite a while for me to get my >>> head wrapped around some of the things you could do. >>> >>> To give you an idea of the fun we had and did with our firewall, >>> >> and >> >>> maybe an idea for you and your network management, we built a >>> >> firewall >> >>> with 1 to 1 nating from Butler to our internal network. We also do >>> >> normal >> >>> nating from Comcast. We then put IP range rules internally for >>> >> traffic to >> >>> go out either Butler or Comcast. 1 range is the specific 1 to 1 nat, >>> >> and >> >>> therefore traffic originating there will show up on the internet >>> >> with the >> >>> static public IP. There is a mirror range of the 1 to 1 nat that is >>> reserved for traffic destined to go out Comcast. There is another >>> >> range >> >>> devoted to machines otherwise not configured in dhcp to only go out >>> Comcast. The 1 to 1 range and the mirror range allows our users to >>> determine what link they wish their traffic to traverse. Granted >>> >> this is >> >>> due to a small user base and ones I can go talk to should a link >>> >> become >> >>> congested. >>> >>> You could possibly augment your network with a asymetrical link like >>> >> we >> >>> did. Then route certain traffic that you can identify as asymetrical >>> >> to >> >>> that link. Web browsing over a fast download slow upload link is >>> >> much >> >>> nicer than over the slower symetrical link. I am sure you would >>> >> probably >> >>> choose different segmentation than we did, but the work would still >>> >> be >> >>> useful to you. >>> >>> -- >>> Steven Critchfield [EMAIL PROTECTED] >>> >>> >> >> ________________________________________________________ >> Mark J. Bailey Jobsoft Design & Development, Inc. >> 104 Arlington Place, Suite 100 Franklin, TN 37064 >> EMAIL: [EMAIL PROTECTED] WEB: http://www.jobsoft.com/ >> VOICE:(615)904-9559 FAX:(615)904-9576 CELL:(615)308-9099 >> >> >> >> > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to nlug-talk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en -~----------~----~----~----~------~----~------~--~---
