honeycomb package

mgmt-cfg-acl-apihc-apivat-func module

TC01: Honeycomb can create ACL classify table

Check if Honeycomb API can create an ACL table.


Given ACL table from Honeycomb should not exist  ${node}  ${hc_acl_table['name']}
  And ACL table from VAT should not exist  ${node}  ${table_index}
 When Honeycomb creates ACL table  ${node}  ${hc_acl_table}
 Then ACL table from Honeycomb should be  ${node}  ${hc_acl_table_oper}
  And ACL table from VAT should be  ${node}  ${table_index}  ${vat_acl_table}

TC02: Honeycomb can remove ACL table

Check if Honeycomb API can delete an ACL table.


Given ACL table from Honeycomb should be  ${node}  ${hc_acl_table_oper}
  And ACL table from VAT should be  ${node}  ${table_index}  ${vat_acl_table}
 When Honeycomb removes ACL table  ${node}  ${hc_acl_table['name']}
 Then ACL table from Honeycomb should not exist  ${node}  ${hc_acl_table['name']}
  And ACL table from VAT should not exist  ${node}  ${table_index}

TC03: Honeycomb manages more than one ACL table

Check if Honeycomb API can create another ACL table.


Given ACL table from Honeycomb should not exist  ${node}  ${hc_acl_table['name']}
  And ACL table from VAT should not exist  ${node}  ${table_index}
 When Honeycomb creates ACL table  ${node}  ${hc_acl_table}
  And Honeycomb creates ACL table  ${node}  ${hc_acl_table2}
 Then ACL table from Honeycomb should be  ${node}  ${hc_acl_table_oper}
  And ACL table from VAT should be  ${node}  ${table_index}  ${vat_acl_table}
  And ACL table from Honeycomb should be  ${node}  ${hc_acl_table2_oper}
  And ACL table from VAT should be  ${node}  ${table_index2}  ${vat_acl_table2}

TC04: Honeycomb can add ACL session to table

Check if Honeycomb API can add an ACL session to a table.


Given ACL table from Honeycomb should be  ${node}  ${hc_acl_table_oper}
  And ACL table from VAT should be  ${node}  ${table_index}  ${vat_acl_table}
 When Honeycomb adds ACL session  ${node}  ${hc_acl_table['name']}  ${hc_acl_session}
 Then ACL session from Honeycomb should be  ${node}  ${hc_acl_table['name']}  ${hc_acl_session}
  And ACL session from VAT should be  ${node}  ${table_index}  ${session_index}  ${vat_acl_session}

TC05: Honeycomb can remove ACL session

Check if Honeycomb API can remove an ACL session.


Given ACL session from Honeycomb should be  ${node}  ${hc_acl_table['name']}  ${hc_acl_session}
  And ACL session from VAT should be  ${node}  ${table_index}  ${session_index}  ${vat_acl_session}
 When Honeycomb removes ACL session  ${node}  ${hc_acl_table['name']}  ${hc_acl_session['match']}
 Then ACL session from Honeycomb should not exist  ${node}  ${hc_acl_table['name']}  ${hc_acl_session['match']}
  And ACL session from VAT should not exist  ${node}  ${table_index}  ${session_index}

TC06: Honeycomb manages more than one ACL session on one table

Check if Honeycomb API can add another ACL sessionto a table.


Given ACL session from Honeycomb should not exist  ${node}  ${hc_acl_table['name']}  ${hc_acl_session['match']}
  And ACL session from VAT should not exist  ${node}  ${table_index}  ${session_index}
 When Honeycomb adds ACL session  ${node}  ${hc_acl_table['name']}  ${hc_acl_session}
  And Honeycomb adds ACL session  ${node}  ${hc_acl_table['name']}  ${hc_acl_session2}
 Then ACL session from Honeycomb should be  ${node}  ${hc_acl_table['name']}  ${hc_acl_session}
  And ACL session from VAT should be  ${node}  ${table_index}  ${session_index}  ${vat_acl_session}
  And ACL session from Honeycomb should be  ${node}  ${hc_acl_table['name']}  ${hc_acl_session2}
  And ACL session from VAT should be  ${node}  ${table_index}  ${session_index2}  ${vat_acl_session2}

TC07: Honeycomb enables ACL on interface

Check if Honeycomb API can enable ACL on an interface.


Given ACL table from Honeycomb should be  ${node}  ${hc_acl_table_oper}
  And ACL table from VAT should be  ${node}  ${table_index}  ${vat_acl_table}
  And ACL session from Honeycomb should be  ${node}  ${hc_acl_table['name']}  ${hc_acl_session}
  And ACL session from VAT should be  ${node}  ${table_index}  ${session_index}  ${vat_acl_session}
 When Honeycomb enables ACL on interface  ${node}  ${interface}  ${hc_acl_table['name']}
 Then Interface ACL settings from Honeycomb should be  ${node}  ${interface}  ${hc_acl_table['name']}
  And Interface ACL settings from VAT should be  ${node}  ${interface}  ${table_index}

TC08: Honeycomb disables ACL on interface

Check if Honeycomb API can disable ACL on an interface.


Given Interface ACL settings from Honeycomb should be  ${node}  ${interface}  ${hc_acl_table['name']}
  And Interface ACL settings from VAT should be  ${node}  ${interface}  ${table_index}
 When Honeycomb disables ACL on interface  ${node}  ${interface}
 Then Interface ACL settings from Honeycomb should be empty  ${node}  ${interface}
  And Interface ACL settings from VAT should be empty  ${node}  ${interface}

TC09: Honeycomb can remove one out of multiple ACL tables

Check if Honeycomb API can delete an ACL table if morethan one table exists.


Given ACL table from Honeycomb should be  ${node}  ${hc_acl_table_oper}
  And ACL table from VAT should be  ${node}  ${table_index}  ${vat_acl_table}
  And ACL table from Honeycomb should be  ${node}  ${hc_acl_table2_oper}
  And ACL table from VAT should be  ${node}  ${table_index2}  ${vat_acl_table2}
 When Honeycomb removes ACL table  ${node}  ${hc_acl_table2['name']}
 Then ACL table from Honeycomb should be  ${node}  ${hc_acl_table_oper}
  And ACL table from VAT should be  ${node}  ${table_index}  ${vat_acl_table}
  And ACL table from Honeycomb should not exist  ${node}  ${hc_acl_table2['name']}
  And ACL table from VAT should not exist  ${node}  ${table_index2}

mgmt-cfg-ietfacl-apihc-apivat-func module

TC01: L2 ACL MAC filtering through IETF-ACL node

[Top] TG=DUT1=TG. [Enc] Eth-IPv4-TCP. [Cfg] (Using Honeycomb API) On DUT1 bridge both interfaces to TGand configure L2 MAC ACL on ingress interface. [Ver] Send simple TCP packets from one TG interface to the other,using different MACs. Receive all packets except those withMACs in the filtered ranges.


Given Setup Interfaces And Bridge Domain For IETF-ACL Test  L2  ${acl_name_l2}
 When Honeycomb Creates ACL Chain Through IETF Node  ${dut_node}  ${acl_name_l2}  L2  ${acl_settings}
  And Honeycomb Assigns IETF-ACL Chain To Interface  ${dut_node}  ${dut_to_tg_if1}  L2  ingress  ${acl_name_l2}  permit
 Then Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${src_mac}  ${tg_to_dut_if2}  ${dst_mac}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${classify_src}  ${tg_to_dut_if2}  ${classify_dst}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${classify_src2}  ${tg_to_dut_if2}  ${classify_dst2}  TCP  ${src_port}  ${dst_port}

TC02: L2 ACL MAC filtering through IETF-ACL node on egress interface

[Top] TG=DUT1=TG. [Enc] Eth-IPv4-TCP. [Cfg] (Using Honeycomb API) On DUT1 bridge both interfaces to TGand configure L2 MAC ACL on egress interface. [Ver] Send simple TCP packets from one TG interface to the other,using different MACs. Receive all packets except those withMACs in the filtered ranges.


Given Setup Interfaces And Bridge Domain For IETF-ACL Test  L2  ${acl_name_l2}
 When Honeycomb Creates ACL Chain Through IETF Node  ${dut_node}  ${acl_name_l2}  L2  ${acl_settings}
  And Honeycomb Assigns IETF-ACL Chain To Interface  ${dut_node}  ${dut_to_tg_if2}  L2  egress  ${acl_name_l2}  permit
 Then Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${src_mac}  ${tg_to_dut_if2}  ${dst_mac}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${classify_src}  ${tg_to_dut_if2}  ${classify_dst}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${classify_src2}  ${tg_to_dut_if2}  ${classify_dst2}  TCP  ${src_port}  ${dst_port}

TC03: L3 ACL IPv4 filtering through IETF-ACL node

[Top] TG=DUT1=TG. [Enc] Eth-IPv4-TCP. [Cfg] (Using Honeycomb API) On DUT1 set IPv4 addresses on bothinterfaces to TG, add ARP entry and routes, and configure L3 IPv4 ACLon ingress interface with src/dst IP and protocol. [Ver] Send simple TCP and UDP packets from one TG interfaceto the other, using different IPv4 IPs. Receive all packets exceptthose with IPs in the filtered ranges and UDP protocol payload.


Given Setup Interface IPs And Routes For IPv4 IETF-ACL Test  L3_IP4  ${acl_name_l3_ip4}
 When Honeycomb Creates ACL Chain Through IETF Node  ${dut_node}  ${acl_name_l3_ip4}  L3_IP4  ${acl_settings}
  And Honeycomb Assigns IETF-ACL Chain To Interface  ${dut_node}  ${dut_to_tg_if1}  L3_IP4  ingress  ${acl_name_l3_ip4}  permit
 Then Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${tg_to_dut_if1_mac}  ${tg_to_dut_if2}  ${dut_to_tg_if1_mac}  UDP  ${src_port}  ${dst_port}
  And Send TCP Or UDP Packet  ${tg_node}  ${classify_src}  ${classify_dst}  ${tg_to_dut_if1}  ${tg_to_dut_if1_mac}  ${tg_to_dut_if2}  ${dut_to_tg_if1_mac}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${classify_src}  ${classify_dst}  ${tg_to_dut_if1}  ${tg_to_dut_if1_mac}  ${tg_to_dut_if2}  ${dut_to_tg_if1_mac}  UDP  ${src_port}  ${dst_port}

TC04: L3 ACL IPv6 filtering through IETF-ACL node

