Skip to content

ACL test plan

Jump to bottom
Andriy Moroz edited this page Feb 8, 2017 · 16 revisions

[DRAFT, UNDER DEVELOPMENT]

##Overview The purpose is to test functionality of ACL rules on the SONIC switch DUT with and without LAGs configured, closely resembling production environment. The test assumes all necessary configuration, including ACL and LAG configuration, BGP routes, are already pre-configured on the SONIC switch before test runs.

###Scope The test is targeting a running SONIC system with fully functioning configuration. The purpose of the test is not to test specific SAI API, but functional testing of ACL on SONIC system, making sure that traffic flows correctly, according to BGP routes advertised by BGP peers of SONIC switch, and the LAG configuration.

NOTE: ACL+LAG test will be able to run only in the testbed specifically created for LAG.

###Related DUT CLI commands Manual ACL configuration can be done using swssconfig utility in swss container.

swssconfig <json-file to apply>

##Test structure ###Setup configuration ACL configuration should be created on the DUT before running the test. Configuration could be deployed using ansible sonic test playbook with the tag acltb_configure.

Scripts for generating ACL configuration on SONIC

There will be two j2 template files for the ACL test configuration: acl_test_table.j2 and acl_test_rules.j2. They will be used by Ansible playbook to generate json files and apply them on the switch.

Ansible scripts to setup and run ACL test

acl_testbed.yml

acl_testbed.yml when run with different tags will

Tag acltb_configure will generate acl json files for the ACL test out of the corresponding j2 files and apply them on the switch.
Tag acltb_test will run ACL test (or ACL+LAG) test.
Tag acltb_cleanup will clear the test ACL configuration from the switch.

ACL test consists of a number of subtests, and each of them will include the following steps:

  1. Run lognanalyzer 'init' phase
  2. Run ACL Sub Test
  3. Run loganalyzer 'analyze' phase

ACL subtests will be implemented in the PTF (acl_testbed_test.py). Every subtest wibb be implemented in a separate class.

Setup of DUT switch

Setup of SONIC DUT will be done by Ansible script. During setup Ansible will copy json file containing configuration for ACL to the swss container on the DUT. swssconfig utility will be used to push configuration to the SONiC DB. Data will be consumed by orchagent.

JSON Sample:

table.json

    [
        {
            "ACL_TABLE:Drop_IP": {
                "policy_desc" : "Drop_IP_Traffic",
                "type" : "L3",
                "ports" : "Ethernet0"
            },
        "OP": "SET"
        }
    ]

rule.json

    [
        {
            "ACL_RULE_TABLE:Drop_IP:TheDrop": {
                "priority" : "55",
                "ETHER_TYPE" : "0x0800",
                "PACKET_ACTION" : "DROP"
            },
            "OP": "SET"
        }
    ]

NOTE Tables and rules configuration will reside in two different jsons and table configuration will be applied before rules to ensure correct objects creation order in SAI.

J2 templates

acl_test_table.j2 will configure single table bound to all switch ports.

    [
        {
            "ACL_TABLE:ACL_Testbed_Test_Table": {
                "policy_desc" : "Thistable_contains_rules_needed_for_the_testbed_regression_tests",
                "type" : "L3",
                "ports":"{% for ifname, v in minigraph_neighbors.iteritems() %}{{"%s" % alias_reverse_map[ifname]}},{% endfor %}",
            },
            "OP": "SET"
        }
    ]

acl_test_rules.j2 will contain ACL rules needed for the test

ACL Rules:

Rule#1: match src ip, action: drop (+1 for IPv6)
Rule#2: match dst ip, action: drop (+1 for IPv6)
Rule#3: match l4_src_port, action: drop
Rule#4: match l4_dst_port, action: drop
Rule#5: match ether type, action: drop
Rule#6: match ip protocol, action: drop
Rule#7: match tcp flags, action: drop
Rule#8: match ip type, action: drop (+1 for IPv6)
Rule#9: match source ports range, action: drop
Rule#10: match destination ports range, action: drop
Rules#11-12: check priority: match some src ip, action: drop + match the same ip (higher prio), action: forward

