Hi,
Why does OpenZiti have three API endpoints for routers:
/edge-router/routers/transit-routerI understand that Ziti routers can be configured differently based on their configuration files. However, does it make any significant difference if the router was created using one of these specific endpoints?
Hi @ayushhsinghh,
I assume you're looking at code or you're looking at inbound http requests in some way, not at the published spec for the edge-api, right? As for "why", it's probably historical reasons.
Is there a reason why you're asking? Some other question/need you're after?
I would recommend you use the edge-api, the edge-routers API. I am not as familiar with /routers and /transit-routers but those sound like fabric API endpoints. I'd personally encourage you to use the /edge-routers endpoint exclusively at this point. @plorenz or @andrew.martinez
might have other thoughts to share.
I wanted to create a Transit router with only the Link.Listeners functionality, without any edge or tunnel listeners.
This led to confusion about whether I should use the /edge-router or /transit-router endpoint to create the router in Ziti, which is why I’m asking this question.
Additionally, I’d appreciate it if you could provide a sample router configuration that enables only transit functionality.
Gotcha, yeah I understand what you're looking for. What you want is to have no edge listeners. This means you can't use that router as a tunneling-enabled router though, so beware, but I'd guess you're not looking to have that functionality in this situation.
You should create an non-tunneling-enabled edge-router (just means the router can't work as a tunneler), but when you make the config file, remove any edge listeners. Using the ziti CLI you could see what this looks like using:
ziti create config router fabric --routerName no-edge
This will emit a config file to std out that looks like this, notice the edge section is simply commented out. That's all it takes:
v: 3
identity:
cert: "/home/cd/no-edge.cert"
server_cert: "/home/cd/no-edge.server.chain.cert"
key: "/home/cd/no-edge.key"
ca: "/home/cd/no-edge.cas"
#alt_server_certs:
# - server_cert: ""
# server_key: ""
ctrl:
endpoint: tls:sg4:6262
link:
dialers:
- binding: transport
listeners:
- binding: transport
bind: tls:0.0.0.0:10080
advertise: tls:sg4:10080
options:
outQueueSize: 4
#listeners:
# bindings of edge and tunnel requires an "edge" section below
# - binding: edge
# address: tls:0.0.0.0:3022
# options:
# advertise: sg4:3022
# connectTimeoutMs: 5000
# getSessionTimeout: 60
# - binding: tunnel
# options:
# mode: host #tproxy|host
csr:
country: US
province: NC
locality: Charlotte
organization: NetFoundry
organizationalUnit: Ziti
sans:
dns:
- localhost
- sg4
ip:
- "127.0.0.1"
- "::1"
#transport:
# ws:
# writeTimeout: 10
# readTimeout: 5
# idleTimeout: 120
# pongTimeout: 60
# pingInterval: 54
# handshakeTimeout: 10
# readBufferSize: 4096
# writeBufferSize: 4096
# enableCompression: true
forwarder:
latencyProbeInterval: 0
xgressDialQueueLength: 1000
xgressDialWorkerCount: 128
linkDialQueueLength: 1000
linkDialWorkerCount: 32
hth
@TheLumberjack
If all routers are to be created as edge-routers, what is the behavior when it comes to adding routers to a service-edge-router-policy?
Let us assume a 3-router topology:
When creating a service that uses these routers:
Does the transit-router also need to be included in the service-edge-router-policy?
I guess what is confusing here is that the service-edge-router-policy only includes edge-router-roles. So if the router is not running an edge, how is it expected carry traffic for the service?
the service-edge-router-policy has to contain both the edge-router and the reverse-proxy router in its edge-router-roles. Does the transit-router also need to be included in the service-edge-router-policy?
No. A serivce-edge-router-policy controls the edge routers that are allowed to initiate or terminate a connection exclusively. Anything and everything in between is irrelevant to the serivce-edge-router-policy. You do not need to include the transit routers in the serivce-edge-router-policy.
So if the router is not running an edge, how is it expected carry traffic for the service?
This is understandably confusing, it's why I do my best to only call ever refer to them as "edge routers" to try to avoid this confusion but inevitably, once you start digging in more, you hit a point where you start to wonder about these distinctions.... To me, every router is an edge-router and it just matters whether the edge-router has link dial/listening enabled, edge listening enabled or both.
As to 'how' it carries traffic, if it's a public router you almost certainly want it to be edge-enabled and link listening enabled (and optionally link dialing enabled). Edge routers that act as "link only" routers - in your example the private transit-router, are there to form links to create the OpenZiti fabric/mesh overlay network. The edge traffic from private reverse-proxy router or from public edge-router would traverse the fabric, in this case composed of two (2) links. It'd look something like this:
I would also add two "link groups" into this mix. I would make sure the private edge router ONLY dialed the DMZ private transit router and I would ensure the DMS private transit router only dialed the public edge router.
So to recap:
That help clear things up? hth
