Uh oh!
There was an error while loading. Please reload this page.
Fix rule duplication with static NAT rules - #3366
Conversation
yadvr
commented
Jun 4, 2019
Can you review this - @ustcweizhou@anuragaw@shwstppr ? |
blueorangutan
commented
Jun 4, 2019
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
yadvr
commented
Jun 4, 2019
Thanks for the PR @richardlawley - do you think it can cause regression when the VR has multiple public IPs (i.e multiple public nics) as this reverts changes from 40d7746 |
yadvr
commented
Jun 4, 2019
Nevermind I compared your changes with what Jayapal was trying to do, LGTM. |
blueorangutan
commented
Jun 4, 2019
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-2838 |
yadvr
commented
Jun 4, 2019
@blueorangutan test |
blueorangutan
commented
Jun 4, 2019
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
blueorangutan
commented
Jun 4, 2019
Trillian test result (tid-3641)
|
ustcweizhou
commented
Jun 4, 2019
I was just testing it. it works fine. |
Description
The VR code has provision for inserting rules at the top or bottom by specifying "front" as the second parameter to
self.fw.append. However, there are a number of cases where someone has been unaware of this and added a rule with the patternself.fw.append(["mangle", "", "-I PREROUTING".... This causes the code to check for the rule already being present to fail, and duplicate rules end up being added.This PR fixes two of these cases which apply to adding static NAT rules. I am aware of more of these cases, but I don't have the ability to easily test the outcome of fixing them. I'm happy to add these in if you're confident that the automated tests will be sufficient. Searching for "-I (case sensitive) finds these.
The code for dealing with "front" is included below to show that this shouldn't have any ill effects:
Fixes: #3177
Types of changes
How Has This Been Tested?
Local tests were performed (see #3177 for details of symptoms), and we have had this fix deployed in production on advanced networks for a couple of months.