[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
merging forwarding & packet filtering?
What do people think about gradually merging the packet-forwarding and
packet-filtering functions in the kernel?
I ask because I keep rediscovering that NetBSD is not adequate for
creating any non-trivial router unless I resort to using PF 'route-to'
statements that consult a packet's source address or port and then
contravene the forwarding table, create state, et cetera. Route-to
rules sometimes lead to hard-to-predict and inefficient behavior inside
the network stack: for example, a packet outbound on interface A may
make a hairpin turn to go out interface B, instead. Once I have set
up the forwarding the way I like it, the kernel forwarding table does
such light duty on these routers that you almost but not quite toss it
It seems to me that if packet filters are already making up for the
forwarding table's shortcomings, and if their pace of development,
speed, suitability for SMP (thinking of NPF here), and versatility
outmatches the forwarding table, we will save ourselves a lot of effort
to refurbish forwarding by rolling the forwarding/filtering functions
into one subsystem.
 Route-to rules do sometimes consult the forwarding table---that's my
hazy recollection, anyway.
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 344-0444 x24
Main Index |
Thread Index |