I would like to chain two docker containers (Docker service function chaining) on a VM running ubuntu 16.04. I would like to chain these containers using an OVS bridge. I follow this instruction. In the first scenario below, I cannot chain the containers, while in the second scenario I can:

First, I install the NSH patch using "start-ovs-deb.sh". However, when I create a port using ovs-docker, the first container cannot ping the other container, and vice versa. They also cannot ping the ovs-bridge created in Ubuntu VM.

Using the original OVS, two containers can ping each other.
I would appreciate if you could provide some insight how to fix this issue.

As per [1], "tests: Change ADD_OF_PORTS from macro to shell function.",
ADD_OF_PORTS, used in patches 0002 and 0003 should be updated.

BR,
Alex

[1] http://patchwork.ozlabs.org/patch/574096/

Hi Yi,

Per the latest NSH draft (https://www.ietf.org/id/draft-ietf-sfc-nsh-04.txt), nsp and nsi should be renamed to spi and si, respectively.

Best regards,
Igor.

I have packet structure with following format

eth | OuterIP |GRE | NSH | Inner IP packet

Few Questions:

1. Currently I can match till GRE, But for NSH matching the diff is not upstreamed yet
   Does this support GRE+NSH or it just supports VXLAN+NSH

2. Does OVS Flow supports raw data[Eth+OuterIP+GRE+NSH+InnerIP] packet match.
   atleast from my reading ovs-ofctl, ovs-fields documentation I did not find
   such a thing.

As someone else wanted to test this out and needed RPMs, I figured I'd just build a new src.rpm with the patches applied (per instructions in the README.md) and load it into COPR.

For your general viewing pleasure: https://copr.fedorainfracloud.org/coprs/leifmadsen/ovs-nsh-master/

I've not tested these RPMs though or vetted them for correct application of the patches. Additionally, I kind of cheated and applied the patches directly to the source rather than applying them from the RPM spec file (I was in a rush).

Use at your own risk.

Hello yang,

I am validating the basic vxlan-gpe to vxlan-gpe communication on using on applying https://github.com/yyang13/ovs_nsh_patches using dpdk datapath that results in crashing of vswitchd process(Terminates using SIGABRT signal).

The diagram and commands used for launching of dpdk is as follows,

192.168.10.10/24                      192.168.10.20/24
+--------------+                       +--------------+
|    br-int   |                       |    br-int    |
+--------------+                       +--------------+
| vxlan0-gpe  |                       | vxlan0-gpe   |
+--------------+                       +--------------+
       |                                      |
       |                                      |
       |                                      |
200.2.0.101/24                     200.2.0.102/24 
+--------------+                      +---------------+
|    br-eth1   |                      |     br-eth1   |
+--------------+                      +---------------+
|    eth1      |----------------------|      eth1     |
+--------------+                      +---------------+       

ifup br-int and ping form br-int (192.168.10.10 to 192.168.10.20) fails and ends up in aborting of vswitchd process.

kernel used : 4.4.0-22 (ubuntu 16.04) Release.
ETH1 and ETH2 : Intel's 10-Gigabit X540-AT2 (rev 01), Binded with vfio-pci module

commands used for launching openvswitch process,

#  ./ovsdb/ovsdb-tool create /etc/openvswitch/conf.db ./vswitchd/vswitch.ovsschema
#  ./ovsdb/ovsdb-server --remote=punix:/var/run/openvswitch/db.sock  --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach
#  ./utilities/ovs-vsctl --no-wait init
#   export DB_SOCK=/var/run/openvswitch/db.sock
#  ./vswitchd/ovs-vswitchd --dpdk -c 0x3 -n 4 --socket-mem 2048,0 -- unix:$DB_SOCK --pidfile --detach --log-file=/var/log/openvswitch/ovs-vswitchd.log -vconsole:err -vsyslog:dbg -vfile:err --verbose=dbg

command used for creating the the br-int and br-eth1 bridges and ports(Remote ip, br-eth and br-int ip is been modified on HOSTB)

# ovs-vsctl add-br br-eth1 -- set bridge br-eth1 datapath_type=netdev
# ovs-vsctl add-port br-eth1 dpdk0 -- set Interface dpdk0 type=dpdk
# ip link set br-eth1  up
# ip addr add 200.2.0.101/24 dev br-eth1

# ovs-vsctl add-br  br-int -- set bridge br-ext  datapath_type=netdev
# ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 type=vxlan options:remote_ip=200.2.0.102 options:key=flow options:dst_port=4790 options:exts=gpe

Requesting to know Is there any steps i am are missing out or there is any alternative way to get vxlan-gpe to vxlan-gpe working, or the current release requires any support for SFC using DPDK data path.

Thanks,
Rakesh

After the "push_nsh" action had executed in flow table, the "set_field" action to ethernet header (i.e mod_dl_src) was no longer working.

I conducted experiment with "ovs-ofctl add-flow" command and monitored with Wireshark on OVS (monitor the network interface of port1 as follows)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            node1(192.168.5.16)--[port2]--OVS--[port1]--node2(192.168.5.13)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---------------------------- Case1
The OVS did't set the mac address to "12:34:56:78:9a:bc" after it push a nsh_header

dump flows :
cookie=0x0, duration=7.552s, table=0, n_packets=2, n_bytes=148, priority=100,ip,in_port=2,nw_src=192.168.5.16,nw_dst=192.168.5.13 actions=push_nsh,load:0x1->NXM_NX_NSH_MDTYPE[],load:0x1->NXM_NX_NSH_NP[],load:0x4->NXM_NX_NSP[0..23],load:0xff->NXM_NX_NSI[],load:0x1->NXM_NX_NSH_C1[],load:0x2->NXM_NX_NSH_C2[],load:0x3->NXM_NX_NSH_C3[],load:0x4->NXM_NX_NSH_C4[],set_field:12:34:56:78:9a:bc->eth_dst,output:1

Wireshark result :
Ethernet II, Src: le:3f:be:5f:a4:6a, Dst: 8a:75:a0:08:d8:ee

---------------------------- Case2
I continue to test with combing two flows to achieve the same utility as Case1
After the "set_field" action had executed int table[0], the OVS pushed NSH header to the packet in table[1]. I show the result as below.

dump flows :
cookie=0x0, duration=12.128s, table=0, n_packets=3, n_bytes=222, priority=100,ip,in_port=2,nw_src=192.168.5.16,nw_dst=192.168.5.13 actions=set_field:12:34:56:78:9a:bc->eth_dst,goto_table:1
cookie=0x0, duration=2.432s, table=1, n_packets=1, n_bytes=74, priority=100,ip,in_port=2,nw_src=192.168.5.16,nw_dst=192.168.5.13 actions=push_nsh,load:0x1->NXM_NX_NSH_MDTYPE[],load:0x1->NXM_NX_NSH_NP[],load:0x4->NXM_NX_NSP[0..23],load:0xff->NXM_NX_NSI[],load:0x1->NXM_NX_NSH_C1[],load:0x2->NXM_NX_NSH_C2[],load:0x3->NXM_NX_NSH_C3[],load:0x4->NXM_NX_NSH_C4[],output:1

Wireshark result :
Ethernet II, Src: le:3f:be:5f:a4:6a, Dst: 12:34:56:78:9a:bc