On Mon, Sep 19, 2005 at 03:13:33PM -0300, Vinicius Pavanelli Vianna wrote:
>
> I tried to disable pf (pfctl -d) and it continues to loss packets
<...>
> The count on in and out are different because the pf is blocking some
> packets
(?)
those seem to contradict one another., just a typo?
> didn't resolve the packet lost i begin to suspect something on the
> bridge code, as i don't see any error on the interface.
welp.. you could turn the bridge off and then run binat in pf, or
perhaps split the subnet.
i could see two ways to do this, one being kinda hackish and perhaps
outright wrong, but i believe either would work.
1) hackish:
( this would work, but involves a lot of ugly crap and proxy-arp,
so i decided to not even bring it up because i don't want people
to yell and puke at me ).
2) assuming the ISP and you have both chosen IPs from the beginning
of the subnet, have your ISP change their iface to you to be a /26 instead of
a /25. so, if they're .1/25, ask them to be .1/26. then change
the subnet mask on your end to match a /26 also ( 255.255.255.192 ).
so assume you're 200.xx.xx.2 netmask 0xffffffc0; have them now
static route 200.xx.xx.64/26 to 200.xx.xx.2.
if you and the ISP are high IPs, ( eg, .125, .126 ), sure, doesn't
matter, just make sure you're both in the same subnet, and then in
the next paragraph, use the lower subnet for the lan instead of the
higher:
this will make it so that you still get what amounts to the same /25,
but can put the lower /26 on the external iface and the upper /26
on your internal iface. so then take an IP from the .64/26 and put
it on the internal em(4) card, renumber any hosts behind that as
needed, and try to see if you still have the same packet loss
( assuming you have changed nothing thus far other than the IP
subnetting ).
if you have the IPs setup that way, you can remove the bridge
from existance and rely on normal net.inet.ip.forwarding=1.
> but the big problem is that some packets doesn't get even on the
> interface, my setup is like "add em0 add em1 up" on bridgename.bridge0
i checked the thread again but didn't see it mentioned.
where are you losing the packets?
are you losing packets on the link between ISP<->You or You<->YourLan ?
if you're losing them on ISP<->You, is that to the other end of the
external iface, ( eg, whatever you put for a default gateway on your
bridge box, their end of your /25 ) or to some other host beyond that?
> i also enabled STP as my ISP told me it would help
> their redundancy.
STP on a bridge seems like a Good Thing, but i don't think the ISP
side of it is going to matter much... i mean.. if they require
people to have the customer side of the link be either A) one single
host or B) something running spanning tree, then yeah, it seems logical,
but if not (eg - they do not make a certain requirement of what you attach
to their link), i would wager that spanning tree is not going to be part
of the solution to your problem. in other words, if they're not
running STP-aware bridges between the interface that is their side of your
/25 and the cable hitting your side of your /25, you running spanning
tree isn't going to mean dick for them.
for now, the "check autoneg/speed-duplex settings" seems to be a
good place to start. make each physical link agree (autoneg or forced)
on both ends, if they don't already.
if that doesn't pan out, consider trying the 1x/25-> 2x/26 thing i mention
above.
ps - given the dmesg you showed, the performance of pf is likely to not
be part of the question. smells like something else is happening here.
jared
--
[ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]