Hi, Jaime. Thanks for your reply. > On 11 Mar 2019, at 16:14, 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?
[Qipeng] The script `setup_odl.sh` of sfc demo103 always `git clone` the latest version of OVS. I confirm that at the execution of this demo, the downloaded and compiled OVS version is 2.11.90. If you haven’t observed this message and your sfc demo103 works well, I thought that my problem may be related to the OVS version. I will verity if this error still occurs with OVS 2.10. > >> 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 > <https://mail.openvswitch.org/pipermail/ovs-discuss/2018-June/046903.html> [Qipeng] Thanks for this information. I will look at it and see if I could provide more information for the community. > > BR > Jaime. Thanks very again, BR, Qipeng > > -----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
