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/NETVIRT-871 netvirt <p>ISSUE : The SNAT implementation in the ODL chooses a NAPT switch among the control and compute nodes. In this NAPT switch node only the table 21 flows are written and in the non-NAPT switch these flows are absent.</p> <p> Due to this in the SNAT scenario when we initiate communication from the non-napt switch, it fails.</p> <p>This is due to the table 47 and table 21(few flows) flows that are absent in the non-napt switch node.</p> <p>This issue is seen in both the controller and conntrack mode, but the behavior is different in both these nodes.</p> <p>IN Controller Mode - The SNAT scenario when we initiate communication from the non-napt switch, it fails during the first attempt.Then when we try from the napt switch node SNAT works perfectly fine, </p> <p> After this step when we try to communicate from the other VM (non-napt switch node) it succeeds. </p> <p>This is due to the table 47 and table 21(few flows) flows that are absent in the non-napt switch node.</p> <p> Once we establish the communication from the VM in the napt switch node, the table 21 flow occurs in the non-napt switch node.</p> <p>IN Conntrack Mode - From the non-napt switch SNAT fails completely , even after trying SNAT from the napt switch node VM. SNAT from the non-napt switch fails.</p> <p>Operating System: All<br/> Platform: All</p> NETVIRT-871

SNAT not working from Non-NAPT switch node

