It works for me now with the latest patch. Thanks. It sounds like Qipeng has a routing issue, DNS issue, or proxy issue.
On Fri, Mar 29, 2019 at 8:44 PM Qipeng Song <[email protected]> wrote: > Hi Jaime, > > Thanks for this new patchset. With these new updates, I found that once > the VM is created by Vagrant file, my VM cannot do `sudo apt-get update`! > > *0% [Working]* > *Err:1 http://us.archive.ubuntu.com/ubuntu > <http://us.archive.ubuntu.com/ubuntu> xenial InRelease* > * Temporary failure resolving 'us.archive.ubuntu.com > <http://us.archive.ubuntu.com>'* > *Err:2 http://security.ubuntu.com/ubuntu > <http://security.ubuntu.com/ubuntu> xenial-security InRelease* > * Temporary failure resolving 'security.ubuntu.com > <http://security.ubuntu.com>'* > > This process is always stuck at this 0% and finally throw out an error > message… > > I tried to use another vm box in Vagrant file > > *config.vm.box = "bento/ubuntu-16.04”* > > This time, there is no ` apt-get update` related problem, however, the > execution of this demo is still failed… because I finally found the > container > `classifier1` is not created! All other containers are there… really > surprising. > > Thus, could you tell me your Vagrant version and virtualbox version? Mine > is Vagrant 2.2.4 and Virtualbox 5.1.38, and my linux kernel > is .15.0-43-generic. By the way, besides VM box "generic/ubuntu1604”, do > you have any other recommandation? > > BR, > Qipeng > > On 29 Mar 2019, at 13:27, Jaime Caamaño Ruiz <[email protected]> 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 <[email protected]> > To: [email protected] > Cc: Brady Johnson <[email protected]>, Qipeng Song <qpsong@gm > ail.com>, sfc-dev opendaylight <[email protected]> > 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 <[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/0469 > 03.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] > > 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 <[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@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 <[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-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 > [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
