Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Jul 2006 12:23:03 +0300
From:      vladone <vladone@spaingsm.com>
To:        ipfw@freebsd.org
Subject:   Re[3]: IPFW Dummynet Bridge Limiting
Message-ID:  <1855971350.20060714122303@spaingsm.com>
In-Reply-To: <1406932981.20060714122109@spaingsm.com>
References:  <48DC429CB053B64EAD91BDD1DE106A11675DE6@es1.corp.commspeed.net> <1406932981.20060714122109@spaingsm.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Hello vladone,

Friday, July 14, 2006, 12:21:09 PM, you wrote:

> Hello Adam,

> Thursday, July 13, 2006, 2:37:19 AM, you wrote:

>> Vladone,

>>         Thanks much for the response. I looked into what you were
>> telling me and here are the results:

>> 1) This wasn't a typo. Apparently, after looking into it, I've seen both
>> options used on different websites and setups. Either way though, I
>> checked these both with sysctl and they are both set to 1.

>> 2) I missed that part of the man page and thanks for clarifying. This is
>> where I get confused. Am I using DIVERT to get packets to the proper
>> pipe? If so, then how can I get it to work properly with many many many
>> rules (one for each customer IP)? If not, then does this option really
>> matter?

>> 3) This part I did read and I'm still slightly confused. Once placed
>> into the proper pipe, I don't want it to continue down the line of rules
>> to search for another match. I like it where it is because it matched
>> the IP and should be limited, correct?

>> Also, I have tried my setup with the one_pass variable on and off.
>> Neither way worked for me anyways.

>> Upon further investigation, I noticed when I set up my laptop with the
>> 216.19.50.37 address and add the rule to match "all" to the pipe, I lose
>> all connectivity. I am unable to ping or pull web pages. Somehow, I
>> originally thought the problem was that there was no limiting going on.
>> This must be because I had a ping running in the background and had the
>> rule set up to limit ip. Now I think what is happening is the packets
>> are getting dropped or not arriving at the destination like they're
>> supposed to.

>> Thanks again.

>> Adam

>> -----Original Message-----
>> From: owner-freebsd-ipfw@freebsd.org
>> [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of vladone
>> Sent: Wednesday, July 12, 2006 3:48 PM
>> To: ipfw@freebsd.org
>> Subject: Re: IPFW Dummynet Bridge Limiting

>> Hello Adam,

>> I dont't use it bridge but some thinks that can help u:
>>  1. use corect syctl variables form: net.link.ether.bridge.ipfw
>>  instead net.link.ether.bridge_ipfw (probably an wrong typing)
>>  2. read the end from man page about bridge, and
>>  net.inet.ip.fw.one_pass variable.
>>  "Also remember that bridged packets are accepted after the first pass
>>      through the firewall irrespective of the setting of the sysctl
>> variable
>>      net.inet.ip.fw.one_pass, and that some ipfw(8) actions such as
>> divert do
>>      not apply to bridged packets.  It might be useful to have a rule of
>> the
>>      form

>>            skipto 20000 ip from any to any bridged
>>  "

>>  3. Luigi Rizzo say in his
>>  documentation: "there is always one pass for bridged packets"
>  First: if u want to apply aan queue or pipe, for many IP's, u can use option mask
>  in pipe or queue. U can get examples about that in dummynet
>  documentation.
>  For bridge, try to use "bridge" option in ipfw rules, to match packtets
>  that are bridged.
>  If u want to pass packetes across multiple pipe or queue, then need
>  to set net.inet.ip.fw.one_pass=0
>  For clients that have public IP's, natd have an option to not
>  translate this adresses.
>  Recomandation:
>  Begin with very simple rules, without any pipe or queue, only count
>  option, and see what is happening. Then grow complexity, in this mode
>  u can find where u wrong.

Sorry, for my mistake, option for ipfw is named "bridged".




-- 
Best regards,
 vladone                            mailto:vladone@spaingsm.com




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?1855971350.20060714122303>