[Top] TG=DUT1=TG. [Enc] Eth-IPv4-TCP. [Cfg] (Using Honeycomb API) On DUT1 set IPv6 addresses on bothinterfaces to TG, add IP neighbor entry and routes, and configureL3 IPv6 ACL on ingress interface with src/dst IP and next-header. [Ver] Send simple TCP and UDP packets from one TG interfaceto the other, using different IPv6 IPs. Receive all packets exceptthose with IPs in the filtered ranges and UDP protocol payload.


Given Path for 2-node testing is set  ${nodes['TG']}  ${nodes['DUT1']}  ${nodes['TG']}
  And Import Variables  resources/test_data/honeycomb/ietf_acl.py  L3_IP6  ${acl_name_l3_ip6}
  And Honeycomb sets interface state  ${dut_node}  ${dut_to_tg_if1}  up
  And Honeycomb sets interface state  ${dut_node}  ${dut_to_tg_if2}  up
  And Set Interface Address  ${dut_node}  ${dut_to_tg_if1}  ${dut_to_tg_if1_ip}  ${prefix_length}
  And Set Interface Address  ${dut_node}  ${dut_to_tg_if2}  ${dut_to_tg_if2_ip}  ${prefix_length}
  And VPP RA suppress link layer  ${dut_node}  ${dut_to_tg_if2}
  And Add IP Neighbor  ${node}  ${dut_to_tg_if2}  ${gateway}  ${tg_to_dut_if2_mac}
  And VPP Route Add  ${node}  ${dst_net}  ${prefix_length}  ${gateway}  interface=${dut_to_tg_if2}  use_sw_index=False
  And VPP Route Add  ${node}  ${classify_dst_net}  ${prefix_length}  ${gateway}  interface=${dut_to_tg_if2}  use_sw_index=False
 When Honeycomb Creates ACL Chain Through IETF Node  ${dut_node}  ${acl_name_l3_ip6}  L3_IP6  ${acl_settings}
  And Honeycomb Assigns IETF-ACL Chain To Interface  ${dut_node}  ${dut_to_tg_if1}  L3_IP6  ingress  ${acl_name_l3_ip6}  permit
 Then Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${tg_to_dut_if1_mac}  ${tg_to_dut_if2}  ${dut_to_tg_if1_mac}  UDP  ${src_port}  ${dst_port}
  And Send TCP Or UDP Packet  ${tg_node}  ${classify_src}  ${classify_dst}  ${tg_to_dut_if1}  ${tg_to_dut_if1_mac}  ${tg_to_dut_if2}  ${dut_to_tg_if1_mac}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${classify_src}  ${classify_dst}  ${tg_to_dut_if1}  ${tg_to_dut_if1_mac}  ${tg_to_dut_if2}  ${dut_to_tg_if1_mac}  UDP  ${src_port}  ${dst_port}

TC05: L4 ACL port filtering through IETF-ACL node

[Top] TG=DUT1=TG. [Enc] Eth-IPv4-TCP. [Cfg] (Using Honeycomb API) On DUT1 set IPv4 addresses on bothinterfaces to TG, add ARP entry and routes, and configure L4 port ACLon ingress interface with src/dst port ranges. [Ver] Send simple TCP and UDP packets from one TG interfaceto the other, using different ports. Receive all packets exceptthose with ports in the filtered ranges.


Given Setup Interface IPs And Routes For IPv4 IETF-ACL Test  L4  ${acl_name_l4}
 When Honeycomb Creates ACL Chain Through IETF Node  ${dut_node}  ${acl_name_l4}  mixed  ${acl_settings}
  And Honeycomb Assigns IETF-ACL Chain To Interface  ${dut_node}  ${dut_to_tg_if1}  mixed  ingress  ${acl_name_l4}  permit  L3
 Then Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${tg_to_dut_if1_mac}  ${tg_to_dut_if2}  ${dut_to_tg_if1_mac}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${tg_to_dut_if1_mac}  ${tg_to_dut_if2}  ${dut_to_tg_if1_mac}  TCP  ${classify_src}  ${classify_dst}

TC06: L2,L3 and L4 ACL together on L2-mode interface

[Top] TG=DUT1=TG. [Enc] Eth-IPv4-TCP. [Cfg] (Using Honeycomb API) On DUT1 bridge both interfaces to TGand configure L2, L3 and L4 ACL on ingress interfacewith src/dst MAC, src/dst IP, protocol and src/dst port ranges. [Ver] Send simple TCP and UDP packets from one TG interfaceto the other, using different MACs, IPv4 IPs and ports. Receiveall packets except those with MACs, IPs and ports in the filteredranges and UDP protocol payload.


Given Setup Interfaces And Bridge Domain For IETF-ACL Test  mixed  ${acl_name_mixed}
 When Honeycomb Creates ACL Chain Through IETF Node  ${dut_node}  ${acl_name_mixed}  mixed  ${acl_settings}
  And Honeycomb Assigns IETF-ACL Chain To Interface  ${dut_node}  ${dut_to_tg_if1}  mixed  ingress  ${acl_name_mixed}  permit  L2
 Then Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${classify_src_mac}  ${tg_to_dut_if2}  ${classify_dst_mac}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${classify_src_ip}  ${classify_dst_ip}  ${tg_to_dut_if1}  ${classify_src_mac}  ${tg_to_dut_if2}  ${classify_dst_mac}  UDP  ${classify_src_port}  ${classify_dst_port}

TC07: L2,L3 and L4 ACL together on L3-mode interface

[Top] TG=DUT1=TG. [Enc] Eth-IPv4-TCP. [Cfg] (Using Honeycomb API) On DUT1 set IPv4 addresses on bothinterfaces to TG, add ARP entry and routes, and configureL2, L3 and L4 ACL on ingress interface with src/dst MAC, src/dst IP,protocol and src/dst port ranges. [Ver] Send simple TCP and UDP packets from one TG interfaceto the other, using different MACs, IPv4 IPs and ports. Receiveall packets except those with MACs, IPs and ports in the filteredranges and UDP protocol payload.


Setup Interface IPs And Routes For IPv4 IETF-ACL Test  mixed  ${acl_name_mixed}
 When Honeycomb Creates ACL Chain Through IETF Node  ${dut_node}  ${acl_name_mixed}  mixed  ${acl_settings}
  And Honeycomb Assigns IETF-ACL Chain To Interface  ${dut_node}  ${dut_to_tg_if1}  mixed  ingress  ${acl_name_mixed}  permit  L3
 Then Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${classify_src_mac}  ${tg_to_dut_if2}  ${classify_dst_mac}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${classify_src_ip}  ${classify_dst_ip}  ${tg_to_dut_if1}  ${classify_src_mac}  ${tg_to_dut_if2}  ${classify_dst_mac}  UDP  ${classify_src_port}  ${classify_dst_port}

TC08: Multiple classify rules in one ACL

[Top] TG=DUT1=TG. [Enc] Eth-IPv4-TCP. [Cfg] (Using Honeycomb API) On DUT1 bridge both interfaces to TGand configure a series of L2 MAC ACL rules on ingress interface. [Ver] Send simple TCP packets from one TG interface to the other,using different MACs. Receive all packets except those withMACs in the ranges filtered by any rule.


Given Setup Interfaces And Bridge Domain For IETF-ACL Test  multirule  ${acl_name_multirule}
 When Honeycomb Creates ACL Chain Through IETF Node  ${dut_node}  ${acl_name_multirule}  L2  ${acl_settings}
  And Honeycomb Assigns IETF-ACL Chain To Interface  ${dut_node}  ${dut_to_tg_if1}  L2  ingress  ${acl_name_multirule}  permit
 Then Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${src_mac}  ${tg_to_dut_if2}  ${dst_mac}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${classify_src}  ${tg_to_dut_if2}  ${classify_dst}  TCP  ${src_port}  ${dst_port}
  And Run Keyword And Expect Error  TCP/UDP Rx timeout  Send TCP Or UDP Packet  ${tg_node}  ${src_ip}  ${dst_ip}  ${tg_to_dut_if1}  ${classify_src2}  ${tg_to_dut_if2}  ${classify_dst2}  TCP  ${src_port}  ${dst_port}

Setup interface IPs and routes for IPv4 ietf-ACL test


Path for 2-node testing is set  ${nodes['TG']}  ${nodes['DUT1']}  ${nodes['TG']}
Import Variables  resources/test_data/honeycomb/ietf_acl.py  ${test_data_id}  ${acl_name}
Honeycomb sets interface state  ${dut_node}  ${dut_to_tg_if1}  up
Honeycomb sets interface state  ${dut_node}  ${dut_to_tg_if2}  up
Honeycomb sets interface ipv4 address with prefix  ${dut_node}  ${dut_to_tg_if1}  ${dut_to_tg_if1_ip}  ${prefix_length}
Honeycomb sets interface ipv4 address with prefix  ${dut_node}  ${dut_to_tg_if2}  ${dut_to_tg_if2_ip}  ${prefix_length}
Add ARP on DUT  ${node}  ${dut_to_tg_if2}  ${gateway}  ${tg_to_dut_if2_mac}
VPP Route Add  ${node}  ${dst_net}  ${prefix_length}  ${gateway}  interface=${dut_to_tg_if2}  use_sw_index=False
VPP Route Add  ${node}  ${classify_dst_net}  ${prefix_length}  ${gateway}  interface=${dut_to_tg_if2}  use_sw_index=False

Setup interfaces and bridge domain for ietf-ACL test


Path For 2-node Testing Is Set  ${nodes['TG']}  ${nodes['DUT1']}  ${nodes['TG']}
Import Variables  resources/test_data/honeycomb/ietf_acl.py  ${test_data_id}  ${acl_name}
Honeycomb Sets Interface State  ${dut_node}  ${dut_to_tg_if1}  up
Honeycomb Sets Interface State  ${dut_node}  ${dut_to_tg_if2}  up
Honeycomb Creates first L2 Bridge Domain  ${dut_node}  ${bd_name}  ${bd_settings}
Honeycomb Adds Interfaces To Bridge Domain  ${dut_node}  ${dut_to_tg_if1}  ${dut_to_tg_if2}  ${bd_name}  ${bd_if_settings}

mgmt-cfg-int-apihcnc-func module

TC01: Honeycomb can create and delete interfaces

Repeatedly create and delete an interface through Netconfand check the reply for any errors.


Given Netconf session is established  ${node}
  And Honeycomb creates first L2 bridge domain  ${node}  bd_netconf  ${bd_settings}
: FOR  ${index}  IN RANGE  20
 \    When Error trigger is sent  ${trigger_105}
 \    Then Replies should not contain RPC errors

TC02: Transaction revert test case 1

