omec-project / up4 Goto Github PK

ONOS app and P4 program abstracting a network of switches as one big 4G/5G UPF

Home Page: https://docs.sd-fabric.org/master/advanced/p4-upf.html

Makefile 1.97% P4 5.16% Python 25.90% Shell 10.56% Java 56.41%

upf 4g 5g p4 onos sdn aether sd-fabric

up4's Introduction

UP4

This repository is part of the SD-Fabric project. It provides an ONOS app that abstracts a network of one or more fabric switches as a virtual "One-Big-UPF", which can be integrated with a 4G/5G mobile core control plane.

The UP4 app is essentially a P4Runtime server that translates read and write requests into multiple ONOS API calls for the underlying physical devices. The One-Big-UPF abstraction is defined using a P4 program describing a "virtual UPF pipeline". Such P4 program doesn't run on switches, but it's used as the schema to define the content of the P4Runtime messages that can be exchanged with the UP4 app.

To learn about the architecture, capabilitites, and instructions, including integration with standard 3GPP interfaces such as PFCP, please refer to the official SD-Fabric documentation.

To learn about the origins of the UP4 project and the rationale behind it, check the paper:

R. MacDavid et al. A P4-based 5G User Plane Function, SOSR 2021

Requirements

To build and test UP4 you will need the following software to be installed on your machine:

Docker
make

Docker is used to run the necessary without worrying about additional dependencies. Before starting, make sure to fetch all the required Docker images:

make deps

Content

P4 Implementation

The directory p4src contains the P4 program defining the virtual UPF pipeline.

To build the P4 program:

make build

To generate the pipeline graphs (in PDF format):

make graph

ONOS App

The directory app contains the Java code for the ONOS app implementation.

To build the app:

make app-build

The app directory has further instructions for loading and testing.

Packet-based Unit Tests

The directory ptf contains unit tests for the virtual UPF P4 program. Tests use PTF, a Python-based framework for data plane testing, and stratum_bmv2, the reference P4 software switch (BMv2 simple_switch) built with Stratum support to provide a P4Runtime and gNMI server interface.

To run all test cases:

make check

ptf/tests contains the actual test case implementation, organized in groups, e.g., routing.py for all test cases pertaining the routing functionality, packetio.py for control packet I/O, etc.

To run all tests in a group:

make check TEST=<GROUP>

To run a specific test case:

make check TEST=<GROUP>.<TEST NAME>

For example:

make check TEST=packetio.PacketOutTest

ptf/lib contains the test runner as well as libraries useful to simplify test case implementation (e.g., helper.py provides a P4Info helper with methods convenient to construct P4Runtime table entries)

Integration Tests

The directory scenarios contains integration test scenarios and scripts to run a Mininet-based emulated network of BMv2 switches controlled by ONOS and UP4.

Check the included README for more information.

up4's People

Contributors

Stargazers

Watchers

Forkers

wailoks jhall11 emanuelegallone accel-gh g-ampo andrea-campanella m00zi durmazemre gatici ddhung81

up4's Issues

Consider switching to private IPs

Shouldn't we use private IPs instead of public IPs, even though we're using Mininet..? is there a reason why public IPs are being used?

Run CI jobs on ONF Jenkins

We ran out of free credits on CircleCI, and this is likely to happen often given the new smoke test. Makes sense to move everything to ONF's Jenkins CI.

NullPointerException when processing counter read from PFCP agent

Commit: test on both aeae3c and b65aa0
After start ONOS, I saw ONOS keeps showing logs below

java.lang.NullPointerException
    at org.omecproject.up4.impl.Up4NorthComponent.readCounterAndTranslate(Up4NorthComponent.java:261)
    at org.omecproject.up4.impl.Up4NorthComponent$Up4NorthService.read(Up4NorthComponent.java:477)
    at p4.v1.P4RuntimeGrpc$MethodHandlers.invoke(P4RuntimeGrpc.java:471)
    at io.grpc.stub.ServerCalls$UnaryServerCallHandler$UnaryServerCallListener.onHalfClose(ServerCalls.java:171)
    at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.halfClosed(ServerCallImpl.java:331)
    at io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1HalfClosed.runInContext(ServerImpl.java:808)
    at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
    at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)

After some debugging, it looks like getUpfProgrammable() is returning null pointer.

2.6-snaptshot missing

Hi,

