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

[Sam Leffler]

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?).

	Sam