Configure two conflicting VxLAN tunnels, then verifythat neither tunnel exists.


Given Netconf session is established  ${node}
${if_data}=  And InterfaceAPI.Get all interfaces oper data  ${node}
 When Error trigger is sent  ${trigger_revert1}
${if_data_new}=  And InterfaceAPI.Get all interfaces oper data  ${node}
 Then Should be equal  ${if_data}  ${if_data_new}

TC03: Transaction revert test case 2

Configure two conflicting TAP interfaces, then verifythat neither interface exists.


Given Netconf session is established  ${node}
${if_data}=  And InterfaceAPI.Get all interfaces oper data  ${node}
 When Error trigger is sent  ${trigger_revert1}
${if_data_new}=  And InterfaceAPI.Get all interfaces oper data  ${node}
 Then Should be equal  ${if_data}  ${if_data_new}

mgmt-cfg-int-subint-apihc-apivat-func module

TC01: Honycomb creates sub-interface

Check if Honeycomb creates a sub-interface.


Given Honeycomb sets interface state  ${node}  ${super_if}  down
  And sub-interface configuration from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
  And interface configuration from VAT should be empty  ${node}  ${sub_if_name}
 When Honeycomb creates sub-interface  ${node}  ${super_if}  ${sub_if_1_match}  ${sub_if_1_tags}  ${sub_if_1_settings}
 Then Sub-interface configuration from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${sub_if_1_oper}
  And Sub-interface configuration from VAT should be  ${node}  ${sub_if_name}  ${sub_if_1_oper}
  And sub-interface indices from Honeycomb and VAT should correspond  ${node}  ${super_if}  ${sub_if_id}

TC02: Honeycomb sets interface and sub-interface up

Honeycomb changes the state of interfaceand of its sub-interface to up.


Given interface state from Honeycomb should be  ${node}  ${super_if}  down
  And interface state from VAT should be  ${node}  ${super_if}  down
Sub-interface state from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  down  down
Sub-interface state from VAT should be  ${node}  ${sub_if_name}  down  down
 When Honeycomb sets interface state  ${node}  ${super_if}  up
 Then interface state from Honeycomb should be  ${node}  ${super_if}  up
  And interface state from VAT should be  ${node}  ${super_if}  up
 When Honeycomb sets the sub-interface up  ${node}  ${super_if}  ${sub_if_id}
 Then Sub-interface state from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  up  up
  And sub-interface state from VAT should be  ${node}  ${sub_if_name}  up  up

TC03: Honeycomb sets sub-interface down while its super-interface is up

Honeycomb sets the sub-interface down while its super-interface is up. It must be possible.


Given sub-interface state from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  up  up
  And sub-interface state from VAT should be  ${node}  ${sub_if_name}  up  up
  And interface state from Honeycomb should be  ${node}  ${super_if}  up
  And interface state from VAT should be  ${node}  ${super_if}  up
 When Honeycomb sets the sub-interface down  ${node}  ${super_if}  ${sub_if_id}
 Then interface state from Honeycomb should be  ${node}  ${super_if}  up
  And interface state from VAT should be  ${node}  ${super_if}  up
  And sub-interface state from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  down  up
  And sub-interface state from VAT should be  ${node}  ${sub_if_name}  down  up

TC04: Honeycomb sets interface and sub-interface down

Honeycomb changes the state of interface down and then changes the state of its sub-interface down, in this order.


Given interface state from Honeycomb should be  ${node}  ${super_if}  up
  And interface state from VAT should be  ${node}  ${super_if}  up
 When Honeycomb sets interface state  ${node}  ${super_if}  down
 Then interface state from Honeycomb should be  ${node}  ${super_if}  down
  And interface state from VAT should be  ${node}  ${super_if}  down
Given sub-interface state from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  up  down
  And sub-interface state from VAT should be  ${node}  ${sub_if_name}  up  down
 When Honeycomb sets the sub-interface down  ${node}  ${super_if}  ${sub_if_id}
 Then sub-interface state from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  down  down
  And sub-interface state from VAT should be  ${node}  ${sub_if_name}  down  down

TC05: Honeycomb fails to set sub-interface up while its super-interface is down

Honeycomb tries to set the sub-interface up while its super-interface is down. It must not be possible.


Given interface state from Honeycomb should be  ${node}  ${super_if}  down
  And interface state from VAT should be  ${node}  ${super_if}  down
  And sub-interface state from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  down  down
  And sub-interface state from VAT should be  ${node}  ${sub_if_name}  down  down
 When Honeycomb fails to set sub-interface up  ${node}  ${super_if}  ${sub_if_id}
 Then interface state from Honeycomb should be  ${node}  ${super_if}  down
  And interface state from VAT should be  ${node}  ${super_if}  down
  And sub-interface state from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  down  down
  And sub-interface state from VAT should be  ${node}  ${sub_if_name}  down  down

TC06: Honeycomb fails to delete sub-interface

Check if Honeycomb can delete an existing sub-interface.


Given sub-interface configuration from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${sub_if_1_oper}
  And sub-interface configuration from VAT should be  ${node}  ${sub_if_name}  ${sub_if_1_oper}
 When Honeycomb fails to remove all sub-interfaces  ${node}  ${super_if}
 Then sub-interface configuration from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${sub_if_1_oper}
  And sub-interface configuration from VAT should be  ${node}  ${sub_if_name}  ${sub_if_1_oper}

TC07: Honeycomb adds sub-interface to new bridge domain

Check if Honeycomb adds a sub-interface to bridge domain.


Given sub-interface configuration from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${sub_if_1_oper}
  And sub-interface configuration from VAT should be  ${node}  ${sub_if_name}  ${sub_if_1_oper}
 When Honeycomb creates first L2 bridge domain  ${node}  ${bd_name}  ${bd_settings}
 Then bridge domain configuration from Honeycomb should be  ${node}  ${bd_name}  ${bd_settings}
 When Honeycomb adds sub-interface to bridge domain  ${node}  ${super_if}  ${sub_if_id}  ${sub_bd_settings}
 Then sub-interface bridge domain configuration from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${sub_bd_settings}
  And sub-interface bridge domain configuration from VAT should be  ${node}  ${sub_if_name}  ${sub_bd_settings}
  And sub-interface configuration from VAT should be  ${node}  ${sub_if_name}  ${sub_if_1_oper}

TC08: Honeycomb enables tag-rewrite pop 1

Check if Honeycomb enables tag-rewrite and sets its parameters correctly. Case: pop 1.


Given rewrite tag from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_pop_1}
 Then rewrite tag from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_pop_1_oper}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_pop_1_VAT}

TC09: Honeycomb enables tag-rewrite push

Check if Honeycomb enables tag-rewrite and sets its parameters correctly. Case: push.


Given rewrite tag from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_push}
 Then rewrite tag from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_push_oper}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_push_VAT}

TC10: Honeycomb enables tag-rewrite translate 1-2

Check if Honeycomb enables tag-rewrite and sets its parameters correctly. Case: translate 1-2.


Given rewrite tag from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_translate_1_2}
 Then rewrite tag from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_translate_1_2_oper}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_translate_1_2_VAT}

TC11: Honeycomb disables tag-rewrite

Check if Honeycomb disables the tag-rewrite.


 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_pop_1}
 Then rewrite tag from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_pop_1_oper}
 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_disabled}
 Then rewrite tag from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_disabled_VAT}

TC12: Honeycomb enables tag-rewrite pop 1 again

Check if Honeycomb can enable tag-rewrite again, once it was disabled by Honeycomb.


Given rewrite tag from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_pop_1}
 Then rewrite tag from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_pop_1_oper}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_pop_1_VAT}

TC13: Honeycomb modifies the tag-rewrite

Honeycomb sets the tag-rewrite: 1. pop 1, then 2. push, then 3. translate 1 - 2 Then Honeycomb disables the tag-rewrite.


Given rewrite tag from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_pop_1}
 Then rewrite tag from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_pop_1_oper}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_pop_1_VAT}
 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_push}
 Then rewrite tag from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_push_oper}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_push_VAT}
 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_translate_1_2}
 Then rewrite tag from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_translate_1_2_oper}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_translate_1_2_VAT}
 When Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_disabled}
 Then rewrite tag from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_disabled_VAT}

TC14: Honeycomb fails to set wrong vlan-type in tag-rewrite

Check that Honeycomb does not accept wrong values of vlan-type in tag-rewrite.


Given rewrite tag from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
 When Honeycomb fails to set wrong rewrite tag  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_translate_1_2_wrong}
 Then rewrite tag from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
  And rewrite tag from VAT should be  ${node}  ${sub_if_name}  ${tag_rewrite_disabled_VAT}

TC15: Honeycomb configures sub-interface ipv4 address

Check if Honeycomb can configure an ipv4 address on thesub-interface.


Given sub-interface ipv4 address from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
  And sub-interface ipv4 address from VAT should be empty  ${node}  ${sub_if_name}
 When Honeycomb sets sub-interface ipv4 address  ${node}  ${super_if}  ${sub_if_id}  ${ipv4['address']}  ${ipv4['prefix-length']}
 Then sub-interface ipv4 address from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${ipv4['address']}  ${ipv4['prefix-length']}
  And sub-interface ipv4 address from VAT should be  ${node}  ${sub_if_name}  ${ipv4['address']}  ${ipv4['prefix-length']}

TC16: Honeycomb removes sub-interface ipv4 address

Check if Honeycomb can remove configured ipv4 addressesfrom the sub-interface.


Given sub-interface ipv4 address from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${ipv4['address']}  ${ipv4['prefix-length']}
Run Keyword And Continue On Failure  And sub-interface ipv4 address from VAT should be  ${node}  ${sub_if_name}  ${ipv4['address']}  ${ipv4['prefix-length']}
 When Honeycomb removes all sub-interface ipv4 addresses  ${node}  ${super_if}  ${sub_if_id}
 Then sub-interface ipv4 address from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
  And sub-interface ipv4 address from VAT should be empty  ${node}  ${sub_if_name}

TC17: Honeycomb modifies existing sub-interface ipv4 address

Check if Honeycomb can modify an ipv4 address alreadyconfigured on the sub-interface.


