Re: [ovs-dev] [ovs-discuss][ovn][dhcp]Could ovn remove restriction of option 3(router)

[Dong Jun]

On 2017/3/3 1:33, Ben Pfaff wrote:

On Thu, Mar 02, 2017 at 07:15:48PM +0800, Dong Jun wrote:

An router IP MUST be set to dhcp v4 option for option 3, but not all subnet
do have a gateway IP. Furthermore,  if i set 0.0.0.0 to option as a
tradeoff, the VM can obtain client ip and a gateway error log occurred
meanwhile.

It seems that it's not a  restriction in RFC 2132, as comparison dnsmaq can
offer a no-router-ip option.

So could ovn remove this restriction or is there anther way to meet the
requirement?

It took me a while to figure out what you're talking about.  Are you
asking whether options:router could be changed from mandatory to
optional in the DHCP_Options table for DHCPv4?

Yes, i think it's better to be optional.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [ovn] What's the manner of sending GARP for distributed dnat_and_snat?

[Dong Jun]

Thanks, get it.


On 2017/1/25 16:30, Mickey Spiegel wrote:


On Wed, Jan 25, 2017 at 12:26 AM, Dong Jun <do...@dtdream.com 
<mailto:do...@dtdream.com>> wrote:


Hi

I learned about the distributed dnat_and_snat. Now I don't see
what's the manner of sending GARP for distributed dnat_and_snat
IP. In the past, we set nat_addresses column in lsp that connected
to gateway lrp. Now the type of lrp was changed from l3gateway to
patch, does this affect GARP for distributed dnat_and_snat IP?


GARP is not supported in the current patch set for distributed NAT. I 
have started working on a couple of patches for GARP with distributed 
NAT. The first patch is allowing options nat-addresses to be set to 
the string "router", in which case northd will collect all the NAT 
external IP addresses and load balancer IP addresses from VIPs and set 
the port_binding nat-addresses correspondingly. The second patch will 
extend GARP functionality for distributed NAT, by replacing options 
nat-addresses with a column nat_addresses that with max:unlimited, and 
the optional addition of a port name to the end of the string. When 
the port name is present, GARP will only be issued for the addresses 
in that column on the chassis where the specified port is resident.


Mickey



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [ovn] What's the manner of sending GARP for distributed dnat_and_snat?

[Dong Jun]

Hi

I learned about the distributed dnat_and_snat. Now I don't see 
what's the manner of sending GARP for distributed dnat_and_snat IP. In 
the past, we set nat_addresses column in lsp that connected to gateway 
lrp. Now the type of lrp was changed from l3gateway to patch, does this 
affect GARP for distributed dnat_and_snat IP?



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Issues with the use of the clone action for resubmission to the pipeline

[Dong Jun]

On 2017/1/7 17:14, Dong Jun wrote:
I tested my 
issue(https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326936.html)