/if needed additionally match src ip/

##PTF Test

Input files for PTF test

PTF test will generate traffic between ports and make sure it passes according to the configured ACL rules. Depending on the testbed topology and the existing configuration (e.g. ECMP, LAGS, etc) packets may arrive to different ports. Therefore ports connection information will be generated from the minigraph and supplied to the PTF script.

Traffic validation in PTF

Depending on the test PTF test will verify the packet arrived or dropped.

##Test cases

Each test case will be additionally validated by the loganalizer and counters reading utility.

Test case #1 - Verify source IP match

Test objective

Verify match source IP address works.

Test steps

  • PTF host will send packet specifying particular source IP address in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #1. PTF docker should not receive this packet.
  • Counter for the rule #1 should increment

Test case #2 - Verify destination IP match

Test objective

Verify match destination IP address works.

Test steps

  • PTF host will send packet specifying particular destination IP address in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #2. PTF docker should not receive this packet.
  • Counter for the rule #2 should increment

Test case #3 - Verify L4 source port match

Test objective

Verify match L4 source port works.

Test steps

  • PTF host will send packet with the specific L4 source port in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #3. PTF docker should not receive this packet.
  • Counter for the rule #3 should increment

Test case #4 - Verify L4 destination port match

Test objective

Verify match L4 source port works.

Test steps

  • PTF host will send packet with the specific L4 destination port in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #4. PTF docker should not receive this packet.
  • Counter for the rule #4 should increment

Test case #5 - Verify ether type match

Test objective

Verify match packet ether type works.

Test steps

  • PTF host will send packet with the specific ether type in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #5. PTF docker should not receive this packet.
  • Counter for the rule #5 should increment

NOTE Ether type used in this test should be "exotic" enough to exclude possible interference with the other tests traffic.

Test case #6 - Verify ip protocol match

Test objective

Verify match ip protocol works.

Test steps

  • PTF host will send packet with the specific ip protocol field in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #6. PTF docker should not receive this packet.
  • Counter for the rule #6 should increment

NOTE IP protocol used in this test should be "exotic" enough to exclude possible interference with the other tests traffic. For example 0x7E (Combat Radio Transport Protocol)

Test case #7 - Verify TCP flags match

Test objective

Verify match TCP flags works.

Test steps

  • PTF host will send TCP packet with the specific flags in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #7. PTF docker should not receive this packet.
  • Counter for the rule #7 should increment.

Test case #8 - Verify ip type match

Test objective

Verify match ip protocol works.

Test steps

  • PTF host will send packet with the specific ip protocol field in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #8. PTF docker should not receive this packet.
  • Counter for the rule #8 should increment

TODO Think about IP protocol to use for the test. Maybe add another match criteria (source ip?)

Test case #9 - Verify source port range match

Test objective

Verify match source port range works.

Test steps

  • PTF host will send TCP packet with the specific source port in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #9. PTF docker should not receive this packet.
  • Counter for the rule #9 should increment

Test case #10 - Verify destination port range match

Test objective

Verify match destination port range works.

Test steps

  • PTF host will send TCP packet with the specific destination port in the packet.
  • When packet reaches SONIC DUT, it should be dropped by the rule #10. PTF docker should not receive this packet.
  • Counter for the rule #10 should increment

Test case #11 - Verify rules priority

Test objective

Verify rules priority works.

Test steps

  • PTF host will send TCP packet with the specific source ip in the packet.
  • When packet reaches SONIC DUT, it will not be dropped by the rule #11 because rule #12 with the same matching criteria allows packet to pass.
  • PTF docker virefies packet arrived.
  • Counter for the rule #12 should increment

Other possible tests

  • match combinations
  • ?

TODO

  • ACL+LAG test configuration and testcases (separate ansible tag)

Open Questions

  • Scalability testing
    Add another 1K rules to check ACL engine capability/performance?
  • Persisting ACL config
    Is there any ACL configuration which is desired to be persistent on the testbed DUT?
Clone this wiki locally