Given sub-interface ipv4 address from Honeycomb should be empty  ${node}  ${super_if}  ${sub_if_id}
  And sub-interface ipv4 address from VAT should be empty  ${node}  ${sub_if_name}
 When Honeycomb sets sub-interface ipv4 address  ${node}  ${super_if}  ${sub_if_id}  ${ipv4['address']}  ${ipv4['prefix-length']}
  And Honeycomb sets sub-interface ipv4 address  ${node}  ${super_if}  ${sub_if_id}  ${ipv4_2['address']}  ${ipv4_2['prefix-length']}
 Then sub-interface ipv4 address from Honeycomb should be  ${node}  ${super_if}  ${sub_if_id}  ${ipv4_2['address']}  ${ipv4_2['prefix-length']}
  And sub-interface ipv4 address from VAT should be  ${node}  ${sub_if_name}  ${ipv4_2['address']}  ${ipv4_2['prefix-length']}

Set super and sub interfaces up

Honeycomb sets super-interface and sub-interface up, in this order.

Arguments: - node - Information about a DUT node. Type: dictionary - super_interface - Super interface. Type: string - identifier - Sub-interface identifier. Type: integer or string

Example: | Set super and sub interfaces up| ${nodes[‘DUT1’]} | GigabitEthernet0/8/0 | 1 |


Honeycomb sets interface state  ${node}  ${super_interface}  up
Honeycomb sets the sub-interface up  ${node}  ${super_interface}  ${identifier}

Set super and sub interfaces down

Honeycomb sets super-interface and sub-interface down, inthis order.

Arguments: - node - Information about a DUT node. Type: dictionary - super_interface - Super interface. Type: string - identifier - Sub-interface identifier. Type: integer or string

Example: | Set super and sub interfaces down| ${nodes[‘DUT1’]} | GigabitEthernet0/8/0 | 1 |


Honeycomb sets interface state  ${node}  ${super_interface}  down
Honeycomb sets the sub-interface down  ${node}  ${super_interface}  ${identifier}

Honeycomb disables tag rewrite

Arguments: - node - Information about a DUT node. Type: dictionary - super_if - Super-interface. Type: string - identifier - Sub-interface ID. Type: integer or string

Example: | Honeycomb disables tag rewrite | ${nodes[‘DUT1’]} | GigabitEthernet0/8/0 | 1 |


Honeycomb configures tag rewrite  ${node}  ${super_if}  ${sub_if_id}  ${tag_rewrite_disabled}

mgmt-cfg-intip4-intip6-apihc-apivat-func module

TC01: Honeycomb configures and reads interface state

Check if Honeycomb API can modify the admin state ofVPP interfaces.


Given Interface state from Honeycomb should be  ${node}  ${interface}  down
  And Interface state from VAT should be  ${node}  ${interface}  down
 When Honeycomb sets interface state  ${node}  ${interface}  up
 Then Interface state from Honeycomb should be  ${node}  ${interface}  up
  And Interface state from VAT should be  ${node}  ${interface}  up
 When Honeycomb sets interface state  ${node}  ${interface}  down
 Then Interface state from Honeycomb should be  ${node}  ${interface}  down
  And Interface state from VAT should be  ${node}  ${interface}  down

TC02: Honeycomb modifies interface IPv4 address with netmask

Check if Honeycomb API can configure interfaces for ipv4with address and netmask provided.


Given IPv4 address from Honeycomb should be empty  ${node}  ${interface}
  And ipv4 address from VAT should be empty  ${node}  ${interface}
 When Honeycomb sets interface ipv4 address  ${node}  ${interface}  ${ipv4_address}  ${ipv4_mask}
 Then IPv4 address from Honeycomb should be  ${node}  ${interface}  ${ipv4_address}  ${ipv4_prefix}
  And IPv4 address from VAT should be  ${node}  ${interface}  ${ipv4_address}  ${ipv4_mask}

TC03: Honeycomb removes IPv4 address from interface

Check if Honeycomb API can remove configured ipv4addresses from interface.


Given IPv4 address from Honeycomb should be  ${node}  ${interface}  ${ipv4_address}  ${ipv4_prefix}
  And IPv4 address from VAT should be  ${node}  ${interface}  ${ipv4_address}  ${ipv4_mask}
 When Honeycomb removes interface ipv4 addresses  ${node}  ${interface}
 Then IPv4 address from Honeycomb should be empty  ${node}  ${interface}
  And ipv4 address from VAT should be empty  ${node}  ${interface}

TC04: Honeycomb modifies interface IPv4 address with prefix

Check if Honeycomb API can configure interfaces for ipv4with address and prefix provided.


Given IPv4 address from Honeycomb should be empty  ${node}  ${interface}
  And ipv4 address from VAT should be empty  ${node}  ${interface}
 When Honeycomb sets interface ipv4 address with prefix  ${node}  ${interface}  ${ipv4_address2}  ${ipv4_prefix}
 Then IPv4 address from Honeycomb should be  ${node}  ${interface}  ${ipv4_address2}  ${ipv4_prefix}
  And IPv4 address from VAT should be  ${node}  ${interface}  ${ipv4_address2}  ${ipv4_mask}

TC05: Honeycomb modifies IPv4 neighbor table

Check if Honeycomb API can add and remove ARP entries.


 When Honeycomb adds interface ipv4 neighbor  ${node}  ${interface}  @{ipv4_neighbor}
 Then IPv4 neighbor from Honeycomb should be  ${node}  ${interface}  @{ipv4_neighbor}

TC06: Honeycomb modifies interface configuration - IPv6

Check if Honeycomb API can configure interfaces for ipv6.


 When Honeycomb sets interface ipv6 address  ${node}  ${interface}  @{ipv6_address}
 Then IPv6 address from Honeycomb should be  ${node}  ${interface}  @{ipv6_address}
  And IPv6 address from VAT should be  ${node}  ${interface}  @{ipv6_address}

TC07: Honeycomb modifies interface configuration - MTU

Check if Honeycomb API can configure interfaceMTU value.


 When Honeycomb sets interface ethernet configuration  ${node}  ${interface}  ${ethernet}
 Then Interface ethernet configuration from Honeycomb should be  ${node}  ${interface}  ${ethernet}
  And Interface ethernet configuration from VAT should be  ${node}  ${interface}  ${ethernet['mtu']}

mgmt-cfg-inttap-apihc-apivat-func module

TC01: Honeycomb configures TAP interface

Check if Honeycomb API can configure a TAP interface.


Given TAP configuration from Honeycomb should be empty  ${node}  ${tap_interface}
  And TAP configuration from VAT should be empty  ${node}  ${tap_interface}
 When Honeycomb creates TAP interface  ${node}  ${tap_interface}  ${tap_settings}
 Then TAP configuration from Honeycomb should be  ${node}  ${tap_interface}  ${tap_settings}
  And TAP configuration from VAT should be  ${node}  ${tap_interface}  ${tap_settings}

TC02: Honeycomb modifies existing TAP interface configuration

Check if Honeycomb API can re-configure and existing TAPinterface with new settings.


Given TAP configuration from Honeycomb should be  ${node}  ${tap_interface}  ${tap_settings}
  And TAP configuration from VAT should be  ${node}  ${tap_interface}  ${tap_settings}
 When Honeycomb configures TAP interface  ${node}  ${tap_interface}  ${tap_settings2}
 Then TAP configuration from Honeycomb should be  ${node}  ${tap_interface}  ${tap_settings2}
  And TAP configuration from VAT should be  ${node}  ${tap_interface}  ${tap_settings2}

TC03: Honeycomb removes TAP interface

Check if Honeycomb API can remove TAP interface.


Given TAP configuration from Honeycomb should be  ${node}  ${tap_interface}  ${tap_settings2}
  And TAP configuration from VAT should be  ${node}  ${tap_interface}  ${tap_settings2}
 When Honeycomb removes TAP interface  ${node}  ${tap_interface}
 Then TAP configuration from Honeycomb should be empty  ${node}  ${tap_interface}
  And TAP configuration from VAT should be empty  ${node}  ${tap_interface}

mgmt-cfg-intvhost-apihc-apivat-func module

TC01: Honeycomb creates vhost-user interface - server

Check if Honeycomb creates a vhost-user interface, role:server.


Given vhost-user configuration from Honeycomb should be empty  ${node}  ${vhost_interface}
 When Honeycomb creates vhost-user interface  ${node}  ${vhost_interface}  ${vhost_user_server}
 Then vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_server}
  And vhost-user configuration from VAT should be  ${node}  ${vhost_user_server}

TC02: Honeycomb modifies vhost-user interface - server

Check if Honeycomb can modify properties of existingvhost-user interface, role: server.


Given vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_server}
 When Honeycomb configures vhost-user interface  ${node}  ${vhost_interface}  ${vhost_user_server_edit_1}
 Then vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_server_edit_1}
  And vhost-user configuration from VAT should be  ${node}  ${vhost_user_server_edit_1}
 When Honeycomb configures vhost-user interface  ${node}  ${vhost_interface}  ${vhost_user_server_edit_2}
 Then vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_server_edit_2}
  And vhost-user configuration from VAT should be  ${node}  ${vhost_user_server_edit_2}
 When Honeycomb configures vhost-user interface  ${node}  ${vhost_interface}  ${vhost_user_server}
 Then vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_server}
  And vhost-user configuration from VAT should be  ${node}  ${vhost_user_server}

TC03: Honeycomb deletes vhost-user interface - server

Check if Honeycomb can delete an existing vhost-userinterface, role: server.


Given vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_server}
 When Honeycomb removes vhost-user interface  ${node}  ${vhost_interface}
 Then vhost-user configuration from Honeycomb should be empty  ${node}  ${vhost_interface}
  And vhost-user configuration from VAT should be empty  ${node}

TC04: Honeycomb creates vhost-user interface - client

Check if Honeycomb creates a vhost-user interface, role:client.


Given vhost-user configuration from Honeycomb should be empty  ${node}  ${vhost_interface}
 When Honeycomb creates vhost-user interface  ${node}  ${vhost_interface}  ${vhost_user_client}
 Then vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_client}
  And vhost-user configuration from VAT should be  ${node}  ${vhost_user_client}

TC05: Honeycomb modifies vhost-user interface - client

Check if Honeycomb can modify properties of existingvhost-user interface, role: client.


Given vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_client}
 When Honeycomb configures vhost-user interface  ${node}  ${vhost_interface}  ${vhost_user_client_edit_1}
 Then vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_client_edit_1}
  And vhost-user configuration from VAT should be  ${node}  ${vhost_user_client_edit_1}
 When Honeycomb configures vhost-user interface  ${node}  ${vhost_interface}  ${vhost_user_client_edit_2}
 Then vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_client_edit_2}
  And vhost-user configuration from VAT should be  ${node}  ${vhost_user_client_edit_2}
 When Honeycomb configures vhost-user interface  ${node}  ${vhost_interface}  ${vhost_user_client}
 Then vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_client}
  And vhost-user configuration from VAT should be  ${node}  ${vhost_user_client}