withpatch serial v3 1-4 (http://patchwork.ozlabs.org/patch/712028/).

It sounds a little vague, i mean all four patches from 1/4 to 4/4.


The issue has been resolved. Gateway NAT and floating ip NAT both 
worked well and conntrack

flows were completed as well.
Thank you.


On 2017/1/6 20:24, Numan Siddique wrote:



On Fri, Jan 6, 2017 at 9:52 AM, Ben Pfaff <b...@ovn.org 
<mailto:b...@ovn.org>> wrote:


On Thu, Jan 05, 2017 at 05:54:46PM -0800, Jarno Rajahalme wrote:
>
> > On Jan 5, 2017, at 4:28 PM, Ben Pfaff <b...@ovn.org
<mailto:b...@ovn.org>> wrote:
> >
> > On Tue, Jan 03, 2017 at 02:55:19AM -0800, Mickey Spiegel wrote:
> >> One of the motivations for clone is to use it as a
lightweight way to
> >> resubmit to an earlier table at the beginning of the
pipeline, without
> >> incurring all of the overhead associated with openflow patch
ports.
> >> One such usage is in OVN, where a recent patch set replaced the
> >> use of openflow patch ports with clone, for OVN patch ports
within
> >> the same bridge (br-int).
> >>
> >> Over the holidays, some issues arose related to this usage of
clone
> >> (see the thread ovn ping from VM to external gateway IP 
failed).

> >
> > Thanks for bringing this up.  I had overlooked these questions
and this
> > issue.
> >
> > I guess that we should save and restore this since we're 
saving and

> > restoring the conntrack metadata.  I've written up a patch.
> >
> >>   ctx->was_mpls
> >
> > I do not think that that this is a correctness issue, but it's
a nice
> > optimization to save and restore this.  I've written up a patch.
>
> I think the rationale is that ‘was_mpls’ is used to track the
validity
> of the flow key across an MPLS POP operation. Since the flow 
key is

> saved and restored, we should save and restore ‘was_mpls’ as well.

OK.  I did send a patch that adds that.  Do you want to make a
suggestion for the commit message?  I may not fully understand the
issue
yet, so I don't think the commit message is very good.

Here's the patch:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327207.html
<https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327207.html>

> >>   ctx->xin->tables_version (not an issue if bridge does not
change)
> >
> > clone doesn't change the bridge, so this shouldn't matter.
> >
> >>   ctx->stack
> >>   ctx->action_set
> >
> > I think it's cleanest if a clone starts off with both of these
empty and
> > saves and restores them.  I've written up a patch.
>
> I think saving and restoring is needed, but I’m not so sure of
> clearing these. However, it seems that there is no way for the
action
> set to be executed within the clone, so I guess it does not 
matter.


I guess that it would also be a clean design, and consistent with
my new
ct_clear action, to not clear them but instead to start from a
copy and
allow for clearing them explicitly within the clone.

There is already an instruction to clear the action set, so we
wouldn't
need to add anything.  I think that the action set can only affect
what
happens inside the clone in terms of matches or actions based on the
actset_output field, though.

I'm not sure of the value of an action to clear the stack, so I'd be
inclined to hold off on that until we think of one.

I'll revise my patch to work this way.

> It would be good to add these changes to the documentation as 
well.


My patch does update the documentation on this point.


​Thanks Ben for all the fixes. We are in middle of performance 
testing with the version of ovn-controller which creates patch ports 
for router ports.


Once this is done, we will be able to test with the patches you have 
proposed.


​Dong Jun- May be if you want to test these patches and I see if it 
resolves the issues which you had posted.

​

Thanks
Numan


___
dev mailing list
d...@openvswitch.org <mailto:d...@openvswitch.org>
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
<https://mail.openvswitch.org/mailman/listinfo/ovs-dev>




___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Issues with the use of the clone action for resubmission to the pipeline

[Dong Jun]

I tested my 
issue(https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326936.html)

withpatch serial v3 1-4 (http://patchwork.ozlabs.org/patch/712028/).

The issue has been resolved. Gateway NAT and floating ip NAT both worked 
well and conntrack

flows were completed as well.
Thank you.


On 2017/1/6 20:24, Numan Siddique wrote:



On Fri, Jan 6, 2017 at 9:52 AM, Ben Pfaff <b...@ovn.org 
<mailto:b...@ovn.org>> wrote:


On Thu, Jan 05, 2017 at 05:54:46PM -0800, Jarno Rajahalme wrote:
>
> > On Jan 5, 2017, at 4:28 PM, Ben Pfaff <b...@ovn.org
<mailto:b...@ovn.org>> wrote:
> >
> > On Tue, Jan 03, 2017 at 02:55:19AM -0800, Mickey Spiegel wrote:
> >> One of the motivations for clone is to use it as a
lightweight way to
> >> resubmit to an earlier table at the beginning of the
pipeline, without
> >> incurring all of the overhead associated with openflow patch
ports.
> >> One such usage is in OVN, where a recent patch set replaced the
> >> use of openflow patch ports with clone, for OVN patch ports
within
> >> the same bridge (br-int).
> >>
> >> Over the holidays, some issues arose related to this usage of
clone
> >> (see the thread ovn ping from VM to external gateway IP failed).
> >
> > Thanks for bringing this up.  I had overlooked these questions
and this
> > issue.
> >
> > I guess that we should save and restore this since we're saving and
> > restoring the conntrack metadata.  I've written up a patch.
> >
> >>   ctx->was_mpls
> >
> > I do not think that that this is a correctness issue, but it's
a nice
> > optimization to save and restore this.  I've written up a patch.
>
> I think the rationale is that ‘was_mpls’ is used to track the
validity
> of the flow key across an MPLS POP operation. Since the flow key is
> saved and restored, we should save and restore ‘was_mpls’ as well.

OK.  I did send a patch that adds that.  Do you want to make a
suggestion for the commit message?  I may not fully understand the
issue
yet, so I don't think the commit message is very good.

Here's the patch:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327207.html
<https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327207.html>

> >>   ctx->xin->tables_version (not an issue if bridge does not
change)
> >
> > clone doesn't change the bridge, so this shouldn't matter.
> >
> >>   ctx->stack
> >>   ctx->action_set
> >
> > I think it's cleanest if a clone starts off with both of these
empty and
> > saves and restores them.  I've written up a patch.
>
> I think saving and restoring is needed, but I’m not so sure of
> clearing these. However, it seems that there is no way for the
action
> set to be executed within the clone, so I guess it does not matter.

I guess that it would also be a clean design, and consistent with
my new
ct_clear action, to not clear them but instead to start from a
copy and
allow for clearing them explicitly within the clone.

There is already an instruction to clear the action set, so we
wouldn't
need to add anything.  I think that the action set can only affect
what
happens inside the clone in terms of matches or actions based on the
actset_output field, though.

I'm not sure of the value of an action to clear the stack, so I'd be
inclined to hold off on that until we think of one.

I'll revise my patch to work this way.

> It would be good to add these changes to the documentation as well.

My patch does update the documentation on this point.


​Thanks Ben for all the fixes. We are in middle of performance testing 
with the version of ovn-controller which creates patch ports for 
router ports.


Once this is done, we will be able to test with the patches you have 
proposed.


​Dong Jun- May be if you want to test these patches and I see if it 
resolves the issues which you had posted.

​

Thanks
Numan


___
dev mailing list
d...@openvswitch.org <mailto:d...@openvswitch.org>
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
<https://mail.openvswitch.org/mailman/listinfo/ovs-dev>




___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] ovn ping from VM to external gateway IP failed.

[Dong Jun]

On 2017/1/3 12:59, Numan Siddique wrote:



On Tue, Jan 3, 2017 at 2:06 AM, Mickey Spiegel <mickeys@gmail.com 
<mailto:mickeys@gmail.com>> wrote:



On Mon, Jan 2, 2017 at 3:46 AM, Numan Siddique
<nusid...@redhat.com <mailto:nusid...@redhat.com>> wrote:



On Mon, Jan 2, 2017 at 2:07 AM, Mickey Spiegel
<mickeys@gmail.com <mailto:mickeys@gmail.com>> wrote:


On Sun, Jan 1, 2017 at 10:31 AM, Numan Siddique
<nusid...@redhat.com <mailto:nusid...@redhat.com>> wrote:



On Sun, Jan 1, 2017 at 6:39 AM, Mickey Spiegel
<mickeys@gmail.com <mailto:mickeys@gmail.com>>
wrote:


On Sat, Dec 31, 2016 at 1:19 AM, Mickey Spiegel
<mickeys@gmail.com
<mailto:mickeys@gmail.com>> wrote:


On Fri, Dec 30, 2016 at 11:37 AM, Mickey
Spiegel <mickeys@gmail.com
<mailto:mickeys@gmail.com>> wrote:


On Fri, Dec 30, 2016 at 7:46 AM, Numan
Siddique <nusid...@redhat.com
<mailto:nusid...@redhat.com>> wrote:

        On Fri, Dec 30, 2016 at 5:36 PM, Dong
Jun <do...@dtdream.com
<mailto:do...@dtdream.com>> wrote:




​
Hi Dong Jun, I am also facing the same
issue on my setup.
​
These are the findings of my
investigation so far

Looks like this issue is seen after
the commit

https://github.com/openvswitch/ovs/commit/f1a8bd06d58f2c5312622fbaeacbc6ce7576e347

<https://github.com/openvswitch/ovs/commit/f1a8bd06d58f2c5312622fbaeacbc6ce7576e347>
​
which removes the usage of patch ports
and uses the clone action instead.
​

I reverted to the commit just before
it and SNAT/DNAT is working as
expected.

In my case, the gateway router is
hosted on node 1 and the I am trying to
reach a VM (192.168.0.5) hosted on
node 2 using the external ip
(10.2.7.105) associated ​with it. I
could see that the node 1 is sending
the packet to node 2 through the
geneve tunnel, but it is dropped by node 2
flows.

Below is the tcpdump of the packet

**
19:39:44.709907 IP 182.16.0.16.60069 >
182.16.0.15.geneve: Geneve, Flags
[none], vni 0x1: IP
nusiddiq.blr.redhat.com
<http://nusiddiq.blr.redhat.com> >
192.168.0.5 <http://192.168.0.5>: ICMP
echo
request, id 13240, seq 1, length 64
***

Below is the tcpdump of the packet
with the ovn-controller (without the
above commit) in the working case

**
19:41:56.783570 IP 182.16.0.12.29778 >
182.16.0.15.geneve: Geneve, Flags
[C], vni 0x1, options [8 bytes]: IP
nusiddiq.blr.redhat.com
<http://nusiddiq.blr.redhat.com> >
192.168.0.5 <http://192.168.0.5>:
ICMP echo request, id 13308, seq 1,
length 64
19:41:56.784270 IP 182.16.0.15.14539 >
182.16.0.12.geneve: Geneve, Flags
[C], vni 0xf, options [8 bytes]: IP
192.168.0.5 > nusiddiq.blr.redhat.com
 

[ovs-dev] ovn ping from VM to external gateway IP failed.

[Dong Jun]

Start devstack in one node(master code).

(10.0.0.7)vm --- (10.0.0.1)dr(169.254.128.2) --- 
(169.254.128.1)ogr(172.24.4.10)  --- (172.24.4.1)br-ex

(fip 172.24.4.7)

$ ip addr show eth0
2: eth0:  mtu 1442 qdisc pfifo_fast 
qlen 1000

inet 10.0.0.7/26 brd 10.0.0.63 scope global eth0
*ping from 10.0.0.7 to 172.24.4.1 FAILED,HELP is greatly appreciated**
*$ ping 172.24.4.1
PING 172.24.4.1 (172.24.4.1): 56 data bytes
^C
--- 172.24.4.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Other OK
ping from vm to 172.24.4.11 and another vm'fip are OK
$ ping 172.24.4.10
PING 172.24.4.10 (172.24.4.10): 56 data bytes
64 bytes from 172.24.4.10: seq=0 ttl=253 time=0.822 ms
$ ping 172.24.4.8
PING 172.24.4.8 (172.24.4.8): 56 data bytes
64 bytes from 172.24.4.8: seq=0 ttl=61 time=1.163 ms
ping from 172.24.4.1 to 172.24.4.7 is OK
  root@c3:/opt/stack# ping 172.24.4.7
PING 172.24.4.7 (172.24.4.7) 56(84) bytes of data.
64 bytes from 172.24.4.7: icmp_seq=1 ttl=62 time=0.903 ms


Here is the right conntrack from 172.24.1 to 172.24.4.7
root@c3:/opt/stack# conntrack -LN | grep icmp
icmp 1 29 src=172.24.4.1 dst=10.0.0.7 type=8 code=0 id=11779 
src=10.0.0.7 dst=172.24.4.1 type=0 code=0 id=11779 mark=0 zone=9 use=1

conntrack v1.4.3 (conntrack-tools): 205 flow entries have been shown.
icmp 1 29 src=172.24.4.1 dst=172.24.4.7 type=8 code=0 id=11779 
src=10.0.0.7 dst=172.24.4.1 type=0 code=0 id=11779 mark=0 zone=4 use=1
icmp 1 29 src=172.24.4.1 dst=172.24.4.7 type=8 code=0 id=11779 
src=172.24.4.7 dst=172.24.4.1 type=0 code=0 id=11779 mark=0 use=1


*HERE IS  some info for this issue ping from 10.0.0.7 to 172.24.4.1
*
root@c3:/opt/stack# conntrack -LN | grep icmp
conntrack v1.4.3 (conntrack-tools): 220 flow entries have been shown.
icmp 1 29 src=10.0.0.7 dst=172.24.4.1 type=8 code=0 id=32513 src=172.24.4.1 
dst=172.24.4.7 type=0 code=0 id=32513 mark=0 zone=3 use=1
icmp 1 29 src=10.0.0.7 dst=172.24.4.1 type=8 code=0 id=32513 [UNREPLIED] 
src=172.24.4.1 dst=10.0.0.7 type=0 code=0 id=32513 mark=0 zone=9 use=1
icmp 1 29 src=172.24.4.7 dst=172.24.4.1 type=8 code=0 id=32513 
src=172.24.4.1 dst=172.24.4.7 type=0 code=0 id=32513 mark=0 use=1

root@c3:/opt/stack# ovs-appctl -t 
/usr/local/var/run/openvswitch/ovn-controller.30677.ctl ct-zone-list
ee2f5eb8-60cd-4efa-94b5-0329ebe5fb25 8
f499ea31-da2c-4673-8313-efdf22f86308_dnat 6
f499ea31-da2c-4673-8313-efdf22f86308_snat 7
provnet-ca213de8-a0e1-4899-8fcf-4a894c876b80 5
417b4dfe-b64a-45fb-952b-9ddea624ae13 9
70ef5a38-7fde-477a-a437-0349d56adcf0_snat 3
94428e19-4bd0-4eb8-b77a-bcab69539a31_dnat 2
94428e19-4bd0-4eb8-b77a-bcab69539a31_snat 1
70ef5a38-7fde-477a-a437-0349d56adcf0_dnat 4

root@c3:/opt/stack# ovs-dpctl dump-flows | grep 172
recirc_id(0x84),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_state(+new-est-rel-rpl-inv+trk-snat-dnat),ct_zone(0x4),ct_mark(0),ct_label(0),eth(src=fa:16:3e:1f:ab:18,dst=fa:16:3e:cf:28:38),eth_type(0x0800),ipv4(src=10.0.0.7,dst=172.24.4.1,proto=1,tos=0,ttl=63,frag=no),icmp(type=8,code=0),
 packets:141, bytes:13818, used:0.296s, 
actions:set(eth(src=fa:16:3e:56:55:b0,dst=9e:eb:2d:f1:8e:42)),set(ipv4(src=10.0.0.7,dst=172.24.4.1,ttl=62)),ct(commit,zone=3,nat(src=172.24.4.7)),recirc(0x85)
recirc_id(0),dp_hash(0),skb_priority(0),in_port(2),skb_mark(0),ct_state(-new+est-rel+rpl-inv+trk-snat-dnat),ct_zone(0),ct_mark(0),ct_label(0),eth(src=9e:eb:2d:f1:8e:42,dst=fa:16:3e:56:55:b0),eth_type(0x0800),ipv4(src=172.24.4.1,dst=172.24.4.7,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0),
 packets:141, bytes:13818, used:0.296s, 
actions:ct(zone=3,nat),ct(commit,zone=4,nat(dst=10.0.0.7)),recirc(0x7e)
recirc_id(0x82),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_state(+new-est-rel-rpl-inv+trk-snat-dnat),ct_zone(0x9),ct_mark(0),ct_label(0),eth(src=fa:16:3e:ba:a1:3b,dst=fa:16:3e:b0:15:8d),eth_type(0x0800),ipv4(src=10.0.0.7,dst=172.24.4.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0),
 packets:141, bytes:13818, used:0.296s, 
actions:ct(commit,zone=9,label=0/0x1),ct(commit,zone=9,label=0/0x1),set(eth(src=fa:16:3e:1f:ab:18,dst=fa:16:3e:cf:28:38)),set(ipv4(src=10.0.0.7,dst=172.24.4.0/255.255.255.252,ttl=63)),ct(zone=4,nat),recirc(0x84)
recirc_id(0x85),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_state(-new+est-rel-rpl-inv+trk+snat-dnat),ct_zone(0x3),ct_mark(0),ct_label(0),eth(src=fa:16:3e:56:55:b0,dst=9e:eb:2d:f1:8e:42),eth_type(0x0800),ipv4(src=172.24.4.7,dst=172.24.4.1,proto=1,tos=0,ttl=62,frag=no),icmp(type=8,code=0),
 packets:139, bytes:13622, used:0.296s, actions:2
recirc_id(0x7e),dp_hash(0),skb_priority(0),in_port(2),skb_mark(0),ct_state(-new-est-rel-rpl+inv+trk-snat-dnat),ct_zone(0x4),ct_mark(0),ct_label(0),eth(src=9e:eb:2d:f1:8e:42,dst=fa:16:3e:56:55:b0),eth_type(0x0800),ipv4(src=172.24.4.1,dst=10.0.0.7,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0),
 packets:141, bytes:13818, used:0.296s, actions:drop

Re: [ovs-dev] [PATCH 1/2] ovn:add easy SNAT test case

[Dong Jun]

Thanks, it's really more realistic.

On 2016/7/28 22:53, Guru Shetty wrote:



On 28 July 2016 at 07:48, Guru Shetty <g...@ovn.org 
<mailto:g...@ovn.org>> wrote:




On 28 July 2016 at 06:55, Dong Jun <do...@dtdream.com
<mailto:do...@dtdream.com>> wrote:

Yes, this test case fail currently and success with the
modification.
If there is another same test case, ignore this patch is OK.


Thank you for the test. I applied the linked patch by Chandra as
it was already reviewed and applied your unit test and also added
you in AUTHORS. I did look at your second patch of the series.
Please read CodingStyle.md for any future contributions.


I forgot to mention that I did add the following incremental to your 
test to make the test case more realistic.
(Also, we still have a bug wherein we allow the router to respond to 
ICMP messages for a SNAT IP. This can be racy.)



@@ -243,19 +243,19 @@ ovn-nbctl lsp-add alice alice1 \

 # Add a SNAT rule
 ovn-nbctl -- --id=@nat create nat type="snat" logical_ip=192.168.1.2 \
-external_ip=20.0.0.2 -- add logical_router R2 nat @nat
+external_ip=172.16.1.1 -- add logical_router R2 nat @nat

 # South-North SNAT: 'foo1' pings 'alice1'. But 'alice1' receives traffic
-# from 20.0.0.2
+# from 172.16.1.1
 NS_CHECK_EXEC([foo1], [ping -q -c 3 -i 0.3 -w 2 172.16.1.2 | 
FORMAT_PING], \

 [0], [dnl
 3 packets transmitted, 3 received, 0% packet loss, time 0ms
 ])

 # We verify that SNAT indeed happened via 'dump-conntrack' command.
-AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(20.0.0.2) | \
+AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(172.16.1.1) | \
 sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl
-icmp,orig=(src=192.168.1.2,dst=172.16.1.2,id=),reply=(src=172.16.1.2,dst=20.0.0.2,id=),zon
+icmp,orig=(src=192.168.1.2,dst=172.16.1.2,id=),reply=(src=172.16.1.2,dst=172.16.1.1,id=),z
 ])


