Hi Jaime, Brady Thanks a lot for patch. With the help from John Lester, I also got sfc103 demo work!
I have been working to extend sfc103 demo to develop a proof-of-concept for my research idea. Now I have two extra questions: 1) I remember that I read it somewhere on the Internet, NSH metadata type 2 has not been implemented with ODL SFC project, right? I checked the source code of OVS. I think NSH metadata type 2 is supported by OVS? 2) I need some tools to evaluate the latency, for example, for an HTTP request. Does ODL SFC provide some utilities for this? I'm also looking for solution for this, if ODL SFC has some utilities, that will be very helpful. In addition, according to Jaime's mail exchanged with OVS community, for sfc103 demo, if we turn off `tx offload` for docker and vagrant's VM, we can avoid this checksum problem? BR, Qipeng On Fri, Mar 29, 2019 at 1:27 PM Jaime Caamaño Ruiz <jcaam...@suse.de> wrote: > Hi > > I just tried out myself. I rebased the patch [1] on master and added a > few fixes but nothing that strikes me as the problem that both of you > are having. One of the fixes includes a new dependency for the OVS 2.11 > kernel module that prevents it to be correctly installed but the > consequence was rather evident. > > For me the connectivity test works even though you notice that it is > very slow because of the retransmissions due to the checksum problem. > > Could you try again with the new patchset? > > [1] https://git.opendaylight.org/gerrit/#/c/79533/ > > BR > Jaime. > > -----Original Message----- > From: John Lester <jd8les...@gmail.com> > To: jcaam...@suse.de > Cc: Brady Johnson <bradyallenjohn...@gmail.com>, Qipeng Song <qpsong@gm > ail.com>, sfc-dev opendaylight <sfc-dev@lists.opendaylight.org> > Subject: Re: [sfc-dev] Problems related to sfc103 demo > Date: Mon, 25 Mar 2019 16:27:41 -0400 > > I still observe the packets not being egressed out the classifier with > Brady's patch. And in the OVS logs, I still see the Invalid argument > warning. I am using OVS 2.11.90 and Linux 4.4.0 (SFC-Demo 103). The > flow rule is shown below. Did the patch work for you? I'm not sure the > out of order actions are the problem? > > cookie=0x0, duration=7464.231s, table=0, n_packets=45, n_bytes=3330, > priority=1000,tcp,in_port="veth- > br",nw_src=192.168.2.0/24,nw_dst=192.168.2.0/24,tp_dst=80 > actions=encap(nsh),set_field:0x38/0xffffff->nsh_spi,set_field:255- > >nsh_si,set_field:0x1->nsh_c1,set_field:0x2->nsh_c2,set_field:0x3- > >nsh_c3,set_field:0x4->nsh_c4,encap(ethernet),load:0xc0a80114- > >NXM_NX_TUN_IPV4_DST[],output:"sff0-dpl" > > Thanks, > JD > > On Mon, Mar 11, 2019 at 11:15 AM Jaime Caamaño Ruiz <jcaam...@suse.de> > wrote: > > Hello Qipeng > > > > > 2019-02-25T16:23:54.162Z|00037|dpif_netlink|WARN|Failed to create > > > sff0- > > > dpl with rtnetlink: Invalid argument > > > > I havent observed this on my side. Could this be related with the > > development OVS version you are running? Did you make sure you are > > running an OVS kernel module that is not too old? > > > > > For the message, > > > `push_eth(src=00:00:00:00:00:00,dst=00:00:00:00:00:00)`, I don’t > > > know > > > whether it really matters, because when I search with this sentence > > > with google, I do find some posts containing such a message. > > > > That should not be a problem. The "Invalid Argument" issue was due to > > writing openflow actions out of order. The fix is included in Brady's > > patch. > > > > We did trace back to an issue in OVS where it does not output correct > > tcp checksums when combined with nsh encapsulation. More info @ [1]. > > I > > suggest that you reproduce the issue and to follow up [1] with your > > own > > info to check if we could get some more traction there. > > > > More info: > > > > [1] https://mail.openvswitch.org/pipermail/ovs-discuss/2018-June/0469 > > 03.html > > > > BR > > Jaime. > > > > -----Original Message----- > > From: Qipeng Song <qps...@gmail.com> > > To: Brady Johnson <bradyallenjohn...@gmail.com>, jcaam...@suse.de > > Cc: sfc-dev opendaylight <sfc-dev@lists.opendaylight.org> > > Subject: Re: [sfc-dev] Problems related to sfc103 demo > > Date: Tue, 26 Feb 2019 00:42:02 +0100 > > > > Dear Brady, > > > > I would like to pick up on this problem again after almost one month. > > I > > noticed that you have submitted a third patch related to this demo. I > > tried. It seems that the problem we discussed is still there. > > > > I agree with you that classifier1 in this demo does not egress any > > packet. I tried to tcpdump `veth-br0` and I do observe the http > > traffic > > sent from `veth-app` device. > > > > In addition, I check the content of /var/log/openvswitch/ovs- > > vswitchd.log. I find one entry what I think maybe helpful for debug > > this problem: > > > > 2019-02-25T16:23:54.162Z|00037|dpif_netlink|WARN|Failed to create > > sff0- > > dpl with rtnetlink: Invalid argument > > > > According to the output of command `ovs-vsctl show`: > > > > root@classifier1:/# ovs-vsctl show > > c4da2445-7a71-4eb5-b4f8-16894a5228dd > > Manager "tcp:192.168.1.5:6640" > > is_connected: true > > Bridge br-sfc > > Controller "tcp:192.168.1.5:6653" > > is_connected: true > > Port "sff0-dpl" > > Interface "sff0-dpl" > > type: vxlan > > options: {dst_port="6633", exts=gpe, remote_ip=flow} > > Port br-sfc > > Interface br-sfc > > type: internal > > Port veth-br > > Interface veth-br > > ovs_version: "2.11.90" > > > > Port sff0-dpl is important to forward packet to sff in a service > > function chain. > > > > For the message, > > `push_eth(src=00:00:00:00:00:00,dst=00:00:00:00:00:00)`, I don’t > > know > > whether it really matters, because when I search with this sentence > > with google, I do find some posts containing such a message. > > > > Thus, I doubt that perhaps the cause of this problem is, due to > > somewhat invalide arguement during creation of sff0-dpl, the packet > > that forwarded from `veth-br`to `sff0-dpl` cannot be correctly > > processed? > > > > Hope to see your feedback. > > > > Thanks in advance, > > Qipeng > > > > > On 21 Jan 2019, at 16:15, Brady Johnson <bradyallenjohn...@gmail.co > > m> > > > wrote: > > > > > > Qipeng, > > > > > > I get this same problem. > > > > > > Those ODL errors dont really matter. Remember, once the flows are > > > written to the OVS bridges, errors in ODL shouldnt affect traffic. > > > > > > With the help of Manuel Buil from OPNFV SFC, we were able to > > > determine that OVS on the classifier is not egressing any packets. > > I > > > tried doing a tcpdump on every interface in classifier1, and didnt > > > get anything. I then saw some errors in /var/log/openvswitch/ovs- > > > vswitchd.log that helped me figure out the problem. First it was > > > complaining about some invalid arguments set on the VXLAN tunnel in > > > OVS, as follows: > > > > > > > 2019-01-21T14:01:04.692Z|00105|dpif(handler7)|WARN|system@ovs-sy > > st > > > > em: failed to put[create] (Invalid argument) ufid:75d78d13-c972- > > > > 4f50-ac66-d0a6668e8b7c rec > > > > > > irc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(2),skb_mark(0/0), > > > > > > ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00 > > > > :11:11:11:11,dst=00:00: > > > > > > 22:22:22:22),eth_type(0x0800),ipv4(src=192.168.2.1/255.255.255.0,d > > > > > > st=192.168.2.2/255.255.255.0,proto=6,tos=0/0,ttl=64/0,frag=no),tcp( > > > > src=51636/0,dst=80),tcp > > > > _flags(0/0), > > > > > > actions:push_nsh(flags=0,ttl=63,mdtype=1,np=3,spi=0x0,si=255,c1=0x0 > > > > > > ,c2=0x0,c3=0x0,c4=0x0),set(tunnel(tun_id=0x0,dst=192.168.1.20,ttl=6 > > > > 4,tp_dst= > > > > > > 6633,flags(df|key))),push_eth(src=00:00:00:00:00:00,dst=00:00:00:0 > > > > 0:00:00),set(nsh(spi=0x4e,si=255,c1=0x1,c2=0x2,c3=0x3,c4=0x4)),3 > > > > 2019-01-21T14:01:04.692Z|00106|dpif(handler7)|WARN|system@ovs-sy > > st > > > > em: execute > > > > > > push_nsh(flags=0,ttl=63,mdtype=1,np=3,spi=0x0,si=255,c1=0x0,c2=0x0, > > > > c3=0x0,c4=0 > > > > > > x0),set(tunnel(tun_id=0x0,dst=192.168.1.20,ttl=64,tp_dst=6633,flag > > > > > > s(df|key))),push_eth(src=00:00:00:00:00:00,dst=00:00:00:00:00:00),s > > > > et(nsh(spi=0x4e,si=255, > > > > c1=0x1,c2=0x2,c3=0x3,c4=0x4)),3 failed (Invalid argument) on > > > > packet > > > > > > tcp,vlan_tci=0x0000,dl_src=00:00:11:11:11:11,dl_dst=00:00:22:22:22: > > > > 22,nw_src=192.168.2.1 > > > > > > ,nw_dst=192.168.2.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=51636,tp_ds > > > > t=80,tcp_flags=syn tcp_csum:e44 > > > > with metadata skb_priority(0),skb_mark(0),in_port(2) mtu 0 > > > > 2019-01-21T14:02:06.181Z|00081|netdev_vport|WARN|sff0-dpl: > > unknown > > > > vxlan argument 'nsp' > > > > sff0-dpl: unknown vxlan argument 'nshc2' > > > > sff0-dpl: unknown vxlan argument 'nshc3' > > > > sff0-dpl: unknown vxlan argument 'nshc4' > > > > sff0-dpl: unknown vxlan argument 'nsi' > > > > sff0-dpl: unknown vxlan argument 'nshc1' > > > > > > I removed those from the tunnel creation in setup_sfc.py but still > > > had similar problems, as follows: > > > > > > > 2019-01-21T14:44:32.795Z|00013|dpif(handler7)|WARN|system@ovs-sys > > te > > > > m: failed to put[create] (Invalid argument) ufid:e316ee8c-30b1- > > > > 4f7b-83ce-94cf9a029cab rec > > > > > > irc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(2),skb_mark(0/0),c > > > > > > t_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00: > > > > 11:11:11:11,dst=00:00: > > > > > > 22:22:22:22),eth_type(0x0800),ipv4(src=192.168.2.1/255.255.255.0,ds > > > > > > t=192.168.2.2/255.255.255.0,proto=6,tos=0/0,ttl=64/0,frag=no),tcp(s > > > > rc=39382/0,dst=80),tcp > > > > _flags(0/0), > > > > > > actions:push_nsh(flags=0,ttl=63,mdtype=1,np=3,spi=0x0,si=255,c1=0x0 > > > > > > ,c2=0x0,c3=0x0,c4=0x0),set(tunnel(tun_id=0x0,dst=192.168.1.20,ttl=6 > > > > 4,tp_dst= > > > > > > 6633,flags(df|key))),push_eth(src=00:00:00:00:00:00,dst=00:00:00:00 > > > > :00:00),set(nsh(spi=0x21,si=255,c1=0x1,c2=0x2,c3=0x3,c4=0x4)),3 > > > > 2019-01-21T14:44:32.795Z|00014|dpif(handler7)|WARN|system@ovs-sys > > te > > > > m: execute > > > > > > push_nsh(flags=0,ttl=63,mdtype=1,np=3,spi=0x0,si=255,c1=0x0,c2=0x0, > > > > c3=0x0,c4=0 > > > > > > x0),set(tunnel(tun_id=0x0,dst=192.168.1.20,ttl=64,tp_dst=6633,flags > > > > > > (df|key))),push_eth(src=00:00:00:00:00:00,dst=00:00:00:00:00:00),se > > > > t(nsh(spi=0x21,si=255, > > > > c1=0x1,c2=0x2,c3=0x3,c4=0x4)),3 failed (Invalid argument) on > > packet > > > > > > tcp,vlan_tci=0x0000,dl_src=00:00:11:11:11:11,dl_dst=00:00:22:22:22: > > > > 22,nw_src=192.168.2.1 > > > > > > ,nw_dst=192.168.2.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=39382,tp_dst > > > > =80,tcp_flags=syn tcp_csum:a04f > > > > with metadata skb_priority(0),skb_mark(0),in_port(2) mtu 0 > > > > > > This is the only flow in classifier1 that's matching, so it has to > > be > > > the one causing these problems: > > > > > > > cookie=0x0, duration=246.179s, table=0, n_packets=10, > > n_bytes=740, > > > > priority=1000,tcp,in_port="veth- > > > > br",nw_src=192.168.2.0/24,nw_dst=192.168.2.0/24,tp_dst=80 > > > > actions=encap(nsh),encap(ethernet),set_field:0x4e/0xffffff- > > > > >nsh_spi,set_field:255->nsh_si,set_field:0x1- > > >nsh_c1,set_field:0x2- > > > > >nsh_c2,set_field:0x3->nsh_c3,set_field:0x4- > > > > >nsh_c4,load:0xc0a80114->NXM_NX_TUN_IPV4_DST[],output:"sff0-dpl" > > > > > > I then compared that flow to how it works in OPNFV SFC, and > > realized > > > we are pushing an ethernet header, but never set the ethernet > > > addresses. Notice this from the above log message: > > > push_eth(src=00:00:00:00:00:00,dst=00:00:00:00:00:00). Even though > > > OVS doesnt say exactly what the invalid argument is, this must be > > the > > > problem. > > > > > > I'll work on having the SFC classifier set the mac addresses > > > accordingly. > > > > > > Regards, > > > > > > Brady > > > > > > > > > On Thu, Jan 17, 2019 at 7:22 PM Qipeng Song <qps...@gmail.com> > > wrote: > > > > Hi, Brady. > > > > > > > > Thanks for your fix. Thanks to this fixt, the error related to > > ODL > > > > API RSP created is resolved. > > > > > > > > However, when I clean all (i.e. vagrant destroy -f) and restart > > > > sfc103(i.e. demo.sh), classifier1 still cannot manage to executes > > > > command <wget> to communicate with classfier2. I use ODL Fluorine > > + > > > > OVS 2.10. > > > > > > > > Before asking for your and the community’s help, I try to figure > > > > out myself. I first check the logfile of ODL (i.e. > > > > path/to/karaf_log/karaf.log) and filter the contents with > > “ERROR”: > > > > > > > > > > > > 2019-01-17T15:52:47,150 | ERROR | opendaylight-cluster-data- > > > > akka.actor.default-dispatcher-3 | > > DOMEntityOwnershipListenerAdapter > > > > | 294 - org.opendaylight.mdsal.eos-binding-adapter - 3.0.4 | > > Error > > > > converting DOM entity ID > > > > /(urn:opendaylight:params:xml:ns:yang:mdsal:core:general- > > > > entity?revision=2015-09- > > > > > > 30)entity/entity[{(urn:opendaylight:params:xml:ns:yang:mdsal:core:g > > > > eneral-entity?revision=2015-09-30)name=ofp-topology-manager}] to > > > > binding InstanceIdentifier > > > > java.lang.NullPointerException: null > > > > 2019-01-17T15:56:13,804 | ERROR | opendaylight-cluster-data- > > > > akka.actor.default-dispatcher-2 | > > DOMEntityOwnershipListenerAdapter > > > > | 294 - org.opendaylight.mdsal.eos-binding-adapter - 3.0.4 | > > Error > > > > converting DOM entity ID > > > > /(urn:opendaylight:params:xml:ns:yang:mdsal:core:general- > > > > entity?revision=2015-09- > > > > > > 30)entity/entity[{(urn:opendaylight:params:xml:ns:yang:mdsal:core:g > > > > eneral-entity?revision=2015-09-30)name=openflow:169900783159372}] > > > > to binding InstanceIdentifier > > > > java.lang.NullPointerException: null > > > > 2019-01-17T15:56:13,825 | ERROR | opendaylight-cluster-data- > > > > akka.actor.default-dispatcher-6 | > > DOMEntityOwnershipListenerAdapter > > > > | 294 - org.opendaylight.mdsal.eos-binding-adapter - 3.0.4 | > > Error > > > > converting DOM entity ID > > > > /(urn:opendaylight:params:xml:ns:yang:mdsal:core:general- > > > > entity?revision=2015-09- > > > > > > 30)entity/entity[{(urn:opendaylight:params:xml:ns:yang:mdsal:core:g > > > > eneral-entity?revision=2015-09-30)name=openflow:161082929448001}] > > > > to binding InstanceIdentifier > > > > java.lang.NullPointerException: null > > > > 2019-01-17T15:56:13,828 | ERROR | opendaylight-cluster-data- > > > > akka.actor.default-dispatcher-4 | > > DOMEntityOwnershipListenerAdapter > > > > | 294 - org.opendaylight.mdsal.eos-binding-adapter - 3.0.4 | > > Error > > > > converting DOM entity ID > > > > /(urn:opendaylight:params:xml:ns:yang:mdsal:core:general- > > > > entity?revision=2015-09- > > > > > > 30)entity/entity[{(urn:opendaylight:params:xml:ns:yang:mdsal:core:g > > > > eneral-entity?revision=2015-09-30)name=openflow:257641316118598}] > > > > to binding InstanceIdentifier > > > > java.lang.NullPointerException: null > > > > 2019-01-17T15:56:13,832 | ERROR | opendaylight-cluster-data- > > > > akka.actor.default-dispatcher-4 | > > DOMEntityOwnershipListenerAdapter > > > > | 294 - org.opendaylight.mdsal.eos-binding-adapter - 3.0.4 | > > Error > > > > converting DOM entity ID > > > > /(urn:opendaylight:params:xml:ns:yang:mdsal:core:general- > > > > entity?revision=2015-09- > > > > > > 30)entity/entity[{(urn:opendaylight:params:xml:ns:yang:mdsal:core:g > > > > eneral-entity?revision=2015-09-30)name=openflow:196794075627855}] > > > > to binding InstanceIdentifier > > > > > > > > The whole log file is available at URL: https://www.dropbox.com/s > > /k > > > > h01oqwrbu0ao72/karaf.log?dl=0 > > > > > > > > Then I check the dump flows of ‘classifier1’ with: docker exec > > -it > > > > classifier1 ovs-ofctl dump-flows -OOpenflow13 br-sfc. The output: > > > > > > > > cookie=0x0, duration=8087.160s, table=0, n_packets=245, > > > > n_bytes=18130, priority=1000,tcp,in_port="veth- > > > > br",nw_src=192.168.2.0/24,nw_dst=192.168.2.0/24,tp_dst=80 > > > > actions=encap(nsh),encap(ethernet),set_field:0xd/0xffffff- > > > > >nsh_spi,set_field:255->nsh_si,set_field:0x1- > > >nsh_c1,set_field:0x2- > > > > >nsh_c2,set_field:0x3->nsh_c3,set_field:0x4- > > > > >nsh_c4,load:0xc0a80114->NXM_NX_TUN_IPV4_DST[],output:"sff0-dpl" > > > > cookie=0x0, duration=8087.154s, table=0, n_packets=0, n_bytes=0, > > > > priority=1000,dl_type=0x894f,nsh_spi=0x80000d,nsh_si=253 > > > > actions=decap(),decap(),output:"veth-br" > > > > cookie=0x14, duration=8087.160s, table=0, n_packets=0, n_bytes=0, > > > > priority=5 actions=goto_table:1 > > > > > > > > Nothing special. 245 packets have been sent out. Then I tried to > > > > verify the dump flows of ’SFF1’, which should receive packets > > from > > > > ‘classifier1’. The dump flows of SFF1 are: > > > > vagrant@odl:~$ docker exec -it sff1 ovs-ofctl dump-flows > > > > -Oopenflow13 br-sfc > > > > cookie=0x0, duration=8356.847s, table=0, n_packets=0, n_bytes=0, > > > > priority=1000,dl_type=0x894f,nsh_spi=0x80000d,nsh_si=253 > > > > actions=load:0xc0a8010a->NXM_NX_TUN_IPV4_DST[],IN_PORT > > > > cookie=0x14, duration=8366.192s, table=0, n_packets=0, > > n_bytes=0, > > > > priority=5 actions=goto_table:1 > > > > cookie=0x14, duration=8366.192s, table=1, n_packets=0, > > n_bytes=0, > > > > priority=250,packet_type=(1,0x894f) > > > > actions=encap(ethernet),goto_table:4 > > > > cookie=0x14, duration=8366.192s, table=1, n_packets=0, > > n_bytes=0, > > > > priority=250,dl_type=0x894f actions=goto_table:4 > > > > cookie=0x14, duration=8366.192s, table=1, n_packets=0, > > n_bytes=0, > > > > priority=5 actions=drop > > > > cookie=0x14, duration=8366.192s, table=2, n_packets=0, > > n_bytes=0, > > > > priority=5 actions=goto_table:3 > > > > cookie=0x14, duration=8366.192s, table=3, n_packets=0, > > n_bytes=0, > > > > priority=5 actions=goto_table:4 > > > > cookie=0x14, duration=8366.192s, table=4, n_packets=0, > > n_bytes=0, > > > > priority=550,dl_type=0x894f,nsh_spi=0x5,nsh_si=255 > > > > actions=load:0xc0a8011e->NXM_NX_TUN_IPV4_DST[],goto_table:10 > > > > cookie=0x14, duration=8366.192s, table=4, n_packets=0, > > n_bytes=0, > > > > priority=550,dl_type=0x894f,nsh_spi=0xd,nsh_si=254 > > > > actions=load:0xc0a80132->NXM_NX_TUN_IPV4_DST[],goto_table:10 > > > > cookie=0x14, duration=8366.192s, table=4, n_packets=0, > > n_bytes=0, > > > > priority=550,dl_type=0x894f,nsh_spi=0x800005,nsh_si=255 > > > > actions=load:0xc0a8011e->NXM_NX_TUN_IPV4_DST[],goto_table:10 > > > > cookie=0x14, duration=8366.192s, table=4, n_packets=0, > > n_bytes=0, > > > > priority=550,dl_type=0x894f,nsh_spi=0xd,nsh_si=255 > > > > actions=load:0xc0a8011e->NXM_NX_TUN_IPV4_DST[],goto_table:10 > > > > cookie=0x14, duration=8366.192s, table=4, n_packets=0, > > n_bytes=0, > > > > priority=550,dl_type=0x894f,nsh_spi=0x80000d,nsh_si=254 > > > > actions=load:0xc0a8011e->NXM_NX_TUN_IPV4_DST[],goto_table:10 > > > > cookie=0x14, duration=8366.192s, table=4, n_packets=0, > > n_bytes=0, > > > > priority=5 actions=goto_table:10 > > > > cookie=0xba5eba1100000102, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > > > priority=660,dl_type=0x894f,nsh_mdtype=1,nsh_spi=0x5,nsh_si=254,nsh > > > > _c1=0x0 actions=IN_PORT > > > > cookie=0xba5eba1100000102, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > > > priority=660,dl_type=0x894f,nsh_mdtype=1,nsh_spi=0x800005,nsh_si=25 > > > > 4,nsh_c1=0x0 actions=IN_PORT > > > > cookie=0xba5eba1100000102, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > > > priority=660,dl_type=0x894f,nsh_mdtype=1,nsh_spi=0x80000d,nsh_si=25 > > > > 3,nsh_c1=0x0 actions=IN_PORT > > > > cookie=0xba5eba1100000103, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, priority=655,in_port="sff1- > > > > dpl",dl_type=0x894f,nsh_spi=0x5,nsh_si=254 > > > > actions=move:NXOXM_NSH_C1[]- > > > > >NXM_NX_TUN_IPV4_DST[],move:NXOXM_NSH_C2[]- > > > > >NXM_NX_TUN_ID[0..31],IN_PORT > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, priority=655,in_port="sff1- > > > > dpl",dl_type=0x894f,nsh_spi=0x5,nsh_si=255 > > > > actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, priority=655,in_port="sff1- > > > > dpl",dl_type=0x894f,nsh_spi=0x800005,nsh_si=255 > > > > actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT > > > > cookie=0xba5eba1100000103, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, priority=655,in_port="sff1- > > > > dpl",dl_type=0x894f,nsh_spi=0x800005,nsh_si=254 > > > > actions=move:NXOXM_NSH_C1[]- > > > > >NXM_NX_TUN_IPV4_DST[],move:NXOXM_NSH_C2[]- > > > > >NXM_NX_TUN_ID[0..31],IN_PORT > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, priority=655,in_port="sff1- > > > > dpl",dl_type=0x894f,nsh_spi=0xd,nsh_si=255 > > > > actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, priority=655,in_port="sff1- > > > > dpl",dl_type=0x894f,nsh_spi=0xd,nsh_si=254 > > > > actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, priority=655,in_port="sff1- > > > > dpl",dl_type=0x894f,nsh_spi=0x80000d,nsh_si=254 > > > > actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT > > > > cookie=0xba5eba1100000103, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, priority=655,in_port="sff1- > > > > dpl",dl_type=0x894f,nsh_spi=0x80000d,nsh_si=253 > > > > actions=move:NXOXM_NSH_C1[]- > > > > >NXM_NX_TUN_IPV4_DST[],move:NXOXM_NSH_C2[]- > > > > >NXM_NX_TUN_ID[0..31],IN_PORT > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > priority=650,dl_type=0x894f,nsh_spi=0x5,nsh_si=255 > > > > actions=move:NXM_NX_TUN_ID[0..31]- > > > > >NXM_NX_TUN_ID[0..31],output:"sff1-dpl" > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > priority=650,dl_type=0x894f,nsh_spi=0x800005,nsh_si=255 > > > > actions=move:NXM_NX_TUN_ID[0..31]- > > > > >NXM_NX_TUN_ID[0..31],output:"sff1-dpl" > > > > cookie=0xba5eba1100000103, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > priority=650,dl_type=0x894f,nsh_spi=0x5,nsh_si=254 > > > > actions=move:NXOXM_NSH_C1[]- > > > > >NXM_NX_TUN_IPV4_DST[],move:NXOXM_NSH_C2[]- > > > > >NXM_NX_TUN_ID[0..31],output:"sff1-dpl" > > > > cookie=0xba5eba1100000103, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > priority=650,dl_type=0x894f,nsh_spi=0x800005,nsh_si=254 > > > > actions=move:NXOXM_NSH_C1[]- > > > > >NXM_NX_TUN_IPV4_DST[],move:NXOXM_NSH_C2[]- > > > > >NXM_NX_TUN_ID[0..31],output:"sff1-dpl" > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > priority=650,dl_type=0x894f,nsh_spi=0xd,nsh_si=254 > > > > actions=move:NXM_NX_TUN_ID[0..31]- > > > > >NXM_NX_TUN_ID[0..31],output:"sff1-dpl" > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > priority=650,dl_type=0x894f,nsh_spi=0xd,nsh_si=255 > > > > actions=move:NXM_NX_TUN_ID[0..31]- > > > > >NXM_NX_TUN_ID[0..31],output:"sff1-dpl" > > > > cookie=0xba5eba1100000101, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > priority=650,dl_type=0x894f,nsh_spi=0x80000d,nsh_si=254 > > > > actions=move:NXM_NX_TUN_ID[0..31]- > > > > >NXM_NX_TUN_ID[0..31],output:"sff1-dpl" > > > > cookie=0xba5eba1100000103, duration=8366.192s, table=10, > > > > n_packets=0, n_bytes=0, > > > > priority=650,dl_type=0x894f,nsh_spi=0x80000d,nsh_si=253 > > > > actions=move:NXOXM_NSH_C1[]- > > > > >NXM_NX_TUN_IPV4_DST[],move:NXOXM_NSH_C2[]- > > > > >NXM_NX_TUN_ID[0..31],output:"sff1-dpl" > > > > cookie=0x14, duration=8366.192s, table=10, n_packets=0, > > n_bytes=0, > > > > priority=5 actions=drop > > > > > > > > It is surprising to find that SFF1 receives 0 packets!!! I think > > > > this is caused by the JAVA error presented before. > > > > > > > > Since I’m new to ODL and SFC, thus I need your help. Do you have > > > > some answers for this or could you give me some blues to solve > > this > > > > problem? > > > > > > > > Thanks very much. > > > > > > > > BR, > > > > Qipeng > > > > > > > > > > > > > > > > > > > > > On 15 Jan 2019, at 18:36, Brady Johnson <bradyallenjohnson@gmai > > l. > > > > > com> wrote: > > > > > > > > > > Qipeng, > > > > > > > > > > The created-rendered-path API is indeed no longer supported. > > That > > > > > API created the RSP (Rendered Service Path, which is the actual > > > > > service chain), but now the RSP gets created when the SFP > > > > > (Service Function Path) is created. > > > > > > > > > > I thought this was already fixed in the sfc103 demo, but > > > > > apparently not :) I submit this patch to fix that and the > > number > > > > > of features you reported earlier: > > > > > > > > > > https://git.opendaylight.org/gerrit/79533 > > > > > > > > > > Regards, > > > > > > > > > > Brady > > > > > > > > > > > > > > > > > > > > On Tue, Jan 15, 2019 at 12:38 AM Qipeng Song <qps...@gmail.com> > > > > > wrote: > > > > > > Hello everyone! > > > > > > > > > > > > Recently I’m working on sfc103 demo.However I’m still stuck > > by > > > > > > the following POST request failure: > > > > > > > > > > > > > POST http://192.168.1.5:8181/restconf/operations/rendered-s > > er > > > > > > > vice-path:create-rendered-path/ > > > > > > > { > > > > > > > "input": { > > > > > > > "name": "RSP2", > > > > > > > "parent-service-function-path": "SFP2", > > > > > > > "symmetric": "true" > > > > > > > } > > > > > > > } > > > > > > > {"errors":{"error":[{"error-type":"protocol","error- > > > > > > > tag":"invalid-value","error-message":"URI has bad format. > > > > > > > Possible reasons:\n 1. \"rendered-service-path:create- > > > > > > > rendered-path\" was not found in parent data node.\n 2. > > > > > > > \"rendered-service-path:create-rendered-path\" is behind > > > > > > > mount point. Then it should be in format \"/yang- > > > > > > > ext:mount/rendered-service-path:create-rendered- > > path\"."}]}} > > > > > > > Traceback (most recent call last): > > > > > > > File "/sfc/sfc-demo/sfc103/update_sfc.py", line 160, in > > > > > > > <module> > > > > > > > post(controller, DEFAULT_PORT, > > > > > > > get_rendered_service_path_uri(), > > > > > > > get_rendered_service_path_data(), True) > > > > > > > File "/sfc/sfc-demo/sfc103/update_sfc.py", line 44, in > > post > > > > > > > r.raise_for_status() > > > > > > > File "/usr/lib/python2.7/dist- > > packages/requests/models.py", > > > > > > > line 840, in raise_for_status > > > > > > > raise HTTPError(http_error_msg, response=self) > > > > > > > requests.exceptions.HTTPError: 400 Client Error: Bad > > Request > > > > > > > for url: http://192.168.1.5:8181/restconf/operations/render > > ed > > > > > > > -service-path:create-rendered-path/ > > > > > > > > > > > > I tried to find solutions in the mail archive. I found > > > > > > something related to my problem(I put it at the end of this > > > > > > mail). I want to know whether this API(created-rendered-path) > > > > > > is supported again in the latest ODL version? If no, do we > > have > > > > > > some workaround to solve this problem? > > > > > > > > > > > > Thanks very much. > > > > > > > > > > > > BR, > > > > > > Qipeng > > > > > > > From: JaimeCaamaño Ruiz > > > > > > > Date: 2018-11-20 22:27 > > > > > > > To: 喻晶洁 > > > > > > > CC: sfc-dev > > > > > > > Subject: Re: OpenDaylight sfc-demo question > > > > > > > Hello > > > > > > > > > > > > > > The demo is currently not working because it relies in an > > ODL > > > > > > API > > > > > > > (create-rendered-path) that has been removed since > > fluorine. > > > > > > I will > > > > > > > work on it in the following days to fix it. > > > > > > > > > > > > > > BR > > > > > > > Jaime. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: 喻晶洁 <yujingjie at fiberhome.com> > > > > > > > To: jcaamano at suse.de > > > > > > > Subject: OpenDaylight sfc-demo question > > > > > > > Date: Tue, 20 Nov 2018 20:10:27 +0800 > > > > > > > > > > > > > > Hi, Dear Jaime, > > > > > > > I am studying the Opendaylight/sfc project. When doing an > > > > > > experiment > > > > > > > with sfc-demo/sfc103(https://github.com/opendaylight/sfc/tr > > ee > > > > > > /master/ > > > > > > > sf > > > > > > > c-demo/sfc103), I have a problem as figure below. When I > > run > > > > > > the > > > > > > > python > > > > > > > file setup_sfc.py, the RestAPI error always occur. > > > > > > > Could you give me some tips? > > > > > > > Run setup_sfc.py and show: > > > > > > > > > > > > > > Run docker-compose and show: > > > > > > > > > > > > > > ODL: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks very much! > > > > > > > > > > > > _______________________________________________ > > > > > > sfc-dev mailing list > > > > > > sfc-dev@lists.opendaylight.org > > > > > > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > > > > _______________________________________________ > > sfc-dev mailing list > > sfc-dev@lists.opendaylight.org > > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > > _______________________________________________ > > sfc-dev mailing list > > sfc-dev@lists.opendaylight.org > > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > -- Qipeng SONG Post-doc, IMT Lille Douai 20 Rue Guglielmo Marconi, 59650 Villeneuve-d'Ascq Tel: +33 (0)6 01 22 57 66
_______________________________________________ sfc-dev mailing list sfc-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/sfc-dev
