Hello,
On Thu, Jan 04, 2024 at 01:01:30AM +0300, Alexander Okonnikov wrote:
> Hi Alexandr,
>
> The fact that new IP address to be used for new sessions makes sense. Though,
> such behavior could pose problems like follow:
>
> 00:48:30.266195 172.16.0.2 > 172.16.1.3: icmp: echo request
> 00:48:30.266239 arp who-has 172.16.0.2 tell 172.16.0.3
> 00:48:31.266169 172.16.0.2 > 172.16.1.3: icmp: echo request
> 00:48:31.266239 arp who-has 172.16.0.2 tell 172.16.0.3
> 00:48:32.266224 172.16.0.2 > 172.16.1.3: icmp: echo request
> 00:48:32.266292 arp who-has 172.16.0.2 tell 172.16.0.3
> 00:48:33.266300 172.16.0.2 > 172.16.1.3: icmp: echo request
> 00:48:33.266368 arp who-has 172.16.0.2 tell 172.16.0.3
> 00:48:34.266192 172.16.0.2 > 172.16.1.3: icmp: echo request
> 00:48:34.266244 arp who-has 172.16.0.2 tell 172.16.0.3
> 00:48:35.266322 172.16.0.2 > 172.16.1.3: icmp: echo request
>
> Here we see, that requests are still NAT'ed using old address (172.16.0.2),
> while another address is assigned on the corresponding interface. At some
> time ARP entry for 172.16.0.2 on neighboring node has been expired, and that
> node is trying to refresh/discover MAC for 172.16.0.2. As far as the
> interface doesn't own 172.16.0.2 anymore, it doesn't respond to such ARP
> requests. As a result we obtain service disruption.
>
> Why not to invalidate existing NAT sessions upon deleting/replacing address?
the simplest (but brutal) workaround is to flush state
table whenever IP address changes:
pfctl -Fs
command above removes all states from table. better way is
to use 'pfctl -k ...' and kill (remove) only desired states
created by NAT rule before address got changed.
how did you discovered that issue? like is it a part of
some real world situation you experienced?
thanks and
a regards
sashan
