[SFC-221] SFC get the null egress vxlan-gpe ports Created: 22/Jun/18  Updated: 23/Aug/18

Status: Open
Project: sfc
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Medium
Reporter: Qiuzheng Ren Assignee: Brady Johnson
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Sometimes the ovs has two same vxlan-gpe ports ,one port is effective and another port number is null. For example :

[root@wlz-controller ~]# ovs-vsctl show
e5d7e63c-0c4a-4f0e-b0db-d3441d02c7c9
Manager "tcp:172.23.27.12:6640"
Bridge br-int
Controller "tcp:172.23.27.12:6653"
fail_mode: secure
Port "bond0"
Interface "bond0"
Port veth_br
Interface veth_br
Port "qosoutveth1"
Interface "qosoutveth1"
error: "could not open network device qosoutveth1 (No such device)"
Port "tun162d5c0de6a"
Interface "tun162d5c0de6a"
type: vxlan
options: {exts=gpe, key=flow, local_ip="10.0.1.91", remote_ip=flow}
Port br-int
Interface br-int
type: internal
Port "tap1e436556-5f"
Interface "tap1e436556-5f"
type: internal
Port "tapb1f58ae4-7c"
Interface "tapb1f58ae4-7c"
type: internal
Port "enp1s0f1"
Interface "enp1s0f1"
Port "tun6f0e9979c0b"
Interface "tun6f0e9979c0b"
type: vxlan
options: {exts=gpe, key=flow, local_ip="10.0.1.91", remote_ip=flow}

When sfc gert the egress vxlan-gpe port, it maybe get the null port. As a result , the flow table is wrong. 



 Comments   
Comment by Jaime Caamaño Ruiz [ 05/Jul/18 ]

Which port is the null port on that output?

Port "tun162d5c0de6a"
Interface "tun162d5c0de6a"
type: vxlan
options: {exts=gpe, key=flow, local_ip="10.0.1.91", remote_ip=flow}

Port "tun6f0e9979c0b"
Interface "tun6f0e9979c0b"
type: vxlan
options: {exts=gpe, key=flow, local_ip="10.0.1.91", remote_ip=flow}

I am surprised about that, I would think OVS would not allow to create two tunnel ports with the same parameters twice.

Comment by Qiuzheng Ren [ 23/Aug/18 ]

But the ovs really create two  tunnel ports and  one of the ports does not have the port number.

[root@wlz-controller odl]# ovs-vsctl show
e3894f29-cb8b-484e-a711-98411854e978
Manager "tcp:172.23.27.12:6640"
is_connected: true
Bridge br-int
Controller "tcp:172.23.27.12:6653"
fail_mode: secure
Port "tunad8b9653c61"
Interface "tunad8b9653c61"
type: vxlan
options: {exts=gpe, key=flow, local_ip="10.0.1.91", remote_ip=flow}
Port br-int
Interface br-int
type: internal
Port "tun9285edd6d47"
Interface "tun9285edd6d47"
type: vxlan
options: {exts=gpe, key=flow, local_ip="10.0.1.91", remote_ip=flow}
Port "tapc5d79335-8b"

[root@wlz-controller odl]# ovs-ofctl show -O Openflow13 br-int
OFPT_FEATURES_REPLY (OF1.3) (xid=0x2): dpid:0000fce6e8bafdd6
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS QUEUE_STATS
OFPST_PORT_DESC reply (OF1.3) (xid=0x3):
1(tapc5d79335-8b): addr:b6:f7:6d:4a:92:84
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
2(tunad8b9653c61): addr:c6:78:1c:b0:c4:4f
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
7(tap5000f882-28): addr:00:00:00:00:0c:51
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
LOCAL(br-int): addr:fc:e6:e8:ba:fd:d6
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (OF1.3) (xid=0x5): frags=normal miss_send_len=0

 

We can see through the command "ovs-vsctl show ",there is two tunnel ports. and  only one tunnel has the port number.

I don't know why it happens. The netvirt module can select the correct tunnel ports and write correct flow tables. I suspect it maybe caused by netvirt.

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