TC06: Honeycomb deletes vhost-user interface - client

Check if Honeycomb can delete an existing vhost-userinterface, role: client.


Given vhost-user configuration from Honeycomb should be  ${node}  ${vhost_interface}  ${vhost_user_client}
 When Honeycomb removes vhost-user interface  ${node}  ${vhost_interface}
 Then vhost-user configuration from Honeycomb should be empty  ${node}  ${vhost_interface}
  And vhost-user configuration from VAT should be empty  ${node}

TC07: Honeycomb does not set vhost-user configuration on another interface type

Check if Honeycomb refuses to set vhost-userconfiguration for interface which is not v3po:vhost-user type.


 When Honeycomb fails setting vhost-user on different interface type  ${node}  ${interface}  ${vhost_user_server}
 Then vhost-user configuration from Honeycomb should be empty  ${node}  ${interface}
  And vhost-user configuration from VAT should be empty  ${node}

TC08: Honeycomb does not set invalid vhost-user configuration

Check if Honeycomb refuses to set invalid parameters tovhost-user interface.


Given vhost-user configuration from Honeycomb should be empty  ${node}  ${vhost_interface}
 When Honeycomb fails setting invalid vhost-user configuration  ${node}  ${vhost_interface}  ${vhost_user_wrong}
 Then vhost-user configuration from Honeycomb should be empty  ${node}  ${vhost_interface}
  And vhost-user configuration from VAT should be empty  ${node}

mgmt-cfg-l2bd-apihc-apivat-func module

TC01: Honeycomb sets up l2 bridge domain

Check if Honeycomb can create bridge domains on VPP node.


 When Honeycomb creates first l2 bridge domain  ${node}  ${bd1_name}  ${bd_settings}
 Then Bridge domain configuration from Honeycomb should be  ${node}  ${bd1_name}  ${bd_settings}
  And Bridge domain configuration from VAT should be  ${node}  ${0}  ${bd_settings}

TC02: Honeycomb manages multiple bridge domains on node

Check if Honeycomb can manage multiple bridge domains ona single node.


Given Bridge domain configuration from Honeycomb should be  ${node}  ${bd1_name}  ${bd_settings}
 When Honeycomb creates l2 bridge domain  ${node}  ${bd2_name}  ${bd_settings}
 Then Bridge domain configuration from Honeycomb should be  ${node}  ${bd1_name}  ${bd_settings}
  And Bridge domain configuration from Honeycomb should be  ${node}  ${bd2_name}  ${bd_settings}
  And Bridge domain configuration from VAT should be  ${node}  ${0}  ${bd_settings}
  And Bridge domain configuration from VAT should be  ${node}  ${1}  ${bd_settings}

TC03: Honeycomb removes bridge domains

Check if Honeycomb can remove bridge domains from a VPPnode.


Given Bridge domain configuration from Honeycomb should be  ${node}  ${bd1_name}  ${bd_settings}
 When Honeycomb removes all bridge domains  ${node}
 Then Honeycomb should show no bridge domains  ${node}
  And VAT should show no bridge domains  ${node}

TC04: Honeycomb assigns interfaces to bridge domain

Check if Honeycomb can assign VPP interfaces to anexisting bridge domain.


Given Honeycomb creates first l2 bridge domain  ${node}  ${bd1_name}  ${bd_settings}
 When Honeycomb adds interfaces to bridge domain  ${node}  @{interfaces}  ${bd1_name}  ${if_settings}
 Then Bridge domain configuration from Honeycomb should be  ${node}  ${bd1_name}  ${bd_settings}
  And Bridge domain configuration from VAT should be  ${node}  ${0}  ${bd_settings}
  And Honeycomb should show interfaces assigned to bridge domain  ${node}  @{interfaces}  ${bd1_name}  ${if_settings}
  And VAT should show interfaces assigned to bridge domain  ${node}  ${0}  @{interfaces}  ${if_settings}

TC05: Honeycomb cannot remove bridge domain with an interface assigned

Check if Honeycomb can remove a bridge domain that has aninterface assigned to it. Expect to fail with code 500.


Given Bridge domain configuration from Honeycomb should be  ${node}  ${bd1_name}  ${bd_settings}
  And Bridge domain configuration from VAT should be  ${node}  ${0}  ${bd_settings}
  And Honeycomb should show interfaces assigned to bridge domain  ${node}  @{interfaces}  ${bd1_name}  ${if_settings}
  And VAT should show interfaces assigned to bridge domain  ${node}  ${0}  @{interfaces}  ${if_settings}
 When Run keyword and expect error  HoneycombError* Status code: 500.  Honeycomb removes all bridge domains  ${node}
 Then Bridge domain configuration from Honeycomb should be  ${node}  ${bd1_name}  ${bd_settings}
  And Bridge domain configuration from VAT should be  ${node}  ${0}  ${bd_settings}
  And Honeycomb should show interfaces assigned to bridge domain  ${node}  @{interfaces}  ${bd1_name}  ${if_settings}
  And VAT should show interfaces assigned to bridge domain  ${node}  ${0}  @{interfaces}  ${if_settings}

mgmt-cfg-l2fib-apihc-apivat-func module

TC01: Honeycomb adds L2 FIB entry (forward)

Honeycomb creates a bridge domain and assignes an interface to it. Then adds an L2 FIB entry (forward) to the bridge domain.


Given Interface state from Honeycomb should be  ${node}  ${interface}  down
 When Honeycomb sets interface state  ${node}  ${interface}  up
 Then Interface state from Honeycomb should be  ${node}  ${interface}  up
 When Honeycomb creates first l2 bridge domain  ${node}  ${bd_name}  ${bd_settings}
 Then Bridge domain configuration from Honeycomb should be  ${node}  ${bd_name}  ${bd_settings}
Given Bridge domain configuration in interface operational data should be empty  ${node}  ${interface}
 When Honeycomb adds interface to bridge domain  ${node}  ${interface}  ${bd_name}  ${if_bd_settings}
 Then Bridge domain configuration in interface operational data should be  ${node}  ${interface}  ${if_bd_settings}
Given L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}
 When Honeycomb adds L2 FIB entry to bridge domain  ${node}  ${bd_name}  ${l2_fib_forward_cfg}
 Then L2 FIB Entry from Honeycomb should be  ${node}  ${bd_name}  ${l2_fib_forward_oper}
  And L2 FIB entry from VAT should be  ${node}  ${bd_index}  ${l2_fib_forward_vat}

TC02: Honeycomb adds L2 FIB entry (static, forward)

Honeycomb adds an L2 FIB entry (static, forward) to the bridge domain.


Given Bridge domain configuration in interface operational data should be  ${node}  ${interface}  ${if_bd_settings}
  And L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}
 When Honeycomb adds L2 FIB entry to bridge domain  ${node}  ${bd_name}  ${l2_fib_static_forward_cfg}
 Then L2 FIB Entry from Honeycomb should be  ${node}  ${bd_name}  ${l2_fib_static_forward_oper}
  And L2 FIB entry from VAT should be  ${node}  ${bd_index}  ${l2_fib_static_forward_vat}

TC03: Honeycomb adds L2 FIB entry (static, filter)

Honeycomb adds an L2 FIB entry (static, filter) to the bridge domain.


Given Bridge domain configuration in interface operational data should be  ${node}  ${interface}  ${if_bd_settings}
  And L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}
 When Honeycomb adds L2 FIB entry to bridge domain  ${node}  ${bd_name}  ${l2_fib_filter_cfg}
 Then L2 FIB Entry from Honeycomb should be  ${node}  ${bd_name}  ${l2_fib_filter_oper}
  And L2 FIB entry from VAT should be  ${node}  ${bd_index}  ${l2_fib_filter_vat}

TC04: Honeycomb adds and removes L2 FIB entry (forward)

Honeycomb adds an L2 FIB entry (forward) to the bridge domain and then Honeycomb removes it from the bridge domain.


Given Bridge domain configuration in interface operational data should be  ${node}  ${interface}  ${if_bd_settings}
  And L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}
 When Honeycomb adds L2 FIB entry to bridge domain  ${node}  ${bd_name}  ${l2_fib_forward_cfg}
 Then L2 FIB Entry from Honeycomb should be  ${node}  ${bd_name}  ${l2_fib_forward_oper}
  And L2 FIB entry from VAT should be  ${node}  ${bd_index}  ${l2_fib_forward_vat}
 When Honeycomb removes L2 FIB entry  ${node}  ${bd_name}  ${l2_fib_forward_oper['phys-address']}
 Then L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}

TC05: Honeycomb adds more than one L2 FIB entry

Honeycomb adds three L2 FIB entries to the bridge domain.


Given Bridge domain configuration in interface operational data should be  ${node}  ${interface}  ${if_bd_settings}
  And L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}
 When Honeycomb adds L2 FIB entry to bridge domain  ${node}  ${bd_name}  ${l2_fib_forward_cfg}
  And Honeycomb adds L2 FIB entry to bridge domain  ${node}  ${bd_name}  ${l2_fib_static_forward_cfg}
  And Honeycomb adds L2 FIB entry to bridge domain  ${node}  ${bd_name}  ${l2_fib_filter_cfg}
 Then L2 FIB Entry from Honeycomb should be  ${node}  ${bd_name}  ${l2_fib_forward_oper}
  And L2 FIB Entry from Honeycomb should be  ${node}  ${bd_name}  ${l2_fib_static_forward_oper}
  And L2 FIB Entry from Honeycomb should be  ${node}  ${bd_name}  ${l2_fib_filter_oper}
  And L2 FIB entry from VAT should be  ${node}  ${bd_index}  ${l2_fib_forward_vat}
  And L2 FIB entry from VAT should be  ${node}  ${bd_index}  ${l2_fib_static_forward_vat}
  And L2 FIB entry from VAT should be  ${node}  ${bd_index}  ${l2_fib_filter_vat}

TC06: Honeycomb fails to set wrong L2 FIB entry

Honeycomb tries to add an L2 FIB entry with wrong parameters to the bridge domain. It must fail.


Given Bridge domain configuration in interface operational data should be  ${node}  ${interface}  ${if_bd_settings}
  And L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}
 When Honeycomb fails to add wrong L2 FIB entry  ${node}  ${bd_name}  ${l2_fib_forward_cfg_wrong_mac}
 Then L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}
 When Honeycomb fails to add wrong L2 FIB entry  ${node}  ${bd_name}  ${l2_fib_forward_cfg_wrong_if}
 Then L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}
 When Honeycomb fails to add wrong L2 FIB entry  ${node}  ${bd_name}  ${l2_fib_forward_cfg_wrong_action}
 Then L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}

