[SFC-203] vxlan_tool not working correctly when packet comes from vxlan-gpe tunnel Created: 27/Sep/17  Updated: 16/Oct/17  Resolved: 16/Oct/17

Status: Resolved
Project: sfc
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Manuel Buil Assignee: Manuel Buil
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 9219

 Description   

In scenarios in which the client and SF1 are in different computes, if vxlan_tool is running in SF1, the vxlan_tool decrements the nsi, sends the packet back to the SFF as expected, but, it also consumes the packet which it just sent. Therefore, the tool starts generating packets artificially with decremented nsi:

NSH base nsp: 48, nsi: 255
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800
NSH base nsp: 48, nsi: 254
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800
NSH base nsp: 48, nsi: 253
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800
NSH base nsp: 48, nsi: 252
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800
NSH base nsp: 48, nsi: 251
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800

This breaks the topology in which two SFs are in one chain and deployed in the same compute and SF2 is blocking packets (firewall). As SF1 will generate packets with nsi=253, even if SF2 drops packets, the chain logic will decapsulate the nsi=253 packets and they will reach the destination

 Comments   
Comment by Manuel Buil [ 10/Oct/17 ]

Here is the patch that fixes it:

https://git.opendaylight.org/gerrit/#/c/64116/

Generated at Wed Feb 07 20:38:54 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.