Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias))
On 2008-Jun-26 22:06:11 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: > I guess what I could do was to "poison" their arp cache for each >address with a "is-at" message. Is there a way to force the sending >of these messages for all the addresses of an interface? The kernel should send out gratuitous ARP requests whenever you assign an address to an interface. You could confirm that this is happening by tcpdumping the interface whilst you add aliases. Rummaging around in ports, you might find net/arping or net/p5-Net-ARP useful if you want to manually generate gratuitous ARP requests. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpzclAQNBmMO.pgp Description: PGP signature
Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6
[EMAIL PROTECTED] wrote: > Would you try patch at the following URL? > http://people.freebsd.org/~yongari/vr/vr.cam.patch Nope, didn't fix it (symptom's still the same)... ;_; Regards, Eugene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6
FWIW, I stumbled upon this while browsing through old -net archives... Apparently re(4) had a similar (same?) problem. http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034336.html http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034339.html Cheers, Eugene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6
On Fri, Jun 27, 2008 at 12:32:06AM -0700, Eugene M. Kim wrote: > [EMAIL PROTECTED] wrote: > > Would you try patch at the following URL? > > http://people.freebsd.org/~yongari/vr/vr.cam.patch > > Nope, didn't fix it (symptom's still the same)... ;_; > I've updated patch again. There was a bug that disabled multicasting filter. Back out previous patch and try again. The URL is the same as before. > Regards, > Eugene -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: altq on vlan
Giulio Ferro wrote: http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch Nope, this patch doesn't apply cleanly to freebsd 7... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6
On Fri, Jun 27, 2008 at 12:44:55AM -0700, Eugene M. Kim wrote: > FWIW, I stumbled upon this while browsing through old -net archives... > Apparently re(4) had a similar (same?) problem. > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034336.html > http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034339.html > I believe these were already fixed in CURRENT/stable. I think your issue is a regression of vr(4) overhauling. Since VT6105M supports perfect filtering on multicast frames with CAM I've added that hardware capability but it seems that CAM programming wasn't correct. > Cheers, > Eugene -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0: sockets stuck in CLOSED state...
On Thu, 26 Jun 2008, Robert Watson wrote: I think the first logical step is to wait for the application to get into that state again, and then run procstat or fstat to dump the file descriptor away for the process. Presumably in the normal steady state, you expect to see a few IPC sockets (syslog, etc), a TCP listen socket, and some number of in-progress TCP sessions. The question, of course, is whether you see a lot more file descriptors than that, and in particular, ones that matched the CLOSED entries in netstat. If you find that there are lots of open file descriptors and they match up approximately with netstat, then it's an application bug that just manifests a bit differently in 7.x than in 6.x. On the other hand, if you see only a small number of open file descriptors, then we may be looking at something quite a bit more complicated. Just a public followup for those following the thread: Ali has sent me netstat and sockstat/fstat data. It looks like each of the TCP connections appear in the netstat output in the CLOSED state also appears in sockstat with a file descriptor. This suggests an bug in which file descriptors are occasionally leaked, perhaps early in their life cycle as there's a bit of data in the input buffer. However, it's unclear still if it's an application bug (occasionally missing a close() on an accepted file descriptor) or a kernel bug (accept() or close() misbehaving such that the application doesn't know the file descriptor is open, or has tried to close it but no succeeded). Ali mentioned in his e-mail that he was seeing EBADF on occasion from close(), which could mean a bug is causing the wrong file descriptor number to be passed in. If there's a kernel bug involved, then you could imagine it being along the lines of "accept(2) returns a file descriptor but also sets an error, so the application simply sees the error but the file descriptor remains installed in the process's file descriptor table", leading to the appearance of a leak. I've asked Ali to do a bit more debugging and tracing of the application to see if we can reach any conclusions about this. In particular, if he traces to a file all file descriptor numbers returned by accept(2), then we can later compare that file with the leaked descriptors present in netstat/sockstat and decide whether the application *should* have known they were open or not. I also spotted a bug in the netstat/sockstat output, unrelated, in which the port number of the inpcb is cleared when the connection closes, meaning that netstat shows '*' as the port number. This isn't really necessary, but does lead to potentially confusing output. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6
Pyun YongHyeon wrote: I've updated patch again. There was a bug that disabled multicasting filter. Back out previous patch and try again. The URL is the same as before. > Regards, > Eugene rtsol still doesn't work with vr0 being in non-promiscuous mode. However, apparently vr0 picked up router solicitations during system boot-up, as ifconfig shows the correct prefixes autoconfigured. It seems something goes wrong in between. 'o 'a Eugene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: altq on vlan
On Thursday 26 June 2008 22:21:54 Giulio Ferro wrote:
> I've tried to set altq bandwidth control on a vlan interface, but this
> feature
> doesn't seem to be supported by the vlan driver.
>
> I've googled around and I've found that there should be a trivial patch
> to enable this feature:
> http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch
>
> If this is so trivial, why hasn't it been included in the freebsd
> source tree?
>
> Anyway has anybody tried that? How does that work? Are there other
> (better) patches around?
You don't need a patch at all. What you do is: Queue on the physical
interface, classify on the vlan interface. It is broken to allow ALTQ on
a virtual interface if you can do it otherwise.
in pf.conf speak:
If you have "ifconfig vlanX vlandev bge0 ..."
altq on bge0 queue { vlan0, vlan1, ... }
queue vlan0 ... { vlan0_foo, vlan0_bar, ... }
queue vlan0_foo
queue vlan0_bar
...
pass on vlanX ... queue vlanX_foobar
And there you go. No patch - whatsoever - required here.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPV6 problem : nd6_lookup: failed to add route for a neighbor
Tuc at T-B-O-H.NET wrote: Hi, Running 5.5 (And no "upgrade" messages please, I'm forced to, its out of my hands) and trying to bring up HE's IPV6. I've got it running on a 4.10 system (Ok, feel free to tell me to upgrade, this one is more a lazy issue.. But I am making progress. I bought new drives that'll be here next week so I can load 7.0 from scratch) with no worries at all. Piece of cake, has been for ages. But once I brought it all up, I got : kernel: nd6_lookup: failed to add route for a neighbor(2001:0470:0007:0028::0001), errno=17 and ALOT of them. Taking a quick look in Google, it seems that they claim its a prefix len issue, but I am running with a 128 prefix length even though it seems they say : Client IPv6 address:2001:470:7:28::2/64 The script they suggest, and I used, is : ifconfig gif0 create ifconfig gif0 tunnel MYIP 216.66.22.2 ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 128 route -n add -inet6 default 2001:470:7:28::1 ifconfig gif0 up The tunnel came up, was passing traffic, but those messages were getting out of hand. I tried a prefixlen of 64, and I got: ...h. I'm not certain here, but since /128 represents only a single address, I can understand why FreeBSD is getting confused. A /128 is an IP within its own solitary subnet, so I'd have to guess that you need a route to the remote end of the tunnel before you can set it as a default gateway. I've been needing to set up a few more tunnels, so I'll try one with FreeBSD this morning with the same setup you have to try to replicate the problem (on 7.0). ifconfig: ioctl (SIOCAIFADDR): Invalid argument What was the command that you had entered when you received the above error? When you tried to change prefix length, did you destroy the existing tunnel first? Sendmail seemed a bit cranky : Jun 26 23:53:19 MYHOST sendmail[17543]: gethostbyaddr(IPv6:2001:470:7:28::2) failed: 1 I believe this is a reverse DNS issue. From how I perceive that message, Sendmail is trying to retrieve a hostname based on that IP. Steve ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0: sockets stuck in CLOSED state...
Ali, good day. Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote: > > Just a quick "me too" message: I also used to see this on my 7.x > > machines. This was with Apache servers in the proxy setup: one > > I'm wondering: where these 32 bit, or 64 bit machines? amd64. > > I had already tried to debug this situation and Mike Silbersack > > helped me with patching the kernel. At that days his patches (that > > went into 7.x) helped, but with higher request rate to the Apache, > > they seem to be back again. I can try to setup the testbed and > > verify if I will still be able to reproduce them. Will it be needed? > > > > Well, if your machine was indeed 64 bit, I for one would be very > interested in knowing if it also appears in 32 bit. Have no i386 machines to test on, sorry. Moreover, I can not yet reproduce the problem on my amd64, but I am continuing experiments. -- Eygene Remember that it is hard to read the on-line manual while single-stepping the kernel. -- FreeBSD Developers handbook ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias))
Peter Jeremy wrote: On 2008-Jun-26 22:06:11 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: I guess what I could do was to "poison" their arp cache for each address with a "is-at" message. Is there a way to force the sending of these messages for all the addresses of an interface? The kernel should send out gratuitous ARP requests whenever you assign an address to an interface. You could confirm that this is happening by tcpdumping the interface whilst you add aliases. Rummaging around in ports, you might find net/arping or net/p5-Net-ARP useful if you want to manually generate gratuitous ARP requests. ping -S src_addr should do the trick too, however, that obviously doesn't scale very well, so it's probably only best to test with.. Steve ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0: sockets stuck in CLOSED state...
I have the same 'problem' if that helps any.. Sockets stuck for over a month in CLOSED and they have a * for the port on the source IP. tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. Eygene Ryabinkin wrote: Ali, good day. Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote: Just a quick "me too" message: I also used to see this on my 7.x machines. This was with Apache servers in the proxy setup: one I'm wondering: where these 32 bit, or 64 bit machines? amd64. I had already tried to debug this situation and Mike Silbersack helped me with patching the kernel. At that days his patches (that went into 7.x) helped, but with higher request rate to the Apache, they seem to be back again. I can try to setup the testbed and verify if I will still be able to reproduce them. Will it be needed? Well, if your machine was indeed 64 bit, I for one would be very interested in knowing if it also appears in 32 bit. Have no i386 machines to test on, sorry. Moreover, I can not yet reproduce the problem on my amd64, but I am continuing experiments. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0: sockets stuck in CLOSED state...
Paul, good day. Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote: > I have the same 'problem' if that helps any.. Sockets stuck for over a > month in CLOSED and they have a * for the port on the source IP. > tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED > 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 > amd64 > Doesn't seem to cause any issues though. And what is listening to that port? Can you identify the application? Just for the record -- may be it will narrow down the search list. Robert Watson told us today at the morning that he spotted the bug that lead to the '*' instead of port number. Robert, can you post the patch -- it seems to be not yet committed, at least cvs-src list has no signs of it? By the way, is the patch touches in_pcbdrop() in /sys/netinet/in_pcb.c, removing instruction 'inp->inp_lport = 0;'? -- Eygene Remember that it is hard to read the on-line manual while single-stepping the kernel. -- FreeBSD Developers handbook ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NAT-T patch integration
At Thu, 26 Jun 2008 12:56:41 -0700, julian wrote: > > I'm planning on committing it unless someone can provide a reason not > to, as I've seen it working, needed it, and have not seen any bad > byproducts. > I'd be interested to know how you tested it. NAT-T and IPsec are non-trivial protocols/subsystems that can have far reaching impacts on the network stack. Also, are you planning to maintain it after committing it? The biggest problem with NAT-T hasn't been the code, it's been that the author, who is doing a great job on the code, has been too busy to maintain it anywhere but at work. That is not a slam on the person or the code, I have the highest respect for both, but it reflects and important reality of the situation. Unless you're stepping up to maintain it as well as commit it I think it should not be committed. I know the Bjoern has been working hard to pick up the IPsec stuff in his free time, and I value his input on this subject quite a bit. Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weirdness - FBSD 7, Routing, Packet generator, em taskq
At Thu, 26 Jun 2008 23:25:18 -0400, Paul wrote: > > I have a FreeBSD router set up with Full BGP routes and I'm doing some > tests on using it for routing. > > 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 > amd64 > > oddness..: > > Use a packet generator to generate random source ips and ports and send > traffic through the router to a destination on the other side, single ip. > What happens is the 'em0 taskq' starts to eat cpu... but the funny > thing is immediately when I start the traffic (say, 100,000 pps) em0 > taskq is about 15% cpu.. and then over the course of 2 minutes or so it > climbs to 60% cpu.. This makes no sense.. The packets per second are > continuous and it just routed 100kpps for 60 seconds with less cpu so > why in the world would it slowly climb like that? > > It's an observation I suppose and I was hoping if someone could > enlighten me on WHY.. :) I did test it on 3 different machines by the way. > It even does this with just a handful of routes in the routing table , I > tried that too just to rule that out. > I don't remember Freebsd 4/5 doing this?? > What are you using to measure the CPU time? Some tools take time to gather up enough samples. Also, have you tried to do any profiling on the kernel to see why this might be the case? http://www.watson.org/~robert/freebsd/netperf/profile/ Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic
The following reply was made to PR kern/121257; it has been noted by GNATS. From: Alex Samorukov <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic Date: Fri, 27 Jun 2008 16:48:15 +0200 I can approve the problem. I found VERY slow outgoing speed on my new server with natd, and the problem was with TSO flag on public interface. Freebsd 7.0/i386, em network driver ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: altq on vlan
On 6/27/08, Max Laier <[EMAIL PROTECTED]> wrote:
>
>
> You don't need a patch at all. What you do is: Queue on the physical
> interface, classify on the vlan interface. It is broken to allow ALTQ on
> a virtual interface if you can do it otherwise.
>
> in pf.conf speak:
>
> If you have "ifconfig vlanX vlandev bge0 ..."
>
> altq on bge0 queue { vlan0, vlan1, ... }
> queue vlan0 ... { vlan0_foo, vlan0_bar, ... }
> queue vlan0_foo
> queue vlan0_bar
> ...
>
> pass on vlanX ... queue vlanX_foobar
>
> And there you go. No patch - whatsoever - required here.
But the patch simplify the cases where you need one queue per vlan.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: altq on vlan
On Friday 27 June 2008 18:57:59 Alexandre Biancalana wrote:
> On 6/27/08, Max Laier <[EMAIL PROTECTED]> wrote:
> > You don't need a patch at all. What you do is: Queue on the
> > physical interface, classify on the vlan interface. It is broken to
> > allow ALTQ on a virtual interface if you can do it otherwise.
> >
> > in pf.conf speak:
> >
> > If you have "ifconfig vlanX vlandev bge0 ..."
> >
> > altq on bge0 queue { vlan0, vlan1, ... }
> > queue vlan0 ... { vlan0_foo, vlan0_bar, ... }
> > queue vlan0_foo
> > queue vlan0_bar
> > ...
> >
> > pass on vlanX ... queue vlanX_foobar
> >
> > And there you go. No patch - whatsoever - required here.
>
> But the patch simplify the cases where you need one queue per vlan.
NO! It is just wrong! There is no relation between vlan queues on the
same physical interface and thus you can't guarantee anything! Can we
please stop with this nonsense and not bring up the patch every other
month.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPV6 problem : nd6_lookup: failed to add route for a neighbor
> > kernel: nd6_lookup: failed to add route for a > > neighbor(2001:0470:0007:0028::0001), errno=17 > > > > Client IPv6 address:2001:470:7:28::2/64 > > > > The script they suggest, and I used, is : > > > > ifconfig gif0 create > > ifconfig gif0 tunnel MYIP 216.66.22.2 > > ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 128 > > route -n add -inet6 default 2001:470:7:28::1 > > ifconfig gif0 up > > > > The tunnel came up, was passing traffic, but those messages were > > getting out of hand. I tried a prefixlen of 64, and I got: > > ...h. I'm not certain here, but since /128 represents only a single > address, I can understand why FreeBSD is getting confused. A /128 is an > IP within its own solitary subnet, so I'd have to guess that you need a > route to the remote end of the tunnel before you can set it as a default > gateway. > Even though its a directly connected endpoint? I was going to ask if trying : route -n add -inet6 default gif0 might make it happier, but it seems route on FBSD 5.5 doesn't accept that format of command. :-/ I also saw suggestions to change the prefixlen to 127, but I get the sem ioctl issue. I don't want to say "But it works elsewhere", but... doing : ipv6_enable="YES" gif_interfaces="gif0" ipv6_defaultrouter="2001:470:1F00:::5E4" gifconfig_gif0="MYIP 64.71.128.82" ipv6_ifconfig_gif0="2001:470:1F00:::5E5 2001:470:1F00:::5E4 prefixlen 128" on a 4.10-STABLE system works fine... But I realize theres been alot of code work since that beast. > > I've been needing to set up a few more tunnels, so I'll try one with > FreeBSD this morning with the same setup you have to try to replicate > the problem (on 7.0). > Ok, thanks. I'm a bit confused also by something I found on the net... http://lists.freebsd.org/pipermail/freebsd-net/2006-May/010718.html Seemed to be a set of patches around this very issue. I've looked at a 7.0-STABLE system and I don't see those changes. But it could very well be that it was updated differently before finally getting into the codebase. I'm not sure how one goes about verifying it. CVSWEB? > > > ifconfig: ioctl (SIOCAIFADDR): Invalid argument > > What was the command that you had entered when you received the above > error? When you tried to change prefix length, did you destroy the > existing tunnel first? > Sorry. I tried : ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 64 I had destroyed the tunnel and started from scratch... > > > Sendmail seemed a bit cranky : > > > > Jun 26 23:53:19 MYHOST sendmail[17543]: > > gethostbyaddr(IPv6:2001:470:7:28::2) failed: 1 > > I believe this is a reverse DNS issue. From how I perceive that message, > Sendmail is trying to retrieve a hostname based on that IP. > Yea, not sure why I mentioned that. But in any case, not sure what to do to remedy the situation. Thanks, Tuc ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0: sockets stuck in CLOSED state...
Hi Eygene.. It happens with telnet :) A lot of my closed entries are from telnet so I can't really put a finger on any specific application :/ Eygene Ryabinkin wrote: Paul, good day. Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote: I have the same 'problem' if that helps any.. Sockets stuck for over a month in CLOSED and they have a * for the port on the source IP. tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. And what is listening to that port? Can you identify the application? Just for the record -- may be it will narrow down the search list. Robert Watson told us today at the morning that he spotted the bug that lead to the '*' instead of port number. Robert, can you post the patch -- it seems to be not yet committed, at least cvs-src list has no signs of it? By the way, is the patch touches in_pcbdrop() in /sys/netinet/in_pcb.c, removing instruction 'inp->inp_lport = 0;'? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0: sockets stuck in CLOSED state...
On Fri, 27 Jun 2008, Eygene Ryabinkin wrote: Paul, good day. Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote: I have the same 'problem' if that helps any.. Sockets stuck for over a month in CLOSED and they have a * for the port on the source IP. tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. And what is listening to that port? Can you identify the application? Just for the record -- may be it will narrow down the search list. Robert Watson told us today at the morning that he spotted the bug that lead to the '*' instead of port number. Robert, can you post the patch -- it seems to be not yet committed, at least cvs-src list has no signs of it? By the way, is the patch touches in_pcbdrop() in /sys/netinet/in_pcb.c, removing instruction 'inp->inp_lport = 0;'? Hi Eygene, I've not yet had a chance to put the patch together; it does involve removing that line, but it's somewhat more complicated because inp_lport is used to signal whether or not the inpcb is still in various linked list. My current thinking is that I'd actually like to make it an explicit flag that indicates being on the lists so that we can have the port set non-zero yet no longer be on the lists (which would cause the closed connection to occupy the tuple). Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weirdness - FBSD 7, Routing, Packet generator, em taskq
I'm watching top -S -I -s1 -H This is just more of an observation.. I'm not having a problem with it, just wondering why it's doing it.. It's almost like most of the system processes in 'top' are a 3-5 minute average instead of an instant percentage. If this is intended behavior I simply wanted to know :) Curiousity Mainly. Also, isn't the emX taskq supposed to be using no cpu when polling is enabled? I'm trying to get em interface to take in 500kpps or more but it just won't do it. The max I can get is close to 400k and then it starts loading up on errors (out of receive buffers, rx overruns) mainly because the cpu is near 100% on em0 taskq. :( We need a SMP em driver for 7.0 :) No profiling yet... just messing around.. Intel Dual port pci-express nic , opteron 2212 , 7.0-stable now AMD64 seeing how much it will take before it errors out so I can figure out something to do with it.. :P Thanks :) Paul [EMAIL PROTECTED] wrote: At Thu, 26 Jun 2008 23:25:18 -0400, Paul wrote: I have a FreeBSD router set up with Full BGP routes and I'm doing some tests on using it for routing. 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 oddness..: Use a packet generator to generate random source ips and ports and send traffic through the router to a destination on the other side, single ip. What happens is the 'em0 taskq' starts to eat cpu... but the funny thing is immediately when I start the traffic (say, 100,000 pps) em0 taskq is about 15% cpu.. and then over the course of 2 minutes or so it climbs to 60% cpu.. This makes no sense.. The packets per second are continuous and it just routed 100kpps for 60 seconds with less cpu so why in the world would it slowly climb like that? It's an observation I suppose and I was hoping if someone could enlighten me on WHY.. :) I did test it on 3 different machines by the way. It even does this with just a handful of routes in the routing table , I tried that too just to rule that out. I don't remember Freebsd 4/5 doing this?? What are you using to measure the CPU time? Some tools take time to gather up enough samples. Also, have you tried to do any profiling on the kernel to see why this might be the case? http://www.watson.org/~robert/freebsd/netperf/profile/ Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: altq on vlan
> > NO! It is just wrong! There is no relation between vlan queues on the > same physical interface and thus you can't guarantee anything! Can we > please stop with this nonsense and not bring up the patch every other > month. Understood !! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0: sockets stuck in CLOSED state...
On Fri, 27 Jun 2008, Paul wrote: I have the same 'problem' if that helps any.. Sockets stuck for over a month in CLOSED and they have a * for the port on the source IP. tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. If you use "sockstat" to list the sockets open in processes, do any match the entry in netstat? If so, which? If you shut down that program, does the entry disappear from netstat? Robert N M Watson Computer Laboratory University of Cambridge Eygene Ryabinkin wrote: Ali, good day. Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote: Just a quick "me too" message: I also used to see this on my 7.x machines. This was with Apache servers in the proxy setup: one I'm wondering: where these 32 bit, or 64 bit machines? amd64. I had already tried to debug this situation and Mike Silbersack helped me with patching the kernel. At that days his patches (that went into 7.x) helped, but with higher request rate to the Apache, they seem to be back again. I can try to setup the testbed and verify if I will still be able to reproduce them. Will it be needed? Well, if your machine was indeed 64 bit, I for one would be very interested in knowing if it also appears in 32 bit. Have no i386 machines to test on, sorry. Moreover, I can not yet reproduce the problem on my amd64, but I am continuing experiments. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Understanding where dummynet fits into an ipfw ruleset
I'm trying to figure out how traffic shaping using dummynet fits into an ipfw ruleset. Mainly, I'm wondering where to put the "ipfw queue" rules (the ones that send the packets to dummynet), in relation to the packet filtering rules, or if it even matters. For instance, do the queue rules apply to all the rules in the set, or only to rules that follow after the queue rules (numerically)? Say I've got a firewall setup that does 1:1 NAT for a bunch of servers (allow incoming/outgoing traffic), as well as 1:many NAT for the workstations (allow outgoing) on the LAN. I want to add traffic shaping rules that give traffic from the workstations to specific IPs greater weight than general traffic from the workstations to the Internet (ie reserve 25% of the bandwidth for important services). Would I put the queue rules at the start of the ruleset or the end? Or in the middle, just above the rules for the workstations? Do I add them after all the bad packet checks and general deny rules that are at the top of the ruleset? Just wondering how the queue rules interact with the general packet filter rules, since they can have the same parameters. Thanks. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias))
Peter Jeremy wrote: On 2008-Jun-26 22:06:11 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: I guess what I could do was to "poison" their arp cache for each address with a "is-at" message. Is there a way to force the sending of these messages for all the addresses of an interface? The kernel should send out gratuitous ARP requests whenever you assign an address to an interface. You could confirm that this is happening by tcpdumping the interface whilst you add aliases. Rummaging around in ports, you might find net/arping or net/p5-Net-ARP useful if you want to manually generate gratuitous ARP requests. I have bad news for you all: this doesn't seem to happen for alias interfaces. I've just tried to replicate what happened days ago. I've verified that only the base (non alias) interface sends proper is-at messages. The aliases don't I could't either ping from one of those addresses or ping to one of them until I isssued: arping -S aliased-address router-address The router didn't know the mac addresses had changed until then... Can anyone confirm this? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NAT-T patch integration
George V. Neville-Neil wrote: At Thu, 26 Jun 2008 12:56:41 -0700, julian wrote: I'm planning on committing it unless someone can provide a reason not to, as I've seen it working, needed it, and have not seen any bad byproducts. I'd be interested to know how you tested it. NAT-T and IPsec are non-trivial protocols/subsystems that can have far reaching impacts on the network stack. Also, are you planning to maintain it after committing it? The biggest problem with NAT-T hasn't been the code, it's been that the author, who is doing a great job on the code, has been too busy to maintain it anywhere but at work. That is not a slam on the person or the code, I have the highest respect for both, but it reflects and important reality of the situation. Unless you're stepping up to maintain it as well as commit it I think it should not be committed. I know the Bjoern has been working hard to pick up the IPsec stuff in his free time, and I value his input on this subject quite a bit. Best, George NAT-T is needed for ipsec to work correctly with a bunch of vpn servers such as the cisco VPN server. It's been seen by dozens of people to do exactly that. It's added to every single pfsense and m0n0wall router out there. Code inspection also shows that it shouldn't compromise non-NAT_T sessions. so, It allows one to do things that many people need. It doesn't screw up existing applications (that I've ever heard of). The author is responsive and shows dedication. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Understanding where dummynet fits into an ipfw ruleset
On Jun 27, 2008, at 1:01 PM, Freddie Cash wrote: Mainly, I'm wondering where to put the "ipfw queue" rules (the ones that send the packets to dummynet), in relation to the packet filtering rules, or if it even matters. For instance, do the queue rules apply to all the rules in the set, or only to rules that follow after the queue rules (numerically)? That pretty depends on whether net.inet.ip.fw.one_pass sysctl is set: pipe pipe_nr Pass packet to a dummynet(4) ``pipe'' (for bandwidth limitation, delay, etc.). See the TRAFFIC SHAPER (DUMMYNET) CONFIGURATION Section for further information. The search terminates; however, on exit from the pipe and if the sysctl(8) variable net.inet.ip.fw.one_pass is not set, the packet is passed again to the firewall code starting from the next rule. Would I put the queue rules at the start of the ruleset or the end? Or in the middle, just above the rules for the workstations? Do I add them after all the bad packet checks and general deny rules that are at the top of the ruleset? Just wondering how the queue rules interact with the general packet filter rules, since they can have the same parameters. It's reasonable to place the dummynet queue and pipe statements immediately after anti-spoofing checks, if net.inet.ip.fw.one_pass is false; that way, all traffic is shaped, including stuff that is later blocked by other IPFW statements. Since the inbound traffic has already passed through your external link(s) anyway, you might as well acknowledge that it has. If net.inet.ip.fw.one_pass is true, then you definitely want to apply your deny rules first, as once something matches a pipe rule, it's going to be passed. The tradeoff is that the accounting/fairness of traffic is less accurate but the firewall ruleset runs faster... -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Understanding where dummynet fits into an ipfw ruleset
On Fri, Jun 27, 2008 at 2:37 PM, Chuck Swiger <[EMAIL PROTECTED]> wrote: > On Jun 27, 2008, at 1:01 PM, Freddie Cash wrote: >> Mainly, I'm wondering where to put the "ipfw queue" rules (the ones >> that send the packets to dummynet), in relation to the packet >> filtering rules, or if it even matters. >> >> For instance, do the queue rules apply to all the rules in the set, or >> only to rules that follow after the queue rules (numerically)? > > That pretty depends on whether net.inet.ip.fw.one_pass sysctl is set: [snip man page snippet] >> Would I put the queue rules at the start of the ruleset or the end? >> Or in the middle, just above the rules for the workstations? Do I add >> them after all the bad packet checks and general deny rules that are >> at the top of the ruleset? >> >> Just wondering how the queue rules interact with the general packet >> filter rules, since they can have the same parameters. > > It's reasonable to place the dummynet queue and pipe statements immediately > after anti-spoofing checks, if net.inet.ip.fw.one_pass is false; that way, > all traffic is shaped, including stuff that is later blocked by other IPFW > statements. Since the inbound traffic has already passed through your > external link(s) anyway, you might as well acknowledge that it has. Makes sense. That's the bit that was messing me up (one_pass). I'm still working my head around how it (one_pass) integrates with all the rest (divert/natd, fwd, dummynet) in a single ruleset. Looking at sysctl output on a handful of systems, some of our firewalls has one_pass enabled, others don't. That's probably what's been tripping me up, as sometimes a ruleset worked, other times it didn't, depending on the FreeBSD release (4.x, 6.x, 7.x) the firewall started with. It's only recently that I've started standardising settings across firewalls with standard hardware configs, generic rc.conf/sysctl.conf, specific rc.conf.local, and so on. Which is why I'm asking. > If net.inet.ip.fw.one_pass is true, then you definitely want to apply your > deny rules first, as once something matches a pipe rule, it's going to be > passed. The tradeoff is that the accounting/fairness of traffic is less > accurate but the firewall ruleset runs faster... So, in this situation, the "allow" rules would be the queue rules? To add traffic shaping to the following, using one_pass=1: 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 300 deny ip from any to 2.2.2.2 in recv em0 Would be: 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 300 deny ip from any to 2.2.2.2 in recv em0 Or am I way off here? :) -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias))
On 2008-Jun-27 22:59:56 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote: >Peter Jeremy wrote: >> The kernel should send out gratuitous ARP requests whenever you assign >> an address to an interface. You could confirm that this is happening >> by tcpdumping the interface whilst you add aliases. >> >I have bad news for you all: this doesn't seem to happen for alias >interfaces. I've just tried to replicate what happened days >ago. I've verified that only the base (non alias) interface sends >proper is-at messages. The aliases don't I'm not seeing this on physical interfaces. I can't immediately verify this on VLAN interfaces but could at work next week. Adding 192.168.123.253 as an alias on FreeBSD 7.0-STABLE (mid May): 08:21:39.899113 00:0f:b0:74:9c:a3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 Adding 192.168.123.253 as an alias on FreeBSD 6.3-PRERELEASE: 08:24:21.077266 00:12:0e:20:2b:ad > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmwFmgmkYdF.pgp Description: PGP signature
Re: FreeBSD NAT-T patch integration
On Fri, 27 Jun 2008 11:06:19 -0400, "George V. Neville-Neil" <[EMAIL PROTECTED]> wrote: > At Thu, 26 Jun 2008 12:56:41 -0700, > julian wrote: >> >> I'm planning on committing it unless someone can provide a reason not >> to, as I've seen it working, needed it, and have not seen any bad >> byproducts. >> > > I'd be interested to know how you tested it. NAT-T and IPsec are > non-trivial protocols/subsystems that can have far reaching impacts on > the network stack. Also, are you planning to maintain it after > committing it? The biggest problem with NAT-T hasn't been the code, > it's been that the author, who is doing a great job on the code, has > been too busy to maintain it anywhere but at work. That is not a slam > on the person or the code, I have the highest respect for both, but it > reflects and important reality of the situation. Unless you're > stepping up to maintain it as well as commit it I think it should not > be committed. I know the Bjoern has been working hard to pick up the > IPsec stuff in his free time, and I value his input on this subject > quite a bit. > I have tested the patch with Cisco (PIX/ASA), Juniper (GT/SSG), Fortigate, Zywall, Linux and NetBSD to ensure interoperability. Mostly, the RFC and draft 2 versions of the protocol were exercised. What other kinds of tests would you like to see? Objections ... 1) NAT-T and IPsec are non-trivial protocols/subsystems The patch hasn't been reviewed enough? The patch hasn't been tested enough? An unresolved issue has been identified? 2) It can have far reaching impacts on the network stack The changes are not been sufficiently protected by the supplied kernel configuration option? 3) The author has been too busy to maintain it anywhere but at work What does this mean? Since you find his level of commitment unacceptable, what would be required for the patch to be accepted? Thanks, -Matthew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Understanding where dummynet fits into an ipfw ruleset
On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote: [ ... ] If net.inet.ip.fw.one_pass is true, then you definitely want to apply your deny rules first, as once something matches a pipe rule, it's going to be passed. The tradeoff is that the accounting/fairness of traffic is less accurate but the firewall ruleset runs faster... So, in this situation, the "allow" rules would be the queue rules? To add traffic shaping to the following, using one_pass=1: 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 300 deny ip from any to 2.2.2.2 in recv em0 Would be: 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 300 deny ip from any to 2.2.2.2 in recv em0 Or am I way off here? :) Hmm. If you have one_pass set, I believe that rule 200 would become superfluous. If it was off, rule 200 would be needed to permit traffic through. However, queue rulesets are used to classify traffic into different bins; then then get pulled out of the bins with packets waiting is proportion to the weights configured via something like: ipfw queue 1 config pipe 1 weight 10 ie, you have to attach queue(s) to a pipe for this classification or sorting to be meaningful. -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weirdness - FBSD 7, Routing, Packet generator, em taskq
Firstly, tried turning off polling? Some of us have found it to be detrimental to performance on the more modern systems. Its use was more practical on older systems were servicing interrupts took alot of CPU power, but the "em" driver supports delaying interrupts until more packets have arrived - see the sysctls available on the em man page. So you're probably better of turning off polling and playing with these tunables, by calculating how many packets you're likely to be able to fit in the tx/rx descriptor array before you need to generate an interrupt. Secondly try pressing shift+c inside top to display "raw cpu usage" instead of the default "weighted cpu usage". Finally, is your test portraying realistic conditions? I am reminded that 1GB/s with 1500 MTU is only roughly 80,000 pps. - Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Route messages
On Sun, 15 Jun 2008 11:16:17 +0100, in sentex.lists.freebsd.net you wrote: >Paul wrote: >> Get these with GRE tunnel on >> FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT >> 2008 :/usr/obj/usr/src/sys/ROUTER amd64 >> But do not get them with 7.0-RELEASE >> >> Any ideas what changed? :) Wish there was some sort of changelog.. >> # of messages per second seems consistent with packets per second on >> GRE interface.. >> No impact in routing, but definitely impact in cpu usage for all >> processes monitoring the route messages. > >RTM_MISS is actually fairly common when you don't have a default route. > Hi, I am seeing this issue as well on a pair of recently deployed boxes, one running MPD and one acting as an area router in front of it. The MPD box has a default route and only has 400 routes or so. A steady stream of those messages, upwards of 500 per second. got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default Is there a way to try and track down what is generating those messages ? Its eating up a fair bit of cpu with quagga (the zebra process specifically) ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0: sockets stuck in CLOSED state...
On Thu, 26 Jun 2008, Eygene Ryabinkin wrote: I had already tried to debug this situation and Mike Silbersack helped me with patching the kernel. At that days his patches (that went into 7.x) helped, but with higher request rate to the Apache, they seem to be back again. I can try to setup the testbed and verify if I will still be able to reproduce them. Will it be needed? IIRC, the problem we found then had some interesting root causes, but the important point was the FreeBSD 7-prerelease was returning a different errno than FreeBSD 6 (and before) had been returning, which caused Apache to leak the FD. I wouldn't be at all surprised if there was a switched errno in some other error path that's causing similar problems. -Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Understanding where dummynet fits into an ipfw ruleset
On Fri, 27 Jun 2008, Chuck Swiger wrote: > On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote: > [ ... ] > >> If net.inet.ip.fw.one_pass is true, then you definitely want to > >> apply your > >> deny rules first, as once something matches a pipe rule, it's going > >> to be > >> passed. The tradeoff is that the accounting/fairness of traffic is > >> less > >> accurate but the firewall ruleset runs faster... > > > > So, in this situation, the "allow" rules would be the queue rules? > > > > To add traffic shaping to the following, using one_pass=1: > > 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > Would be: > > 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > Or am I way off here? :) > > Hmm. If you have one_pass set, I believe that rule 200 would become > superfluous. If it was off, rule 200 would be needed to permit > traffic through. I'm keen to be certain about this myself. I think that one_pass only affects the packet on the current pass, in this case on the incoming pass from ip_input at rule 100 above. So if one_pass is set, the packet is queued (and accepted in) and the search terminates, but with one_pass off, the packet is reinjected at rule 200 when it leaves the pipe after its limitation and/or delay, and would need to be specifically allowed. However I don't think that affects the outgoing pass, ie after routing the packet still has to go through the firewall again (from ip_output), so in this case it will be allowed if it's going out to 2.2.2.2 via em1, else is denied at rule 300. Another option might be to only apply pipe/queue actions to 'out' rules, but mixing that with both 1:many and 1:1 NAT will complicate matters .. > However, queue rulesets are used to classify traffic > into different bins; then then get pulled out of the bins with packets > waiting is proportion to the weights configured via something like: > >ipfw queue 1 config pipe 1 weight 10 > > ie, you have to attach queue(s) to a pipe for this classification or > sorting to be meaningful. Yes I suspect Freddie might want to use pipe rather than queue here too, if just for bandwidth limitation rather than weighted queueing by type of traffic? And is it only wanted for managing the inbound traffic? It's quite confusing at first that pipe and queue are both ipfw 'actions', and are also terms used as pipe and queue configuration parameters, as in a queue definition specifies a particular 'pipe pipe_nr' and that 'queue' is used to specify a pipe's queue size .. Caveat: I'm only using pipes so far, and on a bridge, not a router, where you only get one shot at allow/deny/pipe on packets incoming through bdg_forward, ie no 'out' rules, for bridged packets anyway. cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