TC07: Honeycomb fails to modify existing L2 FIB entry

Honeycomb tries to modify an existing L2 FIB entry. It must fail.


Given Bridge domain configuration in interface operational data should be  ${node}  ${interface}  ${if_bd_settings}
  And L2 FIB Table from Honeycomb should be empty  ${node}  ${bd_name}
  And L2 FIB Table from VAT should be empty  ${node}  ${bd_index}
 When Honeycomb adds L2 FIB entry to bridge domain  ${node}  ${bd_name}  ${l2_fib_forward_cfg}
 Then L2 FIB Entry from Honeycomb should be  ${node}  ${bd_name}  ${l2_fib_forward_oper}
 When Honeycomb fails to modify L2 FIB entry  ${node}  ${bd_name}  ${l2_fib_forward_oper['phys-address']}  outgoing-interface  ${l2_fib_forward_modified_cfg['outgoing-interface']}
 Then L2 FIB Entry from Honeycomb should be  ${node}  ${bd_name}  ${l2_fib_forward_oper}
  And L2 FIB entry from VAT should be  ${node}  ${bd_index}  ${l2_fib_forward_vat}

Set test interface down

Set the interface used in tests down.


Honeycomb sets interface state  ${node}  ${interface}  down

mgmt-cfg-lisp-apihc-apivat-func module

TC01: Honeycomb enables Lisp feature

Check if Honeycomb can enable the Lisp feature.


Given Lisp Should Not Be Configured  ${node}
 When Honeycomb Enables Lisp  ${node}
 Then Lisp state From Honeycomb Should Be  ${node}  enabled
  And Lisp state From VAT Should Be  ${node}  enabled

TC02: Honeycomb adds locator set and locator

Check if Honeycomb can configure a locator set.


Given Lisp state From Honeycomb Should Be  ${node}  enabled
 When Honeycomb adds locator set  ${node}  ${interface}  ${locator_set}
 Then Locator Set From Honeycomb Should Be  ${node}  ${interface}  ${locator_set}

TC03: Honeycomb configures Lisp - remote mapping - Bridge Domain

Check if Honeycomb can configure a remote Lisp mappingwith a bridge domain.


Given Lisp state From Honeycomb Should Be  ${node}  enabled
  And Honeycomb creates first l2 bridge domain  ${node}  ${bd_name}  ${bd_settings}
 When Honeycomb adds Lisp mapping  ${node}  ${lisp_settings_remote_bd}
 Then Lisp mapping From Honeycomb Should Be  ${node}  ${remote_bd_subtable}
  And Lisp mapping From VAT Should Be  ${node}  ${vat_remote_bd}

TC04: Honeycomb can remove Lisp mapping

Check if Honeycomb can remove a configured Lisp mapping.


Given Lisp mapping From Honeycomb Should Be  ${node}  ${remote_bd_subtable}
  And Lisp mapping From VAT Should Be  ${node}  ${vat_remote_bd}
 When Honeycomb removes all lisp mappings  ${node}
 Then Lisp mappings from Honeycomb should not exist  ${node}
  And Lisp mappings from VAT should not exist  ${node}

TC05: Honeycomb configures Lisp - remote mapping - VRF

Check if Honeycomb can configure a remote Lisp mappingwith VRF.


Given Lisp mappings from Honeycomb should not exist  ${node}
  And Lisp mappings from VAT should not exist  ${node}
 When Honeycomb adds Lisp mapping  ${node}  ${lisp_settings_remote_vrf}
 Then Lisp mapping From Honeycomb Should Be  ${node}  ${remote_vrf_subtable}
  And Lisp mapping From VAT Should Be  ${node}  ${vat_remote_vrf}

TC06: Honeycomb configures Lisp - local mapping - Bridge Domain

Check if Honeycomb can configure a local Lisp mappingwith a bridge domain.


Given Locator Set From Honeycomb Should Be  ${node}  ${interface}  ${locator_set}
  And Lisp mappings from Honeycomb should not exist  ${node}
  And Lisp mappings from VAT should not exist  ${node}
  And Honeycomb creates first l2 bridge domain  ${node}  ${bd2_name}  ${bd_settings}
 When Honeycomb adds Lisp mapping  ${node}  ${lisp_settings_local_bd}
 Then Lisp mapping From Honeycomb Should Be  ${node}  ${local_bd_subtable}
  And Lisp mapping From VAT Should Be  ${node}  ${vat_local_bd}

TC07: Honeycomb configures Lisp - local mapping - VRF

Check if Honeycomb can configure a local Lisp mappingwith VRF.


Given Locator Set From Honeycomb Should Be  ${node}  ${interface}  ${locator_set}
  And Lisp mappings from Honeycomb should not exist  ${node}
  And Lisp mappings from VAT should not exist  ${node}
 When Honeycomb adds Lisp mapping  ${node}  ${lisp_settings_local_vrf}
 Then Lisp mapping From Honeycomb Should Be  ${node}  ${local_vrf_subtable}
  And Lisp mapping From VAT Should Be  ${node}  ${vat_local_vrf}

TC08: Honeycomb configures Lisp mapping with adjacency

Check if Honeycomb can configure local and remote Lispmappings with VRF, and configure adjacency.


Given Locator Set From Honeycomb Should Be  ${node}  ${interface}  ${locator_set}
  And Honeycomb creates first l2 bridge domain  ${node}  ${bd2_name}  ${bd_settings}
  And Lisp mappings from Honeycomb should not exist  ${node}
  And Lisp mappings from VAT should not exist  ${node}
  And Honeycomb adds Lisp mapping  ${node}  ${lisp_settings_both_vrf}
 When Honeycomb adds Lisp adjacency  ${node}  ${7}  remote_map_vrf  adj01  ${vrf_adjacency}
 Then Lisp mapping from Honeycomb should be  ${node}  ${adj_subtable}

TC09: Honeycomb configures Lisp map resolver

Check if Honeycomb can configure a Lisp map resolver.


Given Lisp state From Honeycomb Should Be  ${node}  enabled
  And Lisp state From VAT Should Be  ${node}  enabled
 When Honeycomb adds Lisp Map resolver  ${node}  192.168.0.4
 Then Map resolver from Honeycomb should be  ${node}  192.168.0.4
  And Map resolver from VAT should be  ${node}  192.168.0.4

TC10: Honeycomb enabled Lisp PITR feature

Check if Honeycomb can configure the Lisp PITR feature.


Given Locator Set From Honeycomb Should Be  ${node}  ${interface}  ${locator_set}
 When Honeycomb enables Lisp PITR feature  ${node}  ${locator_set}
 Then PITR config from Honeycomb should be  ${node}  ${locator_set}
  And PITR config from VAT should be  ${node}  ${locator_set}

TC11: Honeycomb can remove configuration of Lisp features

Check if Honeycomb can disable all Lisp features.


Given Map resolver from Honeycomb should be  ${node}  192.168.0.4
  And PITR config from Honeycomb should be  ${node}  ${locator_set}
 When Honeycomb disables all Lisp features  ${node}
 Then Lisp Should Not Be Configured  ${node}

mgmt-cfg-nsh-apihc-apivat-func module

TC01: Honeycomb can configure NSH entry

Check if Honeycomb can configure an NSH entry.


Given NSH configuration from Honeycomb should be empty  ${node}
 When Honeycomb adds NSH entry  ${node}  entry1  ${nsh_entry1}
 Then NSH entry from Honeycomb should be  ${node}  entry1  ${nsh_entry1_oper}

TC02: Honeycomb can remove NSH entry

Check if Honeycomb can remove an existing NSH entry.


Given NSH entry from Honeycomb should be  ${node}  entry1  ${nsh_entry1_oper}
 When Honeycomb removes NSH entry  ${node}  entry1
 Then NSH configuration from Honeycomb should be empty  ${node}

TC03: Honeycomb can configure new NSH entry

Check if Honeycomb can configure an NSH antry after onehas been deleted.


Given NSH configuration from Honeycomb should be empty  ${node}
 When Honeycomb adds NSH entry  ${node}  entry2  ${nsh_entry2}
 Then NSH entry from Honeycomb should be  ${node}  entry2  ${nsh_entry2_oper}

TC04: Honeycomb can configure multiple NSH entries at the same time

Check if Honeycomb can configure an NSH entry when onealready exists.


Given NSH configuration from Honeycomb should be empty  ${node}
 When Honeycomb adds NSH entry  ${node}  entry1  ${nsh_entry1}
  And Honeycomb adds NSH entry  ${node}  entry2  ${nsh_entry2}
 Then NSH entry from Honeycomb should be  ${node}  entry1  ${nsh_entry1_oper}
  And NSH entry from Honeycomb should be  ${node}  entry2  ${nsh_entry2_oper}

TC05: Honeycomb can configure NSH map

Check if Honeycomb can configure an NSH map.


Given NSH configuration from Honeycomb should be empty  ${node}
  And Honeycomb creates VxLAN GPE interface  ${node}  ${vxlan_gpe_if1}  ${vxlan_gpe_base_settings1}  ${vxlan_gpe_settings1}
 When Honeycomb adds NSH entry  ${node}  entry1  ${nsh_entry1}
  And Honeycomb adds NSH map  ${node}  map1  ${nsh_map1}
 Then NSH map from Honeycomb should be  ${node}  map1  ${nsh_map1_oper}

TC06: Honeycomb can remove NSH map

Check if Honeycomb can remove an existing NSH map.


Given NSH entry from Honeycomb should be  ${node}  entry1  ${nsh_entry1_oper}
  And VxLAN GPE configuration from Honeycomb should be  ${node}  ${vxlan_gpe_if1}  ${vxlan_gpe_base_settings1}  ${vxlan_gpe_settings1}
  And NSH map from Honeycomb should be  ${node}  map1  ${nsh_map1_oper}
 When Honeycomb removes NSH map  ${node}  map1
 Then NSH map from Honeycomb should not exist  ${node}  map1
  And NSH entry from Honeycomb should be  ${node}  entry1  ${nsh_entry1_oper}

TC07: Honeycomb can modify existing NSH map

Check if Honeycomb can configure an NSH map after onehas been deleted.


Given NSH map from Honeycomb should not exist  ${node}  map1_edit
  And NSH entry from Honeycomb should be  ${node}  entry1  ${nsh_entry1_oper}
  And VxLAN GPE configuration from Honeycomb should be  ${node}  ${vxlan_gpe_if1}  ${vxlan_gpe_base_settings1}  ${vxlan_gpe_settings1}
 When Honeycomb adds NSH map  ${node}  map1_edit  ${nsh_map1_edit}
 Then NSH map from Honeycomb should be  ${node}  map1_edit  ${nsh_map1_edit_oper}
  And NSH entry from Honeycomb should be  ${node}  entry1  ${nsh_entry1_oper}

TC08: Honeycomb can configure multiple NSH maps at the same time

Check if Honeycomb can configure and NSH map when onealready exists.


Given NSH map from Honeycomb should not exist  ${node}  map2
  And NSH entry from Honeycomb should be  ${node}  entry1  ${nsh_entry1_oper}
  And VxLAN GPE configuration from Honeycomb should be  ${node}  ${vxlan_gpe_if1}  ${vxlan_gpe_base_settings1}  ${vxlan_gpe_settings1}
  And Honeycomb creates VxLAN GPE interface  ${node}  ${vxlan_gpe_if2}  ${vxlan_gpe_base_settings2}  ${vxlan_gpe_settings2}
 When Honeycomb adds NSH map  ${node}  map1  ${nsh_map1}
  And Honeycomb adds NSH map  ${node}  map2  ${nsh_map2}
 Then NSH map from Honeycomb should be  ${node}  map1  ${nsh_map1_oper}
  And NSH map from Honeycomb should be  ${node}  map2  ${nsh_map2_oper}

mgmt-cfg-pbb-apihc-apivat-func module

TC01: Honeycomb sets PBB sub-interface

Honeycomb creates a new PBB sub-interface.


Honeycomb creates PBB sub interface  ${node}  ${super_if}  ${cfg_pbb_sub_if_1}

TC02: Honeycomb modifies existing PBB sub-interface

Honeycomb modifies an existing PBB sub-interface.


Honeycomb creates PBB sub interface  ${node}  ${super_if}  ${cfg_pbb_sub_if_1_mod}

TC03: Honeycomb deletes existing PBB sub-interface

Honeycomb deletes an existing PBB sub-interface.


Honeycomb Removes PBB sub interface  ${node}  ${super_if}

TC04: Honeycomb fails to set wrong destination-address for new PBB sub-interface

Honeycomb fails to create a new PBB sub-interface withwrong value of parameter destination-address, type yang:mac-address.


Honeycomb fails to create PBB sub interface  ${node}  ${super_if}  ${cfg_pbb_sub_if_wrong_dst_addr}

TC05: Honeycomb fails to set wrong source-address for new PBB sub-interface

Honeycomb fails to create a new PBB sub-interface withwrong value of parameter source-address, type yang:mac-address.


Honeycomb fails to create PBB sub interface  ${node}  ${super_if}  ${cfg_pbb_sub_if_wrong_src_addr}

TC06: Honeycomb fails to set wrong b-vlan-tag-vlan-id for new PBB sub-interface

Honeycomb fails to create a new PBB sub-interface withwrong value of parameter b-vlan-tag-vlan-id, type uint16, 12 bitrange, range 1..4095.


Honeycomb fails to create PBB sub interface  ${node}  ${super_if}  ${cfg_pbb_sub_if_wrong_vlan_tag}

TC07: Honeycomb fails to set wrong i-tag-isid for new PBB sub-interface

Honeycomb fails to create a new PBB sub-interface withwrong value of parameter i-tag-isid, type uint32, 24 bit range,range 1..16777215.


Honeycomb fails to create PBB sub interface  ${node}  ${super_if}  ${cfg_pbb_sub_if_wrong_i_tag}

TC08: Honeycomb fails to create new PBB sub-interface without vlan tag

Honeycomb fails to create a new PBB sub-interface withoutparameter b-vlan-tag-vlan-id.


Honeycomb fails to create PBB sub interface  ${node}  ${super_if}  ${cfg_pbb_sub_if_no_vlan_tag}

mgmt-cfg-snat44-apihc-apivat-func module

TC01: Honeycomb configures NAT entry

Honeycomb configures a static NAT entry.


Given NAT configuration from Honeycomb should be empty  ${node}  ${nat_empty}
 When Honeycomb Configures NAT Entry  ${node}  ${entry1}
 Then NAT Entries From Honeycomb Should Be  ${node}  ${entry1}
  And NAT Entries From VAT Should Be  ${node}  ${entry1_vat}

TC02: Honeycomb removes NAT entry

Honeycomb removes a configured static NAT entry.


Given NAT Entries From Honeycomb Should Be  ${node}  ${entry1}
  And NAT Entries From VAT Should Be  ${node}  ${entry1_vat}
 When Honeycomb Configures NAT Entry  ${node}  ${NONE}
 Then NAT configuration from Honeycomb should be empty  ${node}  ${nat_empty}

TC03: Honeycomb configures multiple NAT entries

Honeycomb configures two static NAT entries.


Given NAT configuration from Honeycomb should be empty  ${node}  ${nat_empty}
 When Honeycomb Configures NAT Entry  ${node}  ${entry1}  ${0}  ${1}
  And Honeycomb Configures NAT Entry  ${node}  ${entry2}  ${0}  ${2}
 Then NAT Entries From Honeycomb Should Be  ${node}  ${entry1_2_oper}  ${0}
  And NAT Entries From VAT Should Be  ${node}  ${entry1_2_vat}

TC04: Honeycomb enables NAT on interface - inbound

Honeycomb configures NAT on an interfacein inbound direction.


Given NAT Interface Configuration From Honeycomb Should Be Empty  ${node}  ${interface}  inbound
  And NAT Interface Configuration From Honeycomb Should Be Empty  ${node}  ${interface}  outbound
 When Honeycomb Configures NAT On Interface  ${node}  ${interface}  inbound
 Then NAT Interface Configuration From Honeycomb Should Be  ${node}  ${interface}  inbound
  And NAT Interface Configuration From VAT Should Be  ${node}  ${nat_interface_vat_in}
  And NAT Interface Configuration From Honeycomb Should be empty  ${node}  ${interface}  outbound

TC05: Honeycomb removes NAT interface configuration

Honeycomb removes NAT configuration from an interface.


Given NAT Interface Configuration From Honeycomb Should Be  ${node}  ${interface}  inbound
  And NAT Interface Configuration From Honeycomb Should Be empty  ${node}  ${interface}  outbound
 When Honeycomb removes NAT interface configuration  ${node}  ${interface}  inbound
 Then NAT Interface Configuration From Honeycomb Should Be empty  ${node}  ${interface}  inbound
  And NAT Interface Configuration From Honeycomb Should Be empty  ${node}  ${interface}  outbound

TC06: Honeycomb enables NAT on interface - outbound

Honeycomb configures NAT on an interfacein outbound direction.


Given NAT Interface Configuration From Honeycomb Should Be empty  ${node}  ${interface}  inbound
  And NAT Interface Configuration From Honeycomb Should Be empty  ${node}  ${interface}  outbound
 When Honeycomb Configures NAT on Interface  ${node}  ${interface}  outbound
 Then NAT Interface Configuration From Honeycomb Should Be empty  ${node}  ${interface}  inbound
  And NAT Interface Configuration From Honeycomb Should Be  ${node}  ${interface}  outbound
  And NAT Interface Configuration From VAT Should Be  ${node}  ${nat_interface_vat_out}

mgmt-cfg-spanrx-apihc-apivat-func module

TC01: Honeycomb can configure SPAN on an interface

Honeycomb configures SPAN on interface and verifies/ against VPP SPAN dump.


Given SPAN configuration from VAT should not exist  ${node}
 When Honeycomb Configures SPAN on interface  ${node}  ${interface1}  ${interface2}
 Then Interface SPAN configuration from VAT should be  ${node}  ${interface1}  ${interface2}

TC02: Honeycomb can disable SPAN on interface

Honeycomb removes existing SPAN configurationon interface and verifies against VPP SPAN dump.


Given Interface SPAN configuration from VAT should be  ${node}  ${interface1}  ${interface2}
 When Honeycomb removes interface SPAN configuration  ${node}  ${interface1}
 Then SPAN configuration from VAT should not exist  ${node}

TC03: Honeycomb can configure SPAN on one interface to mirror two interfaces

Honeycomb configures SPAN on interface, mirroringtwo interfaces at the same time. Then verifies against VPP SPAN dump.


Given SPAN configuration from VAT should not exist  ${node}
 When Honeycomb Configures SPAN on interface  ${node}  ${interface1}  ${interface2}  ${interface3}
 Then Interface SPAN configuration from VAT should be  ${node}  ${interface1}  ${interface2}  ${interface3}

mgmt-cfg-vxlan-apihc-apivat-func module

TC01: Honeycomb configures VxLAN tunnel

Check if Honeycomb API can configure VxLAN settings.


Given VxLAN configuration from Honeycomb should be empty  ${node}  ${vx_interface}
  And VxLAN configuration from VAT should be empty  ${node}
 When Honeycomb sets interface VxLAN configuration  ${node}  ${vx_interface}  ${vxlan_settings}
 Then VxLAN configuration from Honeycomb should be  ${node}  ${vx_interface}  ${vxlan_settings}
  And VxLAN configuration from VAT should be  ${node}  ${vxlan_settings}
${vxlan_index}=  Get Interface index from oper data  ${node}  ${vx_interface}
Set Suite Variable  ${vxlan_index}

TC02: Honeycomb disables VxLAN tunnel

Check if Honeycomb API can reset VxLAN configuration.


Given VxLAN configuration from Honeycomb should be  ${node}  ${vx_interface}  ${vxlan_settings}
  And Honeycomb should not show disabled interface in oper data  ${node}  ${vxlan_index}
  And VxLAN configuration from VAT should be  ${node}  ${vxlan_settings}
 When Honeycomb removes VxLAN tunnel settings  ${node}  ${vx_interface}
 Then VxLAN configuration from Honeycomb should be empty  ${node}  ${vx_interface}
  And Honeycomb should show disabled interface in oper data  ${node}  ${vxlan_index}
  And VxLAN configuration from VAT should be empty  ${node}

TC03: Honeycomb can configure VXLAN tunnel after one has been disabled

Check if Honeycomb API can configure VxLAN settings againafter previous settings have been removed.


Given VxLAN configuration from Honeycomb should be empty  ${node}  ${vx_interface}
  And Honeycomb should show disabled interface in oper data  ${node}  ${vxlan_index}
  And VxLAN configuration from VAT should be empty  ${node}
 When Honeycomb sets interface VxLAN configuration  ${node}  ${vx_interface}  ${vxlan_settings2}
 Then VxLAN configuration from Honeycomb should be  ${node}  ${vx_interface}  ${vxlan_settings2}
  And Honeycomb should not show disabled interface in oper data  ${node}  ${vxlan_index}
  And VxLAN configuration from VAT should be  ${node}  ${vxlan_settings2}

