[NETVIRT-1397] SNAT - UDP connection to External Gateway From SNAT VM Instance fails in itm-direct-tunnels jobs Created: 07/Aug/18  Updated: 19/Sep/18  Resolved: 19/Sep/18

Status: Resolved
Project: netvirt
Component/s: natservice
Affects Version/s: None
Fix Version/s: Fluorine-SR1

Type: Bug Priority: Medium
Reporter: Sam Hague Assignee: Chetan Arakere Gowdru
Resolution: Done Votes: 0
Labels: csit:failures
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The test randomly fails across the three vms.

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-0cmb-1ctl-2cmp-openstack-pike-upstream-stateful-itm-direct-tunnels-oxygen/21/

https://jenkins.opendaylight.org/releng/view/netvirt-csit/job/netvirt-csit-1node-0cmb-1ctl-2cmp-openstack-queens-upstream-stateful-itm-direct-tunnels-fluorine/26/robot/



 Comments   
Comment by Chetan Arakere Gowdru [ 17/Aug/18 ]

Hi Edwin/Hema,

 

I tried to narrow down this issue are following are the observation.

 

Ref: https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-0cmb-1ctl-2cmp-openstack-queens-gate-stateful-itm-direct-tunnels-fluorine/1/robot-plugin/log_03_external_network.html.gz#s1-t19

 

  1. An UDP packet is sent from Non-Napt Switch and enter via Tunnel-interface -tunaad8f9c7a1b. Note here the lport been set with value 2

cookie=0x8000001, duration=2756.820s, table=0, n_packets=6223, n_bytes=583936, priority=5,in_port=2 actions=write_metadata:0x20000000001/0xfffff0000000001,goto_table:36

 

  1. Now this packet entered NAT pipeline and been punted to ODL for programming SNAT flows.
  2. While sending packet the packet back to pipeline, using lport tag, we query the operational/odl-interface-meta:if-indexes-interface-map DS to get the interface name and found wrong interface name.
{ "if-index": 2, "interface-name": "66664030340515:br-physnet1-pa:trunk"}

 

  1. As a result, the packet is sent back to wrong dpn/interface(66664030340515:br-physnet1-pa) instead of sending back to tunnel port(tunaad8f9c7a1b).
  2. NAT first attempts to get the value from the above DS and if not found, will try to fetch from the packet. Since, in this case, if found an interface-name for a given lporttag, it sent to wrong interface(br-physnet1-pa) instead of sending to tunnel interface.

 

Question: Why the table 0->36 setting the lporttag with value 2 which is not valid for tunnel interface - tunaad8f9c7a1b ?

 

Thanks,

Chetan

Comment by Chetan Arakere Gowdru [ 21/Aug/18 ]

Hi Chetan,

  When you are using ITM direct tunnels,,all tunnel related information is stored by ITM and not interface manager. If you are referring to lport tag for a tunnel interface, then you should refer to operational/odl-itm-meta:if-indexes-tunnel-map.

The interface corresponding to the lport that you found in interface manager’s ifindexes map is that of vm interfaces and not tunnel interface.

Regards,

Hema

Comment by Chetan Arakere Gowdru [ 21/Aug/18 ]

Hi Hema,

 

Thanks for the input.

 

Is the if-index used for the tunnel-interface and other interface is not unique across these two DS(if-indexes-tunnel-map/ if-indexes-interface-map) ??

 

Thanks,

Chetan

Comment by Chetan Arakere Gowdru [ 21/Aug/18 ]

Hi Chetan,

  Yes, ifIndex has to be unique across tunnel and VM interfaces. In downstream ITM uses the same ID POOL as interface manager. This was not up-streamed correctly. I will raise a patch for this. Thanks for pointing this.

Thanks,

Hema

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