-
Notifications
You must be signed in to change notification settings - Fork 0
gnmi_set_test
Ensures that the device respects certain gNMI SetRequest corner case behaviors.
- ATE port-1 and DUT port-1
- ATE port-2 and DUT port-2
Each test should be implemented as three variants:
- RootOp: performs a get-modify-set of the full config at root. The SetRequest
contains one
replace
operation. - ContainerOp: performs a get-modify-set on both
/interfaces
and/network-instances
. The SetRequest contains tworeplace
operations, one for each container of the list. - ItemOp: SetRequest contains
delete
,replace
orupdate
on the list items (e.g. under/interfaces/interface[name]
and/network-instances/network-instance[name]
).
The results MUST be the same.
Notes:
- Use
--deviation_default_network_instance
for the name of the default VRF. - Use
--deviation_static_protocol_name
for the name of the static protocol.
This test checks that the config read from the device can be written back.
- Obtain the full config at root using gNMI Get.
- Deploy the config back to the same device using a gNMI SetRequest.
This test checks that the config of a physical interface can be reset to the default value using the delete operation.
-
Initialize the interfaces in the same SetRequest.
- Configure
dut:port1
with the descriptiondut:port1
. - Configure
dut:port2
with the descriptiondut:port2
.
Verify through telemetry that these interfaces are configured correctly.
- Configure
-
Delete
dut:port1
anddut:port2
in the same SetRequest.In the ContainerOp variant, delete the interfaces by omission.
Verify through telemetry that the interfaces still exist, but the description has been reset to no value.
This test checks that the IP address of a deleted interface can be immediately reused by another interface.
Allocate two aggregate interface names using netutil.NextAggregateInterface.
We refer to them as dut:agg1
and dut:agg2
below.
-
Initialize the interfaces in the same SetRequest.
- Delete
dut:port1
,dut:port2
,dut:agg1
anddut:agg2
. - Configure
dut:agg1
with memberdut:port1
and IP address 192.0.2.1/30. - Configure
dut:agg2
with memberdut:port2
and IP address 192.0.2.5/30.
Verify through telemetry that these interfaces are configured correctly.
- Delete
-
Modify the interfaces in the same SetRequest:
- Delete
dut:agg1
. - Configure
dut:agg2
to have the IP address 192.0.2.1/30.
Verify through telemetry that
dut:agg2
has the correct IP address. - Delete
-
Clean up by deleting
dut:agg2
.
This test checks that the IP addresses of two interfaces can be swapped in the same SetRequest.
-
Initialize the interfaces in the same SetRequest:
- Configure
dut:port1
with IP address 192.0.2.1/30. - Configure
dut:port2
with IP address 192.0.2.5/30.
Verify through telemetry that these interfaces are configured correctly.
- Configure
-
Modify the interfaces in the same SetRequest:
- Set
dut:port1
address to 192.0.2.5/30. - Set
dut:port2
address to 192.0.2.1/30.
Verify through telemetry that the interfaces have the correct IP addresses.
- Set
This test checks that a non-existing VRF can be deleted.
-
Initialize by making sure the VRF
GREEN
does not exist.This is no-op for ContainerOp and RootOp. Only ItemOp will generate a DELETE operation in the SetRequest. The request should succeed.
This test checks that a non-default VRF can be deleted.
-
Initialize the interfaces in the same SetRequest:
- Configure
dut:port1
with IP address 192.0.2.1/30. - Configure
dut:port2
with IP address 192.0.2.5/30. - Configure a non-default VRF
BLUE
attaching both interfaces.
Verify through telemetry that these interfaces are configured correctly and attached to the non-default VRF.
- Configure
-
Clean up by deleting VRF
BLUE
.Verify through telemetry that the VRF is not present.
This test checks that interfaces can be moved from one VRF to a different VRF while preserving the interface configs.
There should be two variants of this test:
- Moving from the default VRF to non-default VRF
BLUE
. - Moving from non-default VRF
RED
to another non-default VRFBLUE
.
Steps:
-
Initialize the attachment in the same SetRequest:
- Configure
dut:port1
with IP address 192.0.2.1/30. - Configure
dut:port2
with IP address 192.0.2.5/30. - Attach both interfaces to the first VRF. Create the first VRF as L3VRF if it is not the default.
Verify through telemetry that these interfaces are configured correctly and attached to the first VRF.
- Configure
-
Modify attachment in the same SetRequest:
- Detach
dut:port1
anddut:port2
from the first VRF. If the first VRF is not the default VRF, delete it. - In the ContainerOp variant, also replace the interfaces
dut:port1
anddut:port2
with exactly the same config as before. - Configure the second VRF as L3VRF attaching
dut:port1
anddut:port2
.
- Detach
-
Verify through telemetry:
- The IP addresses of
dut:port1
anddut:port2
are as expected. - The
dut:port1
anddut:port2
interfaces are attached to the second VRF.
- The IP addresses of
-
Clean up by deleting the second VRF.
This test checks that the static protocol name is usable.
-
Initialize the attachment in the same SetRequest:
- Configure
dut:port1
with IP address 192.0.2.1/30. - Configure
dut:port2
with IP address 192.0.2.5/30. - Configure a non-default VRF
BLUE
attaching both interfaces. - Configure the static routes in VRF
BLUE
as follows:- Prefix 198.51.100.0/24 has next-hop 192.0.2.2 and interface
dut:port1
. - Prefix 203.0.113.0/24 has next-hop 192.0.2.6 and interface
dut:port2
.
- Prefix 198.51.100.0/24 has next-hop 192.0.2.2 and interface
Verify through telemetry that the static routes are configured correctly.
- Configure
-
Modify the static routes in VRF
BLUE
as follows in the same SetRequest.- Prefix 198.51.100.0/24 has next-hop 192.0.2.6 and interface
dut:port2
. - Prefix 203.0.113.0/24 has next-hop 192.0.2.2 and interface
dut:port1
.
Verify through telemetry that the static routes are configured correctly.
- Prefix 198.51.100.0/24 has next-hop 192.0.2.6 and interface
-
Clean up by deleting VRF
BLUE
.
- gNMI.Set
-
Home
- Test Plans
- Authz: General Authz (1-4) tests
- CNTR-2: Container network connectivity tests
- DP-1.2: QoS policy feature config
- DP-1.3: QoS ECN feature config
- DP-1.4: QoS Interface Output Queue Counters
- DP-1.7: One strict priority queue traffic test
- DP-1.8: Two strict priority queue traffic test
- DP-1.9: WRR traffic test
- DP-1.10: Mixed strict priority and WRR traffic test
- DP-1.11: Bursty traffic test
- DP-1.14: QoS basic test
- example-0.1: Topology Test
- FP-1.1: Power admin DOWN/UP Test
- gNMI-1.1: cli Origin
- gNMI-1.2: Benchmarking: Full Configuration Replace
- gNMI-1.3: Benchmarking: Drained Configuration Convergence Time
- gNMI-1.4: Telemetry: Inventory
- gNMI-1.5: Telemetry: Port Speed Test
- gNMI-1.8: Configuration Metadata-only Retrieve and Replace
- gNMI-1.9: Get requests
- gNMI-1.10: Telemetry: Basic Check
- gNMI-1.11: Telemetry: Interface Packet Counters
- gNMI-1.12: Mixed OpenConfig/CLI Origin
- gNMI-1.13: Optics Telemetry, Instant, threshold, and miscellaneous static info
- gNMI-1.14: OpenConfig metadata consistency during large config push
- gNMI-1.15: Set Requests
- gNMI-1.16: fabric redundancy test
- gNMI-1.17: Controller Card redundancy test
- gNMI-1.18: gNMI subscribe with sample mode for backplane capacity counters
- gNMI-1.19: ConfigPush after Control Card switchover
- gNMI-1.20: Telemetry: Optics Thresholds
- gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test
- gNMI-1.22: Controller card port attributes
- gNMI-1.27: gNMI Sample Mode Test
- gNOI-2.1: Packet-based Link Qualification
- gNOI-3.1: Complete Chassis Reboot
- gNOI-3.2: Per-Component Reboot
- gNOI-3.3: Supervisor Switchover
- gNOI-3.4: Chassis Reboot Status and Reboot Cancellation
- gNOI-4.1: Software Upgrade
- gNOI-5.1: Ping Test
- gNOI-5.2: Traceroute Test
- gNOI-5.3: Copying Debug Files
- gNOI-6.1: Factory Reset
- Health-1.1: Generic Health Check
- Health-1.2: Healthz component status paths
- MGT-1: Management HA solution test
- MTU-1.3: Large IP Packet Transmission
- OC-1.2: Default Address Families
- OC-26.1: Network Time Protocol (NTP)
- P4RT-1.1: Base P4RT Functionality
- P4RT-1.2: P4RT Daemon Failure
- P4RT-2.1: P4RT Election
- P4RT-2.2: P4RT Metadata Validation
- P4RT-3.1: Google Discovery Protocol: PacketIn
- P4RT-3.2: Google Discovery Protocol: PacketOut
- P4RT-5.1: Traceroute: PacketIn
- P4RT-5.2: Traceroute Packetout
- P4RT-6.1: Required Packet I/O rate: Performance
- P4RT-7.1: LLDP: PacketIn
- P4RT-7.2: LLDP: PacketOut
- Replay-1.0: Record/replay presession test
- Replay-1.1: Record/replay diff command trees test
- Replay-1.2: P4RT Replay Test
- RT-1.1: Base BGP Session Parameters
- RT-1.2: BGP Policy & Route Installation
- RT-1.3: BGP Route Propagation
- RT-1.4: BGP Graceful Restart
- RT-1.5: BGP Prefix Limit
- RT-1.7: Local BGP Test
- RT-1.10: BGP Keepalive and HoldTimer Configuration Test
- RT-1.11: BGP remove private AS
- RT-1.12: BGP always compare MED
- RT-1.14: BGP Long-Lived Graceful Restart
- RT-1.19: BGP 2-Byte and 4-Byte ASN support
- RT-1.21: BGP TCP MSS and PMTUD
- RT-1.23: BGP AFI SAFI OC DEFAULTS
- RT-1.24: BGP 2-Byte and 4-Byte ASN support with policy
- RT-1.25: Management network-instance default static route
- RT-1.26: Basic static route support
- RT-1.27: Static route to BGP redistribution
- RT-1.28: BGP to IS-IS redistribution
- RT-1.29: BGP chained import/export policy attachment
- RT-1.30: BGP nested import/export policy attachment
- RT-1.32: BGP policy actions - MED, LocPref, prepend, flow-control
- RT-1.33: BGP Policy with prefix-set matching
- RT-1.51: BGP multipath ECMP
- RT-1.52: BGP multipath UCMP support with Link Bandwidth Community
- RT-2.1: Base IS-IS Process and Adjacencies
- RT-2.2: IS-IS LSP Updates
- RT-2.6: IS-IS Hello-Padding enabled at interface level
- RT-2.7: IS-IS Passive is enabled at interface level
- RT-2.8: IS-IS metric style wide not enabled
- RT-2.9: IS-IS metric style wide enabled
- RT-2.10: IS-IS change LSP lifetime
- RT-2.11: IS-IS Passive is enabled at the area level
- RT-2.12: Static route to IS-IS redistribution
- RT-2.13: Weighted-ECMP for IS-IS
- RT-2.14: IS-IS Drain Test
- RT-3.1: Policy based VRF selection
- RT-3.2: Multiple <Protocol, DSCP> Rules for VRF Selection
- RT-4.10: AFTs Route Summary
- RT-5.1: Singleton Interface
- RT-5.2: Aggregate Interfaces
- RT-5.3: Aggregate Balancing
- RT-5.4: Aggregate Forwarding Viable
- RT-5.5: Interface hold-time
- RT-5.6: Interface Loopback mode
- RT-5.8: IPv6 Link Local
- RT-5.9: Disable IPv6 ND Router Arvetisment
- RT-5.10: IPv6 Link Local generated by SLAAC
- RT-6.1: Core LLDP TLV Population
- RT-7.1: BGP default policies
- RT-7.2: BGP Policy Community Set
- RT-7.3: BGP Policy AS Path Set
- RT-7.4: BGP Policy AS Path Set and Community Set
- RT-7.5: BGP Policy - Match and Set Link Bandwidth Community
- RT-7.8: BGP Policy Match Standard Community and Add Community Import/Export Policy
- RT-7.11: BGP Policy - Import/Export Policy Action Using Multiple Criteria
- SEC-3.1: Authentication
- SFLOW-1: sFlow Configuration and Sampling
- System-1: System testing
- TE-1.1: Static ARP
- TE-1.2: My Station MAC
- TE-2.1: gRIBI IPv4 Entry
- TE-2.2: gRIBI IPv4 Entry With Aggregate Ports
- TE-3.1: Base Hierarchical Route Installation
- TE-3.2: Traffic Balancing According to Weights
- TE-3.3: Hierarchical weight resolution
- TE-3.5: Ordering: ACK Received
- TE-3.6: ACK in the Presence of Other Routes
- TE-3.7: Base Hierarchical NHG Update
- TE-3.31: Hierarchical weight resolution with PBF
- TE-4.1: Base Leader Election
- TE-4.2: Persistence Mode
- TE-5.1: gRIBI Get RPC
- TE-6.1: Route Removal via Flush
- TE-6.2: Route Removal In Non Default VRF
- TE-8.1: DUT Daemon Failure
- TE-8.2: Supervisor Failure
- TE-9.1: FIB FAILURE DUE TO HARDWARE RESOURCE EXHAUST
- TE-9.2: MPLS based forwarding Static LSP
- TE-9: gRIBI MPLS Compliance
- TE-10: gRIBI MPLS Forwarding
- TE-11.1: Backup NHG: Single NH
- TE-11.2: Backup NHG: Multiple NH
- TE-11.3: Backup NHG: Actions
- TE-11.21: Backup NHG: Multiple NH with PBF
- TE-11.31: Backup NHG: Actions with PBF
- TE-13.1: gRIBI route ADD during Failover
- TE-13.2: gRIBI route DELETE during Failover
- TE-14.1: gRIBI Scaling
- TE-14.2: encap and decap scale
- TE-15.1: gRIBI Compliance
- TE-16.1: basic encapsulation tests
- TE-16.2: encapsulation FRR scenarios
- TE-17.1: VRF selection policy driven TE
- TR-6.1: Remote Syslog feature config
- TRANSCEIVER-1: Telemetry: 400ZR Chromatic Dispersion(CD) telemetry values streaming
- TRANSCEIVER-3: Telemetry: 400ZR Optics firmware version streaming
- TRANSCEIVER-4: Telemetry: 400ZR RX input and TX output power telemetry values streaming.
- TRANSCEIVER-5: Configuration: 400ZR channel frequency, output TX launch power and operational mode setting.
- TRANSCEIVER-6: Telemetry: 400ZR Optics performance metrics (pm) streaming.
- TRANSCEIVER-7: Telemetry: 400ZR Optics inventory info streaming
- TRANSCEIVER-8: Telemetry: 400ZR Optics module temperature streaming.
- TRANSCEIVER-9: Telemetry: 400ZR TX laser bias current telemetry values streaming.
- TRANSCEIVER-10: Telemetry: 400ZR Optics FEC(Forward Error Correction) Uncorrectable Frames Streaming.
- TRANSCEIVER-11: Telemetry: 400ZR Optics logical channels provisioning and related telemetry.
- TRANSCEIVER-12: Telemetry: 400ZR Transceiver Supply Voltage streaming.
- TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.
- TUN-1.4: Interface based IPv6 GRE Encapsulation
- TUN-1.9: GRE inner packet DSCP
- Test Plans