Skip to content
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

[VLAN test] Add VLAN test #375

Merged
merged 9 commits into from
Dec 30, 2017
Merged

Conversation

tieguoevan
Copy link
Contributor

Signed-off-by: Judong [email protected]

@lguohan lguohan requested a review from stcheng December 5, 2017 11:16
- debug: var=vlan_intf_list

- name: Flush all IP addresses on the LAGs
shell: cfgmgr intf del {{ (item.addr ~ "/" ~ item.mask)|ipaddr()|upper() }} dev {{ item.attachto }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cfgmgr is not checked in. any plan to do this?

Copy link
Contributor

@lguohan lguohan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not know how to run this test since the cfgmgr is not checked-in. Is there any plan to integrate cfgmgr into the sonic-utilities first?

@tieguoevan
Copy link
Contributor Author

I have replace cfgmgr to vlan command introduced by sonic-net/sonic-utilities#151. Please take a look at. Thank you.

- "{{ minigraph_portchannel_interfaces }}"
become: true

- name: Delete all IP addresses on the LAGs in config DB
Copy link
Contributor Author

@tieguoevan tieguoevan Dec 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a workaround since there is no command line to do both configure interface IP and write to configDB now. Is there any plan to support this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We plan to support IP and Lag configuration though configDb in next release March.


In reply to: 155185549 [](ancestors = 155185549)

dst_mac, self.dataplane.get_mac(0, target["port_index"]),
src_ip, target["remote_ip"], 63)

# Test case #5
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Test case 5 tests ping to CPU and verifies reply from CPU.

@keboliu
Copy link
Contributor

keboliu commented Dec 7, 2017

One general question may not relate to the code but need to clarify.
How about the requirement to the fanout switch for these newly added cases?
In the test plan mentioned QinQ need to be configured on the fanout switch, could you elaborate it?

@tieguoevan
Copy link
Contributor Author

Hi @keboliu,
QinQ is the only requirement for the fanout switch.
I think different vectors' devices have different configuration for QinQ. For us, we use a H3C switch as our fanout switch and enable QinQ by simply enabling it on every port connecting to the DUT according to its configuration guide

#-----------------------------------------
- name: Clean up Vlan test configuration on the testbed
include: vlan_cleanup.yml
tags: vlan_cleanup
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggest adding using log analyzer to analyze the errors in the log as part of the test as ACL test and Everflow test did, by this could make these test cases more complete.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you kebo, LogAnalyzer will make the test case more complete. But I think it's better for me to add LogAnalyzer later after the test check in due to the time factor.

shell: config save -y
become: true

- name: Reboot is required for config_db.json change
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could this reboot be avoided by using "config reload config_db.json" to flush and reload the new configuration?

shell: mv /etc/sonic/config_db_bak.json /etc/sonic/config_db.json
become: true

- name: Reboot is required for config_db.json change
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question as previous one, is this reboot avoidable by using "config reload config_db_back.json"?

@lguohan
Copy link
Contributor

lguohan commented Dec 7, 2017

@tieguoevan, can you provide command line how to run this test in README.test.md?