On 2016/7/28 21:31, Guru Shetty wrote:



On 27 July 2016 at 23:30, Dongjun <do...@dtdream.com
<mailto:do...@dtdream.com> <mailto:do...@dtdream.com
<mailto:do...@dtdream.com>>> wrote:

Signed-off-by: Dongjun <do...@dtdream.com
<mailto:do...@dtdream.com> <mailto:do...@dtdream.com
<mailto:do...@dtdream.com>>>


Usually, we have a test with the corresponding code
change. Can you have a look at
https://www.mail-archive.com/dev@openvswitch.org/msg66099.html
and see whether you are happy with the code change?

---
 tests/system-ovn.at <http://system-ovn.at>
<http://system-ovn.at> | 106
+++-
 1 file changed, 105 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 tests/system-ovn.at
<http://system-ovn.at>
<http://system-ovn.at>

diff --git a/tests/system-ovn.at
<http://system-ovn.at> <http://system-ovn.at>
b/tests/system-ovn.at <http://system-ovn.at>
<http://system-ovn.at>
old mode 100644
new mode 100755
index 13f380f..cb50fd4
--- a/tests/system-ovn.at <http://system-ovn.at>
<http://system-ovn.at>
+++ b/tests/system-ovn.at <http://system-ovn.at>
<http://system-ovn.at>

