Yes, you seem to have a good grasp.
there is no longer a mgmt
section. Where did you find that reference, I'd like to make sure the doc is accurate. ctrl
is the port how routers connect to the controller.
The routers reach out to the public controller and establish a control channel, then the router and controller are able to communicate.
@qrkourier just confirming before hand . I am deploying routers only at private networks and I would follow with this command
helm upgrade --install "private-router123" openziti/ziti-router \
--namespace ziti \
--set-file enrollmentJwt=./router1.jwt \
--set edge.advertisedHost=private-router123-edge.ziti.svc.cluster.local \
--set linkListeners.transport.service.enabled=false \
--set ctrl.endpoint="{{ ctrlPlane.advertisedHost }}:6262"
So one question which I should have asked before is , can I just always deploy private routers on every private network I have and it will just work fine?
From my perps , it seems like if we deploy private routers it only listens to controller and in that way if we deploy all private routers we are going to overload controller maybe ?
Private routers will help service performance by providing a local data path. Ensure the router has an edge listener the local identities are allowed to use. The data will stay local if the destination is local as long as the private router is available. If the private router is unavailable, the data can still flow through a public router, but it takes longer to relay. Only routers carry service payload data, so private routers do not burden the controller more than public routers.
ohk one more thing --> while installing public routers of loadbalancer type , Initially how do we know the advertising and link listener URL of routers , because loadbalancer gets created later and we had to upgrade the router to add that loadbalancer url to make it work .
I assume a public router is reachable on a public IP (by FQDN), and a private router is not. Both public and private can be configured to advertise edge and link listeners, and it's advisable to advertise link listeners only on a public IP (as a FQDN). It is a best practice for private routers to have an edge listener and no link listener, and for public routers to have both configured. This reduces log noise from unreachable advertisements, which can obscure the problem during troubleshooting.
You're asking how one knows a router's advertised address (e.g., router1.edge.ziti.example.com:443
) before the LoadBalancer is provisioned.
Here's the order of things that I expect.
- Choose a FQDN like
router1.edge.ziti.example.com
for the advertised addresses of the public router.
- Deploy the router, using this FQDN, with Helm inputs that specify its edge service is of type LoadBalancer.
- Learn the EXTERNAL_IP that becomes provisioned by the cloud provider's service controller for the LoadBalancer service.
- Create a DNS record with the service's external (public) IP.
Now clients can resolve the FQDN to the LoadBalancer service and reach the router's edge listener.
Reminder: the LoadBalancer provisioned by the cloud's service controller must be a TCP proxy (TLS passthrough). If it terminates TLS (has a server certificate), then the router will not function.
You can use these same steps with any TLS server provided by a controller or router that needs to be reachable by a FQDN (a public, advertised address).
It's not required to use a LoadBalancer service, however. That's one way to publish a cluster service. The other options are ClusterIP+Ingress/Gateway and NodePort.
Hi @qrkourier , I get these errors now when I deploy routers with that command
{"error":"error dialing outgoing link [l/1pn4xkobBN7j1nE4Tc103n@10]: error dialing payload channel for [l/1pn4xkobBN7j1nE4Tc103n]: dial tcp 10.0.157.16:3031: i/o timeout","file":"github.com/openziti/ziti/router/link/link_registry.go:478","func":"github.com/openziti/ziti/router/link.(*linkRegistryImpl).evaluateLinkState.func1","iteration":10,"key":"default-\u003etls:NxWYfPm0eH-\u003edefault","level":"error","linkId":"1pn4xkobBN7j1nE4Tc103n","msg":"error dialing link","time":"2024-06-17T06:02:00.469Z"}
{"file":"github.com/openziti/ziti/router/link/link_state.go:97","func":"github.com/openziti/ziti/router/link.(*linkState).updateStatus","iteration":10,"key":"default-\u003etls:NxWYfPm0eH-\u003edefault","level":"info","linkId":"1pn4xkobBN7j1nE4Tc103n","msg":"status updated","newState":"dialFailed","oldState":"dialing","time":"2024-06-17T06:02:00.469Z"}
ohk again the same terminator issue
I'll offer some guidelines to help me help you because I'm unable to discern the nature of the problem based on what you posted. Reminder: router link errors might not be a significant problem, but may be "noise" due to unreachable link listeners. We've talked about this a few times in this topic. Does it make sense?
- Start a new topic for a new problem. This ensures the solution will be helpful to other forum users and defines the context and the problem. This also welcomes anyone that understands the problem to comment.
- Paste text snippets that describe the symptom (the visible signs of dysfunction), not screenshots, if possible. Thank you for this, it saves a lot of time for the responder and makes the symptom searchable for other users.
- Provide a step-by-step procedure that recreates the same problem every time (reproduction of the issue). This helps you to think through the issue and sometimes find the solution before posting. Please share the solution anyway for other users!
sure thanks @qrkourier , will make it organised and if I find any issues ill point them to this thread too