TC04: Honeycomb does not set VxLAN configuration on another interface type

Check if Honeycomb API prevents setting VxLANon incorrect interface.


Given VxLAN configuration from Honeycomb should be empty  ${node}  ${interface}
  And VxLAN configuration from VAT should be empty  ${node}
 When Honeycomb fails setting VxLan on different interface type  ${node}  ${interface}  ${vxlan_settings2}
 Then VxLAN configuration from Honeycomb should be empty  ${node}  ${interface}
  And VxLAN configuration from VAT should be empty  ${node}

TC05: Honeycomb does not set invalid VxLAN configuration

Check if Honeycomb API prevents setting incorrect VxLANsettings.


Given VxLAN configuration from Honeycomb should be empty  ${node}  ${vx_interface}
  And VxLAN configuration from VAT should be empty  ${node}
 When Honeycomb fails setting invalid VxLAN configuration  ${node}  ${vx_interface}  ${vxlan_invalid}
 Then VxLAN configuration from Honeycomb should be empty  ${node}  ${vx_interface}

TC06: Honeycomb configures VxLAN tunnel with ipv6

Check if Honeycomb API can configure VxLAN withipv6 settings.


Given VxLAN configuration from Honeycomb should be empty  ${node}  ${vx_interface}
  And VxLAN configuration from VAT should be empty  ${node}
 When Honeycomb sets interface VxLAN configuration  ${node}  ${vx_interface}  ${vxlan_settings_ipv6}
 Then VxLAN configuration from Honeycomb should be  ${node}  ${vx_interface}  ${vxlan_settings_ipv6_long}
  And VxLAN configuration from VAT should be  ${node}  ${vxlan_settings_ipv6}

mgmt-cfg-vxlangpe-apihc-apivat-func module

TC01: Honeycomb creates VxLAN GPE tunnel

Check if Honeycomb API can configure a VxLAN GPE tunnel.


Given interface configuration from Honeycomb should be empty  ${node}  ${vxlan_gpe_if1}
  And interface configuration from VAT should be empty  ${node}  ${vxlan_gpe_if1}
 When Honeycomb creates VxLAN GPE interface  ${node}  ${vxlan_gpe_if1}  ${vxlan_gpe_base_settings}  ${vxlan_gpe_settings}
 Then VxLAN GPE configuration from Honeycomb should be  ${node}  ${vxlan_gpe_if1}  ${vxlan_gpe_base_settings}  ${vxlan_gpe_settings}
  And VxLAN GPE configuration from VAT should be  ${node}  ${vxlan_gpe_if1}  ${vxlan_gpe_settings}
  And VxLAN GPE Interface indices from Honeycomb and VAT should correspond  ${node}  ${vxlan_gpe_if1}

TC02: Honeycomb removes VxLAN GPE tunnel

Check if Honeycomb API can remove VxLAN GPE tunnel.


Given VxLAN GPE configuration from Honeycomb should be  ${node}  ${vxlan_gpe_if1}  ${vxlan_gpe_base_settings}  ${vxlan_gpe_settings}
VxLAN GPE configuration from VAT should be  ${node}  ${vxlan_gpe_if1}  ${vxlan_gpe_settings}
 When Honeycomb removes VxLAN GPE interface  ${node}  ${vxlan_gpe_if1}
 Then VxLAN GPE configuration from Honeycomb should be empty  ${node}  ${vxlan_gpe_if1}
  And VxLAN GPE configuration from VAT should be empty  ${node}

TC03: Honeycomb sets wrong interface type while creating VxLAN GPE tunnel

Check if Honeycomb refuses to create a VxLAN GPE tunnelwith a wrong interface type set.


Given interface configuration from Honeycomb should be empty  ${node}  ${vxlan_gpe_if2}
  And interface configuration from VAT should be empty  ${node}  ${vxlan_gpe_if2}
 When Honeycomb fails to create VxLAN GPE interface  ${node}  ${vxlan_gpe_if2}  ${vxlan_gpe_wrong_type_base_settings}  ${vxlan_gpe_settings}
 Then interface configuration from Honeycomb should be empty  ${node}  ${vxlan_gpe_if2}
  And interface configuration from VAT should be empty  ${node}  ${vxlan_gpe_if2}

TC04: Honeycomb sets wrong protocol while creating VxLAN GPE tunnel

Check if Honeycomb refuses to create a VxLAN GPE tunnelwith a wrong next-protocol set.


Given interface configuration from Honeycomb should be empty  ${node}  ${vxlan_gpe_if3}
  And interface configuration from VAT should be empty  ${node}  ${vxlan_gpe_if3}
 When Honeycomb fails to create VxLAN GPE interface  ${node}  ${vxlan_gpe_if3}  ${vxlan_gpe_wrong_protocol_base_settings}  ${vxlan_gpe_wrong_protocol_settings}
 Then interface configuration from Honeycomb should be empty  ${node}  ${vxlan_gpe_if3}
  And interface configuration from VAT should be empty  ${node}  ${vxlan_gpe_if3}

TC05: Honeycomb sets VxLAN GPE tunnel on existing interface with wrong type

Check if Honeycomb refuses to create a VxLAN GPE tunnelon existing interface with wrong type.


Given VxLAN GPE configuration from VAT should be empty  ${node}
 When Honeycomb fails to create VxLAN GPE interface  ${node}  ${vxlan_gpe_existing_if}  ${vxlan_gpe_base_wrong_interface_settings}  ${vxlan_gpe_wrong_interface_settings}
 Then VxLAN GPE configuration from VAT should be empty  ${node}

TC06: Honeycomb creates VxLAN GPE tunnel with ipv6

Check if Honeycomb API can configure a VxLAN GPE tunnelwith IPv6 addresses.


Given VxLAN GPE configuration from VAT should be empty  ${node}
  And VxLAN GPE configuration from Honeycomb should be empty  ${node}  ${vxlan_gpe_if5}
 When Honeycomb creates VxLAN GPE interface  ${node}  ${vxlan_gpe_if5}  ${vxlan_gpe_base_ipv6_settings}  ${vxlan_gpe_ipv6_settings}
 Then VxLAN GPE configuration from Honeycomb should be  ${node}  ${vxlan_gpe_if5}  ${vxlan_gpe_base_ipv6_settings}  ${vxlan_gpe_ipv6_settings}
  And Run Keyword And Continue On Failure  VxLAN GPE configuration from VAT should be  ${node}  ${vxlan_gpe_if5}  ${vxlan_gpe_ipv6_settings}
  And VxLAN GPE Interface indices from Honeycomb and VAT should correspond  ${node}  ${vxlan_gpe_if5}

TC07: Honeycomb creates a second VxLAN GPE tunnel with ipv6

Check if Honeycomb API can configure another VxLANGPE tunnel with IPv6 addresses.


Given interface configuration from Honeycomb should be empty  ${node}  ${vxlan_gpe_if6}
  And interface configuration from VAT should be empty  ${node}  ${vxlan_gpe_if6}
 When Honeycomb creates VxLAN GPE interface  ${node}  ${vxlan_gpe_if6}  ${vxlan_gpe_base_ipv6_settings2}  ${vxlan_gpe_ipv6_settings2}
 Then VxLAN GPE configuration from Honeycomb should be  ${node}  ${vxlan_gpe_if6}  ${vxlan_gpe_base_ipv6_settings2}  ${vxlan_gpe_ipv6_settings2}
  And VxLAN GPE configuration from VAT should be  ${node}  ${vxlan_gpe_if6}  ${vxlan_gpe_ipv6_settings2}
  And VxLAN GPE Interface indices from Honeycomb and VAT should correspond  ${node}  ${vxlan_gpe_if6}

mgmt-notif-apihcnc-func module

TC01: Honeycomb sends notification on interface state change

Check if Honeycomb sends a state-changed notificationwhen the state of an interface is changed.


Given Interface state from Honeycomb should be  ${node}  ${interface}  down
  And Interface state from VAT should be  ${node}  ${interface}  down
  And Notification listener is established  ${node}
 When Honeycomb sets interface state  ${node}  ${interface}  up
 Then Honeycomb should send interface state notification  ${interface}  up
 When Honeycomb sets interface state  ${node}  ${interface}  down
  And Honeycomb should send interface state notification  ${interface}  down

TC02: Honeycomb sends notification on interface deletion

Check if Honeycomb sends an interface-deleted notification when an interface is deleted.


Given TAP configuration from Honeycomb should be  ${node}  ${tap_interface}  ${tap_settings}
  And TAP configuration from VAT should be  ${node}  ${tap_interface}  ${tap_settings}
  And Notification listener is established  ${node}
 When Honeycomb removes TAP interface  ${node}  ${tap_interface}
 Then Honeycomb should send interface deleted notification  ${tap_interface}

mgmt-statepersist-apihc-func module

TC01: Honeycomb persists configuration through restart of both Honeycomb and VPP

Checks if Honeycomb maintains configuration after bothHoneycomb and VPP are restarted.


Given Honeycomb configures every setting  ${node}  ${interface}
  And Honeycomb and VPP should verify every setting  ${node}  ${interface}
 When Honeycomb and VPP are restarted  ${node}
 Then Honeycomb and VPP should verify every setting  ${node}  ${interface}
  And Honeycomb should show no rogue interfaces  ${node}

TC02: Honeycomb persists configuration through restart of Honeycomb

Checks if Honeycomb maintains configuration after itis restarted.


Given Honeycomb and VPP should verify every setting  ${node}  ${interface}
 When Honeycomb is restarted  ${node}
 Then Honeycomb and VPP should verify every setting  ${node}  ${interface}
  And Honeycomb should show no rogue interfaces  ${node}

TC03: Honeycomb persists configuration through restart of VPP

Checks if Honeycomb updates VPP settings after VPP isrestarted.


Given Honeycomb and VPP should verify every setting  ${node}  ${interface}
 When VPP is restarted  ${node}
 Then Honeycomb and VPP should verify every setting  ${node}  ${interface}
  And Honeycomb should show no rogue interfaces  ${node}

TC04: Honeycomb reverts to defaults if persistence files are invalid

Checks if Honeycomb reverts to default configuration whenpersistence files are damaged or invalid.


 When Persistence file is damaged during restart  ${node}
 Then Honeycomb and VPP should have default configuration  ${node}