@@ -1,4 +1,4 @@
-AT_SETUP([ovn -- 2 LRs connected via LS, gateway
router, NAT])
+AT_SETUP([ovn -- 2 LRs connected via LS, gateway
router, SNAT and
DNAT])
 AT_KEYWORDS([ovnnat])

 CHECK_CONNTRACK()
@@ -168,6 +168,110 @@ as
 OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port
patch-.*/d"])
 AT_CLEANUP

+AT_SETUP([ovn -- 2 LRs connected via LS, gateway
router, easy SNAT])
+AT_KEYWORDS([ovnnat])
+
+CHECK_CONNTRACK()
+ovn_start
+OVS_TRAFFIC_VSWITCHD_START()
+ADD_BR([br-int])
+
+# Set external-ids in br-int needed for ovn-controller
+ovs-vsctl \
+-- set Open_vSwitch .
external-ids:system-id=hv1 \
+-- set Open_vSwitch .
external-ids:ovn-remote=unix:$ovs_base/ovn-sb/ovn-sb.sock \
+-- set Open_vSwitch .
external-ids:ovn-encap-type=geneve \
+-- set Open_vSwitch .
external-ids:ovn-encap-ip=169.0.0.1 \
+-- set bridge br-int fa

Re: [ovs-dev] [PATCH 1/2] ovn:add easy SNAT test case

