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/046903.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.com> > 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-syst > > 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-syst > > 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-syste > > 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-syste > > 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@gmail. > > > 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-ser > > > > > 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/rendered > > > > > -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/tree > > > > /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
