-
Notifications
You must be signed in to change notification settings - Fork 753
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix GCU test_dynamic_acl failure on 2vlan config testbed #16637
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Zhaohui Sun <zhaohuisun@microsoft.com>
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Zhaohui Sun <zhaohuisun@microsoft.com>
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run |
Commenter does not have sufficient privileges for PR 16637 in repo sonic-net/sonic-mgmt |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
logging.info("It has vlan: {}".format(config_facts['VLAN_INTERFACE'].keys())) | ||
increment = 65 | ||
else: | ||
increment = 129 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we be able to calculate the increment instead? Something like:
vlan_num = len(config_facts['VLAN_INTERFACE'])
increment = math.ceil(129 / vlan_num)
# For 1 vlan, increment is 129
# for 2, increment is 65
# for 3, increment is 43 etc
Just to cover ourselves in future for similar issues, if we need to have testbeds with more VLANs
increment = 65 | ||
else: | ||
increment = 129 | ||
|
||
# Increment address by 3 to offset it from the intf on which the address may be learned |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment is outdated as of this PR (which must have been missed back then): #12711
Would we be able to update/remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a little confusing here, why 3 vlan, increment is 43?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed offline, if pick 129 as increment for 2vlan scenarios, ip address chosen in the script will be overlapped with the second vlan's scope, which will cause case failure.
For 3vlans, we don't have this scenarios for now.
Signed-off-by: Zhaohui Sun <zhaohuisun@microsoft.com>
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
@StormLiangMS could you please help review? |
Signed-off-by: Zhaohui Sun <zhaohuisun@microsoft.com>
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description of PR
Summary:
Fixes # (issue)
failures of test_gcu_acl_arp_rule_creation when enabling 2 vlan config
With 2vlan config on testbed, GCU test_dynamic_acl failed due to ip conflict with the ip address of the second vlan interface,
192.168.0.129.
ping success, but there is no arp entry for this ip address.
Then case failed.
Failures of test_gcu_acl_dhcp_rule_creation when enabling 2 vlan config
Previous logic just picks up the latest ipv4 address or ipv6 address from
mg_facts['minigraph_vlan_interfaces']
, which doesn't work for the first vlan caseType of change
Back port request
Approach
What is the motivation for this PR?
Otherwise, incrementing by 129 will cause IP overlap within the second VLAN's IP range, 192.168.0.129.
How did you do it?
intf_ipv4_addr.network_address
is 192.168.0.0, after increase 129, it becomes 192.168.0.129, which is same with ip address of the second vlan interface.ptf_intf_ipv4_addr = increment_ipv4_addr(intf_ipv4_addr.network_address, incr=129)
config_facts['VLAN_INTERFACE'][vlan_name]
, differentvlan_name
will get differnet ip addressHow did you verify/test it?
run tests/generic_config_updater/test_dynamic_acl.py
Supported testbed topology if it's a new test case?
Documentation