Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

README PF-1.3: Policy-based Static GUE Encapsulation to IPv4 tunnel #3482

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,334 @@
# PF-1.3: Policy-based Static GUE Encapsulation to IPv4 tunnel

## Summary

This test verifies Policy Forwarding (PF) action to encapsulate packets in an
IPv4 GUE tunnel. The encapsulation is based on a statically configured GUE
tunnel and static route.

robshakir marked this conversation as resolved.
Show resolved Hide resolved
## Testbed Type

* [`featureprofiles/topologies/ate2_dut5_dum5.testbed`](https://github.com/openconfig/featureprofiles/blob/main/topologies/ate2_dut5_dum5.testbed)

## Procedure

### Test environment setup

* DUT and DUM have 5 ports each.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this diagram needs to be updated with the change to have no DUM.


```
------- -------
| | ==== LAG1 ==== | |
[ ATE:Port1 ] ---- | DUT | | DUM | ---- [ ATE:Port2 ]
robshakir marked this conversation as resolved.
Show resolved Hide resolved
| | ==== LAG2 ==== | |
------- -------
```

* Routes are advertised from ATE:Port2.
* Traffic is generated from ATE:Port1.
* ATE:Port2 is used as the destination port for GUE encapsulated traffic.
Copy link
Member

Choose a reason for hiding this comment

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

instead, consider ATE port 2 is just the next hop for the DUT. The encapsulated packet can be captured at ATE port 2 and decoded to ensure it has the expected format.

Make decap testing a separate test.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ack, updated the test verifications. Decap will being done in a separate test.


#### Configuration

1. DUT:Port1 is configured as Singleton IP interface towards ATE:Port1.

2. DUT:Port2 and DUT:Port3 are configured as LAG1 IP interface towards
DUM:Port2 and DUM:Port3 respectively.

3. DUT:Port4 and DUT:Port5 are configured as LAG2 IP interface towards
DUM:Port4 and DUM:Port5 respectively.

4. DUM:Port1 is configured as Singleton IP interface towards ATE:Port2.

5. DUT is configured to form two eBGP sessions with DUM using the directly
connected LAG interface IPs.

6. DUM is configured to form an eBGP sessions with ATE:Port2 using the directly
connected Singleton interface IP.

7. ATE:Port2 is configured to advertise destination networks (IPv4-DST-NET,
IPv6-DST-NET) and tunnel destination (IPv4-DST-GUE) to DUM. When DUM
advertised these prefixes to the DUT over the two eBGP sessions, the
protocol next hops for the destination networks should be re-configured as
below:

- Destination network IPv4-DST-NET with protocol next hop PNH-IPv4.
- Destination network IPv6-DST-NET with protocol next hop PNH-IPv6.

8. DUT is configured with an IPv4 GUE tunnel with destination IPv4-DST-GUE
without any explicit tunnel Type of Service (ToS) or Time to Live (TTL)
values.

9. DUT is configured with the following static routes:

- To PNH-IPv4, next hop is the statically configured IPv4 GUE tunnel.
- To PNH-IPv6, next hop is the statically configured IPv4 GUE tunnel.

dplore marked this conversation as resolved.
Show resolved Hide resolved
### PF-1.3.1: IPv4 traffic GUE encapsulation without explicit ToS/TTL configuration on tunnel

ATE action:

* Generate **IPv4 traffic** from ATE:Port1 to random IP addresses in
IPv4-DST-NET using a random combination source addresses at linerate.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a required number of source addresses? (A random combination could mean that the test just picks one source address.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated to specify fixed packet count and number of distinct flows.

* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set TTL of the packets to *10*.

Verify:

* Policy forwarding packet counters matches the packet count of traffic
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we clarify which counter this is expected to be? I assume that it is the matched-packets path that is defined below?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it's matched-packets, updated the test cases to reflect this.

generated from ATE:Port1.
* The packet count of traffic sent from ATE:Port1 should be equal to the sum
of all packets egressing DUT ports 2 to 5.
* All packets egressing DUT ports 2 to 5 are GUE encapsulated.
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems to be harder to verify if we have DUM in the topology -- in the scenario that we are using ATE here I think we can do this with ingress accounting or pcap, but otherwise don't we need to pcap on DUM?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated the topology to use one device only and we can do ingress accounting on ATE.

* ECMP hashing works (equal traffic) over the two LAG interfaces.
* LAG hashing works (equal traffic) over the two Singleton ports.
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps just clarify that the 'two Singleton ports' here are the individual ports within LAG1 and LAG2 -- you are not saying that we need to check the ATE-DUT and ATE-DUM interfaces AIUI.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ack, done.

* ToS for all GUE encapsulated packets:
* GUE header ToS is **0x80**.
robshakir marked this conversation as resolved.
Show resolved Hide resolved
* Inner header ToS is **0x80**.
* TTL for all GUE encapsulated packets:
* GUE header TTL is **9**.
* Inner header TTL is **9**.

### PF-1.3.2: IPv6 traffic GUE encapsulation without explicit ToS/TTL configuration on tunnel

ATE action:

* Generate **IPv6 traffic** from ATE:Port1 to random IP addresses in
IPv6-DST-NET using a random combination source addresses at linerate.
* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set TTL of the packets to *10*.

Verify:
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comments here as above w.r.t clarifications.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So these are the un-encapsulated packets from ATE:Port1, did you mean to state again in the bullets?


* Policy forwarding packet counters matches the packet count of traffic
generated from ATE:Port1.
* The packet count of traffic sent from ATE:Port1 should be equal to the sum
of all packets egressing DUT ports 2 to 5.
* All packets egressing DUT ports 2 to 5 are GUE encapsulated.
* ECMP hashing works (equal traffic) over the two LAG interfaces.
* LAG hashing works (equal traffic) over the two Singleton ports.
* ToS for all GUE encapsulated packets:
* GUE header ToS is **0x80**.
* Inner header Traffic Class is **0x80**.
* TTL for all GUE encapsulated packets:
* GUE header TTL is **9**.
* Inner header Hop Limit is **9**.

### PF-1.3.3: IPv4 traffic GUE encapsulation with explicit ToS configuration on tunnel

DUT and ATE actions:

* Re-configure the IPv4 GUE tunnel on the DUT with ToS value *0x60*.
* Generate **IPv4 traffic** from ATE:Port1 to random IP addresses in
Copy link
Contributor

Choose a reason for hiding this comment

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

Again, I think it's worth clarifying the minimum entropy that you expect here. Something like "ensuring that there are at least X unique source-destination pairs".

Copy link
Member

Choose a reason for hiding this comment

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

I would specify the number of 5 tuple flows and a fixed number of packets to send from ATE port 1. Then the validation should have some number of packets received on each ATE port 2 interface +/- some tolerance.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated to specify fixed packet count and number of distinct flows.

IPv4-DST-NET using a random combination source addresses at linerate.
* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set TTL of the packets to *10*.

Verify:
Copy link
Contributor

Choose a reason for hiding this comment

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

Ditto re: clarifications from the IPv4 case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These are the un-encapsulated packets from ATE:Port1, did you mean to state again in the bullets?

Copy link
Contributor

Choose a reason for hiding this comment

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

I just meant to ensure that we make the same clarifications that were expressed above in this section. It looks like you did.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok cool.


* Policy forwarding packet counters matches the packet count of traffic
generated from ATE:Port1.
* The packet count of traffic sent from ATE:Port1 should be equal to the sum
of all packets egressing DUT ports 2 to 5.
* All packets egressing DUT ports 2 to 5 are GUE encapsulated.
* ECMP hashing works (equal traffic) over the two LAG interfaces.
* LAG hashing works (equal traffic) over the two Singleton ports.
* ToS for all GUE encapsulated packets:
* GUE header ToS is **0x60**.
* Inner header ToS is **0x80**.
* TTL for all GUE encapsulated packets:
* GUE header TTL is **9**.
* Inner header TTL is **9**.

### PF-1.3.4: IPv6 traffic GUE encapsulation with explicit ToS configuration on tunnel
robshakir marked this conversation as resolved.
Show resolved Hide resolved

DUT and ATE actions:

* Re-configure the IPv4 GUE tunnel on the DUT with ToS value *0x60*.
* Generate **IPv6 traffic** from ATE:Port1 to random IP addresses in
IPv4-DST-NET using a random combination source addresses at linerate.
* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set TTL of the packets to *10*.

Verify:

* Policy forwarding packet counters matches the packet count of traffic
generated from ATE:Port1.
* The packet count of traffic sent from ATE:Port1 should be equal to the sum
of all packets egressing DUT ports 2 to 5.
* All packets egressing DUT ports 2 to 5 are GUE encapsulated.
* ECMP hashing works (equal traffic) over the two LAG interfaces.
* LAG hashing works (equal traffic) over the two Singleton ports.
* ToS for all GUE encapsulated packets:
* GUE header ToS is **0x60**.
* Inner header Traffic Class is **0x80**.
* TTL for all GUE encapsulated packets:
* GUE header TTL is **9**.
* Inner header Hop Limit is **9**.

### PF-1.3.5: IPv4 traffic GUE encapsulation with explicit TTL configuration on tunnel

DUT and ATE actions:

* Re-configure the IPv4 GUE tunnel on the DUT without an explicit ToS value.
* Re-configure the IPv4 GUE tunnel on the DUT with TTL value of *20*.
* Generate **IPv4 traffic** from ATE:Port1 to random IP addresses in
IPv4-DST-NET using a random combination source addresses at linerate.
* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set TTL of the packets to *10*.

Verify:

* Policy forwarding packet counters matches the packet count of traffic
generated from ATE:Port1.
* The packet count of traffic sent from ATE:Port1 should be equal to the sum
of all packets egressing DUT ports 2 to 5.
* All packets egressing DUT ports 2 to 5 are GUE encapsulated.
* ECMP hashing works (equal traffic) over the two LAG interfaces.
* LAG hashing works (equal traffic) over the two Singleton ports.
* ToS for all GUE encapsulated packets:
* GUE header ToS is **0x80**.
* Inner header ToS is **0x80**.
* TTL for all GUE encapsulated packets:
* GUE header TTL is **20**.
* Inner header TTL is **9**.

### PF-1.3.6: IPv6 traffic GUE encapsulation with explicit TTL configuration on tunnel
Copy link
Member

Choose a reason for hiding this comment

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

IMO, it is ok to say, modify the flows in PF-1.3.5 to using IPv6 and repeat the traffic generation and validation. This is likely how one would write the code for this anyways.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ack, updated the IPv6 versions to be this way.

Copy link
Contributor

Choose a reason for hiding this comment

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

Are all of the parameters that we want to specify the same between IPv4 and IPv6? It seems OK to do this as long as we need no modifications and (of course) we assume that IPv4 field names are translated to v6 ones. (I didn't mind the repetition for clarity.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, all the parameters are the same. IPv4 ToS/TTL fields will be translated to IPv6 Traffic Class/Hop Limit respectively. Hope this works, otherwise let me know and I'll repeat with just these two field names being different.


DUT and ATE actions:

* Re-configure the IPv4 GUE tunnel on the DUT without an explicit ToS value.
* Re-configure the IPv4 GUE tunnel on the DUT with TTL value of *20*.
* Generate **IPv6 traffic** from ATE:Port1 to random IP addresses in
IPv4-DST-NET using a random combination source addresses at linerate.
* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set TTL of the packets to *10*.

Verify:

* Policy forwarding packet counters matches the packet count of traffic
generated from ATE:Port1.
* The packet count of traffic sent from ATE:Port1 should be equal to the sum
of all packets egressing DUT ports 2 to 5.
* All packets egressing DUT ports 2 to 5 are GUE encapsulated.
* ECMP hashing works (equal traffic) over the two LAG interfaces.
* LAG hashing works (equal traffic) over the two Singleton ports.
* ToS for all GUE encapsulated packets:
* GUE header ToS is **0x80**.
* Inner header Traffic Class is **0x80**.
* TTL for all GUE encapsulated packets:
* GUE header TTL is **20**.
* Inner header Hop Limit is **9**.

### PF-1.3.7: IPv4 traffic GUE encapsulation with explicit ToS and TTL configuration on tunnel

DUT and ATE actions:

* Re-configure the IPv4 GUE tunnel on the DUT with ToS value *0x60*.
* Re-configure the IPv4 GUE tunnel on the DUT with TTL value of *20*.
* Generate **IPv4 traffic** from ATE:Port1 to random IP addresses in
IPv4-DST-NET using a random combination source addresses at linerate.
* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set TTL of the packets to *10*.

Verify:

* Policy forwarding packet counters matches the packet count of traffic
generated from ATE:Port1.
* The packet count of traffic sent from ATE:Port1 should be equal to the sum
of all packets egressing DUT ports 2 to 5.
* All packets egressing DUT ports 2 to 5 are GUE encapsulated.
* ECMP hashing works (equal traffic) over the two LAG interfaces.
* LAG hashing works (equal traffic) over the two Singleton ports.
* ToS for all GUE encapsulated packets:
* GUE header ToS is **0x60**.
* Inner header ToS is **0x80**.
* TTL for all GUE encapsulated packets:
* GUE header TTL is **20**.
* Inner header TTL is **9**.

### PF-1.3.8: IPv6 traffic GUE encapsulation with explicit ToS and TTL configuration on tunnel

DUT and ATE actions:

* Re-configure the IPv4 GUE tunnel on the DUT with ToS value *0x60*.
* Re-configure the IPv4 GUE tunnel on the DUT with TTL value of *20*.
* Generate **IPv6 traffic** from ATE:Port1 to random IP addresses in
IPv4-DST-NET using a random combination source addresses at linerate.
* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set TTL of the packets to *10*.

Verify:

* Policy forwarding packet counters matches the packet count of traffic
generated from ATE:Port1.
* The packet count of traffic sent from ATE:Port1 should be equal to the sum
of all packets egressing DUT ports 2 to 5.
* All packets egressing DUT ports 2 to 5 are GUE encapsulated.
* ECMP hashing works (equal traffic) over the two LAG interfaces.
* LAG hashing works (equal traffic) over the two Singleton ports.
* ToS for all GUE encapsulated packets:
* GUE header ToS is **0x60**.
* Inner header Traffic Class is **0x80**.
* TTL for all GUE encapsulated packets:
* GUE header TTL is **20**.
* Inner header Hop Limit is **9**.

### PF-1.3.9: IPv4 traffic that should be GUE encapsulation but TTL=1
robshakir marked this conversation as resolved.
Show resolved Hide resolved

ATE action:

* Generate **IPv4 traffic** from ATE:Port1 to random IP addresses in
IPv4-DST-NET using source address of ATE:Port1 at linerate.
* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set TTL of the packets to *1*.

Verify:

* All packets should have TTL decremented to 0, dropped and ICMP Time
Exceeded (Type 11) / Time to Live exceeded in Transit (Code 0) sent back to
source address (ATE:Port1).

### PF-1.3.10: IPv6 traffic that should be GUE encapsulation but Hop Limit=1

ATE action:

* Generate **IPv6 traffic** from ATE:Port1 to random IP addresses in
IPv4-DST-NET using source address of ATE:Port1 at linerate.
* Use 512 bytes frame size.
* Set ToS value of *0x80* for all packets.
* Set Hop Limit of the packets to *1*.

Verify:

* All packets should have Hop Limit decremented to 0, dropped and
ICMPv6 Time Exceeded (Type 3) / hop limit exceeded in transit (Code 0) sent
back to source address (ATE:Port1).

## OpenConfig Path and RPC Coverage

```yaml
paths:
# TODO propose new OC paths for GUE encap based on the protocol next hop of a route
Copy link
Member

Choose a reason for hiding this comment

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

It is true, new OC paths will be needed. FYI, they should follow the pattern being established in the /afts tree, but using /policy-forwarding instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ack, thanks for the pointer. I'll follow this to send proposal for the OC paths.


# telemetry
/network-instances/network-instance/policy-forwarding/policies/policy/rules/rule/state/matched-pkts:
/network-instances/network-instance/policy-forwarding/policies/policy/rules/rule/state/matched-octets:

rpcs:
gnmi:
gNMI.Set:
union_replace: true
replace: true
gNMI.Subscribe:
on_change: true
```
Loading
Loading