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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
