Based on the following doc the router yaml section listener.binding=tunnel requires listener.binding=edge:
What is the rationale behind this requirement?
For example, in the gateway topology described in https://openziti.io/docs/guides/topologies/gateway/router the remote-router that is sitting next to the Ubuntu server requires a tunneller but does not require any edge component at all (since it is not expected to service an edge-client). It would only require a link.listener and a listener.binding=tunnel.
I would not expect the edge router to be required to have an edge listener. It would need to be "tunneler enabled" which means when you create the router in the controller, it needs --tunneler-enabled or -t supplied. This ensures the router is granted an identity and thus can act "like a tunneler".
I'll have to test it out when using the router as a tunneler without the edge binding. I wouldn't expect that to be necessary.
Sure enough. I tried it and received a panic:
PANIC ziti/ziti/router.run: {error=[required binding [edge] not found in [listeners], at least one edge binding is required]} error registering edge in framework
panic: (*logrus.Entry) 0xc00034aee0
I'm not sure what the rationale is here. I'll have to ask other people on the team to know if there's some reason for it.
Thank you @TheLumberjack .
Yes I noticed that panic too and was a little surprised 
Also, I mis-poke in my original description of the gateway example. You are quite correct, the remote-router does not need a link-listener. Just the tunneller.
That the edge router/tunneler needs an edge binding is a historical artifact that will hopefully go away soon. The initial tunnel implementation in the router piggy-backed off of the edge implementation, re-using some of the communication and distributed state management code. Over time, we've worked on disentangled that, and as part of the HA work, we're making an effort to finish the separation.
Cheers,
Paul
1 Like