[Dong Jun]

Yes, this test case fail currently and success with the modification.
If there is another same test case, ignore this patch is OK.

On 2016/7/28 21:31, Guru Shetty wrote:



On 27 July 2016 at 23:30, Dongjun > wrote:


Signed-off-by: Dongjun >


Usually, we have a test with the corresponding code change. Can you 
have a look at 
https://www.mail-archive.com/dev@openvswitch.org/msg66099.html and see 
whether you are happy with the code change?


---
 tests/system-ovn.at  | 106
+++-
 1 file changed, 105 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 tests/system-ovn.at


diff --git a/tests/system-ovn.at 
b/tests/system-ovn.at 
old mode 100644
new mode 100755
index 13f380f..cb50fd4
--- a/tests/system-ovn.at 
+++ b/tests/system-ovn.at 
@@ -1,4 +1,4 @@
-AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, NAT])
+AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, SNAT and
DNAT])
 AT_KEYWORDS([ovnnat])

 CHECK_CONNTRACK()
@@ -168,6 +168,110 @@ as
 OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port patch-.*/d"])
 AT_CLEANUP

+AT_SETUP([ovn -- 2 LRs connected via LS, gateway router, easy SNAT])
+AT_KEYWORDS([ovnnat])
+
+CHECK_CONNTRACK()
+ovn_start
+OVS_TRAFFIC_VSWITCHD_START()
+ADD_BR([br-int])
+
+# Set external-ids in br-int needed for ovn-controller
+ovs-vsctl \
+-- set Open_vSwitch . external-ids:system-id=hv1 \
+-- set Open_vSwitch .
external-ids:ovn-remote=unix:$ovs_base/ovn-sb/ovn-sb.sock \
+-- set Open_vSwitch . external-ids:ovn-encap-type=geneve \
+-- set Open_vSwitch . external-ids:ovn-encap-ip=169.0.0.1 \
+-- set bridge br-int fail-mode=secure
other-config:disable-in-band=true
+
+# Start ovn-controller
+start_daemon ovn-controller
+
+# Logical network:
+# Two LRs - R1 and R2 that are connected to each other via LS "join"
+# in 20.0.0.0/24  network. R1 has switchess
foo (192.168.1.0/24 ) connected to it.
+# R2 has alice (172.16.1.0/24 ) connectedto it.
+# R2 is a gateway router on which we add NAT rules.
+#
+#foo -- R1 -- join - R2 -- alice
+
+ovn-nbctl lr-add R1
+ovn-nbctl lr-add R2 -- set Logical_Router R2 options:chassis=hv1
+
+ovn-nbctl ls-add foo
+ovn-nbctl ls-add alice
+ovn-nbctl ls-add join
+
+ovn-nbctl lrp-add R1 foo 00:00:01:01:02:03 192.168.1.1/24

