On 2/18/2011 7:49 PM, kevin wrote:
My current testing has shown little promise -- both firewalls will go up,
traffic will only go to the first firewall. If I reboot that first firewall,
no traffic will flow to the second bridging firewall. Note that all IPs on
my network (inside and out) are
Just updated a box to the 8.2-PREREL as of friday and now when we do any
serious amounts of network traffice we see:-
bge0: watchdog timeout -- resetting
bge0: link state changed to DOWN
bge0: link state changed to UP
The interface never recovers, we have to use remote console to down, wait
30
On 2/19/2011 4:13 PM, kevin wrote:
Could you send your ifconfig bridge output from both firewalls?
If STP is turned off on the four switch ports that the firewalls are
patched, one of the two firewalls must be root of the spanning tree.
I believe if you don't specify 'stp' in the rc.conf
On 2/19/2011 4:52 PM, Nikos Vassiliadis wrote:
I believe if you don't specify 'stp' in the rc.conf ifconfig statement,
freebsd by default sets the bridge as 'rstp' :
Yes, that's correct.
note to self
It helps sometimes when you read the actual message before trying to
answer:)
/note to
This may be totally unrelated to bge, investigating a potential failing stick
of ram in the machine in question so until we've ruled this out as the cause
don't want to waste anyone's time.
I did however notice the logic between the two fixes for DMA on 5704's on PCIX
in svn differ so wondering
No, you have to specify stp there. The default STP mode is RSTP.
If you don't specify stp, you'll get a dumb ethernet bridge.
Thanks very much for clarification. This helps me immensely. My room for
testing is limited so this will help me take the right steps necessary.
One quick last question :
One other thing :
id 00:17:d6:a9:31:e7 priority 16384 hellotime 2 fwddelay 15
And :
root id 00:12:cf:69:e9:ea priority 16384 ifcost 0 port 0
I was under the impression the priority for the root bridge should be a
lower number ? Would you be able to post your rc.conf bridge entries for
each
On 2/19/2011 6:11 PM, kevin wrote:
One other thing :
id 00:17:d6:a9:31:e7 priority 16384 hellotime 2 fwddelay 15
And :
root id 00:12:cf:69:e9:ea priority 16384 ifcost 0 port 0
I was under the impression the priority for the root bridge should be a
lower number ?
The priority is
On 2/19/2011 6:07 PM, kevin wrote:
One quick last question : would you recommend pfsync in this scenario,
between bridges? I've been hearing a lot of issues with pfsync but I'm not
sure what behavior to expect in a bridging scenario such as this one.
Can't really comment about pfsync as i have
On 19/02/2011 11:07, kevin wrote:
No, you have to specify stp there. The default STP mode is RSTP.
If you don't specify stp, you'll get a dumb ethernet bridge.
Thanks very much for clarification. This helps me immensely. My room for
testing is limited so this will help me take the right steps
Hi,
I would like to vote in favor of keeping NATM in the kernel. The reason
is that I am currently working on writing a device driver for the
SpeedTouch USB modem, to replace ports/net/pppoa which is not supported
on FreeBSD8+ any more. The SpeedTouch USB in fact terminates as an ATM
In ng_tty.c, function ngt_newhook(), there is the following code:
if (sc-hook)
return (EISCONN);
NGTLOCK(sc);
sc-hook = hook;
NGTUNLOCK(sc);
I do not think this is proper - should not the test be within the lock?
Regards,
Martin
--
Martin
There is a also the caveat: The switch will probably _not_ forward the STP
BPDU's from one port to another. This is because if the switch is a properly
compliant bridge it will not forwards the frames as they are marked as link
local ethernet multicast frame which is not allowed to forwarded by a
On Fri, Feb 18, 2011 at 11:26 PM, grarpamp grarp...@gmail.com wrote:
Doesn't FreeBSD have some sort of ndiswrapper function for this?
http://www.broadcom.com/support/802.11/linux_sta.php
NDISulator, ndis(4).
Hmm, maybe that only applies to the Windows driver bundles as
distributed by the
On Sat, Feb 19, 2011 at 03:59:57PM -, Steven Hartland wrote:
This may be totally unrelated to bge, investigating a potential failing
stick
of ram in the machine in question so until we've ruled this out as the cause
don't want to waste anyone's time.
I did however notice the logic
Hi guys, lists,
It's me, the bi-weekly panic guy. Guess what, it crashed today. As an
act of desperation I disabled the pipe dumping script after previous
crash, which today turned out to be merely a coincidence and didn't
prevent panics. (I thought it to be a longshot anyway, but it was the
only
2011/2/19 Pawel Tyll pt...@nitronet.pl:
Hi guys, lists,
It's me, the bi-weekly panic guy. Guess what, it crashed today. As an
act of desperation I disabled the pipe dumping script after previous
crash, which today turned out to be merely a coincidence and didn't
prevent panics. (I thought it
I've never seen a trace like this, and no absolutely nothing about dummynet,
sorry.
If it is in some way em's fault, then making sure you have the latest code
would be
a good idea. I have a test driver that is under selective test, it does
effect the code
path that you seem to be in, so it might
Hi,
After receiving a DDoS recently (likely SYN related on ports with
legitimate services), I was unable to contact my primary interface
gateway (immediate switch it's connected to).
When I looked at the ARP table I saw an 'incomplete' entry for this
gateway. I deleted it manually then
Same backtrace as reported here?
I'm unable to get the new backtrace, but judging from what I can see
on the console pre-reboot, it's exactly the same deal since
8.0-RELEASE - panic with dummynet as main star.
What revision of the em(4) driver code are you using? I know Jack has
been working
I was actually going to suggest Pawl try a different network device if
possible. I'm using dummynet on a network gateway equipped with
on-board bge(4). I haven't had any crashes, but then again, I'm not
seeing that many packets either.
It seems to be closely related to amount of processed
I've never seen a trace like this, and no absolutely nothing about dummynet,
sorry.
If it is in some way em's fault, then making sure you have the latest code
would be
a good idea. I have a test driver that is under selective test, it does
effect the code
path that you seem to be in, so
Hi Jack,
It would seem I've just been encountering this issue on an `em'
interface as well (chip ID 0x10d38086). The system has been up for a
bit more than a day. netstat(1) list about 2500 clusters allocation
denial. The mentioned interface was unable to receive traffic,
however, it continued to
23 matches
Mail list logo
