Re: [ovs-discuss] GRE over IPv6 configuration
On 6/18/2019 8:11 PM, William Tu wrote:
> On Tue, Jun 18, 2019 at 9:15 AM William Tu wrote:
>> On Mon, Jun 17, 2019 at 10:46 PM Eli Britstein wrote:
>>>
>>> On 6/18/2019 1:22 AM, Gregory Rose wrote:
On 6/12/2019 2:20 AM, Eli Britstein wrote:
> Could you please have a look (and even better try?) still need to
> tidy up
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Felibr-mellanox%2Flinux%2Ftree%2Fovs-ipv6-gredata=02%7C01%7Celibr%40mellanox.com%7Cb5e034b901e54e2301b608d6f4100fe5%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636964747162815714sdata=16q01k9tTgklmmTFeD6ZOmFwUSNzUAvVONJX8Y7FNEA%3Dreserved=0
>
>
>
Hi Eli,
I finally managed to getting around and building your kernel. At
least it does do away with the protocol error message but
I haven't gotten it working yet. Stay tuned and I'll provide feedback.
>>> Hi Greg,
>>>
>>> I think William was right pointing out the comment from Pravin. I agree
>>> with them that if we can avoid changing the kernel, and support it via
>>> lib/dpif-netlink-rtnl.c, it is the way to go, and we should abandon the
>>> kernel changes.
>>>
>>> I haven't deep dived into it yet to see how ip6erspan works (at least no
>>> creation error, didn't run traffic though) and ip6gre doesn't.
>>>
>> Hi Eli and Greg,
>>
>> I've found the root cause using upstream kernel 5.2.
>> When adding an ip6gre device type, the
>> ovs_vport_cmd_new
>>new_vport
>> netdev_create
>>ovs_netdev_link
>>
>> and fails due to
>> if (vport->dev->flags & IFF_LOOPBACK ||
>> (vport->dev->type != ARPHRD_ETHER &&
>> vport->dev->type != ARPHRD_NONE) ||
>> ovs_is_internal_dev(vport->dev)) {
>> err = -EINVAL;
>>
>> Because ip6gre is ARPHRD_IP6GRE
>> Which means ip6gre never works using upstream kernel :(
>>
>> If we use ip6gretap, then its type is ARPHRD_ETHER,
>> and the ip6gretap device can be created successfully.
>>
>> And for ip6erspan, it's never been a issue because it is ARPHRD_ETHER.
>>
>> And when using compat module, ip6gre works due to a coincident here:
>> at datapath/linux/compat/ip6_gre.c
>> static struct rtnl_link_ops ip6gre_link_ops __read_mostly = {
>> .kind = "ip6gre",
>> .maxtype= RPL_IFLA_GRE_MAX,
>>
>>
>> static struct rtnl_link_ops ip6gre_tap_ops __read_mostly = {
>> .kind = "ip6gre",
>> .maxtype= RPL_IFLA_GRE_MAX,
>> .policy = ip6gre_policy,
>> .priv_size = sizeof(struct ip6_tnl),
>>
>> We happen to use ip6gre_tap link ops in type "ip6gre"
>>
>> Regards,
>> William
>>
>>> Furthermore, I think the following is missing, as there is no ip6gretap,
>>> only ip6gre:
>>>
> Hi Greg and Eli,
>
> Should we add both ip6gre (L3) and ip6gretap (L2) support?
> @Eli, which mode do you want to use?
ip6gretap
I applied this patch too, and indeed the error is resolved. However, i
still don't get traffic. Have you verified it works to indicate a setup
issue for me?
>
> I apply the patch below, and ip6gretap port can be created successfully
> by doing using kernel 5.2 upstream ovs module:
> # ovs-vsctl add-port br0 at_gre1 -- \
> set int at_gre1 type=ip6gretap options:remote_ip=fc00:100::1
>
> but not the type=ip6gre
>
> diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
> index 2e23a8c14fcf..d666f239aeed 100644
> --- a/lib/dpif-netlink-rtnl.c
> +++ b/lib/dpif-netlink-rtnl.c
> @@ -104,7 +104,7 @@ vport_type_to_kind(enum ovs_vport_type type,
> case OVS_VPORT_TYPE_IP6ERSPAN:
> return "ip6erspan";
> case OVS_VPORT_TYPE_IP6GRE:
> -return "ip6gre";
> +return "ip6gretap";
> case OVS_VPORT_TYPE_NETDEV:
> case OVS_VPORT_TYPE_INTERNAL:
> case OVS_VPORT_TYPE_LISP:
> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
> index c554666acce0..28897153744b 100644
> --- a/lib/dpif-netlink.c
> +++ b/lib/dpif-netlink.c
> @@ -698,7 +698,7 @@ get_vport_type(const struct dpif_netlink_vport *vport)
> return "ip6erspan";
>
> case OVS_VPORT_TYPE_IP6GRE:
> -return "ip6gre";
> +return "ip6gretap";
>
> case OVS_VPORT_TYPE_UNSPEC:
> case __OVS_VPORT_TYPE_MAX:
> @@ -729,7 +729,7 @@ netdev_to_ovs_vport_type(const char *type)
> return OVS_VPORT_TYPE_ERSPAN;
> } else if (!strcmp(type, "ip6erspan")) {
> return OVS_VPORT_TYPE_IP6ERSPAN;
> -} else if (!strcmp(type, "ip6gre")) {
> +} else if (!strcmp(type, "ip6gretap")) {
> return OVS_VPORT_TYPE_IP6GRE;
> } else if (!strcmp(type, "gre")) {
> return OVS_VPORT_TYPE_GRE;
> diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
> index ab591667f447..da95f680d454 100644
> --- a/lib/netdev-vport.c
> +++ b/lib/netdev-vport.c
> @@ -1216,10 +1216,10 @@ netdev_vport_tunnel_register(void)
> },
> {{NULL, NULL, 0, 0}}
> },
> -{ "ip6gre_sys",
> +{ "ip6gretap_sys",
>
Re: [ovs-discuss] ovs-dpctl del-flow works strange
Hi Ben, it's OK, behavior accepted :) But, I still cannot remove a specific entry without specifying the 'ufid'. Would you be so kind as to give me an example of how to remove a given entry without 'ufid'? Thanks On Tue, 2019-06-18 at 09:33 -0700, Ben Pfaff wrote: > In general, we don't pay much attention to OVS behavior here, because > this isn't something users should do. > > On Tue, Jun 18, 2019 at 11:10:40AM +0800, Levente Csikor wrote: > > Minor update: > > Iperf was using different source port when re-initiated, so this is > > why > > it became again part of fast path. > > > > If I send packets that matches the allow rule and all header fields > > are > > the same, then it won't be cached again once it has been deleted. > > > > > > On Tue, 2019-06-18 at 10:38 +0800, Levente Csikor wrote: > > > Hi fellow OVS users and gurus, > > > > > > I am playing with ovs-dpctl del-flow command to manually remove > > > entries > > > from the cache. > > > > > > I have a following entry in the cache which let's incoming > > > traffic to > > > a > > > destination IP with udp port 80 to a service: > > > > > > recirc_id(0),in_port(4),eth(),eth_type(0x0800),ipv4(dst=10.0.0.2, > > > prot > > > o= > > > 17,frag=no),udp(dst=80), packets:247279, bytes:14836740, > > > used:0.000s, > > > actions:2 > > > > > > However, if I want to delete the flow and use the syntax off > > > directly > > > adding a flow to the datapath described in the manual, i.e., > > > using > > > syntax like this: > > > ovs-dpctl del-flow > > > "in_port(4),eth(),eth_type(0x0800),ipv4(dst=10.0.0.2,proto=17,fra > > > g=no > > > ), > > > udp(dst=80) > > > > > > it gives me an error that it does not find a corresponding flow > > > rule: > > > ovs-dpctl: deleting flow (No such file or directory) > > > Perhaps you need to specify a UFID? > > > > > > > > > Then, I realized that if dpctl dump-flows is called with > > > parameter '- > > > m', it prints out the ufid (unique flow identifiers) for the > > > datapath > > > entries. > > > Using a command like this accordingly does the job: > > > ovs-dpctl del-flow ufid:5cc7e599-7050-4b4a-83d6-8a8fe8e8a975 > > > > > > What is the difference? and can someone let me know an example of > > > del- > > > flow command to show what to include in/exlude of the command? > > > > > > > > > On the other hand, when I finally remove an entry via ufid, then > > > it > > > seems that it is permanently removed! > > > Traffic is still on, but no new entries are spawned in the > > > datapath > > > letting me think that now everything is going through the slow > > > path > > > (especially that an experiment of iperf between two VMs, the > > > throughput > > > dropped down below 1Gbps from 35-40Gbps. > > > > > > I also tried to stop the traffic, wait more than 10 sec to let > > > the > > > megaflow cache entries expire, and restarted the traffic. > > > Then, the traffic is cached again and everything is back to its > > > normal > > > operation. > > > > > > > > > For curiosity, I have tried the same thing for a drop-rule > > > instead of > > > an allow rule. > > > (This means that the entry I am deleting is not represented in > > > both > > > the > > > slow path and fast path in the same way, i.e., there can be many > > > entries in the cache that matches a drop rule.) > > > Anyway, if I remove a (drop) entry from the fast path then the > > > corresponding entry will never ever be there again: > > > > > > - Packets matching on the drop rule are still coming in -> > > > processed > > > by > > > slow path > > > - Wait again more than 10 sec, still won't be cached again -> > > > processed > > > by slow path > > > > > > I did even try this with removing all entries in the fast path > > > that > > > correspond to a drop rule in the flow table. I still have the > > > same > > > case. > > > > > > > > > What am I doing wrong? Is there any timeout for these deletions? > > > > > > Thanks, > > > lev > > > > > > > ___ > > discuss mailing list > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] GRE over IPv6 configuration
On 6/18/2019 10:11 AM, William Tu wrote:
On Tue, Jun 18, 2019 at 9:15 AM William Tu wrote:
Hi Greg and Eli,
Should we add both ip6gre (L3) and ip6gretap (L2) support?
@Eli, which mode do you want to use?
I apply the patch below, and ip6gretap port can be created successfully
by doing using kernel 5.2 upstream ovs module:
# ovs-vsctl add-port br0 at_gre1 -- \
set int at_gre1 type=ip6gretap options:remote_ip=fc00:100::1
but not the type=ip6gre
diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
index 2e23a8c14fcf..d666f239aeed 100644
--- a/lib/dpif-netlink-rtnl.c
+++ b/lib/dpif-netlink-rtnl.c
@@ -104,7 +104,7 @@ vport_type_to_kind(enum ovs_vport_type type,
case OVS_VPORT_TYPE_IP6ERSPAN:
return "ip6erspan";
case OVS_VPORT_TYPE_IP6GRE:
-return "ip6gre";
+return "ip6gretap";
case OVS_VPORT_TYPE_NETDEV:
case OVS_VPORT_TYPE_INTERNAL:
case OVS_VPORT_TYPE_LISP:
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index c554666acce0..28897153744b 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -698,7 +698,7 @@ get_vport_type(const struct dpif_netlink_vport *vport)
return "ip6erspan";
case OVS_VPORT_TYPE_IP6GRE:
-return "ip6gre";
+return "ip6gretap";
case OVS_VPORT_TYPE_UNSPEC:
case __OVS_VPORT_TYPE_MAX:
@@ -729,7 +729,7 @@ netdev_to_ovs_vport_type(const char *type)
return OVS_VPORT_TYPE_ERSPAN;
} else if (!strcmp(type, "ip6erspan")) {
return OVS_VPORT_TYPE_IP6ERSPAN;
-} else if (!strcmp(type, "ip6gre")) {
+} else if (!strcmp(type, "ip6gretap")) {
return OVS_VPORT_TYPE_IP6GRE;
} else if (!strcmp(type, "gre")) {
return OVS_VPORT_TYPE_GRE;
diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
index ab591667f447..da95f680d454 100644
--- a/lib/netdev-vport.c
+++ b/lib/netdev-vport.c
@@ -1216,10 +1216,10 @@ netdev_vport_tunnel_register(void)
},
{{NULL, NULL, 0, 0}}
},
-{ "ip6gre_sys",
+{ "ip6gretap_sys",
{
TUNNEL_FUNCTIONS_COMMON,
- .type = "ip6gre",
+ .type = "ip6gretap",
.build_header = netdev_gre_build_header,
.push_header = netdev_gre_push_header,
.pop_header = netdev_gre_pop_header
diff --git a/lib/tnl-ports.c b/lib/tnl-ports.c
index 17353046cc6e..2157d7de11ae 100644
--- a/lib/tnl-ports.c
+++ b/lib/tnl-ports.c
@@ -172,7 +172,7 @@ tnl_type_to_nw_proto(const char type[])
return IPPROTO_TCP;
}
if (!strcmp(type, "gre") || !strcmp(type, "erspan") ||
-!strcmp(type, "ip6erspan") || !strcmp(type, "ip6gre")) {
+!strcmp(type, "ip6erspan") || !strcmp(type, "ip6gretap")) {
return IPPROTO_GRE;
}
if (!strcmp(type, "vxlan")) {
This patch, as is, reports "ovs-vsctl: no row "type=ip6gretap" in table
Interface"
Is there something I missed?
I had something that worked once but now it's always failing with that
message. Trying to figure out what it means.
- Greg
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN in Userspace
On Tue, Jun 18, 2019 at 12:21 PM Flavio Leitner wrote: > On Tue, Jun 18, 2019 at 10:41:16AM -0400, Vasu Dasari wrote: > > Flavio, > > > > The device(could be a regular interface) should have been added to OVS > with > > "add-port" and when it is removed, ARP entries learnt on it well be > removed > > as well. > > Not necessarily. You could have a regular kernel interface with the > tunnel endpoint address which is not part of an OVS bridge. > The code being added should cover that as well. Probably you can comment on this after you look at my code. > > > The code is ready. Regarding, testing the code I am planning on extending > > already existing case where tests are performed to check ARP entry > > existence, like for example, "tunnel_push_pop - underlay bridge match" in > > tunnel-push-pop.at. I hope that is fine, or should I be writing a > separate > > unit test case? > > Usually we just add more tests to the file to cover additional > use-cases. > > Ok. Will add a new test case then. On another note, I see ARP neighbor add and show commands. This covers L3 side. For L2 side, I see fdb show command, but there is no set command. I would like to add that one also. Any comments? Current fdb show: ovs-appctl fdb/show s1 Proposed CLI for fdb/set operation would look like: ovs-appctl fdb/set ovs-appctl fdb/set s1 2 0 00:00:01:00:00:02 What do you think? Thanks -Vasu fbl > > > > > -Vasu > > > > *Vasu Dasari* > > > > > > On Fri, Jun 14, 2019 at 9:15 AM Flavio Leitner wrote: > > > > > On Thu, Jun 13, 2019 at 10:58:21PM -0400, Vasu Dasari wrote: > > > > Flavio, > > > > > > > > tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a > bridge > > > is > > > > removed, ARP entries learnt on that bridge alone have to be removed. > > > > Entries from other bridges have to be in tact. > > > > > > > > I am thinking of doing the following: > > > > > > > > 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const > char* > > > > br_name) which purges all neighbor entries on bridge br_name. > > > > > > That's better, indeed. > > > > > > > > > > 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke > the > > > > function tnl_neigh_flush () to flush the entries. > > > > > > > > til_neigh_xxx() functions are getting called from > ofproto-dpif-xlate.c, > > > and > > > > hence thinking that xlate_xbridge_remove() is a right place to do the > > > job. > > > > > > > > What do you think? > > > > > > The device with the IP address can be any regular interface, so > > > do you think it would work if you remove a device that is out of > > > OVS? > > > > > > fbl > > > > > > > > > > > -Vasu > > > > > > > > > > > > On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari > wrote: > > > > > > > > > Yes Flavio. Looking at code to fix this. Will send fix for review > soon. > > > > > > > > > > Vasu > > > > > > > > > > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner > > > wrote: > > > > > > > > > > > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote: > > > > > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with > > > stale ARP > > > > > >> entries after a bridge is deleted. > > > > > >> > > > > > >> I ran my tunneling experiment successfully. Used mininet to > > > simulate the > > > > > >> environment. After quitting the mininet, switch s1 is deleted. > But, > > > I > > > > > still > > > > > >> see the ARP entries in OVS. > > > > > > > > > > > > Looks like when route_table_valid is false we also need to > > > > > > call tnl_neigh_cache_flush() otherwise you will need to wait > > > > > > the ARP entry in the cache to expire (15min?) which is quite > > > > > > a long time. > > > > > > > > > > > > Do you think you can work on a patch? > > > > > > > > > > > >> root@mn1:~# ovs-vsctl show > > > > > >> f6af5f1c-a11c-435f-9b03-7317f364ae48 > > > > > >>Manager "ptcp:6640" > > > > > >>ovs_version: "2.9.0" > > > > > >> > > > > > >> Even thought there is no s1, I still see entries here. > > > > > >> root@mn1:~# ovs-appctl tnl/arp/show > > > > > >> IPMAC > > > Bridge > > > > > >> > > > > > > > > > == > > > > > >> 172.168.1.1 > 02:42:ac:14:00:02 s1 > > > > > >> 172.168.1.2 > 02:42:ac:14:00:03 s1 > > > > > >> 10.0.0.10 > 82:ec:29:c0:bc:ef s1 > > > > > >> 10.0.0.1 > d2:54:11:f0:95:df s1 > > > > > >> > > > > > >> > > > > > >> Just for completeness, this is what I had to do to fix my > > > configuration. > > > > > >> > > > > > >> Figured out what was wrong with my configuration. > > > > > >> > > > > > >> Modify my bridge s1 to be: > > > > > >> > > > > > >> ovs-vsctl --may-exist add-br s1 \ > > > > > >>-- set Bridge s1 datapath_type=netdev \ > > > > > >>-- set bridge s1 fail-mode=standalone \ > > > > > >> other_config:hwaddr=$(cat /sys/class/net/eth1/address) > > > > > >> > > > > > >> Add the flows: > > > > > >> ovs-ofctl add-flow s1
Re: [ovs-discuss] GRE over IPv6 configuration
On 6/18/2019 11:28 AM, Gregory Rose wrote: That's pretty much the same patch I've got and am testing right now. I think it's the right way to go. Do you want to post this to netdev or would you prefer me to do it? Excuse me, I meant OVS dev, not NET dev... Thanks, - Greg ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] GRE over IPv6 configuration
On 6/18/2019 10:11 AM, William Tu wrote:
On Tue, Jun 18, 2019 at 9:15 AM William Tu wrote:
On Mon, Jun 17, 2019 at 10:46 PM Eli Britstein wrote:
On 6/18/2019 1:22 AM, Gregory Rose wrote:
On 6/12/2019 2:20 AM, Eli Britstein wrote:
Could you please have a look (and even better try?) still need to
tidy up
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Felibr-mellanox%2Flinux%2Ftree%2Fovs-ipv6-gredata=02%7C01%7Celibr%40mellanox.com%7C25425e700b58418b19fa08d6f37253ae%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636964069686971905sdata=Ki55ZQGwQKNNDkB4PZ1zpk9aqC42TXbt5WT%2F86SDauo%3Dreserved=0
Hi Eli,
I finally managed to getting around and building your kernel. At
least it does do away with the protocol error message but
I haven't gotten it working yet. Stay tuned and I'll provide feedback.
Hi Greg,
I think William was right pointing out the comment from Pravin. I agree
with them that if we can avoid changing the kernel, and support it via
lib/dpif-netlink-rtnl.c, it is the way to go, and we should abandon the
kernel changes.
I haven't deep dived into it yet to see how ip6erspan works (at least no
creation error, didn't run traffic though) and ip6gre doesn't.
Hi Eli and Greg,
I've found the root cause using upstream kernel 5.2.
When adding an ip6gre device type, the
ovs_vport_cmd_new
new_vport
netdev_create
ovs_netdev_link
and fails due to
if (vport->dev->flags & IFF_LOOPBACK ||
(vport->dev->type != ARPHRD_ETHER &&
vport->dev->type != ARPHRD_NONE) ||
ovs_is_internal_dev(vport->dev)) {
err = -EINVAL;
Because ip6gre is ARPHRD_IP6GRE
Which means ip6gre never works using upstream kernel :(
If we use ip6gretap, then its type is ARPHRD_ETHER,
and the ip6gretap device can be created successfully.
And for ip6erspan, it's never been a issue because it is ARPHRD_ETHER.
And when using compat module, ip6gre works due to a coincident here:
at datapath/linux/compat/ip6_gre.c
static struct rtnl_link_ops ip6gre_link_ops __read_mostly = {
.kind = "ip6gre",
.maxtype= RPL_IFLA_GRE_MAX,
static struct rtnl_link_ops ip6gre_tap_ops __read_mostly = {
.kind = "ip6gre",
.maxtype= RPL_IFLA_GRE_MAX,
.policy = ip6gre_policy,
.priv_size = sizeof(struct ip6_tnl),
We happen to use ip6gre_tap link ops in type "ip6gre"
Regards,
William
Furthermore, I think the following is missing, as there is no ip6gretap,
only ip6gre:
Hi Greg and Eli,
Should we add both ip6gre (L3) and ip6gretap (L2) support?
@Eli, which mode do you want to use?
I apply the patch below, and ip6gretap port can be created successfully
by doing using kernel 5.2 upstream ovs module:
# ovs-vsctl add-port br0 at_gre1 -- \
set int at_gre1 type=ip6gretap options:remote_ip=fc00:100::1
but not the type=ip6gre
diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
index 2e23a8c14fcf..d666f239aeed 100644
--- a/lib/dpif-netlink-rtnl.c
+++ b/lib/dpif-netlink-rtnl.c
@@ -104,7 +104,7 @@ vport_type_to_kind(enum ovs_vport_type type,
case OVS_VPORT_TYPE_IP6ERSPAN:
return "ip6erspan";
case OVS_VPORT_TYPE_IP6GRE:
-return "ip6gre";
+return "ip6gretap";
case OVS_VPORT_TYPE_NETDEV:
case OVS_VPORT_TYPE_INTERNAL:
case OVS_VPORT_TYPE_LISP:
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index c554666acce0..28897153744b 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -698,7 +698,7 @@ get_vport_type(const struct dpif_netlink_vport *vport)
return "ip6erspan";
case OVS_VPORT_TYPE_IP6GRE:
-return "ip6gre";
+return "ip6gretap";
case OVS_VPORT_TYPE_UNSPEC:
case __OVS_VPORT_TYPE_MAX:
@@ -729,7 +729,7 @@ netdev_to_ovs_vport_type(const char *type)
return OVS_VPORT_TYPE_ERSPAN;
} else if (!strcmp(type, "ip6erspan")) {
return OVS_VPORT_TYPE_IP6ERSPAN;
-} else if (!strcmp(type, "ip6gre")) {
+} else if (!strcmp(type, "ip6gretap")) {
return OVS_VPORT_TYPE_IP6GRE;
} else if (!strcmp(type, "gre")) {
return OVS_VPORT_TYPE_GRE;
diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
index ab591667f447..da95f680d454 100644
--- a/lib/netdev-vport.c
+++ b/lib/netdev-vport.c
@@ -1216,10 +1216,10 @@ netdev_vport_tunnel_register(void)
},
{{NULL, NULL, 0, 0}}
},
-{ "ip6gre_sys",
+{ "ip6gretap_sys",
{
TUNNEL_FUNCTIONS_COMMON,
- .type = "ip6gre",
+ .type = "ip6gretap",
.build_header = netdev_gre_build_header,
.push_header = netdev_gre_push_header,
.pop_header = netdev_gre_pop_header
diff --git a/lib/tnl-ports.c b/lib/tnl-ports.c
index 17353046cc6e..2157d7de11ae 100644
--- a/lib/tnl-ports.c
+++ b/lib/tnl-ports.c
@@ -172,7 +172,7 @@ tnl_type_to_nw_proto(const char type[])
return IPPROTO_TCP;
}
Re: [ovs-discuss] GRE over IPv6 configuration
On 6/18/2019 9:15 AM, William Tu wrote:
On Mon, Jun 17, 2019 at 10:46 PM Eli Britstein wrote:
On 6/18/2019 1:22 AM, Gregory Rose wrote:
On 6/12/2019 2:20 AM, Eli Britstein wrote:
Could you please have a look (and even better try?) still need to
tidy up
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Felibr-mellanox%2Flinux%2Ftree%2Fovs-ipv6-gredata=02%7C01%7Celibr%40mellanox.com%7C25425e700b58418b19fa08d6f37253ae%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636964069686971905sdata=Ki55ZQGwQKNNDkB4PZ1zpk9aqC42TXbt5WT%2F86SDauo%3Dreserved=0
Hi Eli,
I finally managed to getting around and building your kernel. At
least it does do away with the protocol error message but
I haven't gotten it working yet. Stay tuned and I'll provide feedback.
Hi Greg,
I think William was right pointing out the comment from Pravin. I agree
with them that if we can avoid changing the kernel, and support it via
lib/dpif-netlink-rtnl.c, it is the way to go, and we should abandon the
kernel changes.
I haven't deep dived into it yet to see how ip6erspan works (at least no
creation error, didn't run traffic though) and ip6gre doesn't.
Hi Eli and Greg,
I've found the root cause using upstream kernel 5.2.
When adding an ip6gre device type, the
ovs_vport_cmd_new
new_vport
netdev_create
ovs_netdev_link
and fails due to
if (vport->dev->flags & IFF_LOOPBACK ||
(vport->dev->type != ARPHRD_ETHER &&
vport->dev->type != ARPHRD_NONE) ||
ovs_is_internal_dev(vport->dev)) {
err = -EINVAL;
Open vswitch cannot deal with port types other than ARPHRD_ETHER and
ARPHRD_NONE. ARPHRD_IP6GRE is not
supported in the code anywhere.
Because ip6gre is ARPHRD_IP6GRE
Which means ip6gre never works using upstream kernel :(
If we use ip6gretap, then its type is ARPHRD_ETHER,
and the ip6gretap device can be created successfully.
Interesting... The implementation in OVS is wrong then.
And for ip6erspan, it's never been a issue because it is ARPHRD_ETHER.
And when using compat module, ip6gre works due to a coincident here:
at datapath/linux/compat/ip6_gre.c
static struct rtnl_link_ops ip6gre_link_ops __read_mostly = {
.kind = "ip6gre",
.maxtype= RPL_IFLA_GRE_MAX,
static struct rtnl_link_ops ip6gre_tap_ops __read_mostly = {
.kind = "ip6gre",
.maxtype= RPL_IFLA_GRE_MAX,
.policy = ip6gre_policy,
.priv_size = sizeof(struct ip6_tnl),
We happen to use ip6gre_tap link ops in type "ip6gre"
Oops.
I'm working on sorting this out... not sure which way but we need to
close this gap between upstream and out of
tree.
- Greg
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] GRE over IPv6 configuration
On Tue, Jun 18, 2019 at 9:15 AM William Tu wrote:
>
> On Mon, Jun 17, 2019 at 10:46 PM Eli Britstein wrote:
> >
> >
> > On 6/18/2019 1:22 AM, Gregory Rose wrote:
> > >
> > > On 6/12/2019 2:20 AM, Eli Britstein wrote:
> > >> Could you please have a look (and even better try?) still need to
> > >> tidy up
> > >>
> > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Felibr-mellanox%2Flinux%2Ftree%2Fovs-ipv6-gredata=02%7C01%7Celibr%40mellanox.com%7C25425e700b58418b19fa08d6f37253ae%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636964069686971905sdata=Ki55ZQGwQKNNDkB4PZ1zpk9aqC42TXbt5WT%2F86SDauo%3Dreserved=0
> > >>
> > >>
> > >>
> > >
> > > Hi Eli,
> > >
> > > I finally managed to getting around and building your kernel. At
> > > least it does do away with the protocol error message but
> > > I haven't gotten it working yet. Stay tuned and I'll provide feedback.
> >
> > Hi Greg,
> >
> > I think William was right pointing out the comment from Pravin. I agree
> > with them that if we can avoid changing the kernel, and support it via
> > lib/dpif-netlink-rtnl.c, it is the way to go, and we should abandon the
> > kernel changes.
> >
> > I haven't deep dived into it yet to see how ip6erspan works (at least no
> > creation error, didn't run traffic though) and ip6gre doesn't.
> >
> Hi Eli and Greg,
>
> I've found the root cause using upstream kernel 5.2.
> When adding an ip6gre device type, the
> ovs_vport_cmd_new
> new_vport
> netdev_create
> ovs_netdev_link
>
> and fails due to
> if (vport->dev->flags & IFF_LOOPBACK ||
> (vport->dev->type != ARPHRD_ETHER &&
> vport->dev->type != ARPHRD_NONE) ||
> ovs_is_internal_dev(vport->dev)) {
> err = -EINVAL;
>
> Because ip6gre is ARPHRD_IP6GRE
> Which means ip6gre never works using upstream kernel :(
>
> If we use ip6gretap, then its type is ARPHRD_ETHER,
> and the ip6gretap device can be created successfully.
>
> And for ip6erspan, it's never been a issue because it is ARPHRD_ETHER.
>
> And when using compat module, ip6gre works due to a coincident here:
> at datapath/linux/compat/ip6_gre.c
> static struct rtnl_link_ops ip6gre_link_ops __read_mostly = {
> .kind = "ip6gre",
> .maxtype= RPL_IFLA_GRE_MAX,
>
>
> static struct rtnl_link_ops ip6gre_tap_ops __read_mostly = {
> .kind = "ip6gre",
> .maxtype= RPL_IFLA_GRE_MAX,
> .policy = ip6gre_policy,
> .priv_size = sizeof(struct ip6_tnl),
>
> We happen to use ip6gre_tap link ops in type "ip6gre"
>
> Regards,
> William
>
> > Furthermore, I think the following is missing, as there is no ip6gretap,
> > only ip6gre:
> >
Hi Greg and Eli,
Should we add both ip6gre (L3) and ip6gretap (L2) support?
@Eli, which mode do you want to use?
I apply the patch below, and ip6gretap port can be created successfully
by doing using kernel 5.2 upstream ovs module:
# ovs-vsctl add-port br0 at_gre1 -- \
set int at_gre1 type=ip6gretap options:remote_ip=fc00:100::1
but not the type=ip6gre
diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
index 2e23a8c14fcf..d666f239aeed 100644
--- a/lib/dpif-netlink-rtnl.c
+++ b/lib/dpif-netlink-rtnl.c
@@ -104,7 +104,7 @@ vport_type_to_kind(enum ovs_vport_type type,
case OVS_VPORT_TYPE_IP6ERSPAN:
return "ip6erspan";
case OVS_VPORT_TYPE_IP6GRE:
-return "ip6gre";
+return "ip6gretap";
case OVS_VPORT_TYPE_NETDEV:
case OVS_VPORT_TYPE_INTERNAL:
case OVS_VPORT_TYPE_LISP:
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index c554666acce0..28897153744b 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -698,7 +698,7 @@ get_vport_type(const struct dpif_netlink_vport *vport)
return "ip6erspan";
case OVS_VPORT_TYPE_IP6GRE:
-return "ip6gre";
+return "ip6gretap";
case OVS_VPORT_TYPE_UNSPEC:
case __OVS_VPORT_TYPE_MAX:
@@ -729,7 +729,7 @@ netdev_to_ovs_vport_type(const char *type)
return OVS_VPORT_TYPE_ERSPAN;
} else if (!strcmp(type, "ip6erspan")) {
return OVS_VPORT_TYPE_IP6ERSPAN;
-} else if (!strcmp(type, "ip6gre")) {
+} else if (!strcmp(type, "ip6gretap")) {
return OVS_VPORT_TYPE_IP6GRE;
} else if (!strcmp(type, "gre")) {
return OVS_VPORT_TYPE_GRE;
diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
index ab591667f447..da95f680d454 100644
--- a/lib/netdev-vport.c
+++ b/lib/netdev-vport.c
@@ -1216,10 +1216,10 @@ netdev_vport_tunnel_register(void)
},
{{NULL, NULL, 0, 0}}
},
-{ "ip6gre_sys",
+{ "ip6gretap_sys",
{
TUNNEL_FUNCTIONS_COMMON,
- .type = "ip6gre",
+ .type = "ip6gretap",
.build_header = netdev_gre_build_header,
.push_header = netdev_gre_push_header,
.pop_header = netdev_gre_pop_header
diff --git a/lib/tnl-ports.c b/lib/tnl-ports.c
index 17353046cc6e..2157d7de11ae 100644
---
Re: [ovs-discuss] [ovs-nsh]How to implement NSH function
Hi Ben, I found it now, Thanks a lot ;) On Tue, Jun 18, 2019 at 04:14:15PM +, Ziyu Wu via discuss wrote: > I want to test NSH features as OVS 2.9+ has been added NSH support. > > But I don’t know how to write the flow entries(actions/fields, As mentioned by Jaime, It’s different from nsh-patch version). > > Where can I get some further instructions/examples for reference? > > I currently found only one sample flow entries like below. > > “ > table=0,in_port=1,dl_type=0x894f,nsh_ttl=63,nsh_mdtype=1,nsh_np=3,nsh_spi=0x123456,nsh_si=255,nsh_c1=0x11223344,actions=set_field:0x2->nsh_flags,set_field:254->nsh_si,set_field:0x44332211->nsh_c1,2 > > ” Did you read ovs-fields(7)? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-nsh]How to implement NSH function
On Tue, Jun 18, 2019 at 04:14:15PM +, Ziyu Wu via discuss wrote: > I want to test NSH features as OVS 2.9+ has been added NSH support. > > But I don’t know how to write the flow entries(actions/fields, As mentioned > by Jaime, It’s different from nsh-patch version). > > Where can I get some further instructions/examples for reference? > > I currently found only one sample flow entries like below. > > “ > table=0,in_port=1,dl_type=0x894f,nsh_ttl=63,nsh_mdtype=1,nsh_np=3,nsh_spi=0x123456,nsh_si=255,nsh_c1=0x11223344,actions=set_field:0x2->nsh_flags,set_field:254->nsh_si,set_field:0x44332211->nsh_c1,2 > > ” Did you read ovs-fields(7)? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] ovs-dpctl del-flow works strange
In general, we don't pay much attention to OVS behavior here, because this isn't something users should do. On Tue, Jun 18, 2019 at 11:10:40AM +0800, Levente Csikor wrote: > Minor update: > Iperf was using different source port when re-initiated, so this is why > it became again part of fast path. > > If I send packets that matches the allow rule and all header fields are > the same, then it won't be cached again once it has been deleted. > > > On Tue, 2019-06-18 at 10:38 +0800, Levente Csikor wrote: > > Hi fellow OVS users and gurus, > > > > I am playing with ovs-dpctl del-flow command to manually remove > > entries > > from the cache. > > > > I have a following entry in the cache which let's incoming traffic to > > a > > destination IP with udp port 80 to a service: > > > > recirc_id(0),in_port(4),eth(),eth_type(0x0800),ipv4(dst=10.0.0.2,prot > > o= > > 17,frag=no),udp(dst=80), packets:247279, bytes:14836740, used:0.000s, > > actions:2 > > > > However, if I want to delete the flow and use the syntax off directly > > adding a flow to the datapath described in the manual, i.e., using > > syntax like this: > > ovs-dpctl del-flow > > "in_port(4),eth(),eth_type(0x0800),ipv4(dst=10.0.0.2,proto=17,frag=no > > ), > > udp(dst=80) > > > > it gives me an error that it does not find a corresponding flow rule: > > ovs-dpctl: deleting flow (No such file or directory) > > Perhaps you need to specify a UFID? > > > > > > Then, I realized that if dpctl dump-flows is called with parameter '- > > m', it prints out the ufid (unique flow identifiers) for the datapath > > entries. > > Using a command like this accordingly does the job: > > ovs-dpctl del-flow ufid:5cc7e599-7050-4b4a-83d6-8a8fe8e8a975 > > > > What is the difference? and can someone let me know an example of > > del- > > flow command to show what to include in/exlude of the command? > > > > > > On the other hand, when I finally remove an entry via ufid, then it > > seems that it is permanently removed! > > Traffic is still on, but no new entries are spawned in the datapath > > letting me think that now everything is going through the slow path > > (especially that an experiment of iperf between two VMs, the > > throughput > > dropped down below 1Gbps from 35-40Gbps. > > > > I also tried to stop the traffic, wait more than 10 sec to let the > > megaflow cache entries expire, and restarted the traffic. > > Then, the traffic is cached again and everything is back to its > > normal > > operation. > > > > > > For curiosity, I have tried the same thing for a drop-rule instead of > > an allow rule. > > (This means that the entry I am deleting is not represented in both > > the > > slow path and fast path in the same way, i.e., there can be many > > entries in the cache that matches a drop rule.) > > Anyway, if I remove a (drop) entry from the fast path then the > > corresponding entry will never ever be there again: > > > > - Packets matching on the drop rule are still coming in -> processed > > by > > slow path > > - Wait again more than 10 sec, still won't be cached again -> > > processed > > by slow path > > > > I did even try this with removing all entries in the fast path that > > correspond to a drop rule in the flow table. I still have the same > > case. > > > > > > What am I doing wrong? Is there any timeout for these deletions? > > > > Thanks, > > lev > > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] [ovs-nsh]How to implement NSH function
Hi experts, Good days. I want to test NSH features as OVS 2.9+ has been added NSH support. But I don’t know how to write the flow entries(actions/fields, As mentioned by Jaime, It’s different from nsh-patch version). Where can I get some further instructions/examples for reference? I currently found only one sample flow entries like below. “ table=0,in_port=1,dl_type=0x894f,nsh_ttl=63,nsh_mdtype=1,nsh_np=3,nsh_spi=0x123456,nsh_si=255,nsh_c1=0x11223344,actions=set_field:0x2->nsh_flags,set_field:254->nsh_si,set_field:0x44332211->nsh_c1,2 ” Appreciate your reply. Best wishes, Ziyu ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN in Userspace
On Tue, Jun 18, 2019 at 10:41:16AM -0400, Vasu Dasari wrote: > Flavio, > > The device(could be a regular interface) should have been added to OVS with > "add-port" and when it is removed, ARP entries learnt on it well be removed > as well. Not necessarily. You could have a regular kernel interface with the tunnel endpoint address which is not part of an OVS bridge. > The code is ready. Regarding, testing the code I am planning on extending > already existing case where tests are performed to check ARP entry > existence, like for example, "tunnel_push_pop - underlay bridge match" in > tunnel-push-pop.at. I hope that is fine, or should I be writing a separate > unit test case? Usually we just add more tests to the file to cover additional use-cases. fbl > > -Vasu > > *Vasu Dasari* > > > On Fri, Jun 14, 2019 at 9:15 AM Flavio Leitner wrote: > > > On Thu, Jun 13, 2019 at 10:58:21PM -0400, Vasu Dasari wrote: > > > Flavio, > > > > > > tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a bridge > > is > > > removed, ARP entries learnt on that bridge alone have to be removed. > > > Entries from other bridges have to be in tact. > > > > > > I am thinking of doing the following: > > > > > > 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const char* > > > br_name) which purges all neighbor entries on bridge br_name. > > > > That's better, indeed. > > > > > > > 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke the > > > function tnl_neigh_flush () to flush the entries. > > > > > > til_neigh_xxx() functions are getting called from ofproto-dpif-xlate.c, > > and > > > hence thinking that xlate_xbridge_remove() is a right place to do the > > job. > > > > > > What do you think? > > > > The device with the IP address can be any regular interface, so > > do you think it would work if you remove a device that is out of > > OVS? > > > > fbl > > > > > > > > -Vasu > > > > > > > > > On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari wrote: > > > > > > > Yes Flavio. Looking at code to fix this. Will send fix for review soon. > > > > > > > > Vasu > > > > > > > > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner > > wrote: > > > > > > > > > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote: > > > > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with > > stale ARP > > > > >> entries after a bridge is deleted. > > > > >> > > > > >> I ran my tunneling experiment successfully. Used mininet to > > simulate the > > > > >> environment. After quitting the mininet, switch s1 is deleted. But, > > I > > > > still > > > > >> see the ARP entries in OVS. > > > > > > > > > > Looks like when route_table_valid is false we also need to > > > > > call tnl_neigh_cache_flush() otherwise you will need to wait > > > > > the ARP entry in the cache to expire (15min?) which is quite > > > > > a long time. > > > > > > > > > > Do you think you can work on a patch? > > > > > > > > > >> root@mn1:~# ovs-vsctl show > > > > >> f6af5f1c-a11c-435f-9b03-7317f364ae48 > > > > >>Manager "ptcp:6640" > > > > >>ovs_version: "2.9.0" > > > > >> > > > > >> Even thought there is no s1, I still see entries here. > > > > >> root@mn1:~# ovs-appctl tnl/arp/show > > > > >> IPMAC > > Bridge > > > > >> > > > > > > == > > > > >> 172.168.1.1 02:42:ac:14:00:02 s1 > > > > >> 172.168.1.2 02:42:ac:14:00:03 s1 > > > > >> 10.0.0.10 82:ec:29:c0:bc:ef s1 > > > > >> 10.0.0.1 d2:54:11:f0:95:df s1 > > > > >> > > > > >> > > > > >> Just for completeness, this is what I had to do to fix my > > configuration. > > > > >> > > > > >> Figured out what was wrong with my configuration. > > > > >> > > > > >> Modify my bridge s1 to be: > > > > >> > > > > >> ovs-vsctl --may-exist add-br s1 \ > > > > >>-- set Bridge s1 datapath_type=netdev \ > > > > >>-- set bridge s1 fail-mode=standalone \ > > > > >> other_config:hwaddr=$(cat /sys/class/net/eth1/address) > > > > >> > > > > >> Add the flows: > > > > >> ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan" > > > > >> ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1" > > > > >> ovs-ofctl add-flow s1 "priority=0 actions=NORMAL" > > > > >> > > > > >> ip addr add 1.1.1.1/24 dev s1 > > > > >> ip link set s1 up > > > > >> ip addr flush dev eth1 2>/dev/null > > > > >> ip link set eth1 up > > > > >> > > > > >> ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02 > > > > > > > > > > Yeah, that will replace the old entry with the new one. > > > > > > > > > > fbl > > > > > > > > > > > > > > >> > > > > >> *Vasu Dasari* > > > > >> > > > > >> > > > > >>> On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff wrote: > > > > >>> > > > > On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote: > > >
Re: [ovs-discuss] GRE over IPv6 configuration
On Mon, Jun 17, 2019 at 10:46 PM Eli Britstein wrote:
>
>
> On 6/18/2019 1:22 AM, Gregory Rose wrote:
> >
> > On 6/12/2019 2:20 AM, Eli Britstein wrote:
> >> Could you please have a look (and even better try?) still need to
> >> tidy up
> >>
> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Felibr-mellanox%2Flinux%2Ftree%2Fovs-ipv6-gredata=02%7C01%7Celibr%40mellanox.com%7C25425e700b58418b19fa08d6f37253ae%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636964069686971905sdata=Ki55ZQGwQKNNDkB4PZ1zpk9aqC42TXbt5WT%2F86SDauo%3Dreserved=0
> >>
> >>
> >>
> >
> > Hi Eli,
> >
> > I finally managed to getting around and building your kernel. At
> > least it does do away with the protocol error message but
> > I haven't gotten it working yet. Stay tuned and I'll provide feedback.
>
> Hi Greg,
>
> I think William was right pointing out the comment from Pravin. I agree
> with them that if we can avoid changing the kernel, and support it via
> lib/dpif-netlink-rtnl.c, it is the way to go, and we should abandon the
> kernel changes.
>
> I haven't deep dived into it yet to see how ip6erspan works (at least no
> creation error, didn't run traffic though) and ip6gre doesn't.
>
Hi Eli and Greg,
I've found the root cause using upstream kernel 5.2.
When adding an ip6gre device type, the
ovs_vport_cmd_new
new_vport
netdev_create
ovs_netdev_link
and fails due to
if (vport->dev->flags & IFF_LOOPBACK ||
(vport->dev->type != ARPHRD_ETHER &&
vport->dev->type != ARPHRD_NONE) ||
ovs_is_internal_dev(vport->dev)) {
err = -EINVAL;
Because ip6gre is ARPHRD_IP6GRE
Which means ip6gre never works using upstream kernel :(
If we use ip6gretap, then its type is ARPHRD_ETHER,
and the ip6gretap device can be created successfully.
And for ip6erspan, it's never been a issue because it is ARPHRD_ETHER.
And when using compat module, ip6gre works due to a coincident here:
at datapath/linux/compat/ip6_gre.c
static struct rtnl_link_ops ip6gre_link_ops __read_mostly = {
.kind = "ip6gre",
.maxtype= RPL_IFLA_GRE_MAX,
static struct rtnl_link_ops ip6gre_tap_ops __read_mostly = {
.kind = "ip6gre",
.maxtype= RPL_IFLA_GRE_MAX,
.policy = ip6gre_policy,
.priv_size = sizeof(struct ip6_tnl),
We happen to use ip6gre_tap link ops in type "ip6gre"
Regards,
William
> Furthermore, I think the following is missing, as there is no ip6gretap,
> only ip6gre:
>
> diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
> index 2e23a8c14..08084abb7 100644
> --- a/lib/dpif-netlink-rtnl.c
> +++ b/lib/dpif-netlink-rtnl.c
> @@ -104,7 +104,13 @@ vport_type_to_kind(enum ovs_vport_type type,
> case OVS_VPORT_TYPE_IP6ERSPAN:
> return "ip6erspan";
> case OVS_VPORT_TYPE_IP6GRE:
> -return "ip6gre";
> +if (tnl_cfg->pt_mode == NETDEV_PT_LEGACY_L3) {
> +return "ip6gre";
> +} else if (tnl_cfg->pt_mode == NETDEV_PT_LEGACY_L2) {
> +return "ip6gretap";
> +} else {
> +return NULL;
> +}
>
> >
> > And thanks for realizing this gap in tunneling coverage for ip6 gre.
> > Slipped the cracks it did.
> Thank you for investing more of your time with it.
> >
> > - Greg
> >
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] OVS and vxlan processor on the same host
Hello, Is it possible to setup openvswitch with a server which process vxlan traffic on the same host? I'd like to setup vxlan with: sudo ovs-vsctl add-port br0 vtep -- set interface vtep type=vxlan option:remote_ip=127.0.0.1 option:key=flow ofport_request=10 Then I'd like to start my server listening for UDP packets on the vxlan port 4789 but it fails because the port is already allocated by openvswitch. So is there a way to configure vxlan port where the OVS is listening on and the remote port on which the vxlan data are sent to? Thanks in advance Miroslav ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN in Userspace
Flavio, The device(could be a regular interface) should have been added to OVS with "add-port" and when it is removed, ARP entries learnt on it well be removed as well. The code is ready. Regarding, testing the code I am planning on extending already existing case where tests are performed to check ARP entry existence, like for example, "tunnel_push_pop - underlay bridge match" in tunnel-push-pop.at. I hope that is fine, or should I be writing a separate unit test case? -Vasu *Vasu Dasari* On Fri, Jun 14, 2019 at 9:15 AM Flavio Leitner wrote: > On Thu, Jun 13, 2019 at 10:58:21PM -0400, Vasu Dasari wrote: > > Flavio, > > > > tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a bridge > is > > removed, ARP entries learnt on that bridge alone have to be removed. > > Entries from other bridges have to be in tact. > > > > I am thinking of doing the following: > > > > 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const char* > > br_name) which purges all neighbor entries on bridge br_name. > > That's better, indeed. > > > > 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke the > > function tnl_neigh_flush () to flush the entries. > > > > til_neigh_xxx() functions are getting called from ofproto-dpif-xlate.c, > and > > hence thinking that xlate_xbridge_remove() is a right place to do the > job. > > > > What do you think? > > The device with the IP address can be any regular interface, so > do you think it would work if you remove a device that is out of > OVS? > > fbl > > > > > -Vasu > > > > > > On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari wrote: > > > > > Yes Flavio. Looking at code to fix this. Will send fix for review soon. > > > > > > Vasu > > > > > > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner > wrote: > > > > > > > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote: > > > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with > stale ARP > > > >> entries after a bridge is deleted. > > > >> > > > >> I ran my tunneling experiment successfully. Used mininet to > simulate the > > > >> environment. After quitting the mininet, switch s1 is deleted. But, > I > > > still > > > >> see the ARP entries in OVS. > > > > > > > > Looks like when route_table_valid is false we also need to > > > > call tnl_neigh_cache_flush() otherwise you will need to wait > > > > the ARP entry in the cache to expire (15min?) which is quite > > > > a long time. > > > > > > > > Do you think you can work on a patch? > > > > > > > >> root@mn1:~# ovs-vsctl show > > > >> f6af5f1c-a11c-435f-9b03-7317f364ae48 > > > >>Manager "ptcp:6640" > > > >>ovs_version: "2.9.0" > > > >> > > > >> Even thought there is no s1, I still see entries here. > > > >> root@mn1:~# ovs-appctl tnl/arp/show > > > >> IPMAC > Bridge > > > >> > > > > == > > > >> 172.168.1.1 02:42:ac:14:00:02 s1 > > > >> 172.168.1.2 02:42:ac:14:00:03 s1 > > > >> 10.0.0.10 82:ec:29:c0:bc:ef s1 > > > >> 10.0.0.1 d2:54:11:f0:95:df s1 > > > >> > > > >> > > > >> Just for completeness, this is what I had to do to fix my > configuration. > > > >> > > > >> Figured out what was wrong with my configuration. > > > >> > > > >> Modify my bridge s1 to be: > > > >> > > > >> ovs-vsctl --may-exist add-br s1 \ > > > >>-- set Bridge s1 datapath_type=netdev \ > > > >>-- set bridge s1 fail-mode=standalone \ > > > >> other_config:hwaddr=$(cat /sys/class/net/eth1/address) > > > >> > > > >> Add the flows: > > > >> ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan" > > > >> ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1" > > > >> ovs-ofctl add-flow s1 "priority=0 actions=NORMAL" > > > >> > > > >> ip addr add 1.1.1.1/24 dev s1 > > > >> ip link set s1 up > > > >> ip addr flush dev eth1 2>/dev/null > > > >> ip link set eth1 up > > > >> > > > >> ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02 > > > > > > > > Yeah, that will replace the old entry with the new one. > > > > > > > > fbl > > > > > > > > > > > >> > > > >> *Vasu Dasari* > > > >> > > > >> > > > >>> On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff wrote: > > > >>> > > > On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote: > > > I am running into an issue which sounds pretty basic, probably I > > > might be > > > missing something. > > > >>> > > > >>> I think you're trying to use kernel tools to configure userspace > > > >>> tunnels. Did you read Documentation/howto/userspace-tunneling.rst? > > > >>> > > > > > > > >> ___ > > > >> discuss mailing list > > > >> disc...@openvswitch.org > > > >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > > > > >
[ovs-discuss] [ovn-loadbalance]Not all subnets can connect to vip
Hi,
I have deployed ovn with openstack/octavia.
I have four subnets,that are 192.168.1.0, 192.168.2.0, 192.168.3.0,
192.168.4.0, which are added to a logical router.
vips : {"192.168.1.8:22"="192.168.1.2:22,192.168.2.2:22,192.168.3.2:22"}
I found that if I want to connect the vip 192.168.1.8:22, my ip must be in
192.168.1.0/24 or 192.168.2.0/24,192.168.3.0/24, otherwise it will failed. That
means the ip which try to connect ,must be in subnet of vip or subnet of pool
member.
Dose this situation is right ? I think all the subnets added to the same
router with vip ,should connect successfully.
Thanks ,
Yun
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
