Hi John, Unfortunately, I still get stuck into this problem. Hope somebody in the community can help us...
BR, Qipeng On Mon, Mar 25, 2019 at 9:27 PM John Lester <[email protected]> wrote: > 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 >> > -- Qipeng SONG Post-doc, IMT Lille Douai 20 Rue Guglielmo Marconi, 59650 Villeneuve-d'Ascq Tel: +33 (0)6 01 22 57 66
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
