Why router has multiple endpoints

Hi,
Why does OpenZiti have three API endpoints for routers:

  • /edge-router
  • /routers
  • /transit-router

I 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