Re: freevrrp
On Thu, Jul 31, 2003 at 09:00:09PM +0200, Oldach, Helge wrote:
> > From: Bryce Edwards [mailto:[EMAIL PROTECTED]
> > Sent: Donnerstag, 31. Juli 2003 18:59
> > To: [EMAIL PROTECTED]
> > Subject: freevrrp
> >
> > I'm trying to run freevrrpd on a server with two interfaces
> > for redundancy.
>
> I would prefer a layer 2 based approach ("EtherChannel") instead because of
> the much better convergence in case of failure, and you also get load
> sharing in both directions. Bundling two or more interfaces by means of
> netgraph would probably serve the job.
>
> Are there any off-the-shelf, i.e. native FEC solutions available?
Have you tried the Netgraph FEC module? I donno if that's what
you want, but worth checking out...
--
Hiten M. Pandya
[EMAIL PROTECTED], [EMAIL PROTECTED]
http://hmp.serverninjas.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: TCP socket shutdown race condition
I don't think that's the problem, although it does seem suspicious.
Here's the struct ucred pointed to by the socket:
(kgdb) p *so.so_cred
$2 = {cr_ref = 3279453304, cr_uid = 3486088556, cr_ngroups = 1, cr_groups =
{
0, 3276863080, 3277717504, 21162, 0, 0, 0, 0, 0, 4294967295, 4294967295,
0, 0, 0, 0, 3279496516}, cr_uidinfo = 0x0}
This looks like garbage, but the cr_uidinfo pointer is null, and the cr_ref
of _this_ structure is 32 bits.
This doesn't look to me like a problem with the uidinfo, it looks to me like
the ucred structure has already been freed.
scot.
-Original Message-
From: Mike Silbersack [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 10:51 PM
To: Scot Loach
Cc: '[EMAIL PROTECTED]'
Subject: Re: TCP socket shutdown race condition
On Fri, 1 Aug 2003, Scot Loach wrote:
> Earlier this week one of our FreeBSD 4.7 boxes panic'd. I've posted the
> stack trace at the end of this message. Using google, I've found several
> references to this panic over the past three years, but it seems its never
> been taken to root cause.
>
> The box crashes because the cr_uidinfo pointer in the so_cred structure is
> null. However, on closer inspection the so_cred structure is corrupted
> (cr_ref=3279453304 for example), so I'm guessing it has already been
freed.
> Looking closer at the socket, I see that the SS_NOFDREF flag is set, which
> supports my theory. The tcpcb is in the CLOSED state, and has the SENTFIN
> flag set.
About how many concurrent connections are you pushing this machine to?
There's an unfortunate problem with uidinfo in 4.x:
struct uidinfo {
LIST_ENTRY(uidinfo) ui_hash;
rlim_t ui_sbsize; /* socket buffer space consumed */
longui_proccnt; /* number of processes */
uid_t ui_uid; /* uid */
u_short ui_ref; /* reference count */
};
It doesn't look like we have any seatbelts preventing ui_ref from
overflowing, thus causing an early free on the way back down, thereby
making all the other references to the structure junk. Can you try going
into kern_resource.c, finding the function uifind, and changing:
if (uip == NULL)
uip = uicreate(uid);
uip->ui_ref++;
return (uip);
to
if (uip == NULL)
uip = uicreate(uid);
uip->ui_ref++;
if (uip->ui_ref == 0)
panic("ui_ref overflowed");
return (uip);
That would confirm that it is the problem you're running into. If that is
the case, please tell us so that we can transition to the political side
of the problem. :)
Mike "Silby" Silbersack
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: TCP socket shutdown race condition
On Sat, 2 Aug 2003, Scot Loach wrote:
> I don't think that's the problem, although it does seem suspicious.
>
> Here's the struct ucred pointed to by the socket:
>
> (kgdb) p *so.so_cred
> $2 = {cr_ref = 3279453304, cr_uid = 3486088556, cr_ngroups = 1, cr_groups =
> {
> 0, 3276863080, 3277717504, 21162, 0, 0, 0, 0, 0, 4294967295, 4294967295,
> 0, 0, 0, 0, 3279496516}, cr_uidinfo = 0x0}
>
> This looks like garbage, but the cr_uidinfo pointer is null, and the cr_ref
> of _this_ structure is 32 bits.
>
> This doesn't look to me like a problem with the uidinfo, it looks to me like
> the ucred structure has already been freed.
>
> scot.
Well, as ui_ref is the best bet, redoing your tests with it expanded to
ui_int is where we need to start before looking further. :)
I believe that a uidinfo->ui_ref over/underflow could cause random memory
corruption, so maybe the panic you're seeing comes about after a bunch of
memory has already been trashed.
So anyway, promote ui_ref to a u_int and retest. Tell us what happens.
Mike "Silby" Silbersack
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dc TX underrun leads to delayed crash
Patch seems to be working fine. I also seem to be getting better linkage and transfer speeds too but that could just be my imagination *shrug*. Thanks. On Wed, Jul 30, 2003 at 05:05:49PM -0500, Mike Silbersack wrote: > > On Wed, 30 Jul 2003, Peter C. Lai wrote: > > > I'm noticing on a moderately loaded system, that sometimes when the kernel > > increases the TX threshold (/kernel: dc0: TX underrun -- increasing TX > > threshold), a few minutes later, the system hardlocks requiring a reset. > > This routinely happens when I'm streaming MP3s over the network and the box > > suddenly hardlocks; after I go back to inspect the logs, the TX buffer underrun > > is the only thing in the log before the start of the kernel reboot messages. > > This is occuring on 4.8-STABLE as of July 7, 2003 on an AMD K6-2 500 with > > 348 Mb RAM and VIA Apollo MVP3 chipset. When the lockups occur, the system > > temperatures are below 40C, with little disk activity, moderate ram and cpu > > usage; the NIC (linksys LNE-100TX A) is usually doing a steady 50K/s at this point. > > -- > > Peter C. Lai > > Rev 1.9.2.47 of if_dc.c (committed July 14th) should fix this problem for > you. MBUF_STRESS_TEST showed similar symptoms as mbuf chain lengths were > increased, which is how I detected the problem. > > Try grabbing the new if_dc.c: > > http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/pci/if_dc.c?rev=1.9.2.47&content-type=text/plain > > And see how things go. > > Mike "Silby" Silbersack -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dc TX underrun leads to delayed crash
On Sat, 2 Aug 2003, Peter C. Lai wrote: > Patch seems to be working fine. I also seem to be getting better linkage and > transfer speeds too but that could just be my imagination *shrug*. Thanks. It's possible that performance would be better under certain situations, but it would take a lot of measurement to really prove it. Either way, I'm glad that the change resolved your problems. Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mbuf clusters exhausted w/o reaching max?
On Fri, Aug 01, 2003 at 03:28:35PM -0500, Mike Silbersack wrote: > > On Fri, 1 Aug 2003, Steve Francis wrote: > > > I have a FreeBSD 4.8-RELEASE #5 system that reported: > > Aug 1 11:50:39 rack2-101 /kernel: All mbuf clusters exhausted, please see > > tuning(7). > > Aug 1 11:50:39 rack2-101 /kernel: All mbufs exhausted, please see tuning(7). > > > > Yet its not close to the max allowed for clusters. > > rack2-101.nyc# netstat -m > > 1338/4240/131072 mbufs in use (current/peak/max): > > 1338 mbufs allocated to data > > 709/3366/32768 mbuf clusters in use (current/peak/max) > > 7792 Kbytes allocated to network (7% of mb_map in use) > > 50 requests for memory denied > > 0 requests for memory delayed > > 0 calls to protocol drain routines > > rack2-101.nyc# > > Mbufs & mbuf clusters are allocated from the kernel map, so it's possible > for allocations to fail due to the kernel map being relatively full due to > other parts of the kernel eating memory. This is probably what's > happening in your case; given that only 50 allocations were denied, it > probably didn't hurt your system much. Actually, he's not running out of address space here; he's probably run out of free pages and could not block to wait for them. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw2 mac address matching weirdness?
I'm running FreeBSD 4.8 RELEASE w/ IPFW2 support enabled. I'm running into some weirdness with the mac address matching feature or perhaps it's my lack of understanding how it interacts with other rules. :) My goal is to transparently redirect everything except a few select MAC addresses but it doesn't appear to work properly. For example: net-ninja# ipfw list 1 skipto 65535 ip from any to any MAC any any in via sis0 2 fwd 127.0.0.1,8080 tcp from any to any dst-port 80 in via sis0 65535 allow ip from any to any This should allow every MAC address to bypass the transparent redirect but it doesn't. If I change rule #1 to: 1 skipto 65535 ip from any to any in via sis0 Things work as advertised. Any ideas? --- Mike Wade ([EMAIL PROTECTED]) Blue Highway Labs, LLC. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw2 mac address matching weirdness?
On Sun, Aug 03, 2003 at 01:31:23AM BST, Mike Wade wrote: > I'm running FreeBSD 4.8 RELEASE w/ IPFW2 support enabled. I'm running > into some weirdness with the mac address matching feature or perhaps it's > my lack of understanding how it interacts with other rules. :) > > My goal is to transparently redirect everything except a few select MAC > addresses but it doesn't appear to work properly. For example: > > net-ninja# ipfw list > 1 skipto 65535 ip from any to any MAC any any in via sis0 > 2 fwd 127.0.0.1,8080 tcp from any to any dst-port 80 in via sis0 > 65535 allow ip from any to any > > This should allow every MAC address to bypass the transparent redirect but > it doesn't. If I change rule #1 to: > > 1 skipto 65535 ip from any to any in via sis0 > > Things work as advertised. Any ideas? Try: sysctl net.link.ether.ipfw=1 Regards, -Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw2 mac address matching weirdness?
On Sun, 3 Aug 2003, Andy Gilligan wrote: > On Sun, Aug 03, 2003 at 01:31:23AM BST, Mike Wade wrote: > > I'm running FreeBSD 4.8 RELEASE w/ IPFW2 support enabled. I'm running > > into some weirdness with the mac address matching feature or perhaps it's > > my lack of understanding how it interacts with other rules. :) > > > > My goal is to transparently redirect everything except a few select MAC > > addresses but it doesn't appear to work properly. For example: > > > > net-ninja# ipfw list > > 1 skipto 65535 ip from any to any MAC any any in via sis0 > > 2 fwd 127.0.0.1,8080 tcp from any to any dst-port 80 in via sis0 > > 65535 allow ip from any to any > > > > This should allow every MAC address to bypass the transparent redirect but > > it doesn't. If I change rule #1 to: > > > > 1 skipto 65535 ip from any to any in via sis0 > > > > Things work as advertised. Any ideas? > > Try: > > sysctl net.link.ether.ipfw=1 Hmm, it was already set: net-ninja# sysctl net.link.ether.ipfw net.link.ether.ipfw: 1 --- Mike Wade ([EMAIL PROTECTED]) Blue Highway Labs, LLC. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw2 mac address matching weirdness?
On Sun, Aug 03, 2003 at 03:39:24AM BST, Mike Wade wrote: > On Sun, 3 Aug 2003, Andy Gilligan wrote: > > > On Sun, Aug 03, 2003 at 01:31:23AM BST, Mike Wade wrote: > > > I'm running FreeBSD 4.8 RELEASE w/ IPFW2 support enabled. I'm running > > > into some weirdness with the mac address matching feature or perhaps it's > > > my lack of understanding how it interacts with other rules. :) > > > > > > My goal is to transparently redirect everything except a few select MAC > > > addresses but it doesn't appear to work properly. For example: > > > > > > net-ninja# ipfw list > > > 1 skipto 65535 ip from any to any MAC any any in via sis0 > > > 2 fwd 127.0.0.1,8080 tcp from any to any dst-port 80 in via sis0 > > > 65535 allow ip from any to any > > > > > > This should allow every MAC address to bypass the transparent redirect but > > > it doesn't. If I change rule #1 to: > > > > > > 1 skipto 65535 ip from any to any in via sis0 > > > > > > Things work as advertised. Any ideas? > > > > Try: > > > > sysctl net.link.ether.ipfw=1 > > Hmm, it was already set: > > net-ninja# sysctl net.link.ether.ipfw > net.link.ether.ipfw: 1 The best advice I can give at the moment is to read the "PACKET FLOW" section in ipfw(8). A brief read over it suggests that it *may* not be possible to do what you ask, due to the rules being parsed twice. (in your case) The first pass is done from ether_demux(), and this will only match the first rule - it won't match tcp or dst-port 80, etc. The second pass will come from ip_input(), which will only match the second rule, as it doesn't know anything about MAC addresses. I could be missing something (it is 4am), so hopefully somebody will step in and tell me I'm wrong :) Sorry I couldn't be of more help. Best regards, -Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
