Network performance in a dual CPU system
bedinelli at madhaus.cns.utoronto.ca
Tue Feb 14 07:54:40 PST 2006
thanks again for looking into this and for your suggestions.
Unfortunately Alpha/Beta/release candidate/pre-release/test versions of
software is a "no go" on that machine. Our short term solution will be
to upgrade the CPU to a faster model. After that, I will be able to
assemble a dual processor system from spare parts and also play with
I will be glad to post the results of my tests to the mailing list, but
it may take awhile.
On 14-Feb-06, at 9:52, Gleb Smirnoff wrote:
> On Tue, Feb 14, 2006 at 09:27:46AM -0500, Marcos Bedinelli wrote:
> M> >M> I tried the 'sysctl net.inet.ip.fastforwarding=1' yesterday
> M> >M> and, as soon as I entered the command, the machine stopped
> M> >forwarding
> M> >M> packets. Unfortunately I was unable to spend time
> M> >the
> M> >M> problem because the machine is in production and can't be down
> M> >not
> M> >M> even a couple of minutes.
> M> >
> M> >This is strange. Can you please show output of 'ifconfig'? Are you
> M> >using
> M> >any packet filters or other additional processing of forwarded
> M> >Did the router generated any ICMP errors or just silently dropped
> M> >packets?
> M> The machine is running Quagga (OSPF and BGP). OSPF runs on bge0. BGP
> M> runs on bge1. It also runs IPFW and basic SNMP.
> M> I suspect the problem I experienced yesterday is related to the IPFW
> M> ruleset. Although it's mainly used for blocking, there are two rules
> M> that forward packets to another machine:
> M> [...]
> M> 07700 fwd a.b.c.d ip from w.x.y.z/16 to any in recv bge0
> M> [...]
> M> 15300 fwd a.b.c.d ip from any to any out xmit disc0
> M> Rule 7700 is doing policy-based routing: if the source IP belongs to
> M> network w.x.y.z/16, the packet is forwarded to host a.b.c.d
> M> I am suspicious about rule 15300. Virtual interface disc0 is our
> M> default route. In other words, the routing table is updated by both
> M> OSPF and BGP. Packets that don't match a specific entry on the
> M> table are sent to disc0. Rule 15300 will catch those packets and
> M> them to host a.b.c.d as well.
> I understood the problem. The fastforwarding code refuses to forward
> packet if it is routed to interface w/o IFF_DRV_RUNNING flag. The disc0
> interface in 6.0-RELEASE doesn't have IFF_DRV_RUNNING flag.
> That's why I added this flag to disc(4) in 6.0-STABLE, to satisfy fast
> Actually, it is incorrect that upper netowork layer looks into
> You can either apply the above patch, or upgrade your system to
> 6.1-BETA. As I
> said before bge(4) driver has undergone some improvements, and I'll
> if you try to upgrade and provide any feedback.
> Totus tuus, Glebius.
> GLEBIUS-RIPN GLEB-RIPE
More information about the freebsd-net