freebsd-net Digest, Vol 363, Issue 3
freebsd-n...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-net
or, via email, send a message with subject or body 'help' to
freebsd-n...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-net digest..."
Today's Topics:
1. Choosing CPU for router (Jon Otterholm)
2. Re: Choosing CPU for router (Matthias Gamsjager)
3. Re: Choosing CPU for router (Andrei Kolu)
4. Re: Choosing CPU for router (Andrei Kolu)
5. Re: Choosing CPU for router (Ivan Voras)
6. RE: Bridge causes freezes (kevin)
7. Re: Choosing CPU for router (??????? ????????)
8. Re: kern/144689: [re] TCP transfer corruption using if_re
(Pyun YongHyeon)
9. PF + BRIDGE + PFSYNC causes system freezing (kevin)
10. Re: kern/144689: [re] TCP transfer corruption using if_re
(Steven Noonan)
11. Re: kern/144689: [re] TCP transfer corruption using if_re
(Pyun YongHyeon)
12. Re: kern/144689: [re] TCP transfer corruption using if_re
(Steven Noonan)
13. Re: kern/144689: [re] TCP transfer corruption using if_re
(Pyun YongHyeon)
14. Re: Choosing CPU for router (Andrew Snow)
15. Re: Choosing CPU for router (Han Hwei Woo)
16. FreeBSD driver for broadcom 57710/57711/57711E 10GE
(Vladimir Korkodinov)
17. Re: PF + BRIDGE + PFSYNC causes system freezing (Daniel Hartmeier)
18. Fwd: Choosing CPU for router (Gilles WAGNER)
19. Re: Choosing CPU for router (Jon Otterholm)
20. Re: Choosing CPU for router (Gilles WAGNER)
21. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)
22. sscanf in kernel (serena zanetta)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Mar 2010 13:40:51 +0100
From: Jon Otterholm <jon.ot...@ide.resurscentrum.se>
Subject: Choosing CPU for router
To: <freeb...@freebsd.org>
Message-ID: <C7C53AE3.2441C%jon.ot...@ide.resurscentrum.se>
Content-Type: text/plain; charset="US-ASCII"
Hi.
In the process to build a new router and want to choose the best possible
CPU for the job.
Narrowed it down to the following:
Intel Q9650 3,0Ghz
Intel i7-965/975 3,2Ghz/3,33Ghz
What would be the benefit from a Xeon?
Motherboard: Supermicro X8SBI-4LN.
RAM: 4GB
The router will be running IPFW and Dummynet for traffic-shaping. Along with
that, standard services like dhcpd.
Any thoughts appreciated.
BG
//Jon
------------------------------
Message: 2
Date: Tue, 16 Mar 2010 13:52:46 +0100
From: Matthias Gamsjager <mgams...@gmail.com>
Subject: Re: Choosing CPU for router
To: freeb...@freebsd.org
Message-ID:
<585602e11003160552v483...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Way over the top for simple fw and dhcpd. but how much traffic will
be involved?
Investing in a good nics will return more then a pricey cpu and
motherboard (eec mem is good idea for 24/7 tho).
On Tue, Mar 16, 2010 at 1:40 PM, Jon Otterholm
<jon.ot...@ide.resurscentrum.se> wrote:
> Hi.
>
> In the process to build a new router and want to choose the best possible
> CPU for the job.
>
> Narrowed it down to the following:
>
> Intel Q9650 3,0Ghz
> Intel i7-965/975 3,2Ghz/3,33Ghz
>
> What would be the benefit from a Xeon?
>
> Motherboard: Supermicro X8SBI-4LN.
> RAM: 4GB
>
> The router will be running IPFW and Dummynet for traffic-shaping. Along with
> that, standard services like dhcpd.
>
> Any thoughts appreciated.
>
> BG
> //Jon
>
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>
------------------------------
Message: 3
Date: Tue, 16 Mar 2010 15:19:47 +0200
From: Andrei Kolu <an...@bsd.ee>
Subject: Re: Choosing CPU for router
To: freeb...@freebsd.org
Message-ID:
<10263ac1003160619j424...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/3/16 Andrei Kolu <an...@bsd.ee>:
> 2010/3/16 Jon Otterholm <jon.ot...@ide.resurscentrum.se>:
>> Hi.
>>
>> In the process to build a new router and want to choose the best possible
>> CPU for the job.
>>
>> Narrowed it down to the following:
>>
>> Intel Q9650 3,0Ghz
>> Intel i7-965/975 3,2Ghz/3,33Ghz
>>
>> What would be the benefit from a Xeon?
>>
>> Motherboard: Supermicro X8SBI-4LN.
>> RAM: 4GB
>>
>> The router will be running IPFW and Dummynet for traffic-shaping. Along with
>> that, standard services like dhcpd.
>>
>> Any thoughts appreciated.
>>
>>
>
> Xeons usually got more cache memory on board and mean to work on
> servers (read: stable). And of course there should be ECC memory.
> AFAIK you can't install more than one CORE cpu onto multicpu
> motherboard but you can do so with XEON.
>
> Did you mean this:
> http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8STi-LN4.cfm
> board?
>
Differences between Xeon and Core:
http://en.wikipedia.org/wiki/Xeon
------------------------------
Message: 4
Date: Tue, 16 Mar 2010 15:15:01 +0200
From: Andrei Kolu <an...@bsd.ee>
Subject: Re: Choosing CPU for router
To: freeb...@freebsd.org
Message-ID:
<10263ac1003160615u272...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/3/16 Jon Otterholm <jon.ot...@ide.resurscentrum.se>:
> Hi.
>
> In the process to build a new router and want to choose the best possible
> CPU for the job.
>
> Narrowed it down to the following:
>
> Intel Q9650 3,0Ghz
> Intel i7-965/975 3,2Ghz/3,33Ghz
>
> What would be the benefit from a Xeon?
>
> Motherboard: Supermicro X8SBI-4LN.
> RAM: 4GB
>
> The router will be running IPFW and Dummynet for traffic-shaping. Along with
> that, standard services like dhcpd.
>
> Any thoughts appreciated.
>
>
Xeons usually got more cache memory on board and mean to work on
servers (read: stable). And of course there should be ECC memory.
AFAIK you can't install more than one CORE cpu onto multicpu
motherboard but you can do so with XEON.
Did you mean this:
http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8STi-LN4.cfm
board?
------------------------------
Message: 5
Date: Tue, 16 Mar 2010 16:11:52 +0100
From: Ivan Voras <ivo...@freebsd.org>
Subject: Re: Choosing CPU for router
To: freeb...@freebsd.org
Message-ID: <hno73d$478$1...@dough.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 03/16/10 13:40, Jon Otterholm wrote:
> Hi.
>
> In the process to build a new router and want to choose the best possible
> CPU for the job.
>
> Narrowed it down to the following:
>
> Intel Q9650 3,0Ghz
> Intel i7-965/975 3,2Ghz/3,33Ghz
Both are overkill, but in general here you should go for clock speed
instead of multicore abilities. If you can get it, you will be better
off with a 3.5 GHz dual-core CPU (like Xeon 52xx) than a 3 GHz quad-core
CPU. Additional cores will not be used by network processing in your case.
Better invest the money in a good network card.
> What would be the benefit from a Xeon?
Stability, but that also comes from using better motherboards, ECC
memory, etc, not only from the CPU.
------------------------------
Message: 6
Date: Tue, 16 Mar 2010 11:33:08 -0400
From: "kevin" <k...@kevinkevin.com>
Subject: RE: Bridge causes freezes
To: "'Giulio Ferro'" <au...@zirakzigil.org>,
<freeb...@freebsd.org>, <freebsd...@freebsd.org>
Message-ID: <00aa01cac51d$fc66f610$f534e230$@com>
Content-Type: text/plain; charset="us-ascii"
>I confirm this problem for another server:
>stable 8 amd64 + vlan + carp
>
>Whenever I join a bridge with a vlan interface:
>
>ifconfig bridge0 addm vlan35
>
>The system soon or later freezes.
>
>This time it has happened after 3 days of normal behavior.
>
>No logs, no dump.
This happens to me as well.
FreeBSD 7.2-RELEASE + bridge + pfsync, no carp.
It freezes (sometimes not right away), no console messages, no logs.
------------------------------
Message: 7
Date: Tue, 16 Mar 2010 21:11:39 +0500
From: ??????? ???????? <gigaby...@gmail.com>
Subject: Re: Choosing CPU for router
To: freeb...@freebsd.org
Message-ID: <773208865.20...@gmail.com>
Content-Type: text/plain; charset="windows-1251"
>2010/3/16 Jon Otterholm <jon.ot...@ide.resurscentrum.se>:
>>
>> Narrowed it down to the following:
>>
>> Intel Q9650 3,0Ghz
>> Intel i7-965/975 3,2Ghz/3,33Ghz
>>
>> What would be the benefit from a Xeon?
>>
>> The router will be running IPFW and Dummynet for traffic-shaping. Along with
>> that, standard services like dhcpd.
> Xeons usually got more cache memory on board and mean to work on
>servers (read: stable). And of course there should be ECC memory.
Xeon may work in multi-CPU servers.
Speaking of routers, you have multicore (2CPU x 4cores = 8cores)
machine with 1-2-3 NIC's, and can't load other cores in CPU
(earlier versions before FBSD 8.x).
You need NIC with MSI (Interrupt Moderation) for better performance.
1. What kind of traffic did you expect?
2. What flow bit per seconds did you expect?
I have PPPoE concentrator based on S3000AHV motherboard with EXPI9400
and EXPI9402 NIC's and Core2Quad Q6600 CPU and FreeBSD 7.2.
This router may handle about 150k pps and 1Gbps for one direction of
internet traffic.
Do you need core i5/7 ?
-------------- next part --------------
An embedded message was scrubbed...
From: Andrei Kolu <an...@bsd.ee>
Subject: Re: Choosing CPU for router
Date: Tue, 16 Mar 2010 15:15:01 +0200
Size: 4956
Url: http://lists.freebsd.org/pipermail/freebsd-net/attachments/20100316/7bb89ab9/1-0001.eml
------------------------------
Message: 8
Date: Tue, 16 Mar 2010 11:23:22 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
To: Steven Noonan <ste...@uplinklabs.net>
Cc: freeb...@freebsd.org, bug-fo...@FreeBSD.org,
yon...@freebsd.org
Message-ID: <2010031618...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Sat, Mar 13, 2010 at 04:18:30AM -0800, Steven Noonan wrote:
> On Fri, Mar 12, 2010 at 9:57 PM, Steven Noonan <ste...@uplinklabs.net> wrote:
> > On Fri, Mar 12, 2010 at 4:24 PM, Steven Noonan <ste...@uplinklabs.net> wrote:
> >> On Fri, Mar 12, 2010 at 4:19 PM, Steven Noonan <ste...@uplinklabs.net> wrote:
> >>> On Fri, Mar 12, 2010 at 9:54 AM, ??<yon...@freebsd.org> wrote:
> >>>> Synopsis: [re] TCP transfer corruption using if_re
> >>>>
> >>>> State-Changed-From-To: open->feedback
> >>>> State-Changed-By: yongari
> >>>> State-Changed-When: Fri Mar 12 17:53:37 UTC 2010
> >>>> State-Changed-Why:
> >>>> This looks like Rx checksum offloading issue. Would you try
> >>>> disabling Rx checksum offloading and test it again?
> >>>> #ifconfig re0 -rxcsum
> >>>> Also show me dmesg output(re(4) related part).
> >>>>
> >>>>
> >>>> Responsible-Changed-From-To: freebsd-net->yongari
> >>>> Responsible-Changed-By: yongari
> >>>> Responsible-Changed-When: Fri Mar 12 17:53:37 UTC 2010
> >>>> Responsible-Changed-Why:
> >>>> Mine.
> >>>>
> >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=144689
> >>>>
> >>>
> >>> Hmm. Disabling Rx checksum offloading helped for one clone process,
> >>> but then this showed up in dmesg during my second test (it seems to be
> >>> doing this regularly for some reason):
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>>
> >>> And no, the cable isn't loose or something. It just decides to take
> >>> the interface down and put it back up.
> >>>
> >>> Here's the rest of 'dmesg | grep re0':
> >>>
> >>> firewire0: <IEEE1394(FireWire) bus> on fwohci0
> >>> dcons_crom0: <dcons configuration ROM> on firewire0
> >>> fwe0: <Ethernet over FireWire> on firewire0
> >>> fwip0: <IP over FireWire> on firewire0
> >>> firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) ??(me)
> >>> firewire0: bus manager 0
> >>> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
> >>> port 0x1200-0x12ff mem 0x88000000-0x880001ff irq 18 at device 0.0 on
> >>> cardbus0
> >>> re0: Chip rev. 0x10000000
> >>> re0: MAC rev. 0x00000000
> >>> miibus1: <MII bus> on re0
> >>> re0: Ethernet address: 00:18:4d:6e:c0:29
> >>> re0: [FILTER]
> >>> re0: link state changed to UP
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: detached
> >>> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
> >>> port 0x1200-0x12ff mem 0x88000000-0x880001ff irq 18 at device 0.0 on
> >>> cardbus0
> >>> re0: Chip rev. 0x10000000
> >>> re0: MAC rev. 0x00000000
> >>> miibus1: <MII bus> on re0
> >>> re0: Ethernet address: 00:18:4d:6e:c0:29
> >>> re0: [FILTER]
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: PHY read failed
> >>> re0: link state changed to DOWN
> >>> re0: link state changed to UP
> >>> re0: PHY read failed
> >>>
> >>> - Steven
> >>>
> >>
> >> I should note that the connection was _lost_ during the second test above.
> >>
> >> I also tested again, and it looks like it added another "re0: PHY read
> >> failed" before silently dropping the connection.
> >>
> >> - Steven
> >>
> >
> > I did a couple captures with Wireshark on the client end. One is with
> > rxcsum enabled on the machine running git-daemon, one is without
> > rxcsum.
> >
> > http://www.uplinklabs.net/~tycho/files/git-cap-norxcsum.bz2
> > http://www.uplinklabs.net/~tycho/files/git-cap.bz2
> >
> > Obviously, you can look at the data yourself and make more sense of
> > it, but here are things I noticed in the captures:
> >
> > With rxcsum:
> > - There are some silent problems that occur in the middle of the
> > capture. Client-to-server: 'TCP ACKed lost segment' a few times, then
> > 'TCP previous segment lost'. This happens multiple times during the
> > capture (before 'git-upload-pack' starts sending data).
> > - Occasional 'TCP window update's. These are highlighted in black for
> > reasons unknown to me. It seems like this would be normal.
> > - The server calls 'git-upload-pack' and we start seeing a large
> > number of client-to-server TCP RST flags being sent and then the
> > connection gets closed due to some detected data corruption in the
> > transfer.
> >
> > Without rxcsum:
> > - About the same amount of client-to-server 'TCP ACKed lost segment's.
> > - 'git-upload-pack' kicks in and things get _really_ hairy. 'TCP Dup
> > ACK' detected by the client many many times.
> > - Finally, a series of 'TCP retransmission's from server to client
> > happen (which is where the connection hangs).
> > - I closed the connection which triggered the final two 'TCP RST's.
> >
> > Also, I forgot to note in my original report that I checked if there
> > was packet loss by using a ping flood, and one packet in the 1.5
> > million packets sent was lost. But I'm not sure whether it's
> > checksumming the data of these packets, so they could be coming back
> > with perfectly valid ICMP headers but corrupted data.
> >
>
> Also, hilariously horrible hack:
>
> - On the server machine, start git-daemon listening on 127.0.0.1:9418.
> - On the server machine, run 'ssh -L <public IP>:9418:127.0.0.1:9418
> user@localhost'.
>
> Then remote git clones work as expected. Very strange. It will have to
> do until I get a less insane solution.
>
The real issue looks like PHY read failure which can result in
unexpected behavior. I don't see rgephy(4) related message here,
would you show me the output of "devinfo -rv | grep phy"?
By chance are you using PCMCIA ethernet controller?
> I don't understand why it makes a difference. Is git-daemon using TCP
> socket options that causes this network interface driver to
> malfunction?
>
No, I don't think so. It would be a bug in driver.
> - Steven
------------------------------
Message: 9
Date: Tue, 16 Mar 2010 15:19:51 -0400
From: "kevin" <k...@kevinkevin.com>
Subject: PF + BRIDGE + PFSYNC causes system freezing
To: <freeb...@freebsd.org>, <freeb...@freebsd.org>
Message-ID: <00bc01cac53d$a92f0b70$fb8d2250$@com>
Content-Type: text/plain; charset="us-ascii"
I have been experiencing this problem with 2x freebsd firewall
implementations running pf + transparent bridging + pfsync between both
boxes.
Today in an effort to narrow down and troubleshoot the issue further, I have
decided to build two FreeBSD 7.2-RELEASE implementations using virtualbox.
Each box was allocated 256mb ram, 3 NIC's (internal network only) and a 4GB
hard drive. I compiled PF/ALTQ/MROUTING into the kernel and installed it. No
other fundamental modifications were made.
The intent is to reproduce the problem in a controlled environment. And
provide any information to @freebsd.org if requested.
Here is the pertinent information below. Note both boxes are identical :
[UNAME]
# uname -a
FreeBSD fw 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue Mar 16 13:18:05 UTC 2010
root@:/usr/obj/usr/src/sys/FW i386
[IFCONFIG]
# ifconfig
em0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 08:00:27:91:2d:fd
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
em1: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 08:00:27:c7:3f:6b
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 08:00:27:de:66:c6
inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
pfsync0: flags=41<UP,RUNNING> metric 0 mtu 1460
pfsync: syncdev: em2 syncpeer: 10.0.0.11 maxupd: 128
bridge0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 1e:29:e0:82:6e:d6
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 20000
member: em0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 1 priority 128 path cost 20000
[KERNEL OPTIONS]
# Multicast routing support
options MROUTING
# PF Firewall
device pf
device pflog
device pfsync
options ALTQ
options ALTQ_CBQ # Class Bases Queuing (CBQ)
options ALTQ_RED # Random Early Detection (RED)
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC)
options ALTQ_PRIQ # Priority Queuing (PRIQ)
options ALTQ_NOPCC # Required for SMP build
[RC.CONF]
keymap="us.iso"
hostname="fw"
gateway_enable="YES"
sshd_enable="YES"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm em0 addm em1 up"
ifconfig_em0="up"
ifconfig_em1="up"
ifconfig_em2="inet 10.0.0.10 netmask 255.255.255.0"
pf_enable="YES"
pf_rules="/etc/pf.conf"
pf_flags=""
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
pflog_flags=""
pfsync_enable="YES"
pfsync_syncdev="em2"
ifconfig_pfsync0="up syncpeer 10.0.0.11 syncif em2"
[PF.CONF]
# macros
ext_if="em0"
int_if="em1"
mng_if="em2"
tcp_services="{ 22, 113, 53, 80 }"
icmp_types="echoreq"
# options
set block-policy return
set loginterface $ext_if
set skip on lo
# scrub
scrub in all random-id fragment reassemble
scrub out on $ext_if random-id
# filter rules
pass in quick
pass out quick
pass quick on $mng_if proto pfsync
Note the only difference in config is the ip address of the pfsycn
interface. When both boxes are on , one or both of them start to really slow
down and ultimately freeze. No messages are pasted on the console and
/var/log/messages is inaccessible during this point.
I would like to assist in diagnosing this issue so if anyone wants me to
check anything or test, please let me know. I would really like to
understand this problem.
Thanks,
Kevin K.
------------------------------
Message: 10
Date: Tue, 16 Mar 2010 12:31:22 -0700
From: Steven Noonan <ste...@uplinklabs.net>
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
To: pyu...@gmail.com
Cc: freeb...@freebsd.org, bug-fo...@freebsd.org,
yon...@freebsd.org
Message-ID:
<f488382f1003161231s2fb...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> On Sat, Mar 13, 2010 at 04:18:30AM -0800, Steven Noonan wrote:
>> On Fri, Mar 12, 2010 at 9:57 PM, Steven Noonan <ste...@uplinklabs.net> wrote:
>> > On Fri, Mar 12, 2010 at 4:24 PM, Steven Noonan <ste...@uplinklabs.net> wrote:
>> >> On Fri, Mar 12, 2010 at 4:19 PM, Steven Noonan <ste...@uplinklabs.net> wrote:
>> >>> On Fri, Mar 12, 2010 at 9:54 AM, ??<yon...@freebsd.org> wrote:
>> >>>> Synopsis: [re] TCP transfer corruption using if_re
>> >>>>
>> >>>> State-Changed-From-To: open->feedback
>> >>>> State-Changed-By: yongari
>> >>>> State-Changed-When: Fri Mar 12 17:53:37 UTC 2010
>> >>>> State-Changed-Why:
>> >>>> This looks like Rx checksum offloading issue. Would you try
>> >>>> disabling Rx checksum offloading and test it again?
>> >>>> #ifconfig re0 -rxcsum
>> >>>> Also show me dmesg output(re(4) related part).
>> >>>>
>> >>>>
>> >>>> Responsible-Changed-From-To: freebsd-net->yongari
>> >>>> Responsible-Changed-By: yongari
>> >>>> Responsible-Changed-When: Fri Mar 12 17:53:37 UTC 2010
>> >>>> Responsible-Changed-Why:
>> >>>> Mine.
>> >>>>
>> >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=144689
>> >>>>
>> >>>
>> >>> Hmm. Disabling Rx checksum offloading helped for one clone process,
>> >>> but then this showed up in dmesg during my second test (it seems to be
>> >>> doing this regularly for some reason):
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>>
>> >>> And no, the cable isn't loose or something. It just decides to take
>> >>> the interface down and put it back up.
>> >>>
>> >>> Here's the rest of 'dmesg | grep re0':
>> >>>
>> >>> firewire0: <IEEE1394(FireWire) bus> on fwohci0
>> >>> dcons_crom0: <dcons configuration ROM> on firewire0
>> >>> fwe0: <Ethernet over FireWire> on firewire0
>> >>> fwip0: <IP over FireWire> on firewire0
>> >>> firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) ??(me)
>> >>> firewire0: bus manager 0
>> >>> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
>> >>> port 0x1200-0x12ff mem 0x88000000-0x880001ff irq 18 at device 0.0 on
>> >>> cardbus0
>> >>> re0: Chip rev. 0x10000000
>> >>> re0: MAC rev. 0x00000000
>> >>> miibus1: <MII bus> on re0
>> >>> re0: Ethernet address: 00:18:4d:6e:c0:29
>> >>> re0: [FILTER]
>> >>> re0: link state changed to UP
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: detached
>> >>> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
>> >>> port 0x1200-0x12ff mem 0x88000000-0x880001ff irq 18 at device 0.0 on
>> >>> cardbus0
>> >>> re0: Chip rev. 0x10000000
>> >>> re0: MAC rev. 0x00000000
>> >>> miibus1: <MII bus> on re0
>> >>> re0: Ethernet address: 00:18:4d:6e:c0:29
>> >>> re0: [FILTER]
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: PHY read failed
>> >>> re0: link state changed to DOWN
>> >>> re0: link state changed to UP
>> >>> re0: PHY read failed
>> >>>
>> >>> - Steven
>> >>>
>> >>
>> >> I should note that the connection was _lost_ during the second test above.
>> >>
>> >> I also tested again, and it looks like it added another "re0: PHY read
>> >> failed" before silently dropping the connection.
>> >>
>> >> - Steven
>> >>
>> >
>> > I did a couple captures with Wireshark on the client end. One is with
>> > rxcsum enabled on the machine running git-daemon, one is without
>> > rxcsum.
>> >
>> > http://www.uplinklabs.net/~tycho/files/git-cap-norxcsum.bz2
>> > http://www.uplinklabs.net/~tycho/files/git-cap.bz2
>> >
>> > Obviously, you can look at the data yourself and make more sense of
>> > it, but here are things I noticed in the captures:
>> >
>> > With rxcsum:
>> > - There are some silent problems that occur in the middle of the
>> > capture. Client-to-server: 'TCP ACKed lost segment' a few times, then
>> > 'TCP previous segment lost'. This happens multiple times during the
>> > capture (before 'git-upload-pack' starts sending data).
>> > - Occasional 'TCP window update's. These are highlighted in black for
>> > reasons unknown to me. It seems like this would be normal.
>> > - The server calls 'git-upload-pack' and we start seeing a large
>> > number of client-to-server TCP RST flags being sent and then the
>> > connection gets closed due to some detected data corruption in the
>> > transfer.
>> >
>> > Without rxcsum:
>> > - About the same amount of client-to-server 'TCP ACKed lost segment's.
>> > - 'git-upload-pack' kicks in and things get _really_ hairy. 'TCP Dup
>> > ACK' detected by the client many many times.
>> > - Finally, a series of 'TCP retransmission's from server to client
>> > happen (which is where the connection hangs).
>> > - I closed the connection which triggered the final two 'TCP RST's.
>> >
>> > Also, I forgot to note in my original report that I checked if there
>> > was packet loss by using a ping flood, and one packet in the 1.5
>> > million packets sent was lost. But I'm not sure whether it's
>> > checksumming the data of these packets, so they could be coming back
>> > with perfectly valid ICMP headers but corrupted data.
>> >
>>
>> Also, hilariously horrible hack:
>>
>> - On the server machine, start git-daemon listening on 127.0.0.1:9418.
>> - On the server machine, run 'ssh -L <public IP>:9418:127.0.0.1:9418
>> user@localhost'.
>>
>> Then remote git clones work as expected. Very strange. It will have to
>> do until I get a less insane solution.
>>
>
> The real issue looks like PHY read failure which can result in
> unexpected behavior. I don't see rgephy(4) related message here,
> would you show me the output of "devinfo -rv | grep phy"?
> By chance are you using PCMCIA ethernet controller?
I am. It's a Netgear GA511. I think I said in my original post that it
was connected via cardbus.
xerxes ~ # devinfo -rv | grep phy
rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x3 at phyno=1
inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1
>
>> I don't understand why it makes a difference. Is git-daemon using TCP
>> socket options that causes this network interface driver to
>> malfunction?
>>
>
> No, I don't think so. It would be a bug in driver.
>
>> - Steven
>
------------------------------
Message: 11
Date: Tue, 16 Mar 2010 13:46:01 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
To: Steven Noonan <ste...@uplinklabs.net>
Cc: freeb...@freebsd.org, bug-fo...@freebsd.org,
yon...@freebsd.org
Message-ID: <2010031620...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Tue, Mar 16, 2010 at 12:31:22PM -0700, Steven Noonan wrote:
> On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
[...]
> > The real issue looks like PHY read failure which can result in
> > unexpected behavior. I don't see rgephy(4) related message here,
> > would you show me the output of "devinfo -rv | grep phy"?
> > By chance are you using PCMCIA ethernet controller?
>
> I am. It's a Netgear GA511. I think I said in my original post that it
> was connected via cardbus.
>
> xerxes ~ # devinfo -rv | grep phy
> rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x3 at phyno=1
> inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1
>
Ok, thanks for the info. Did the controller ever work before?
Or you start seeing the issue on 8.0-RELEASE?
------------------------------
Message: 12
Date: Tue, 16 Mar 2010 13:51:05 -0700
From: Steven Noonan <ste...@uplinklabs.net>
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
To: pyu...@gmail.com
Cc: freeb...@freebsd.org, bug-fo...@freebsd.org,
yon...@freebsd.org
Message-ID:
<f488382f1003161351u4d...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Mar 16, 2010 at 1:46 PM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 12:31:22PM -0700, Steven Noonan wrote:
>> On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
>
> [...]
>
>> > The real issue looks like PHY read failure which can result in
>> > unexpected behavior. I don't see rgephy(4) related message here,
>> > would you show me the output of "devinfo -rv | grep phy"?
>> > By chance are you using PCMCIA ethernet controller?
>>
>> I am. It's a Netgear GA511. I think I said in my original post that it
>> was connected via cardbus.
>>
>> xerxes ~ # devinfo -rv | grep phy
>> Â Â Â Â Â Â Â Â Â Â rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x3 at phyno=1
>> Â Â Â Â Â Â Â Â inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1
>>
>
> Ok, thanks for the info. Did the controller ever work before?
> Or you start seeing the issue on 8.0-RELEASE?
>
The last time I had FreeBSD on this machine was with 7.0-RELEASE (or
7.1?), and I didn't have the GA511 at that time, so I don't know
whether it worked before or not.
(Incidentally, on my other machine, I get "PHY read failure" all the
time with its Marvell Yukon controller [if_msk])
- Steven
------------------------------
Message: 13
Date: Tue, 16 Mar 2010 14:07:52 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
To: Steven Noonan <ste...@uplinklabs.net>
Cc: freeb...@freebsd.org, i...@FreeBSD.org,
bug-fo...@freebsd.org, yon...@freebsd.org
Message-ID: <2010031621...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Tue, Mar 16, 2010 at 01:51:05PM -0700, Steven Noonan wrote:
> On Tue, Mar 16, 2010 at 1:46 PM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> > On Tue, Mar 16, 2010 at 12:31:22PM -0700, Steven Noonan wrote:
> >> On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> >
> > [...]
> >
> >> > The real issue looks like PHY read failure which can result in
> >> > unexpected behavior. I don't see rgephy(4) related message here,
> >> > would you show me the output of "devinfo -rv | grep phy"?
> >> > By chance are you using PCMCIA ethernet controller?
> >>
> >> I am. It's a Netgear GA511. I think I said in my original post that it
> >> was connected via cardbus.
> >>
> >> xerxes ~ # devinfo -rv | grep phy
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x3 at phyno=1
> >> ?? ?? ?? ?? ?? ?? ?? ?? inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1
> >>
> >
> > Ok, thanks for the info. Did the controller ever work before?
> > Or you start seeing the issue on 8.0-RELEASE?
> >
>
> The last time I had FreeBSD on this machine was with 7.0-RELEASE (or
> 7.1?), and I didn't have the GA511 at that time, so I don't know
> whether it worked before or not.
>
This is first report for PHY read error on RTL8169S. I have no idea
what's happening here at this moment. I'm not familiar with
cardbus(4) so it also makes me hard to identify the root cause of
the issue. Maybe imp can give some instructions to debug.
> (Incidentally, on my other machine, I get "PHY read failure" all the
> time with its Marvell Yukon controller [if_msk])
>
For msk(4) issue, please open new PR and let me know the PR number.
------------------------------
Message: 14
Date: Wed, 17 Mar 2010 12:14:55 +1100
From: Andrew Snow <and...@modulus.org>
Subject: Re: Choosing CPU for router
To: Matthias Gamsjager <mgams...@gmail.com>, freeb...@freebsd.org
Message-ID: <4BA02D0F...@modulus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Matthias Gamsjager wrote:
> Way over the top for simple fw and dhcpd. but how much traffic will
> be involved?
> Investing in a good nics will return more then a pricey cpu and
> motherboard (eec mem is good idea for 24/7 tho).
Agreed.
The Supermicro Atom miniserver is more than enough CPU grunt for this
sort of routing/ipfw task. The main reason to go Xeon is if you need
ECC RAM, and even then you can get away with just using the cheapest CPU
available.
- Andrew
------------------------------
Message: 15
Date: Tue, 16 Mar 2010 20:51:48 -0700
From: Han Hwei Woo <h...@pce-net.com>
Subject: Re: Choosing CPU for router
To: freeb...@freebsd.org
Message-ID: <4BA051D4...@pce-net.com>
Content-Type: text/plain; charset=windows-1251; format=flowed
Get Intel NIC's, and the fastest clockspeed CPU you can find. I'd recommend:
Intel Core i5 670 (3.46GHz)
Supermicro X8SIL-F Motherboard (includes KVM over IP)
Äìèòðèé Çàìóðàåâ wrote:
>> 2010/3/16 Jon Otterholm <jon.ot...@ide.resurscentrum.se>:
>>
>>> Narrowed it down to the following:
>>>
>>> Intel Q9650 3,0Ghz
>>> Intel i7-965/975 3,2Ghz/3,33Ghz
>>>
>>> What would be the benefit from a Xeon?
>>>
>>> The router will be running IPFW and Dummynet for traffic-shaping. Along with
>>> that, standard services like dhcpd.
>>>
>
>
>> Xeons usually got more cache memory on board and mean to work on
>> servers (read: stable). And of course there should be ECC memory.
>>
> Xeon may work in multi-CPU servers.
> Speaking of routers, you have multicore (2CPU x 4cores = 8cores)
> machine with 1-2-3 NIC's, and can't load other cores in CPU
> (earlier versions before FBSD 8.x).
>
> You need NIC with MSI (Interrupt Moderation) for better performance.
>
> 1. What kind of traffic did you expect?
> 2. What flow bit per seconds did you expect?
>
> I have PPPoE concentrator based on S3000AHV motherboard with EXPI9400
> and EXPI9402 NIC's and Core2Quad Q6600 CPU and FreeBSD 7.2.
> This router may handle about 150k pps and 1Gbps for one direction of
> internet traffic.
> Do you need core i5/7 ?
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: Choosing CPU for router
> From:
> Andrei Kolu <an...@bsd.ee>
> Date:
> Tue, 16 Mar 2010 15:15:01 +0200
> To:
> freeb...@freebsd.org
>
> To:
> freeb...@freebsd.org
>
>
> 2010/3/16 Jon Otterholm <jon.ot...@ide.resurscentrum.se>:
>
>> Hi.
>>
>> In the process to build a new router and want to choose the best possible
>> CPU for the job.
>>
>> Narrowed it down to the following:
>>
>> Intel Q9650 3,0Ghz
>> Intel i7-965/975 3,2Ghz/3,33Ghz
>>
>> What would be the benefit from a Xeon?
>>
>> Motherboard: Supermicro X8SBI-4LN.
>> RAM: 4GB
>>
>> The router will be running IPFW and Dummynet for traffic-shaping. Along with
>> that, standard services like dhcpd.
>>
>> Any thoughts appreciated.
>>
>>
>>
>
> Xeons usually got more cache memory on board and mean to work on
> servers (read: stable). And of course there should be ECC memory.
> AFAIK you can't install more than one CORE cpu onto multicpu
> motherboard but you can do so with XEON.
>
> Did you mean this:
> http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8STi-LN4.cfm
> board?
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
------------------------------
Message: 16
Date: Wed, 17 Mar 2010 11:51:54 +0500
From: Vladimir Korkodinov <vi...@perm.raid.ru>
Subject: FreeBSD driver for broadcom 57710/57711/57711E 10GE
To: freeb...@freebsd.org
Message-ID:
<3b7c94e71003162351m36b...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello!
We bought HP Blade system BL460C G6 that built on Broadcom
57710/57711/57711E 10GbE LAN. David Christensen from Broadcom said he
wrote a driver for this chipset but hasn't released this one public.
http://lists.freebsd.org/pipermail/freebsd-net/2009-July/022561.html
I asked him if he could send me the driver but he didn't respond.
Does anybody have the driver already? Could you send it to us?
------------------------------
Message: 17
Date: Wed, 17 Mar 2010 09:12:56 +0100
From: Daniel Hartmeier <dan...@benzedrine.cx>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: kevin <k...@kevinkevin.com>
Cc: freeb...@freebsd.org, freeb...@freebsd.org
Message-ID: <20100317081...@insomnia.benzedrine.cx>
Content-Type: text/plain; charset=us-ascii
On Tue, Mar 16, 2010 at 03:19:51PM -0400, kevin wrote:
> I would like to assist in diagnosing this issue so if anyone wants me to
> check anything or test, please let me know. I would really like to
> understand this problem.
What are your settings for
$ sysctl -a | grep bridge.pfil
Have you tried filtering only on one of the physical bridge interfaces,
with net.link.bridge.pfil_bridge=0 and set skip on { lo0, bridge0, em1 }?
Daniel
------------------------------
Message: 18
Date: Wed, 17 Mar 2010 10:12:39 +0100
From: Gilles WAGNER <gil...@gmail.com>
Subject: Fwd: Choosing CPU for router
To: freeb...@freebsd.org
Message-ID:
<a952d5981003170212t1fe...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/3/17 Andrew Snow <and...@modulus.org>
Matthias Gamsjager wrote:
>
>> Way over the top for simple fw and dhcpd. but how much traffic will
>> be involved?
>> Investing in a good nics will return more then a pricey cpu and
>> motherboard (eec mem is good idea for 24/7 tho).
>>
>
>
> Agreed.
>
> The Supermicro Atom miniserver is more than enough CPU grunt for this sort
> of routing/ipfw task. The main reason to go Xeon is if you need ECC RAM,
> and even then you can get away with just using the cheapest CPU available.
>
>
> - Andrew
>
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>
Hi,
That's what I would choose : 2 or more atom miniserver and pfsync. But I
don't know how well it can work with ipfw.
Gilles
------------------------------
Message: 19
Date: Wed, 17 Mar 2010 11:22:34 +0100
From: Jon Otterholm <jon.ot...@ide.resurscentrum.se>
Subject: Re: Choosing CPU for router
To: Gilles WAGNER <gil...@gmail.com>, <freeb...@freebsd.org>
Message-ID: <C7C66BFA.244BF%jon.ot...@ide.resurscentrum.se>
Content-Type: text/plain; charset="US-ASCII"
Den 2010-03-17 10.12, skrev "Gilles WAGNER" <gil...@gmail.com>:
> 2010/3/17 Andrew Snow <and...@modulus.org>
>
> Matthias Gamsjager wrote:
>>
>>> Way over the top for simple fw and dhcpd. but how much traffic will
>>> be involved?
>>> Investing in a good nics will return more then a pricey cpu and
>>> motherboard (eec mem is good idea for 24/7 tho).
>>>
>>
>>
>> Agreed.
>>
>> The Supermicro Atom miniserver is more than enough CPU grunt for this sort
>> of routing/ipfw task. The main reason to go Xeon is if you need ECC RAM,
>> and even then you can get away with just using the cheapest CPU available.
>>
>>
>> - Andrew
>>
>> _______________________________________________
>> freeb...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>>
> Hi,
>
> That's what I would choose : 2 or more atom miniserver and pfsync. But I
> don't know how well it can work with ipfw.
>
> Gilles
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
This machine is going to act as access-router serving ~500 FTTH-customers.
About 500Mbit/s and 200kpps. The big issue is Dummynet, around 1000 pipes (2
pipes/customer).
I don't think an Atom-based machine can handle this, am I wrong?
//Jon
------------------------------
Message: 20
Date: Wed, 17 Mar 2010 11:33:57 +0100
From: Gilles WAGNER <gil...@gmail.com>
Subject: Re: Choosing CPU for router
To: freeb...@freebsd.org
Message-ID:
<a952d5981003170333v2d2...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/3/17 Jon Otterholm <jon.ot...@ide.resurscentrum.se>
>
>
>
> Den 2010-03-17 10.12, skrev "Gilles WAGNER" <gil...@gmail.com>:
>
> > 2010/3/17 Andrew Snow <and...@modulus.org>
> >
> > Matthias Gamsjager wrote:
> >>
> >>> Way over the top for simple fw and dhcpd. but how much traffic will
> >>> be involved?
> >>> Investing in a good nics will return more then a pricey cpu and
> >>> motherboard (eec mem is good idea for 24/7 tho).
> >>>
> >>
> >>
> >> Agreed.
> >>
> >> The Supermicro Atom miniserver is more than enough CPU grunt for this
> sort
> >> of routing/ipfw task. The main reason to go Xeon is if you need ECC
> RAM,
> >> and even then you can get away with just using the cheapest CPU
> available.
> >>
> >>
> >> - Andrew
> >>
> >> _______________________________________________
> >> freeb...@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
> >>
> > Hi,
> >
> > That's what I would choose : 2 or more atom miniserver and pfsync. But I
> > don't know how well it can work with ipfw.
> >
> > Gilles
> > _______________________________________________
> > freeb...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>
> This machine is going to act as access-router serving ~500 FTTH-customers.
> About 500Mbit/s and 200kpps. The big issue is Dummynet, around 1000 pipes
> (2
> pipes/customer).
>
> I don't think an Atom-based machine can handle this, am I wrong?
>
> //Jon
>
> I don't think an atom-based machine can handle this. But what about 4 ? Or
more. D510-based motherboard are cheap and energy efficient. So good
failover by total redundancy, and your router can grow easily (by adding
atom)
But I think this would be harder to configure than a big CPU, with tons of
ram and good NICs.
Gilles
------------------------------
Message: 21
Date: Wed, 17 Mar 2010 11:47:32 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Daniel Hartmeier <dan...@benzedrine.cx>
Cc: freeb...@freebsd.org, kevin <k...@kevinkevin.com>,
freeb...@freebsd.org
Message-ID: <4BA0B344...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 17.03.2010 09:12, Daniel Hartmeier wrote:
> On Tue, Mar 16, 2010 at 03:19:51PM -0400, kevin wrote:
>
>
>> I would like to assist in diagnosing this issue so if anyone wants me to
>> check anything or test, please let me know. I would really like to
>> understand this problem.
>>
> What are your settings for
>
> $ sysctl -a | grep bridge.pfil
>
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 1
net.link.bridge.pfil_onlyip: 1
> Have you tried filtering only on one of the physical bridge interfaces,
> with net.link.bridge.pfil_bridge=0 and set skip on { lo0, bridge0, em1 }?
>
> Daniel
>
Ok, I'm trying "set skip on {lo0, bridge0}".
I'll let you know if there is any improvement.
Thanks.
------------------------------
Message: 22
Date: Wed, 17 Mar 2010 12:12:50 +0100
From: serena zanetta <sz3...@gmail.com>
Subject: sscanf in kernel
To: freeb...@freebsd.org
Message-ID:
<b2ecfd381003170412k759...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I need to convert an ascii string in its corresponding hex version (the same
as sscanf(str,"%02x%02x...",...) does) in the kernel.
Could someone help me?
Thank you in advice,
Serena
------------------------------
End of freebsd-net Digest, Vol 363, Issue 3
*******************************************