#--------------------------------------------------------------------------
def build_icmp_packet(self, vlan_id,
src_mac="00:22:00:00:00:02", dst_mac="00:22:00:00:00:01",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where does this dst_mac get populated the in the DUT switch. How does the switch know how to forward this packet?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If dst_mac is not specified, an unknown unicast ICMP package is constructed by default. "00:22:00:00:00:01" is unknown for switch unless a coincidence, switch need to flood this packet in the VLAN.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since your purpose is to broadcast the packet, why not use broadcast mac in this case? the behavior of unknown unicast mac can be changed.

@lguohan
Copy link
Contributor

lguohan commented Dec 8, 2017

@tieguoevan, did you modify the arp_responder to support new format?

root@ce4c4380a07c:~# more /tmp/from_t1.json 
{"eth4.200": ["192.168.200.4"], "eth0.200": ["192.168.200.0"], "eth1.100": ["192.168.100.1"], "eth16.100": ["192.168.100.16"], "eth4": ["192.168.100.4"], "eth16": ["192.168.200.16"], "eth1": ["192.168.200.1"], "eth0": ["192.168
.100.0"]}

@tieguoevan
Copy link
Contributor Author

I think arp_responder is support this format. What error message have you encountered?

self.verify_icmp_packets_from_specified_port(target["port_index"],
target["vlan_id"] if target["vlan_id"] != target["pvid"] else 0,
dst_mac, self.dataplane.get_mac(0, target["port_index"]),
src_ip, target["peer_ip"], 63)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

port 16 is part of lag, the packet can go to either port 16 or port 17. Here you only check port 16 which is not enough.

01:36:21.910  root      : INFO    : Send tagged(200) packet from 4...
01:36:21.910  root      : INFO    : 7c:fe:90:5e:6b:04 -> 90:b1:1c:f4:a8:53, 192.168.200.4 -> 192.168.100.16
01:36:21.912  root      : INFO    : Verify packet from port 16

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test only supports t0 testbed type now. The t0 testbed type should only suppprt one member in LAG? If t1-lag is supported in the future, here need to be modified indeed.

Copy link
Contributor

@lguohan lguohan Dec 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

another issue.

05:14:27.515  root      : INFO    : Test case #4 starting ...
05:14:27.524  root      : INFO    : Send tagged(200) packet from 4...
05:14:27.525  root      : INFO    : 7c:fe:90:5e:6b:04 -> 90:b1:1c:f4:a8:53, 192.168.200.4 -> 192.168.100.4
05:14:27.528  root      : INFO    : Verify packet from port 4
05:14:27.543  root      : INFO    : Send tagged(200) packet from 4...
05:14:27.543  root      : INFO    : 7c:fe:90:5e:6b:04 -> 90:b1:1c:f4:a8:53, 192.168.200.4 -> 192.168.100.16
05:14:27.545  root      : INFO    : Verify packet from port 16
05:14:27.558  root      : INFO    : Send tagged(200) packet from 4...
05:14:27.559  root      : INFO    : 7c:fe:90:5e:6b:04 -> 90:b1:1c:f4:a8:53, 192.168.200.4 -> 192.168.100.0
05:14:27.562  root      : INFO    : Verify packet from port 0

The destination IP 192.168.100.0 is strange

pass
#--------------------------------------------------------------------------

def setUpArpResponder(self):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in order for the test to make, every port in the ptf conainer needs to have a different mac. That is not the setup by default, you need to run this script. Can you add in the test?

https://github.com/Azure/sonic-mgmt/blob/master/ansible/roles/test/files/helpers/change_mac.sh

#--------------------------------------------------------------------------
def send_icmp_packet(self, vlan_port, vlan_id=0,
src_mac="00:22:00:00:00:02", dst_mac="00:22:00:00:00:01",
src_ip="192.168.0.1", dst_ip="192.168.0.2", ttl=64):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you already have default paramaters in build_icmp_packet, can we avoid duplication here?

#--------------------------------------------------------------------------
def verify_icmp_packets(self, vlan_port, vlan_id,
src_mac="00:22:00:00:00:02", dst_mac="00:22:00:00:00:01",
src_ip="192.168.0.1", dst_ip="192.168.0.2", ttl=64):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you already have default paramaters in build_icmp_packet, can we avoid duplication here?

masked_exp_pkt = Mask(exp_pkt)
masked_exp_pkt.set_do_not_care_scapy(scapy.IP, "id")

verify_packets(self, masked_exp_pkt, list(str(src_port)))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you print similiar log here?

self.log("Verify packet from ports ???")

I do not find the verify log in test 5.

- name: Configure IP addresses on VLAN interfaces in Config DB
shell: docker exec -i database redis-cli -n 4 hset "VLAN_INTERFACE|Vlan{{ item.vlan_id }}|{{ item.ip }}" NULL NULL
with_items: "{{ vlan_intf_list }}"
become: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all these steps seems complex, why not provide a configdb.json file we need here and just reload to the new configdb?

become: true

- name: Configure IP addresses on VLAN interfaces in Config DB
shell: docker exec -i database redis-cli -n 4 hset "VLAN_INTERFACE|Vlan{{ item.vlan_id }}|{{ item.ip }}" NULL NULL
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to config ip addr manually in previous task? isn't enough by just configuring the VLAN_INTERFACE in the configdb?

include_vars: '/tmp/vlan_info.yml'

- debug: var=vlan_ports_list
- debug: var=vlan_intf_list
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we move line 7-20 to vlantb.yml? I need those variables when I only run the vlan_test.yml

Copy link
Contributor

@lguohan lguohan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as comments

@keboliu
Copy link
Contributor

keboliu commented Dec 11, 2017

@tieguoevan besides enabling the QinQ configuration on the fanout switch ports which connected to the DUT, how about the fanout trunk port which connected to the root fanout? any extra configuration needed?

@tieguoevan
Copy link
Contributor Author

Modified. Please have a look again. Thanks. @lguohan

@tieguoevan
Copy link
Contributor Author

@keboliu no extra configuration needed for us.

@keboliu
Copy link
Contributor

keboliu commented Dec 12, 2017

All cases passed on my local testbed.

@lguohan lguohan merged commit 3821db2 into sonic-net:master Dec 30, 2017
praveen-li pushed a commit to praveen-li/sonic-mgmt that referenced this pull request Jun 20, 2019
* msft_github/master:
  [PFCWD]: Add Add support for t0 toplogy and arista fanout testbed (sonic-net#424)
  add orchagent process check before each test and sanity after each test (sonic-net#431)
  Move mem_check.sh into helpers/ directory to conform with location of other helper scripts (sonic-net#435)
  fix tests for t0-116 topology (sonic-net#430)
  Updated labinfo file with Arista fanout sku (sonic-net#429)
  add missing snmp testcases to top level snmp.yml; fixed wrong test file for neighbour test; change arp test comment more readable (sonic-net#428)
  Fix sku-sensors-data for 7060 (sonic-net#427)
  Fix port alias mapping for Arista-7050QX-32S (sonic-net#426)
  [Lag 2] Allow lacp timing tests to retry limited times until succeeded (sonic-net#403)
  [hwsku]: Add Accton-AS7716-32X (sonic-net#405)
  add generate minigrah using testbed_name option (sonic-net#425)
  Update README.testbed.md
  Create README.testbed.Example.md
  Update README.testbed.Config.md
  add missing test case name (sonic-net#417)
  fix typo when assign dscp_mode for decap test (sonic-net#418)
  [repeat harness] rework repeat harness and introduce test case continuous reboot (sonic-net#416)
  allow upgrade sonic via onie or sonic-to-sonic upgrade method (sonic-net#413)
  [topology]: Fix t1-64-lag topology device link base indices (sonic-net#414)
  Run sudo command with log_analyzer (sonic-net#415)
  [sonic tests] use host time instead of ansible time (sonic-net#410)
  [upgrade_sonic]: Fix the hostname in the wait_for condition (sonic-net#411)
  [Test cases] clean up some test cases changes and enabling more tests (sonic-net#409)
  add restart_swss (sonic-net#412)
  [sonic test] introduce a repeat harness (sonic-net#402)
  Update README.test.md
  [bgp_speaker]: always clean up test environment after it finishes (sonic-net#406)
  [vlan]: add vlan test to test by testname (sonic-net#408)
  [bug]: convert the interface from unicode to string (sonic-net#407)
  [VLAN test] Add VLAN test (sonic-net#375)
  [vm]: change the default Front plane port to 4 instead of 8 (sonic-net#404)
  Update README.testbed.Setup.md
  [acl]: Adopt tests with acl-loader to t0 and t1-lag topo. (sonic-net#370)
  add connect_topo command for testbed-cli.sh (sonic-net#398)
  [FIB, BGP speaker] fix t0-116 topology source port list (sonic-net#396)
  [bgp_speaker]: Specify VLAN IP route in case LPM to other nexthop (sonic-net#394)
  [sensor]: Change sensor labels for Arista 7050 and 7260 (sonic-net#395)
  Delete Arista DPMs sensors data (sonic-net#393)
  [bug]: change maximum packet to 9114 to send in the mtu test (sonic-net#391)
@chenkelly
Copy link
Contributor

chenkelly commented Dec 13, 2019

Hi all
Please advise us your suggestion. Thanks very much.
There are two members in every port channel for t0-116 topology, but only select first trunk member (port_index) to run vlan test cases in PTF VM according to VLAN ports information which generated by vlan_info.j2 file.
It is strange because we cannot suppose that testing DUT always select fixed trunk member for egress forwarding after applying load balance algorithm which is depend on ASIC design.
PTF determine VLAN test is failed if testing DUT select second member of port channel as egress port.

Please see our test results belows.

  1. Deploy minigraph.
    DUT create four PortChannel0001~0004, two members in every PortChannel.
   root@as8000:~# show int p
   Flags: A - active, I - inactive, Up - up, Dw - Down, N/A - not available,
          S - selected, D - deselected, * - not synced
     No.  Team Dev         Protocol     Ports
   -----  ---------------  -----------  ---------------------------
    0001  PortChannel0001  LACP(A)(Up)  Ethernet25(S) Ethernet24(S)
    0002  PortChannel0002  LACP(A)(Up)  Ethernet27(S) Ethernet26(S)
    0003  PortChannel0003  LACP(A)(Up)  Ethernet29(S) Ethernet28(S)
    0004  PortChannel0004  LACP(A)(Up)  Ethernet30(S) Ethernet31(S)
  1. Run VLAN test case.
    For PortChannel0001, port_index is first member "24" and it is added to VLAN 100 with untagged member and VLAN 200 with tagged member.
    For PortChannel0003, port_index is first member "28" and it is added to VLAN 200 with untagged member and VLAN 100 with tagged member.
    When PTF run case 1, send untagged packet from 24 and expect port 28 receive tagged packet.
    Ethernet24 of DUT receives untagged packets and then forward to other VLAN member (PortChannel0003) of VLAN 100.
    If ASCI select member Ethernet29 to send out tagged VLAN 100 packets, the test is failed finially.
    sonic@8c173b24ac3b:~/sonic-mgmt/ansible$ cat /tmp/vlan_info.yml
    ---     

            

    vlan_ports_list:
      - dev: PortChannel0001
        port_index: 24
        pvid: '100'
        permit_vlanid:
          '100':
            peer_ip: '192.168.100.97'
            remote_ip: '100.1.1.97'
          '200':
            peer_ip: '192.168.200.97'
            remote_ip: '200.1.1.97'
      - dev: PortChannel0003
        port_index: 28
        pvid: '200'
        permit_vlanid:
          '100':
            peer_ip: '192.168.100.91'
            remote_ip: '100.1.1.91'
          '200':
            peer_ip: '192.168.200.91'
            remote_ip: '200.1.1.91'     

            

    vlan_intf_list:
      - vlan_id: '100'
        ip: '192.168.100.1/24'
      - vlan_id: '200'
        ip: '192.168.200.1/24'      

            

    ...
    root@01432d0008ea:~# cat /tmp/vlan_test.log
    02:16:05.806  root      : INFO    : ++++++++ Fri Dec 13 02:16:05 2019 ++++++++
    02:16:05.886  scapy.runtime: WARNING : No route found for IPv6 destination :: (no default route?)
    02:16:05.920  root      : INFO    : VXLAN support found in Scapy
    02:16:05.921  root      : INFO    : ERSPAN support found in Scapy
    02:16:05.922  root      : INFO    : GENEVE support found in Scapy
    02:16:05.922  root      : INFO    : MPLS support found in Scapy
    02:16:05.923  root      : INFO    : NVGRE support found in Scapy
    02:16:06.019  root      : INFO    : Importing platform: remote
    02:16:06.021  root      : INFO    : port map: {(0, 86): 'eth86', (0, 53): 'eth53', (0, 20): 'eth20', (0, 89): 'eth89', (0, 56): 'eth56', (0, 109): 'eth109', (0, 7): 'eth7', (0, 76): 'eth76', (0, 43): 'eth43', (0, 10): 'eth10', (0, 94): 'eth94', (0, 61): 'eth61', (0, 98): 'eth98', (0, 28): 'eth28', (0, 65): 'eth65', (0, 32): 'eth32', (0, 15): 'eth15', (0, 116): 'eth116', (0, 83): 'eth83', (0, 50): 'eth50', (0, 103): 'eth103', (0, 17): 'eth17', (0, 70): 'eth70', (0, 37): 'eth37', (0, 106): 'eth106', (0, 4): 'eth4', (0, 73): 'eth73', (0, 40): 'eth40', (0, 55): 'eth55', (0, 22): 'eth22', (0, 91): 'eth91', (0, 58): 'eth58', (0, 111): 'eth111', (0, 25): 'eth25', (0, 78): 'eth78', (0, 45): 'eth45', (0, 12): 'eth12', (0, 113): 'eth113', (0, 80): 'eth80', (0, 63): 'eth63', (0, 100): 'eth100', (0, 30): 'eth30', (0, 67): 'eth67', (0, 34): 'eth34', (0, 1): 'eth1', (0, 118): 'eth118', (0, 85): 'eth85', (0, 52): 'eth52', (0, 19): 'eth19', (0, 88): 'eth88', (0, 39): 'eth39', (0, 108): 'eth108', (0, 6): 'eth6', (0, 75): 'eth75', (0, 42): 'eth42', (0, 9): 'eth9', (0, 93): 'eth93', (0, 60): 'eth60', (0, 97): 'eth97', (0, 27): 'eth27', (0, 64): 'eth64', (0, 47): 'eth47', (0, 14): 'eth14', (0, 115): 'eth115', (0, 82): 'eth82', (0, 49): 'eth49', (0, 102): 'eth102', (0, 16): 'eth16', (0, 69): 'eth69', (0, 36): 'eth36', (0, 105): 'eth105', (0, 3): 'eth3', (0, 72): 'eth72', (0, 87): 'eth87', (0, 54): 'eth54', (0, 21): 'eth21', (0, 90): 'eth90', (0, 57): 'eth57', (0, 110): 'eth110', (0, 24): 'eth24', (0, 77): 'eth77', (0, 44): 'eth44', (0, 11): 'eth11', (0, 112): 'eth112', (0, 95): 'eth95', (0, 62): 'eth62', (0, 99): 'eth99', (0, 29): 'eth29', (0, 66): 'eth66', (0, 33): 'eth33', (0, 0): 'eth0', (0, 117): 'eth117', (0, 84): 'eth84', (0, 51): 'eth51', (0, 18): 'eth18', (0, 71): 'eth71', (0, 38): 'eth38', (0, 107): 'eth107', (0, 5): 'eth5', (0, 74): 'eth74', (0, 41): 'eth41', (0, 8): 'eth8', (0, 23): 'eth23', (0, 92): 'eth92', (0, 59): 'eth59', (0, 96): 'eth96', (0, 26): 'eth26', (0, 79): 'eth79', (0, 46): 'eth46', (0, 13): 'eth13', (0, 114): 'eth114', (0, 81): 'eth81', (0, 48): 'eth48', (0, 101): 'eth101', (0, 31): 'eth31', (0, 68): 'eth68', (0, 35): 'eth35', (0, 104): 'eth104', (0, 2): 'eth2', (0, 119): 'eth119'}
    02:16:06.021  root      : INFO    : Autogen random seed: 14127903
    02:16:06.080  root      : INFO    : *** TEST RUN START: Fri Dec 13 02:16:06 2019
    02:16:06.082  root      : INFO    : Create VLAN intf
    02:16:06.103  root      : INFO    : Start arp_responder
    02:16:07.296  root      : INFO    : VLAN test starting ...
    02:16:07.296  root      : INFO    : Test case #1 starting ...
    02:16:07.301  root      : INFO    : Send untagged packet from 24 ...
    02:16:07.301  root      : INFO    : 00:22:00:00:00:02 192.168.0.1 -> ff:ff:ff:ff:ff:ff 192.168.0.2
    02:16:08.169  root      : INFO    : Verify untagged packets from ports [] tagged packets from ports [28]
    02:16:10.182  root      : INFO    : VLAN test ending ...
    02:16:10.182  root      : INFO    : Stop arp_responder
    02:16:10.436  root      : INFO    : Delete VLAN intf
    02:16:10.510  root      : INFO    : *** TEST RUN END  : Fri Dec 13 02:16:10 2019
    02:16:10.511  dataplane : INFO    : Thread exit

@neethajohn neethajohn mentioned this pull request Aug 12, 2020
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants