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 <[email protected]> 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/046903.html > > BR > Jaime. > > -----Original Message----- > From: Qipeng Song <[email protected]> > To: Brady Johnson <[email protected]>, [email protected] > Cc: sfc-dev opendaylight <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> 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 <[email protected]> > > > > 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 > > > > > [email protected] > > > > > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev >
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
