Network performance in a dual CPU system

Marcos Bedinelli bedinelli at madhaus.cns.utoronto.ca
Tue Feb 14 07:54:40 PST 2006


Gleb,

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  
fastforwarding.

I will be glad to post the results of my tests to the mailing list, but  
it may take awhile.


Cheers!


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  
> morning
> 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  
> troubleshooting
> M> >the
> M> >M> problem because the machine is in production and can't be down  
> for
> 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  
> packets?
> M> >Did the router generated any ICMP errors or just silently dropped
> M> >packets?
> M>
> M>
> 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>
> 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>       [...]
> 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>
> M>
> 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>
> 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  
> routing
> M> table are sent to disc0. Rule 15300 will catch those packets and  
> send
> 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
> forwarding:
>
>    
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_disc.c.diff? 
> r1=1.48&r2=1.48.2.1
>
> Actually, it is incorrect that upper netowork layer looks into  
> if_drv_flags.
>
> 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  
> appreciate
> if you try to upgrade and provide any feedback.
>
> -- 
> Totus tuus, Glebius.
> GLEBIUS-RIPN GLEB-RIPE


--
Marcos



More information about the freebsd-net mailing list