net.inet.ip.forwarding and net.inet.ip.fastforwarding

[Andre Oppermann]

Sam Leffler wrote:
> 
> eculp at bafirst.com wrote:
> > Quoting Sam Leffler <sam at errno.com>:
> >
> >> Matt Emmerton wrote:
> >>
> >>>> Hi guys.
> >>>>
> >>>> What's the difference between net.inet.ip.forwarding and
> >>>
> >>>
> >>> net.inet.ip.fastforwarding  ?
> >>>
> >>>> What's the role of net.inet.ip.fastforwarding ?
> >>>
> >>>
> >>>
> >>>> From inet(4):
> >>>
> >>>
> >>>      IPCTL_FORWARDING      (ip.forwarding) Boolean: enable/disable
> >>> forwarding
> >>>                            of IP packets.  Defaults to off.
> >>>
> >>>      IPCTL_FASTFORWARDING  (ip.fastforwarding) Boolean:
> >>> enable/disable the
> >>> use
> >>>                            of fast IP forwarding code.  Defaults to off.
> >>> When
> >>>                            fast forwarding is enabled, IP packets are
> >>> for-
> >>>                            warded directly to the appropriate network
> >>> inter-
> >>>                            face with a minimal validity checking, which
> >>>                            greatly improves the throughput.  On the
> >>> other
> >>>                            hand, they bypass the standard procedures,
> >>> such
> >>> as
> >>>                            IP option processing and ipfirewall(4)
> >>> checking.
> >>>                            It is not guaranteed that every packet
> >>> will be
> >>>                            fast-forwarded.
> >>>
> >>
> >> This quote is out of date; on current fastforwarding is purely an
> >> optimization path--if the packet requires features not supported by
> >> the fast path then it's processed normally.
> >
> >
> > Maybe I should have another ristreto before asking this, but based on
> > what I understand from this thread and speaking of current 7.0:
> >
> >  a. I would set both in sysctl.conf
> >     net.inet.ip.forwarding=1
> >     net.inet.ip.fastforwarding=1
> >  b. There would be no "down side" in current 7.0
> >
> > Is this more or less correct?  If so, will this posibly be the case in
> > the 6.0 release also or only in current?
> 
> 6.0 and 7.x share the same code so the settings are identical.  As to
> downside you pay a penalty if the fastforwarding code has to hand the
> packet back to the "slow path".  There may also be side effects from the
> run-to-completion model it uses.  You should test to decide if the
> feature is worth enabling for your environment.  I'm not sure it's had
> much testing (Andre?).

When activated on a router it gives a very nice speed boost.  Process
completion pays off very well here.  It has got a lot of testing at
various ISP's on their production routers.  For hosts it doesn't really
hurt but is totally pointless.

-- 
Andre