Checking if there is anything specific to consider when doing this?
Is it just a ziti command… or are there more steps required.
It’s not really well documented in a nice and easy way to consume. There are a couple different ways you can go about it though. The easiest way is to take your existing config, modify it and then use that config to create/enroll the second router. If you want a second, public edge router that would work fine.
You can also run ziti create config router edge --help and make a public router that way or add --private to make a “private edge router”. A router that has edge enabled, but won’t advertise a link to other edge routers. That means it will dial out and form links to other routers, but
those other routers won’t try to connect to this router. That’s really useful when the router is in a private data center. If that makes sense.
We added this issue recently for this but it’s not done yet Improve private option doc in CLI command · Issue #735 · openziti/ziti · GitHub
If you want to dig through the ziti-cli-scripts.sh script you can see the commands used to make “public” and “private” edge routers. Also if you fire up the docker-compose environment you can see two public routers, one purely ‘fabric’ router (a router without edge enabled), and two private edge routers…
I feel like that’s not going to be enough to get you working - but maybe it will. If not - holla back here and we’ll get that edge router enrolled and working. I’m sure… I’ll try to recap what you need below but I might miss a step…
Short Bullets
- copy existing config/make a new one using
ziti create config rotuer - make sure you edit the CSR section, add external DNS and IP addresses accordingly
- use ziti CLI or zac to make a new router. i recommend setting “tunneler enabled” on like this in ZAC
or with the -tflag in the CLI - use the ziti-router binary to
enrollthe router - copy the systemd file from the quickstart for the router and use it to bootstrap another router
2 Likes
I am working through this over the weekend… and though to ask… what are the benefits by making a router tunneller enabled?
One would be that you can use the zitified ssh app.
Are there any other reasons… I want to learn more about this specific capability so that I know how best to use it.
Depends on what you're doing really. If you're using a ziti-edge-tunnel on all your hosts or if you're going app-embedded, then there's no real reason/need for it. It's sometimes convenient to use it as another identity. The best reason I can think of is so that you can ssh to the router for 'normal' activity. You could make an ssh service that offloads to "localhost:22" and not need a port open on the firewall.
Usually people start with it when they only want to deploy "a single device" on their "trusted" network that provides access to that 'trusted zone'. IF you had 100 computers in that network, deploying one edge router is 'easier' than deploying 100 tunnellers on every machine... "less secure" since you're trusting the whole network but easier...
That's why app-embedded is so great. You just ask people to 'run the app' they likely don't even know they are using a zero trust overlay.
1 Like
ahh… get it now… nice. Thanks for the clarification.
I was looking through the edge router yaml file.
what do you change? I don't mind if its 100% the same unless this will cause a problem
I also remember that you have made previous comments about the dialer.. and listener.
From what I can remember
The dialer is what will make outbound calls
The listener is what creates the terminator
Is this correct?
I can understand how the listener works.. but what is a dialer used for an edge router.. may seem a stupid question.. but I dont have a networking background
this second edge router - are you making it a 'public' one? One for redundancy and extra bandwidth which any edge device anywhere can use?
or are you looking to make a private one - one in a data center that's used for getting traffic into a private networking space?
yes
maybe. if you're talking about the "link listener" then no. the link listener tells other routers to connect to this router to form the mesh. you want at least one link listener for sure. if you're talking about the "listeners.binding: edge" section - then yes. adding "edge" to the edge router will cover adding terminators as necessary
so depending on what you're looking to "do" - make a public router or a private one there are small differences.
If you copy the router config you have already - you just need to find the sections that refer to the host itself. so for mine i think these are all the spots to change:
ctrl:
endpoint: tls:ctrl_ext_fqdn:6262 <-- this should be the external addy of the controller
link:
dialers:
- binding: transport
listeners:
- binding: transport
bind: tls:0.0.0.0:10080
advertise: tls:ext_router_fqdn:10080 <-- this should be the external addy of the router
options:
outQueueSize: 4
listeners:
# bindings of edge and tunnel requires an "edge" section below
- binding: edge
address: tls:0.0.0.0:8442
options:
advertise: ext_router_fqdn:8442 <-- this should be the external addy of the router
connectTimeoutMs: 1000
getSessionTimeout: 60s
- binding: tunnel
options:
mode: host #tproxy|host
edge:
csr:
country: US
province: NC
locality: Charlotte
organization: NetFoundry
organizationalUnit: Ziti
sans:
dns:
- router_hostname <--the hostname
- localhost
- ext_router_fqdn <-- this should be the external addy of the router
ip:
- "127.0.0.1"
- "external_ip" <-- this should be the external IP of the router
1 Like
I am testing to see what impact it has on performance.
My current setup works well with one reverse proxy... but slows down when I chain it with another.
The first one makes a private dns available in the fabric.. using a ziti host
The second makes the dns available to a local client.. using a ziti dialer
All of this traffic is over one edge router.. so I am guessing that there is a bit of congestion happening
So.. I thought.. lets create a second edge router to see if ziti can perform some magic here 
In relation to the config changes… maybe I am making a mistake… as it appears you can only have one edge router per machine…
Does that make sense?
So… maybe instead… I need to create some servicer routers.
Would this make any difference?
no. you could run two routers on one machine... you might need to listen on other ports then, you'll need to make sure you change the 'identity' section and the paths to the certs etc. There are just a lot of other things that can go wrong doing it that way because the two routers can clash with one another if you don't do it carefully.
i'd start with 'another machine' first just to keep it easy but you can run > 1 on a machine if you configure it correctly. I don't think it "makes sense" in production situations but for dev - it makes sense why you'd want to do that
1 Like
Interesting… so… I am sort of on the right track
I think what it’s inspiring me to do is to create a multi cloud network… and create the second edge router on another private network…
This is probably the easiest next step…
PS… I could create another compute… but this is not an option I have
PS2… I could create a dockerised network… but its not something I have a lot of skill in… and will create more problems for me
Does this make sense?
What doesn’t make sense to me is if you’re making a multi-cloud network you’ll have to have another compute node.
But like I said, as long as you change all the ports and all the config, you can run two routers on one machine.
1 Like
ok… that probably saves me a lot of pain
I will give this a shot… as I will learn a whole lot more about how to setup and configure these edge routers… and how the interact with the service routers
I just learned the the certificates for the edge router are created when you enrol the edge router.
This is starting to make sense now
https://openziti.github.io/ziti/manage/sample-edge-router-config.yaml
PS>. I also just realised you also need to create an identity for the edge router that you will use for enrolment
Quick check @dovholuknf.. as I was looking through the quick start install script.. and realised that there is a step to create the router PKI
createRouterPki "${ZITI_EDGE_ROUTER_RAWNAME}"
I was anticipating that this happens as a part of the enrolment process.. where they are created if they do not exist?
If they do exist.. I presume the use the details provided
Actually.. this may not be right.. as I noticed that the router jwt file is outputted when its created ..
edge create edge-router "${ZITI_EDGE_ROUTER_RAWNAME}" -o "${ZITI_HOME_OS_SPECIFIC}/${ZITI_EDGE_ROUTER_RAWNAME}.jwt" -t -a "public"
Here is a list of the commands that I will try later today.. I want to check them one more time
#0.. load the env file
#1 create a router config
router_name=instance-20220416-1603-2nd-edge-router
output_file="${ZITI_HOME}/${router_name}.yaml"
ziti create config router edge --routerName "${router_name}" > "${output_file}"
#2 edit the CSR section, add external DNS and IP addresses accordingly
refer to the original router yaml file
#3 ziti CLI to make a new router
ziti edge create edge-router "${router_name}" -o "${ZITI_HOME_OS_SPECIFIC}/${router_name}.jwt" -t -a "public"
#4 use the ziti-router binary to enroll the router
ziti-router enroll "${ZITI_HOME_OS_SPECIFIC}/${router_name}.yaml" --jwt "${ZITI_HOME_OS_SPECIFIC}/${router_name}.jwt" &> "${ZITI_HOME_OS_SPECIFIC}/${router_name}.enrollment.log"
Once done.. all you need to do then is to start the router...
ZITI_EDGE_ROUTER_RAWNAME=instance-20220416-1603-2nd-edge-router
. ./ziti-cli-functions.sh && startExpressEdgeRouter
That is what happens. I actually don't know why that function was created to be honest. I wonder if it's just really old, back before I actually understood how router enrollment worked.
I gotta say, I don't think it's needed. I'll maybe look into that Monday
1 Like
Quick update.. as I took the leap and worked through all of the steps.
Everything went along smoothly until I needed to start up the edge router.
I did not change the following settings.. but it appears this was in error
link:
dialers:
- binding: transport
listeners:
- binding: transport
bind: tls:0.0.0.0:10080
advertise: tls:instance-20220416-1603:10080
options:
outQueueSize: 4
.. which returned an error
FATAL fabric/router.(*Router).startXlinkListeners: error listening on Xlink (error listening (listen tcp 0.0.0.0:10080: bind: address already in use))
[1]+ Exit 1 "${ZITI_BIN_D
Any tips on what to do? Not sure what would happen if I made port 10080 10081..