Hi All
Up this thread after few years :-)
Now I have following HW/SW setup:
- FreeBSD 12.3-STABLE r372089 GENERIC amd64
- Xeon(R) CPU E5-2470 v2 @ 2.40GHz
- ix0 hardware
- about 10-15 vlans like "vlan: 100 vlanpcp: 0 parent interface: ix0"
- and all vlans are bridged via bridgeX
- about 200 mul
30.08.2019 1:39, Rodney W. Grimes wrote:
> One of the things I do when writting a firewall is very early break
> up the traffic based on which interface(s) it is coming in/out of
> and do a skipto based on that, then further classify based on layers
> so that I am usually only doing 1 compare as i
> 28.08.2019 23:58, Victor Gamov wrote:
>
> > P.S. Two questions about rules syntax optimization. What is more effective:
> > skipto tablearg udp from any to table(AllMcast_out)
> > or
> > skipto tablearg udp from any to table(AllMcast_out) out xmit vlan*
>
> Can't tell, this heavily depends o
28.08.2019 23:58, Victor Gamov wrote:
> P.S. Two questions about rules syntax optimization. What is more effective:
> skipto tablearg udp from any to table(AllMcast_out)
> or
> skipto tablearg udp from any to table(AllMcast_out) out xmit vlan*
Can't tell, this heavily depends on table contents
On 28/08/2019 18:48, Eugene Grosbein wrote:
28.08.2019 17:18, Victor Gamov wrote:
Why do you need to filter ARP on bridge? That's unusial. VLANs are
isolated by default and by definition, unless you explicitly enable
inter-vlan routing and setup your routing table.
May be I have some misunder
28.08.2019 17:18, Victor Gamov wrote:
>> Why do you need to filter ARP on bridge? That's unusial. VLANs are
>> isolated by default and by definition, unless you explicitly enable
>> inter-vlan routing and setup your routing table.
>
> May be I have some misunderstood here but...
> If I have many
On 28/08/2019 24:45, Eugene Grosbein wrote:
28.08.2019 3:59, Victor Gamov wrote:
sysctl.conf = net.link.ether.ipfw=1 net.link.bridge.ipfw=1
net.link.bridge.ipfw_arp=1 net.link.bridge.pfil_member=1
net.inet.ip.fw.verbose_limit=100 net.inet.ip.fw.verbose=1
=
Do you really use ipfw f
28.08.2019 3:20, Victor Gamov wrote:
hw.igb.max_interrupt_rate=32000
>>>
>>> It's about 5000-7000 per rxq
>>
>> 7000 is quite close considering it is average for quite long period (a
>> second or seconds).
>> It can hit 8000 for some ticks easily in your case.
>
> Eugene, can you explain m
28.08.2019 3:59, Victor Gamov wrote:
>>> sysctl.conf
>>> =
>>> net.link.ether.ipfw=1
>>> net.link.bridge.ipfw=1
>>> net.link.bridge.ipfw_arp=1
>>> net.link.bridge.pfil_member=1
>>>
>>> net.inet.ip.fw.verbose_limit=100
>>> net.inet.ip.fw.verbose=1
>>> =
>> Do you really use ipfw filtering
On 27/08/2019 23:30, Eugene Grosbein wrote:
28.08.2019 2:20, Victor Gamov wrote:
sysctl.conf
=
net.link.ether.ipfw=1
net.link.bridge.ipfw=1
net.link.bridge.ipfw_arp=1
net.link.bridge.pfil_member=1
net.inet.ip.fw.verbose_limit=100
net.inet.ip.fw.verbose=1
=
You should avoid passing sa
28.08.2019 2:20, Victor Gamov wrote:
>> Victor, do you have some non-default tuning in your /boot/loader.conf or
>> /etc/sysctl.conf?
>> If yes, could you show them?
> Nothing special.
>
> loader.conf
> =
> machdep.hyperthreading_allowed="0"
> net.inet.ip.fw.default_to_accept=1
> =
>
>
On 27/08/2019 22:59, Eugene Grosbein wrote:
28.08.2019 2:22, Victor Gamov wrote:
Also, you should monitor interrupt numbers shown by "systat -vm 3" for igb*
devices
at hours of most load. If they approach 8000 limit but not exceed it,
you may be suffering from this and should raise the limit w
28.08.2019 2:22, Victor Gamov wrote:
>> Also, you should monitor interrupt numbers shown by "systat -vm 3" for igb*
>> devices
>> at hours of most load. If they approach 8000 limit but not exceed it,
>> you may be suffering from this and should raise the limit with
>> /boot/loader.conf:
>>
>> hw
On 27/08/2019 21:50, Eugene Grosbein wrote:
28.08.2019 1:46, Eugene Grosbein wrote:
28.08.2019 1:03, Andrey V. Elsukov wrote:
As you can see, when ipfw produces high load, interrupt column is more
than system.
Interrupt numbers higher than others generally mean that traffic is processed
wi
On 27/08/2019 21:46, Eugene Grosbein wrote:
28.08.2019 1:03, Andrey V. Elsukov wrote:
As you can see, when ipfw produces high load, interrupt column is more
than system.
Interrupt numbers higher than others generally mean that traffic is processed
without netisr queueing mostly.
That is expe
28.08.2019 1:46, Eugene Grosbein wrote:
> 28.08.2019 1:03, Andrey V. Elsukov wrote:
>
>> As you can see, when ipfw produces high load, interrupt column is more
>> than system.
>
> Interrupt numbers higher than others generally mean that traffic is processed
> without netisr queueing mostly.
> T
On 27/08/2019 21:03, Andrey V. Elsukov wrote:
On 26.08.2019 19:25, Victor Gamov wrote:
More general question about my current config. I have about 200Mbit
input multicasts which bridged and filtered later (about 380 Mbit
bridged if trafshow does not lie me :-) )
My FreeBSD box (12.0-STABLE r34
28.08.2019 1:03, Andrey V. Elsukov wrote:
> As you can see, when ipfw produces high load, interrupt column is more
> than system.
Interrupt numbers higher than others generally mean that traffic is processed
without netisr queueing mostly.
That is expected for plain routing. I'm not sure if this
On 26.08.2019 19:25, Victor Gamov wrote:
> More general question about my current config. I have about 200Mbit
> input multicasts which bridged and filtered later (about 380 Mbit
> bridged if trafshow does not lie me :-) )
>
> My FreeBSD box (12.0-STABLE r348449 GENERIC amd64) has one "Intel(R)
On 26/08/2019 20:15, Eugene Grosbein wrote:
26.08.2019 23:25, Victor Gamov wrote:
More general question about my current config. I have about
200Mbit input multicasts which bridged and filtered later (about
380 Mbit bridged if trafshow does not lie me :-) )
Don't trust trafshow. Use: systat
26.08.2019 23:25, Victor Gamov wrote:
> More general question about my current config. I have about 200Mbit input
> multicasts which bridged and filtered later (about 380 Mbit bridged if
> trafshow does not lie me :-) )
Don't trust trafshow. Use: systat -ifstat 1
> My FreeBSD box (12.0-STABLE
On 24/08/2019 22:34, Eugene Grosbein wrote:
25.08.2019 1:13, Victor Gamov wrote:
I have nonstandard network task for my FreeBSD box:
many VLANs bridged together via bridge interface and specific multicast traffic
must be send
from one VLAN to many (but not all) other VLANs.
It is quite stand
On 26.08.2019 03:30, Eugene Grosbein wrote:
>>> Also, you should use old table numbers instead of new symbolic table names
>>> when you have many rules checking for interface names and much traffic
>>> because checks for numbered tables are slightly more efficient.
>>> You may use symbolic names st
26.08.2019 3:37, Andrey V. Elsukov wrote:
> On 24.08.2019 22:34, Eugene Grosbein wrote:
>> If you are concerned of performance, general rule applies: less checks,
>> better performance.
>>
>> First, use 'out xmit' instead of 'out via'. They are semantically equal and
>> this is micro-optimizatio
On 24.08.2019 22:34, Eugene Grosbein wrote:
> If you are concerned of performance, general rule applies: less checks,
> better performance.
>
> First, use 'out xmit' instead of 'out via'. They are semantically equal and
> this is micro-optimization
> but it still saves extra check unneeded when
25.08.2019 3:44, Victor Gamov wrote:
> Eugene
>
> Many thanks for your reply!
>
> I need to read more about tablearg and then modify my current production
> rules step by step.
Also, rules like "ipfw add 25013 deny udp from any to any" should be simplified
to "ipfw add 25013 deny ip from any t
Eugene
Many thanks for your reply!
I need to read more about tablearg and then modify my current production
rules step by step.
Thank you again!
On 24/08/2019 23:11, Eugene Grosbein wrote:
25.08.2019 2:34, Eugene Grosbein wrote:
Also, use table arguments and not only table values, do not
25.08.2019 2:34, Eugene Grosbein wrote:
> Also, use table arguments and not only table values, do not ignore their
> existence:
>
> ipfw table $Mcast1_iface_out add vlan20 $mcast11
> ipfw table $Mcast1_iface_out add vlan20 $mcast12
> ipfw table $Mcast1_iface_out add vlan20 $mcast13
> ipfw add 25
25.08.2019 1:13, Victor Gamov wrote:
> I have nonstandard network task for my FreeBSD box:
> many VLANs bridged together via bridge interface and specific multicast
> traffic must be send
> from one VLAN to many (but not all) other VLANs.
It is quite standard filtering bridge :-)
> I use ipfw
29 matches
Mail list logo
