https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/SFC-203 sfc <p>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:</p> <p>NSH base nsp: 48, nsi: 255<br/> NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800<br/> NSH base nsp: 48, nsi: 254<br/> NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800<br/> NSH base nsp: 48, nsi: 253<br/> NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800<br/> NSH base nsp: 48, nsi: 252<br/> NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800<br/> NSH base nsp: 48, nsi: 251<br/> NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800</p> <p>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</p> <p>Operating System: All<br/> Platform: All</p> SFC-203

vxlan_tool not working correctly when packet comes from vxlan-gpe tunnel

Bug Resolved Done Manuel Buil Manuel Buil Wed, 27 Sep 2017 10:02:33 +0000 Mon, 16 Oct 2017 08:37:53 +0000 Mon, 16 Oct 2017 08:37:53 +0000 unspecified General 0 1 <p>Here is the patch that fixes it:</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/64116/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/64116/</a></p> Development External issue ID 9219 External issue URL Rank 0|i02fov: