> I'm running:
> /sbin/ipfw pipe list > pipestats-`date "+%Y%m%d-%H%M%S"`
> from cron every minute for statistical purposes.
> Randomly (more often in loaded hours) it results in:
> ipfw: invalid oid len 0
> Is this enough to squash this bug?
Just a quick note:
It happened since 8.2, and
Hi lists,
I'm running:
/sbin/ipfw pipe list > pipestats-`date "+%Y%m%d-%H%M%S"`
from cron every minute for statistical purposes.
Randomly (more often in loaded hours) it results in:
ipfw: invalid oid len 0
Is this enough to squash this bug?
___
fre
Hi Hiroki,
> Does the attached patch (for 8.x kernel) fix your problem?
Unfortunately, it doesn't. :(
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr
Hi lists,
I'm observing something strange.
ipv6_enable="YES"
ipv6_gateway_enable="YES"
ipv6_network_interfaces="vlan3901"
ipv6_ifconfig_vlan3901="2001:7f8:42::a503:9310:1/64"
vlan3901: flags=8943 metric 0
mtu 1500
options=3
ether 00:15:17:38:13:7f
inet6 fe80::92e2:baff:f
> plans, yes - not sure how long it will take. I have compiled
> ipfw+dummynet as a standalone module (outside the kernel)
> but have not yet hooked the code to netmap to figure out how fast
> it can run.
If I understand correctly, this would require netmap to catch every
packet from interfaces
> a 1500-byte frame is 12k bits so you need 830 Kpps
> to saturate the 10G link in one direction (and say another 450 Kpps
> as acks in the other direction).
Obviously, sorry. Didn't have enough sleep lately :)
___
freebsd-net@freebsd.org mailing list
h
> IPFW seems to add more or less constant overhead per rule. In our setup,
> ~20 rules increase load by 100% (one core). We are able to reach 10GE
> (1.1mpps) on some routers with most packets travelling 8-10 ipfw rules.
> However, even with ipfw add 1 allow ip from any to any
> 1.1 mpps routing u
Hi lists,
Are there any profiling tools in the system or ports that would allow
me to determine how much processing is being done per packet and how
long does it take? I would like to predict possible PPS load for my
system and perhaps locate and remove some bottlenecks.
Is IPFW efficient
> At the moment maximum number of tables remains the same however it is
> now possible to define IPFW_TABLES_MAX to 65k without much (memory)
> overhead. Since pointer to tables are stored in array, defining 2^32
> tables require 4G * (8+8+1) memory for pointers only.
65k is also a good amount.
Hi Alexander,
> Changes:
> * Tables (actually, radix trees) are now created/freed on demand.
Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily
high number that would allow flexible numbering of tables? Arbitrarily
high being 0x or some other nice large number that won
Hi Alexander,
> I've got working implementation for IPv4+IPv6 and interface tables:
Lately every time I have some kind of problem, you come with a
solution ready :>
Thanks for the heads-up!
___
freebsd-net@freebsd.org mailing list
http://lists
Hi lists,
Are there any plans to implement IPv6 tables in ipfw? It would seem
that our gov. may want to force us into IPv6 in 6 months ;)
Cheers.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubsc
Hi list,
Having a different MAC address on vlan interface and parent interface
requires enabling promiscuous mode. Is this a bug, or is it working as
intended? Will leaving promiscuous mode enabled indefinitely hurt
performance on gigabit em interface?
_
Hi Adrian,
> Good news !
> Last night I remove FLOWTABLE option and since then the server is stable.
> No crash what so ever an I was able to increase the number of tunnels.
Yeah, FLOWTABLE still needs work, good news on the stability. Could
you perhaps drop us all a note in two weeks if things ke
Hi grappamp,
> I had notices some GSOC project in maybe 2008
> on MPLS. There doesn't seem to be much current
> talk of this. So I am unsure, excluding the GSOC,
> of the overall picture of MPLS in FreeBSD.
> Is there any current work? Or directions planned?
> Overall interest / demand?
I wrote ab
Hi Alexander,
> Actually, I'm working on MPLS support.
> Project page: http://freebsd.mpls.in
> Wiki: http://freebsd.mpls.in/wiki/index.php?title=Architecture
> Documentation is a bit outdated especially in QoS case
> I plan to get L3VPN working in several weeks
That's excellent news. Should yo
rking - so lets not get behind too far :)
Awaiting your thoughts,
Pawel Tyll
Nitronet Sp. z o.o.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Hi Luigi,
> we have recently worked on a project, called netmap, which lets
> FreeBSD send/receive packets at line rate even at 10 Gbit/s with
> very low CPU overhead: one core at 1.33 GHz does 14.88 Mpps with a
> modified ixgbe driver, which gives plenty of CPU cycles to handle
> multiple interfa
Hi guys and lists,
Hope I won't bring bad luck on myself by posting this too early, but
here goes.
Apparently during the last 3 weeks my bi-weekly crashing problem has
been solved. That, or world built without openssl was the reason.
$ uprecords
# Uptime | System
> addresses not needed, thanks. From what i saw in the backtrace, the panic
> occurred on an incoming packet on the 'antispoof' option.
> The ruleset confirms the backtrace, but since
> 'antispoof' happens
> to be run on every packet given it is on the first rule,
> it apparently has nothing to do
> understood. I am just saying that for instance the vlan presence and
> changes is quite significant in this context.
> You say vlans are "pretty much static" but can you tell us who adds/remove
> them, assign addresses ?
It's not that much work and changes are simple and far between. I do
that p
> The way a problem is presented has a big impact on how it gets handled:
> in this specific case the poster is pointing out a possible culprit
> (which may be helpful or misleading), and gives no hint on other
> things that may be relevant: number of interfaces, vlans, tunnels, taps,
> bpf etc ? a
> 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 i
> 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 p
> 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
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
> Just replying so you know I'm seeing it, but something that takes 14 days to
> even happen
> is NOT going to be an easy one to find. As Brandon said, all the info you
> can provide please.
Here's the dump in case you've not seen it before. Somehow 8.1-RELEASE
managed to make a proper dump, which
The following reply was made to PR kern/152360; it has been noted by GNATS.
From: Pawel Tyll
To: bug-follo...@freebsd.org
Cc: Brandon Gooch
Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet.
Date: Mon, 24 Jan 2011 02:04:10 +0100
Machine fell after 14 days, 22:31:42 for
On Fri, Jan 7, 2011, Brandon Gooch wrote:
> It's likely that the mbuf handling problem (in em_refresh_mbufs()) is
> triggered by the processing you're doing with ipfw (or elsewhere for
> that matter), so, yes, I think it's a bug fixed in the revision
> discussed.
> When you update and test, pleas
The following reply was made to PR kern/152360; it has been noted by GNATS.
From: Pawel Tyll
To: bug-follo...@freebsd.org
Cc: Brandon Gooch
Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet.
Date: Sun, 9 Jan 2011 03:14:09 +0100
As per Brandon Gooch's suggestion syste
One more question tough,
I have 4 identical machines, also with em-driven NICs - yet this is
the only one that dies like this. OTOH Other machines don't do traffic
shaping and do not use ipfw that extensively. Does this match your
theory?
___
freebsd-n
Hi Brandon,
> Might this be an issue with the em(4) driver? It may be that it's fixed:
> http://svn.freebsd.org/viewvc/base?view=revision&sortby=date&revision=216440
Thanks Brandon - I'll update to fresh stable and get back to you... in
three to four weeks :)
Hi lists,
I've reported this problem:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152360
and ever since 8.1-RELEASE this machine keeps panicking every two weeks
or so. Any help will be much appreciated. I'll be happy to provide any
more info to help tracking this down.
__
The following reply was made to PR kern/152360; it has been noted by GNATS.
From: Pawel Tyll
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet.
Date: Thu, 25 Nov 2010 18:40:16 +0100
Confirmed crash on FreeBSD 8.1-STABLE #0: Mon Nov 8 12
On Sat, 2 Nov 2002, Julian Elischer wrote:
> The code for doing non complient pppoe was written to be used as a
> client. I'm amazed it works as a server too.. (and I wrote it).
Well, it worked allright for me (and it would be a nice feature too, short
of this bug ;) )
> Am I right in understandi
Hi Brian,
Today, after few hours of fighting with FreeBSD, I found one nasty bug in
your PPPoEd implementation. It all started with accidental patching of
RASPPPoE windows PPPoE client (http://user.cs.tu-berlin.de/~normanb/).
There is a patch for RASPPPoE, which allows it to connect to non-RFC
co
36 matches
Mail list logo