+ovn-nbctl lrp-add R2 alice 00:00:02:01:02:03 172.16.1.1/24

+ovn-nbctl lrp-add R1 R1_join 00:00:04:01:02:03 20.0.0.1/24

+ovn-nbctl lrp-add R2 R2_join 00:00:04:01:02:04 20.0.0.2/24

+
+# Connect foo to R1
+ovn-nbctl lsp-add foo rp-foo -- set Logical_Switch_Port rp-foo \
+type=router options:router-port=foo
addresses=\"00:00:01:01:02:03\"
+
+# Connect alice to R2
+ovn-nbctl lsp-add alice rp-alice -- set Logical_Switch_Port
rp-alice \
+type=router options:router-port=alice
addresses=\"00:00:02:01:02:03\"
+
+# Connect R1 to join
+ovn-nbctl lsp-add join r1-join -- set Logical_Switch_Port r1-join \
+type=router options:router-port=R1_join
addresses='"00:00:04:01:02:03"'
+
+# Connect R2 to join
+ovn-nbctl lsp-add join r2-join -- set Logical_Switch_Port r2-join \
+type=router options:router-port=R2_join
addresses='"00:00:04:01:02:04"'
+
+# Static routes.
+ovn-nbctl lr-route-add R1 172.16.1.0/24 
20.0.0.2
+ovn-nbctl lr-route-add R2 192.168.0.0/16 
20.0.0.1
+
+# Logical port 'foo1' in switch 'foo'.
+ADD_NAMESPACES(foo1)
+ADD_VETH(foo1, foo1, br-int, "192.168.1.2/24
", "f0:00:00:01:02:03", \
+ "192.168.1.1")
+ovn-nbctl lsp-add foo foo1 \
+-- lsp-set-addresses foo1 "f0:00:00:01:02:03 192.168.1.2"
+
+# Logical port 'alice1' in switch 'alice'.
+ADD_NAMESPACES(alice1)
+ADD_VETH(alice1, alice1, br-int, "172.16.1.2/24
", "f0:00:00:01:02:04", \
+ "172.16.1.1")
+ovn-nbctl lsp-add alice alice1 \
+-- lsp-set-addresses alice1 "f0:00:00:01:02:04 172.16.1.2"
+
+# Add a SNAT rule
+ovn-nbctl -- --id=@nat create nat type="snat"
logical_ip=192.168.1.2 \
+external_ip=20.0.0.2 -- add logical_router R2 nat @nat
+
+# South-North SNAT: 'foo1' pings 'alice1'. But 'alice1' receives
traffic
+# from 20.0.0.2