# Creating circuit error: how to understand it? **URL:** \ **Category:** zrok\ **Created:** [August 7, 2025, 10:24pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968 "2025-08-07T22:24:00Z")\ **Posts on this page:** 13\ **Page:** 2
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 12, 2025, 8:37pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/21 "2025-08-12T20:37:51Z")
> [@michael.quigley](#): > > And your `apt` usage scenario might be opening a LOT YES. Exactly. It is what I have said above. A large number of connections \> 90. All these connections are super busy. ---
**Author:** ![michael.quigley](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/michael.quigley/32/1123_2.png) [@michael.quigley](https://openziti.discourse.group/u/michael.quigley)\ **Post date:** [August 12, 2025, 8:38pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/22 "2025-08-12T20:38:27Z")
Ok… sounds like your network needs more capacity? ---
**Author:** ![michael.quigley](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/michael.quigley/32/1123_2.png) [@michael.quigley](https://openziti.discourse.group/u/michael.quigley)\ **Post date:** [August 12, 2025, 8:39pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/23 "2025-08-12T20:39:52Z")
Upgrade your ziti to `v1.6.7` when it comes out and try enabling the “super network” flag in zrok. That will separate the control plane from the data plane and might improve performance. But ultimately, we’re limited by the compute and bandwidth that’s available. An overlay network, by design, is going to impose some amount of performance penalty. ---
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 12, 2025, 8:40pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/24 "2025-08-12T20:40:33Z")
I see that 1 connection is enough. ```auto curl --proxy http://127.0.0.1:port -o /dev/null https://sbg.proof.ovh.net/files/10Gb.dat ``` So my parallel curl takes up to 12 seconds ```auto curl --proxy http://127.0.0.1:port -s -w '%{time_total}s' -o /dev/null http://www.google.com 13.482587s ``` ---
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 12, 2025, 8:43pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/25 "2025-08-12T20:43:06Z")
> [@michael.quigley](#): > > Ok… sounds like your network needs more capacity? There is no problem with network. The share (tcptunnel) is on 500Mbs network. A parallel curl without proxy work fast: ```auto curl -s -w '%{time_total}s' -o /dev/null http://www.google.com 0.090997s curl --proxy http://127.0.0.1:port -s -w '%{time_total}s' -o /dev/null http://www.google.com 8.180164s curl -s -w '%{time_total}s' -o /dev/null http://www.google.com 0.085028s ``` ---
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 12, 2025, 8:54pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/26 "2025-08-12T20:54:27Z")
> [@michael.quigley](#): > > we’re limited by the compute and bandwidth that’s available. This is the configuration: People run apt upgrade on their pc, miles away from me. I run curl at home. The share (tcptunnel) is on a dedicated host with a 500Mbps network. ---
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 12, 2025, 9:03pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/27 "2025-08-12T21:03:44Z")
> [@michael.quigley](#): > > That will separate the control plane from the data plane and might improve performance. On one side: zrok share (tcptunnel) has a very good network 500Mbps. On another side: The user does apt upgrade using a mobile network (284kB/s) My home network is about 20Mbps. ---
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 12, 2025, 11:16pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/28 "2025-08-12T23:16:05Z")
I have just tried a similar scenario: ### **I Configuration:** tcpTunnel **Host1 (500Mbps)** ```auto zrok share private -b tcpTunnel 127.0.0.1:port --headless --open [1.029] INFO sdk-golang/ziti.(*listenerManager).createSessionWithBackoff: {session token=[dd372a1b-6cf0-4287-9d1e-77b303f22f43]} new service session [1.235] INFO main.(*sharePrivateCommand).shareLocal: allow other to access your share with the following command: zrok access private yontuncx87d6 [1.235] INFO zrok/endpoints/tcpTunnel.(*Backend).Run: started ``` **Host2 (100Mbps)** ```auto zrok access private yontuncx87d6 -b 127.0.0.1:7777 --headless [0.904] INFO main.(*accessPrivateCommand).accessLocal: access the zrok share at the following endpoint: tcp://127.0.0.1:7777 ``` **Host3 (20Mbps)** ```auto zrok access private yontuncx87d6 -b 127.0.0.1:7777 --headless ``` ### II We validate the setup. **Host2 (100Mbps)** ```auto curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com 0.241377s ``` **Host3 (20Mbps)** ```auto curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com 0.248842s ``` ### **III We run the test.** **Host3 (20Mbps):** downloading at 2237kB/s ```auto curl --proxy http://127.0.0.1:7777 -o /dev/null https://sbg.proof.ovh.net/files/10Gb.dat % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 10.0G 0 36.6M 0 0 2225k 0 1:18:30 0:00:16 1:18:14 2237k ``` **Host2 (100Mbps):** http request ```auto curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com 16.366836s curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com 16.962323s curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com 15.521564s ``` After we have stopped the download (at a very low speed 2MB/s) on Host3 we repeat the curl on Host2 **Host2 (100Mbps):** http request ```auto curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com 0.238639s ``` ---
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 13, 2025, 5:52am UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/29 "2025-08-13T05:52:52Z")
It seems that we have the same problem with socks shares. ### **I Configuration:** socks **Host1 (500Mbps)** ```auto zrok share private -b socks --headless --open [1.043] INFO sdk-golang/ziti.(*listenerManager).createSessionWithBackoff: {session token=[d56f711f-7077-4a60-872f-e4cd2be27bf8]} new service session [1.182] INFO main.(*sharePrivateCommand).shareLocal: allow other to access your share with the following command: zrok access private q2y67021wywn ``` **Host2 (100Mbps)** ```auto zrok access private q2y67021wywn -b 127.0.0.1:9999 --headless ``` **Host3 (20Mbps)** ```auto zrok access private q2y67021wywn -b 127.0.0.1:9999 --headless ``` ### II We validate the configuration. **Host2 (100Mbps)** ```auto curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com 0.322686s ``` **Host3 (20Mbps)** ```auto curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com 0.303178s ``` ### III We run the test. **Host3 (20Mbps):** downloading at 2512kB/s ```auto curl --proxy socks5://127.0.0.1:9999 -o /dev/null https://mirror.in2p3.fr/pub/fedora/linux/releases/42/Workstation/x86_64/iso/Fedora-Workstation-Live-42-1.1.x86_64.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 2 2287M 2 61.0M 0 0 2488k 0 0:15:41 0:00:25 0:15:16 2512k ``` **Host2 (100Mbps):** http request ```auto curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com 17.690794s curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com 19.403398s curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com 21.163678s ``` ### IV Conclusion While downloading from Host3 at a very low speed 2MB/s we obtain on Host2 having 100Mbps network connection the execution time about 20 seconds. ---
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 13, 2025, 8:24am UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/30 "2025-08-13T08:24:59Z")
> [@michael.quigley](#): > > Upgrade your ziti to `v1.6.7` The last available [stable version is openziti 1.5.4](https://netfoundry.jfrog.io/ui/native/zitipax-openziti-deb-stable/pool/openziti/amd64/) ---
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 19, 2025, 12:53pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/31 "2025-08-19T12:53:37Z")
> [@michael.quigley](#): > > That will separate the control plane from the data plane and might improve performance. ```auto { "chSeq": 43500, "circuitId": "plmsS14-c", "connId": 188, "edgeSeq": 0, "error": "timeout waiting to put message in send queue: context deadline exceeded", "file": "github.com/openziti/ziti/router/xgress_edge/listener.go:725", "func": "github.com/openziti/ziti/router/xgress_edge.(*edgeClientConn).sendStateConnectedReply", "level": "error", "msg": "failed to send state response", "time": "2025-08-19T11:27:57.858Z", "type": "EdgeStateConnectedType" } ``` Probably this is an example of the situation you were talking about above. On the other hand in my tests the network bandwidth is much higher and the same result you will obtain even on a local interface. You could enable an environment local to the service. And with this local environment you will face the same problem accessing the local service (socks for simplicity). In my test: one host is slowly downloding (2MB/s) and another one (with 100Mbps network, or even a local environment) tries to run curl. I don’t know: It could happen that the buffers are filled up with data that the slowing downloading client has no time to consume. So the service works in a single client mode. zrok version 1.1.2 ```auto zrok config set superNetwork true systemctl --user restart zrok-agent.service ``` ```auto curl --proxy http://127.0.0.1:port -o /dev/null https://mirror.in2p3.fr/pub/fedora/linux/releases/42/Workstation/x86_64/iso/Fedora-Workstation-Live-42-1.1.x86_64.iso ``` ```auto curl --proxy http://127.0.0.1:port -s -w '%{time_total}s' -o /dev/null https://www.google.com 15.713272s ``` It seems that **superNetwork true** does not change anything. ---
**Author:** ![plorenz](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/plorenz/32/54_2.png) [@plorenz](https://openziti.discourse.group/u/plorenz)\ **Post date:** [August 19, 2025, 5:14pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/32 "2025-08-19T17:14:31Z")
Are you running that against routers with a minimum version or 1.6.7? The performance optimizations require support on both the SDK and router side. ---
**Author:** ![Rantanplan](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/rantanplan/32/3353_2.png) [@Rantanplan](https://openziti.discourse.group/u/Rantanplan)\ **Post date:** [August 19, 2025, 6:33pm UTC](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968/33 "2025-08-19T18:33:13Z")
1. I have installed the ziti 1.6.7 on the host running the service. However ziti-controller is still 1.5.4. The routers are local to the service. I have 6 routers on the same host because the host has 6 ipv4 and one ipv6. 2. I have enabled superNetwork on the both sides: for the service and agent environments. 3. I have restarted zrok socks service (zrok 1.1.2) 4. I run the test. [Previous page](https://openziti.discourse.group/t/creating-circuit-error-how-to-understand-it/4968.md?page=1)