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-system: 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,dst=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=64,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=0x4e,si=255,c1=0x1,c2=0x2,c3=0x3,c4=0x4)),3 2019-01-21T14:01:04.692Z|00106|dpif(handler7)|WARN|system@ovs-system: 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),set(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_dst=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-system: 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),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,dst=192.168.2.2/255.255.255.0,proto=6,tos=0/0,ttl=64/0,frag=no ),tcp(src=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=64,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-system: 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),set(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:general-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:general-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:general-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:general-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:general-entity?revision=2015-09-30)name=openflow:196794075627855}] > to binding InstanceIdentifier > > The whole log file is available at URL: > https://www.dropbox.com/s/kh01oqwrbu0ao72/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=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=0x80000d,nsh_si=253,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 <[email protected]> > 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-service-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 >> <https://lists.opendaylight.org/mailman/listinfo/sfc-dev>> >> *>* To: jcaamano at suse.de >> <https://lists.opendaylight.org/mailman/listinfo/sfc-dev> >> *>* 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/ >> <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