Recently, we looked into your paper(https://www.cs.princeton.edu/~jrex/papers/up4-sosr21.pdf) want to use the UP4 but find some following issues and hope you can help us.

(1) When we are going to execute the setup.xml(make setup.xml), we met the first issue which is about the invalid onos-stc-2.6-SNAPSHOT.jar file as shown in the first image. It seems that the program is trying to download 2.6 snapshot by using this command “curl https://repo1.maven.org/maven2/$MVN_JAR > $JAR”. This command will go to the website https://repo1.maven.org/maven2/org/onosproject/onos-stc/ which doesn’t include the 2.6 snapshot.

(2)We could solve issue in (1) by changing the STC_VERSION to 2.5 in the Makefile under scenarios but 2.5 snapshot seems to have some issues in handling the onos. The issue shows that mininet is stuck in listening the gRPC requests and fails after a while.

Can you tell me how to solve the issues above?

I will be very grateful if you can help me!

NPE when executing up4:read-flows

karaf@root > up4:read-flows                                                                                                                                                                                                                                                                                                                                         02:16:49
2020-09-23 02:16:53,196 ERROR [ShellUtil] Exception caught while executing command
java.lang.IllegalArgumentException: PDR and FAR should be the same direction!
	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:134)
	at org.omecproject.up4.UpfFlow$Builder.build(UpfFlow.java:167)
	at org.omecproject.up4.behavior.FabricUpfProgrammable.getFlows(FabricUpfProgrammable.java:297)
	at org.omecproject.up4.cli.ReadFlowsCommand.doExecute(ReadFlowsCommand.java:23)
	at org.onosproject.cli.AbstractShellCommand.execute(AbstractShellCommand.java:159)
	at org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
	at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
	at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
	at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
	at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
	at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
	at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
	at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
	at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
Error executing command: PDR and FAR should be the same direction!

Support reading all PDR counters in one request

Today PFCP agent has to issue one P4RT Read RPC for each PDR counter ID, thus limiting scalability. The P4RT API supports wildcard reads. We should implement the same in the UP4 app, such that PFCP agent can read all counters (both pre qos and post qos) in one request.

cc @badhrinathpa

pfcp-smoke.xml: Push-Netcfg failed

I cannot run pfcp-smoke.xml due to an error with netcfg. Does the community have any idea on how to fix the error?

Reproducibility steps:

/up4/scenarios$ sudo make pfcp-smoke.xml
...
...
...

2022-11-04 13:46:04  Onos-Enable-Grpc-Log-3 completed
2022-11-04 13:46:04  Onos-Enable-Grpc-Log-2 completed
2022-11-04 13:46:04  Setup completed
2022-11-04 13:46:04  Net-Setup started
2022-11-04 13:46:04  Initial-Summary-Check started -- onos-check-summary localhost [0-9]* 0 0 0
2022-11-04 13:46:05  Initial-Summary-Check completed
2022-11-04 13:46:05  Push-Netcfg started -- onos-netcfg localhost /opt/up4/scenarios/topo/netcfg-leafspine.json
2022-11-04 13:46:05  Push-Netcfg failed
...
2022-11-04 13:46:05  Net-Setup failed
....
2022-11-04 13:46:05  Check-Summary skipped
2022-11-04 13:46:05  Check-Dbuf-Ready-1 skipped
2022-11-04 13:46:05  Check-Dbuf-Ready-2 skipped
2022-11-04 13:46:05  Check-Dbuf-Ready-3 skipped
...
2022-11-04 13:46:06  Clear-Fwd-1 failed
2022-11-04 13:46:06  Mock-Smf-Stop failed
...
2022-11-04 13:46:07  Smf-Teardown failed
....
2022-11-04 13:46:08  Docker-Compose-Down started -- docker-compose --env-file ./tmp/.env.docker down -t0
2022-11-04 13:46:11  Docker-Compose-Down completed
2022-11-04 13:46:11  Teardown completed
2:54 Failed! 56 steps succeeded; 5 steps failed;

NPE when using CLI command up4-read-flows

Might be related to #59 as I saw this happening right after that.

karaf@root > up4:read-flows                                                                                19:42:38
19:42:46.421 ERROR [ShellUtil] Exception caught while executing command
java.lang.NullPointerException: A FAR must be provided.
	at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:799)
	at org.omecproject.up4.UpfFlow$Builder.build(UpfFlow.java:153)
	at org.omecproject.up4.behavior.FabricUpfProgrammable.getFlows(FabricUpfProgrammable.java:287)
	at org.omecproject.up4.cli.ReadFlowsCommand.doExecute(ReadFlowsCommand.java:23)
	at org.onosproject.cli.AbstractShellCommand.execute(AbstractShellCommand.java:159)
	at org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
	at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
	at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
	at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
	at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
	at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
	at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
	at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
	at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
Error executing command: A FAR must be provided

UP4 App unable to detect P4 pipeconf

I have P4 switch configured at onos, but UP4 app in Onos is unable to detect P4 Pipeconf configured
I have attached config below. Will you please let me know what could be the issue.

17:11:40.368 INFO [Up4DeviceManager] No UpfProgrammable set because deviceId present in config is not a valid UPF!
17:11:40.369 WARN [Up4NorthComponent] UP4 client attempted to read or write to logical switch while the physical device was unavailable.
17:11:40.370 INFO [Up4NorthComponent] StreamChannel closed

onos@root > netcfg                                                                                                                                                                                         17:11:49
{
  "devices" : {
    "device:spine" : {
      "basic" : {
        "driver" : "stratum-tofino",
        "gridX" : 400,
        "gridY" : 400,
        "locType" : "grid",
        "managementAddress" : "grpc://172.21.23.10:9559?device_id=1",
        "pipeconf" : "org.stratumproject.fabric.mavericks_sde_9_7_0"
      }
    }
  },
  "ports" : { },
  "links" : { },
  "hosts" : { },
  "apps" : {
    "org.onosproject.provider.lldp" : {
      "suppression" : {
        "deviceTypes" : [ "ROADM", "OTN", "FIBER_SWITCH", "OPTICAL_AMPLIFIER", "OLS", "TERMINAL_DEVICE" ],
        "annotation" : "{\"no-lldp\":null}"
      }
    },
    "org.omecproject.up4" : {
      "up4" : {
        "devices" : [ "device:spine" ],
        "n3Addr" : "172.21.23.20",
        "uePools" : [ "10.240.0.0/16" ],
        "sliceId" : 0,
        "pscEncapEnabled" : false
      }
    }
  },
  "regions" : { },
  "layouts" : { }
}
onos@root > 
onos@root > devices                                                                                                                                                                                        17:11:58
id=device:spine, available=true, local-status=connected 2h19m ago, role=MASTER, type=SWITCH, mfr=Barefoot Networks, hw=Tofino, sw=Stratum, serial=unknown, chassis=0, driver=stratum-tofino:org.stratumproject.fabric.mavericks_sde_9_7_0, gridX=400.0, gridY=400.0, locType=grid, managementAddress=grpc://172.21.23.10:9559?device_id=1, name=device:spine, p4DeviceId=1, protocol=P4Runtime, gNMI, gNOI
onos@root >

Add reuse linting to pre-merge CI jobs

To catch files with missing copyright headers or invalid license. Easy peasy with GitHub actions: https://github.com/stratum/fabric-tna/blob/master/.github/workflows/reuse.yml

Check in p4info.bin and bmv2.json

NPE when removing PDRs

I've seen this once. The full ONOS log is attached.

java.lang.NullPointerException
	at org.omecproject.up4.behavior.FabricUpfProgrammable.removePdr(FabricUpfProgrammable.java:344)
	at org.omecproject.up4.impl.Up4NorthComponent.translateAndDelete(Up4NorthComponent.java:145)
	at org.omecproject.up4.impl.Up4NorthComponent$Up4NorthService.write(Up4NorthComponent.java:352)
	at p4.v1.P4RuntimeGrpc$MethodHandlers.invoke(P4RuntimeGrpc.java:467)
	at io.grpc.stub.ServerCalls$UnaryServerCallHandler$UnaryServerCallListener.onHalfClose(ServerCalls.java:171)
	at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.halfClosed(ServerCallImpl.java:331)
	at io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1HalfClosed.runInContext(ServerImpl.java:808)
	at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
	at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

up4-onos.log

NPE at app startup because of P4RT Read RPC coming from PFCP agent

Full ONOS log attached.

The NPE is triggered by a P4RT Read request. If the read is for the source interface table, this issue might be connected with another issue with pfcp-agent not using the right s1u address for uplink entries.

cc @badhrinathpa @thakurajayL I have attached the full pfcp agent log.

02:07:05.680 ERROR [SerializingExecutor] Exception while executing runnable io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1HalfClosed@755f7f75
java.lang.NullPointerException: null
	at org.omecproject.up4.impl.Up4NorthComponent.readEntriesAndTranslate(Up4NorthComponent.java:205) ~[?:?]
	at org.omecproject.up4.impl.Up4NorthComponent$Up4NorthService.read(Up4NorthComponent.java:491) ~[?:?]
	at p4.v1.P4RuntimeGrpc$MethodHandlers.invoke(P4RuntimeGrpc.java:471) ~[?:?]
	at io.grpc.stub.ServerCalls$UnaryServerCallHandler$UnaryServerCallListener.onHalfClose(ServerCalls.java:171) ~[?:?]
	at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.halfClosed(ServerCallImpl.java:331) ~[!/:?]
	at io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1HalfClosed.runInContext(ServerImpl.java:808) ~[!/:?]
	at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37) ~[!/:?]
	at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123) [!/:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]

onos.log
pfcp_after_up4_npe.txt

Change stratum image used for integration testing to non-tutorial image

Eventually someone should switch the mininet image that is used in the integration testing from opennetworking/ngsdn-tutorial:stratum_bmv2 to opennetworking/mn-stratum:latest. There are some minor issues that will need to be addressed when switching, so it is not completely trivial

When updating dbufDataplaneAddr in netcfg buffered packets are sent to the old address

It looks like we need some logic to detect changes to dbufDataplaneAddr and update existing buffering FARs and make sure the new address is used for new FARs.,

Source interface entries disappearing after switch reboot

We have seen this a few times in the production pod

CircleCI reports success even when tests fail

As seen in #5

Improve session printing

Improvements should include: sorting sessions by IP address, multiple levels of verbosity

Return error on unsupported FARs

It might happen that pfcp-agent installs a FAR like this one:

SEID:0xa2a8d634737a8e400000000 - Match(Dst=10.240.251.252, !GTP)  -->  FarID 2054  -->  Forward+NotifyCP();
    >>   196 Ingress pkts ->   196 Egress pkts

Does it mean we should forward and clone to CPU as packet-in? Do we support that in the physical pipeline? If not, we should return an error when inserting such FAR.

Make wildcard counter reads respond with a non-blocking stream

Paraphrased from a comment by @ccascone:
Instead of blocking on wildcard counter reads, it would be nice to stream responses to the pfcp agent as we get them from the physical device.
If we don't want gRPC APIs to leak into UpfProgrammable (which is a good thing), we might be able to use the Java Flow API for reactive streams: https://www.tutorialspoint.com/how-to-implement-reactive-streams-using-flow-api-in-java-9
This may require changes in the P4RuntimeClient API as well.

App should return P4RT error to PFCP agent when switch tables are full

We run into issues were the PDR and FAR tables on Tofino were full, but the up4 app was accepting new entries from the PFCP agent.

Instead, the app should be able to check whether tables are full and return errors to the PFCP agent when new entries cannot be accommodated. The PFCP agent should be responsible for relaying errors back to the SPGW-C.

Errors can be reported via gRPC status as described in the P4RT spec.

Promote UpfProgrammable to ONOS driver behavior

The API seems stable, clean, and mature enough to become an ONOS driver behavior.

As such, we should:

Move UpfProgrammable.java and all related classes (UpfFlow.java etc) to the ONOS core API package
Provide an implementation of UpfProgrammable.java for fabric-tna as part of the fabric-tna repo
Provide an implementation of UpfProgrammable.java for fabric-v1model as part of the ONOS repo

Build and push PTF image with CircleCI

To avoid having to grant permissions to specific users and so gate-keeping changes to the image.

NPE when updating dbuf netcfg

01:32:11.906 WARN [ListenerRegistry] Exception encountered while processing event NetworkConfigEvent{time=2021-02-25T01:32:11.893Z, type=CONFIG_UPDATED, config=Optional[{"serviceAddr":"dbuf.dbuf:10000","dataplaneAddr":"10.32.5.182:2152"}], prevConfig=Optional[{"serviceAddr":"dbuf.dbuf:10000","dataplaneAddr":"10.32.5.181:2152"}], configClass=class org.omecproject.up4.config.Up4DbufConfig}
java.lang.NullPointerException: null
	at org.omecproject.up4.impl.Up4DeviceManager.addDbufStateToUpfProgrammable(Up4DeviceManager.java:336) ~[?:?]
	at org.omecproject.up4.impl.Up4DeviceManager.dbufUpdateConfig(Up4DeviceManager.java:320) ~[?:?]
	at org.omecproject.up4.impl.Up4DeviceManager$InternalConfigListener.event(Up4DeviceManager.java:453) ~[?:?]
	at org.omecproject.up4.impl.Up4DeviceManager$InternalConfigListener.event(Up4DeviceManager.java:441) ~[?:?]
	at org.onosproject.event.ListenerRegistry.process(ListenerRegistry.java:66) [!/:?]
	at org.onosproject.event.impl.CoreEventDispatcher$DispatchLoop.process(CoreEventDispatcher.java:198) [!/:?]
	at org.onosproject.event.impl.CoreEventDispatcher$DispatchLoop.run(CoreEventDispatcher.java:180) [!/:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]```

NorthConstants.java should be automatically generated from a P4Info file

To improve the chances of detecting breaking P4 changes at compile-time

Codecov uploader being deprecated

While working on fabric-tna's Jenkinsfile, I noticed the codecov uploader deprecation notice: the current bash uploader used within this repository will work until February 2022. Opening this issue to keep track on this.
reference on codecov

UP4 app should return p4info that is representative of HW resources

Currently, the UP4 app expects to be programmed with the same P4Info obtained when compiling the logical pipeline. However, this one contains information that might not reflect the available hw resources, for example table size, counter size, etc. For the PFCP agent to be able to take decisions on whether to accept or not new UEs, or to optimize the counter ID allocation logic, we should support the following:

Assume the UP4 app is aways pre-provisioned with a P4Info, so a client (PFCP agent) can issue a GetForwardingPipelineConfig without doing a SetForwardingPipelineConfig
Transform P4info obtained from the logical pipeline with values that reflect table/counter size on hw realization (fabric-tna)

Add app CLI command to perform checkup

When debugging issues with UE data flow, it would be nice to have an ONOS CLI command that tells us whether there is a problem with UP4 or not. Common issues with data flow are:

Missing interface entries (sometimes they disappear and we don't know why)
Missing PDR or FAR
Packet dropped somewhere else in the pipeline, in which case we can compare ingress/egress PDR counters

Such CLI command could check all of this and report an explanation of the problem if any.

Ping @badhrinathpa.

Switch integration tests from simple make target to the ONOS STC framework

From Carmelo: "As the complexity of our integration tests grows, it makes more sense to use something like the ONOS STC framework, which already comes with utilities to check onos status, verify device availability, etc"
https://wiki.onosproject.org/pages/viewpage.action?pageId=12421025

Partial/inconsistent state after deactivating and re-activating app

karaf@root > up4:read-flows                                                                                                                           22:53:00
SEID:0x1368210ac274f88b00000000 - Match(Dst=10.32.5.126, TEID=0xf1c10041)  -->  FarID 83  -->  Forward();
    >>   194 Ingress pkts ->   194 Egress pkts
SEID:0x1368210ac274f88b00000000 - Match(Dst=10.240.255.168, !GTP)  -->  FarID 84  -->  Encap(Src=10.32.5.126, SPort=2152, TEID=0x2000108, Dst=10.32.5.5);
    >>   164 Ingress pkts ->   164 Egress pkts
2 flows found

karaf@root > app deactivate up4
karaf@root > app activate up4

karaf@root > up4:read-flows                                                                                                                           22:58:01
SEID:0x1368210ab5754c7a00000000 - NO PDR!  -->  FarID 86  -->  Encap(Src=10.32.5.126, SPort=2152, TEID=0x2000408, Dst=10.32.5.5);
    >> NO STATISTICS!
1 flows found

pfcp-smoke: failed execution

Hi,

recently, I read the paper about P4-based UPF and tried to use the UP4 but I met a problem with running scenario pfcp-smoke.
When executing setup.xml, I met the problem with onos-user-key as shown in the attached image and the default password didn't work.

< Environment that I run UP4 >

Ubuntu 20.04
Docker 20.10.17
Docker-compose 1.25.0
Zulu OpenJDK 11

Can you help to solve this issue?
I will be very grateful if you can help for solving this problem.

karaf@root > up4:read-interfaces                                                                                                                                                                                                                                                                                      23:35:32
Interface{Uplink, 10.32.5.126/32}
Interface{Uplink, 10.32.5.127/32}
Interface{Downlink, 10.240.0.0/16}