Bug Resolved Duplicate Unassigned YOGA LAKSHMI SWETHA PAYYAVULA Fri, 25 Aug 2017 07:46:15 +0000 Mon, 8 Apr 2019 16:58:30 +0000 Tue, 10 Oct 2017 05:53:00 +0000 Carbon General 0 10 <p>The non-NAPT switches will not have the table 47 entries. The packet will be forwarded to tunnel from table 26 to the NAPT switch and translation happens in NAPT switch.</p> <p>Could you please provide the flow dumps in NAPT and Non NAPT switches.</p> <p>PFA for the dump flows for napt and non-napt switches</p> <p>Attachment dump_flows_9035 has been added with description: dump flows</p> <p>Please ignore the previous attachment</p> <p>Attachment Dumpflows_9053.txt has been added with description: Napt and no-napt flows</p> <p>Steps to Reproduce the Issue in Controller Mode :</p> <p>1. Create Internal Network, Subnet<br/> 2. Create 2 VM's for the internal network<br/> 3. Create External Network and subnet<br/> 4. Create router and associate the router to both the networks<br/> 5. From the Non-Napt Switch VM initiate SNAT communication</p> <p>SNAT Communication FAILS</p> <p>6. From the Napt Switch VM initiate the SNAT communication it succeeds<br/> 7. Repeat the Step5, now the SNAT works fine</p> <p>IN Conntrack Mode - From the non-napt switch SNAT fails completely , even after trying SNAT from the napt switch node VM. SNAT from the non-napt switch fails.<br/> The Step 5 and Step 7 both fails.</p> <p>Could you please upload the flows in conntrack mode as well? Also where you able to locate where exactly the packet is dropped? In conntrack mode ping is supported so you can try it , which will give sufficient packet count to trace where it is dropped. I don't see packet counts for table 26 and for router mac flow in table 19 in the flow dump. Is it passing successfully through the acl tables?</p> <p>Attachment karaf.log.zip has been added with description: ODL log</p> <p>(In reply to Aswin Suryanarayanan from comment #5)<br/> &gt; Could you please upload the flows in conntrack mode as well? Also where you<br/> &gt; able to locate where exactly the packet is dropped? In conntrack mode ping<br/> &gt; is supported so you can try it , which will give sufficient packet count to<br/> &gt; trace where it is dropped. I don't see packet counts for table 26 and for<br/> &gt; router mac flow in table 19 in the flow dump. Is it passing successfully<br/> &gt; through the acl tables?</p> <p>Aswin,<br/> Attached the conntrack flows for control and compute nodes. </p> <p> case1: initiate ping from Non NAPT switch at first.<br/> compute node 1 selected as NAPT switch , when we initiate ping first time from VM instance(30.0.0.7) created in compute node2.<br/> Not getting dropped in the compute node1, finally the packet reaching table 22 flow.<br/> cookie=0x8000004, duration=1474.961s, table=22, n_packets=254, n_bytes=24892, priority=0 actions=CONTROLLER:65535<br/> and ping failed.<br/> controller log some error are displayed.</p> <p> ERROR:<br/> 2017-09-22 16:03:02,767 | ERROR | pool-16-thread-1 | SubnetRoutePacketInHandler | 360 - org.opendaylight.netvirt.vpnmanager-impl - 0.4.2.SNAPSHOT | Vpn interface tune09d81ac14f doesn't exist.<br/> 2017-09-22 16:03:03,769 | ERROR | pool-16-thread-1 | SubnetRoutePacketInHandler | 360 - org.opendaylight.netvirt.vpnmanager-impl - 0.4.2.SNAPSHOT | Vpn interface tune09d81ac14f doesn't exist.<br/> 2017-09-22 16:03:04,770 | ERROR | pool-16-thread-1 | SubnetRoutePacketInHandler | 360 - org.opendaylight.netvirt.vpnmanager-impl - 0.4.2.SNAPSHOT | Vpn interface tune09d81ac14f doesn't exist.<br/> 2017-09-22 16:03:05,769 | ERROR | pool-16-thread-1 | SubnetRoutePacketInHandler | 360 - org.opendaylight.netvirt.vpnmanager-impl - 0.4.2.SNAPSHOT | Vpn interface tune09d81ac14f doesn't exist.<br/> 2017-09-22 16:03:06,772 | ERROR | pool-16-thread-1 | SubnetRoutePacketInHandler | 360 - org.opendaylight.netvirt.vpnmanager-impl - 0.4.2.SNAPSHOT | Vpn interface tune09d81ac14f doesn't exist.<br/> 2017-09-22 16:03:47,494 | INFO | pool-16-thread-1 | ArpUtils | 360 - org.opendaylight.netvirt.vpnmanager-impl - 0.4.2.SNAPSHOT | SubnetRoutePacketInHandler: sendArpRequest dpnId 225338375821825, actions [], groupId 210006, senderIPAddress 192.168.90.21, targetIPAddress 192.168.90.1<br/> 2017-09-22 16:03:47,564 | ERROR | pool-16-thread-1 | EvpnUtils | 368 - org.opendaylight.netvirt.elanmanager-impl - 0.4.2.SNAPSHOT | getEvpnRd : evpnName is NULL for elanInfo ElanInstance{getElanInstanceName=9143b3ce-1c14-4862-9afa-fad50ed780b8, getElanSegments=[], getElanTag=5003, getMacTimeout=300, getPhysicalNetworkName=physnet1, getSegmentType=class org.opendaylight.yang.gen.v1.urn.opendaylight.netvirt.elan.rev150602.SegmentTypeFlat, isExternal=true, augmentations={}}<br/> 2017-09-22 16:03:47,564 | ERROR | pool-16-thread-1 | EvpnUtils | 368 - org.opendaylight.netvirt.elanmanager-impl - 0.4.2.SNAPSHOT | advertisePrefix : rd is NULL for elanInfo ElanInstance{getElanInstanceName=9143b3ce-1c14-4862-9afa-fad50ed780b8, getElanSegments=[], getElanTag=5003, getMacTimeout=300, getPhysicalNetworkName=physnet1, getSegmentType=class org.opendaylight.yang.gen.v1.urn.opendaylight.netvirt.elan.rev150602.SegmentTypeFlat, isExternal=true, augmentations={}}, macAddress 00:0C:29:4D:9A:B</p> <p> when we initiate ping from the VM instance (30.0.0.8) napt switch ,<br/> ping succeed and I could see the dynamic flow installed in table 21. after the packets sent to controller from the flow <br/> cookie=0x8000004, duration=1474.961s, table=22, n_packets=254, n_bytes=24892, priority=0 actions=CONTROLLER:65535</p> <p> dynamic flow created "cookie=0x8000003, duration=2223.586s, table=21, n_packets=63, n_bytes=6174, priority=42,ip,metadata=0x30d42/0xfffffe,nw_dst=192.168.90.1 actions=set_field:00:0c:29:4d:9a:b5-&gt;eth_dst,load:0x400-&gt;NXM_NX_REG6[],resubmit(,220)"</p> <p> case 2: initiate ping from Non NAPT switch after ping succeed from NAPT switch.</p> <p> In this case also ping from Non NAPT failed.<br/> packets reached NAPT switch and getting dropped in table 220.<br/> cookie=0x8000007, duration=3619.781s, table=220, n_packets=59, n_bytes=5782, priority=10,reg6=0x400,metadata=0x1/0x1 actions=drop</p> <p> attached case1 and case2 complete logs.</p> <p>Attachment compute1_napt_case1.zip has been added with description: compute node1 dump flow for case 1</p> <p>Attachment compute1_napt_case2.zip has been added with description: compute node1 dump flow for case 2</p> <p>Attachment compute2_non_napt_case1.zip has been added with description: compute node2 dump flow for case 1</p> <p>Attachment compute2_non_napt_case2.zip has been added with description: compute node2 dump flow for case 2</p> <p>Attachment control_node_case1.zip has been added with description: control node dump flow for case 1</p> <p>Attachment control_node_case2.zip has been added with description: controlnode dump flow for case 2</p> <p>Is this 192.168.90.1 your gateway? If so, the table21 flow should be installed when the router g/w is set and not by the subnet route handler, if you had set the g/w while creating the subnet.</p> <p>If it is a PNF you may be hitting <span class="error">&#91;1&#93;</span>. are you working with the latest code?</p> <p><span class="error">&#91;1&#93;</span>https://bugs.opendaylight.org/show_bug.cgi?id=8882</p> <p>(In reply to Aswin Suryanarayanan from comment #14)<br/> &gt; Is this 192.168.90.1 your gateway? If so, the table21 flow should be<br/> &gt; installed when the router g/w is set and not by the subnet route handler, if<br/> &gt; you had set the g/w while creating the subnet.<br/> &gt; <br/> &gt; If it is a PNF you may be hitting <span class="error">&#91;1&#93;</span>. are you working with the latest code?<br/> &gt; <br/> &gt; <span class="error">&#91;1&#93;</span>https://bugs.opendaylight.org/show_bug.cgi?id=8882</p> <p>Hi Aswin,</p> <p> 192.168.90.1 is not gateway.<br/> it is a external host we are trying to reach.<br/> the code we used for testing is bit old taken on august mid stable/carbon release.</p> <p>tried to evaluate the same in latest build<span class="error">&#91;1&#93;</span> seems patch part auto creation is failing.</p> <p>after executing below commands old code creating patch port between br-int and br-ex with new code patch port is not created automatically,<br/> is there any open bug for patch port creation?</p> <p><span class="error">&#91;1&#93;</span>https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.6.2-SNAPSHOT/distribution-karaf-0.6.2-20170925.072222-788.tar.gz</p> <p> Aswin,<br/> Tested with latest stable/carbon build still i am facing the same issue.<br/> ping failed from non-NAPT switch.<br/> used <span class="error">&#91;1&#93;</span> build for testing does it have your fix <span class="error">&#91;2&#93;</span><br/> only DNAT is working in below distribution.</p> <p><span class="error">&#91;1&#93;</span>https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.6.2-SNAPSHOT/distribution-karaf-0.6.2-20170926.152417-792.tar.gz</p> <p><span class="error">&#91;2&#93;</span>https://bugs.opendaylight.org/show_bug.cgi?id=8882</p> <p>I am using br-ex for external network communication <br/> OVS show output:</p> <p>c296d41b-bfe9-49a0-98b0-0e80d6303793<br/> Manager "tcp:192.168.80.1:6640"<br/> is_connected: true<br/> Manager "ptcp:6641:127.0.0.1"<br/> is_connected: true<br/> Bridge br-int<br/> Controller "tcp:192.168.80.1:6653"<br/> is_connected: true<br/> fail_mode: secure<br/> Port br-int<br/> Interface br-int<br/> type: internal<br/> Port "tapa8524892-a1"<br/> Interface "tapa8524892-a1"<br/> Port "tun4631a9da8ce"<br/> Interface "tun4631a9da8ce"<br/> type: vxlan<br/> options: </p> {key=flow, local_ip="192.168.80.1", remote_ip="192.168.80.3"} <p> Port "tapebfc53aa-ab"<br/> Interface "tapebfc53aa-ab"<br/> Port br-ex-patch<br/> Interface br-ex-patch<br/> type: patch<br/> options: </p> {peer=br-ex-int-patch} <p> Port "tun3811195a8d9"<br/> Interface "tun3811195a8d9"<br/> type: vxlan<br/> options: </p> {key=flow, local_ip="192.168.80.1", remote_ip="192.168.80.2"} <p> Bridge br-ex<br/> Port br-ex<br/> Interface br-ex<br/> type: internal<br/> Port "ens36"<br/> Interface "ens36"<br/> Port br-ex-int-patch<br/> Interface br-ex-int-patch<br/> type: patch<br/> options: </p> {peer=br-ex-patch} <p> ovs_version: "2.6.1"</p> <p>Are you seeing any error logs ? Did you use conntrack/controller mode? Ping works only in conntrack mode.</p> <p>Hi Ashwin,</p> <p> We tested the SNAT scenario from Non-Napt switch in the conntrack mode, It is working fine. But we are yet to test in the controller mode,<br/> We used the below distro for testing :</p> <p><span class="error">&#91;1&#93;</span>https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.6.2-SNAPSHOT/distribution-karaf-0.6.2-20170925.072222-788.tar.gz.</p> <p>Thank you</p> <p>Hi Ashwin,</p> <p> We tested the SNAT scenario from Non-Napt switch in the conntrack mode, It is working fine. But we are yet to test in the controller mode,<br/> We used the below distro for testing :</p> <p><span class="error">&#91;1&#93;</span>https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.6.2-SNAPSHOT/distribution-karaf-0.6.2-20170925.072222-788.tar.gz.</p> <p>Thank you</p> <p>Hi Ashwin,</p> <p> We tested the SNAT scenario from Non-Napt switch in the conntrack mode, It is working fine. But we are yet to test in the controller mode,<br/> We used the below distro for testing :</p> <p><span class="error">&#91;1&#93;</span>https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.6.2-SNAPSHOT/distribution-karaf-0.6.2-20170925.072222-788.tar.gz.</p> <p>Thank you</p> <p>Hi Ashwin,</p> <p> We tested in the Controller mode, SNAT is working fine from a Non-Napt Switch node.We used the same distro (as mentioned in the last comment). Everything is working fine.</p> <p>Thank you</p> Duplicate NETVIRT-803 Development External issue ID 9053 External issue URL Rank 0|i01uh3: