Res: Res: Res: Dropped Packets

INDEED, DO YOU HAVE ANY MIN & MAX NUMBER FOR BPS AND PPS
FOR THIS 
FIREWALL'S INTERNAL AND EXTERNAL INTERFACES? ON WHICH
INTERFACE ARE YOU 
DROPPING THE PACKETS?

REGARDS,

    CHRIS



300MBPS   AND  20.000 PPS.  BUT  I  WILL DO A BIGGEST
FIREWALL. 

THIS IS AN INTERNAL FIREWALL...  I THINK THE ENTRY IN THE
TABLE SESSION IS DESAPEARING, SO THE CLIENT NEEDS TO MAKE
ANOTHER CONECTION.  I´M THINKING ABOUT CREATE A STATELESS
RULE. 






      ABRA SUA CONTA NO YAHOO! MAIL, O úNICO SEM LIMITE DE
ESPAçO PARA ARMAZENAMENTO!
HTTP://BR.MAIL.YAHOO.COM/
_______________________________________________
FREEBSD-PFFREEBSD.ORG MAILING LIST
HTTP://LISTS.FREEBSD.ORG/MAILMAN/LISTINFO/FREEBSD-PF
TO UNSUBSCRIBE, SEND ANY MAIL TO
"FREEBSD-PF-UNSUBSCRIBEFREEBSD.ORG"

Lorenz Helleis wrote:
> Indeed, do you have any min & max number for bps
and pps for this 
> firewall's internal and external interfaces? On which
interface are you 
> dropping the packets?
> 
> Regards,
> 
>     Chris
> 
> 
> 
> 300Mbps   and  20.000 pps.  But  i  will do a biggest
firewall. 
> 
> This is an internal firewall...  I think the entry in
the table session is desapearing, so the client needs to
make another conection.  I´m thinking about create a
stateless rule. 
> 

Do the machines generating the traffic have multiple paths?

The only time I've really seen pf have problems with
sessions is when 
the devices send and receive traffic via different paths or
multiple 
paths (i.e. traffic comes in via firewall01 but goes out
firewall02 and 
firewall01 and firewall02 do not implement pfsync).

Regards,

	Chris
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

On Fri, Mar 7, 2008 at 4:40 PM, Lorenz Helleis
<lorenzhelleisyahoo.com.br> wrote:
>  This is an internal firewall...  I think the entry in
the table session is desapearing, so the client needs to
make > another conection.  I´m thinking about create a
stateless rule.

I suspect this will only decrease your packet rates.  From
what I
understand, state table lookups are MUCH cheaper than rule
table
lookups.  Also, the congestion count increases (from memory)
when the
nic can't send packets, you might look at increasing then
net.inet.ip.intr_queue_maxlen sysctl if
net.inet.ip.intr_queue_drops
is showing a non-zero value (which it likely is if you are
pushing
400kpps w/out increasing the queue).

BTW, what version of FreeBSD, I didn't see it already
mentioned in the thread.

--Bill
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"