| |||||||||||||
LCE: Challenges for Linux networkingLCE: Challenges for Linux networkingPosted Nov 8, 2012 9:18 UTC (Thu) by rusty (✭ supporter ✭, #26)In reply to: LCE: Challenges for Linux networking by bjencks Parent article: LCE: Challenges for Linux networking
Yes, you can atomically update each table. It was designed that way.
That doesn't mean that applications use the kernel API appropriately; for a long time libiptc didn't give you a great way to do atomic updates of more than one rule at a time.
Changing NAT rules is a weird one, because for radical changes you really want to kill all old connections. Figuring out which existing connections would be NATed differently and resetting them might be a nice twist if people were seeing problems here.
Cheers,
(Log in to post comments)
LCE: Challenges for Linux networking Posted Nov 8, 2012 12:48 UTC (Thu) by jengelh (subscriber, #33263) [Link]
>Figuring out which existing connections would be NATed differently and resetting them might be a nice twist
I do not think you can actually solve this "twist". The fact that NFCT mappings - and thus TCP tuples - do not change when the nat table is changed could be considered a feature in itself. Sort of like an RCU for tuples.
|
|||||||||||||