Reviewing the configurations when making a second edge router private

I am consolidating my learnings, and noticed a previous example where I created a second public edge router.

Here is a copy of the discussion

This is a summary of the changes needed

  1. use a new port number
  2. use the IP address of the controller to advertise on
  3. include the IP address of the controller in the edge CSR IP tags
# bindings of edge and tunnel requires an "edge" section below
  - binding: edge
    address: tls:
      advertise: 222.333.44.22:8442
  - binding: tunnel
      mode: host #tproxy|host

        - ""
        - "222.333.44.22"

Some questions that I have are:

  1. If you comment out the listeners section, would this make the public edge router a private edge router

I remember a references in the past about private routersā€¦ but are not really sure what they are

  1. what is the difference between the edge / tunnel bindings

I am not really clear on this

  1. When making changesā€¦ at what point do you need to re-enrol the edge router identity

why is this needed?
I remember that the edge router identity need to be re-created if you are using a Oracle Linux serverā€¦ because it does not use the IP address for the listener to advertise on

Any tips / insights would be greatly appreciated.

I remember noticing this comment in one of the earlier threadsā€¦ so that answers my question re the tunneller bindingā€¦ as its not needed if you use app embedded networksā€¦ but is if you dont :slight_smile:

I think I worked this one outā€¦ because when you enrol the identity for the edge routerā€¦ it defines the IP addresses in the SAN for the router certificateā€¦

Henceā€¦ you donā€™t need to recreate it if you are simply making a few minor changesā€¦ only if it affects the SAN details of the certificate.

1 Like

If youā€™re not app-embedded, you need tunnelers of some kind. You can either have the tunneler running inside an edge-router, in which case you need the tunneler binding, or you can have it running standalone, in which case you donā€™t. A standalone tunneler looks just like any other SDK app to the edge router.

1 Like

I think usually public/private routers refer to where they sit on the internet, in public or private networks.

Public routers are those that can be reached on the public internet. Public edge routers can be used to allow clients coming from arbitrary locations access to a ziti network. Public routers (either fabric or edge) can also be a means for routers in private networks to be bridged together. If you have private routers in private networks A and B, they canā€™t reach each other. But they can both reach out and from links to one or more public routers, allowing traffic to flow from A to B (provided you have the right policies configured).

Private routers are those that are in a private network. They reach out to the public routers to form the fabric mesh and provide access to the services that are in the same private network. They can also provide access to clients in the same private network.

If you removed everything from the listeners section you wouldnā€™t be able to initiate any connections to that router. Depending on what you had in the dialers section, you might be able to have traffic terminating on that router.

1 Like

The edge binding configures a listener for edge SDK clients. The tunnel binding runs a tunneler in the router process.

edge binding: router[edge listener] ā† network ā†’ edge sdk clients
tunnel binding: router[tunneler] ā† network ā†’ non-sdk apps

1 Like