Inspecting the Fabric and Mesh

Hello, I'm new the OpenZiti and have set up 2 routers in clouds to serve as the "mesh" and connected some services geographically distributed. I am connecting wonderfully to services, but I was wondering if there was a way to inspect the full route taken to see the edge router to edge router mesh usage. ziti fabric list links and ziti fabric list circuits provide some information but I am unsure of how to parse them to visualize routes.

Hi @danclay, welcome to the community and to OpenZiti (and zrok and browzer)!

For better visualizing the circuit, you might try using the ziti admin console (ZAC) and the visualizer?

visualizer

Other than that, what sort of questions about the circuit do you have? If you want to show me an example, me (or someone) could take a look and answer any questions. Is there something in particular you're wondering about?

1 Like

Yup, just checked that out and it has helped. I noticed the ZAC console doesn't seem to show any links between edge routers, is that just visual (attached below)? If so, is there any way to check the existence of the inter-router links? I was most curious of visualizing (mentally or visually) of this type of connectivity and how cost may work with it. For instance, if someone connected to the local-router is connecting to the service, are the options any of:

  1. local-router --> cloud-edge-router1 --> service-tunnel
  2. local-router --> cloud-edge-router2 --> service-tunnel
  3. local-router --> cloud-edge-router(1 or 2) --> cloud-edge-router(1 or 2) --> service-tunnel

If so, what factors determine this? Will rerouting occur if a router clogs up from, say, another endpoint's file transfer?

Let's imagine a complex path, something like:

[r/h-DqbP927]->[l/1qp6LIzSlWkQM1jSSTJG1j]->[l/2td3LAbcdeQM1jSSTJG1j]->[r/Ce1f5dDCey]

Here we see a circuit that first

  • connects to a router with id h-DqbP927
  • traverses the link with id 1qp6LIzSlWkQM1jSSTJG1j
  • traverses the link with id 2td3LAbcdeQM1jSSTJG1j
  • ends at the router with id e1f5dDCey, which offloads the traffic to wherever it's going

As for the visualizer, it's not something I've worked on myself. I'll see if I can get someone to comment on that.

Okay that clarifies the CLI a bit. So if I were to build a complex network and encourage bouncing around routers (maybe modifying costs), I should see the link IDs in the circuit command match up with links containing a router dialer and router acceptor in the link list command? e.g. though the UI doesn't show it, I have a link that shows
3sYbIsNWafVOky34fzrqoD │ router2 │ router1
Does this mean the two routers have formed a mesh?

Alright, I used our existing docker compose quickstart (which is complicated for these sorts of reasons)... I updated it so that it uses link groups and forced the path and then I made a web request and captured the path.

╭───────────┬───────────────────────────┬──────────┬────────────────────────┬─────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ID        │ CLIENT                    │ SERVICE  │ TERMINATOR             │ CREATEDAT           │ PATH                                                                                                                         │
├───────────┼───────────────────────────┼──────────┼────────────────────────┼─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 3IEiiQQiU │ cm25nmh5200fgmumbdejqwxbj │ http.svc │ 6G9M1UCSxvarE6nibEUdlJ │ 2024-10-12 04:32:47 │ r/ziti-edge-router -> l/5oTWKh6Hurr1UaAVacZiHR -> r/ziti-fabric-router-br -> l/20nJKIgwm4byEPDjKu9vkA -> r/ziti-private-blue │
╰───────────┴───────────────────────────┴──────────┴────────────────────────┴─────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
results: 1-1 of 1

$ ziti fabric list links
╭────────────────────────┬───────────────────────┬───────────────────────┬─────────────┬─────────────┬─────────────┬───────────┬────────┬───────────╮
│ ID                     │ DIALER                │ ACCEPTOR              │ STATIC COST │ SRC LATENCY │ DST LATENCY │ STATE     │ STATUS │ FULL COST │
├────────────────────────┼───────────────────────┼───────────────────────┼─────────────┼─────────────┼─────────────┼───────────┼────────┼───────────┤
│ 20nJKIgwm4byEPDjKu9vkA │ ziti-private-blue     │ ziti-fabric-router-br │           1 │       2.1ms │       2.3ms │ Connected │     up │         5 │
│ 3TS2LBeqnZjF1XJb7HFr4  │ ziti-private-red      │ ziti-edge-router-wss  │           1 │       1.2ms │       2.4ms │ Connected │     up │         4 │
│ 4c2Cumio5vIQv5pdqt8aB1 │ ziti-edge-router-wss  │ ziti-edge-router      │           1 │       1.2ms │       2.6ms │ Connected │     up │         4 │
│ 5oTWKh6Hurr1UaAVacZiHR │ ziti-fabric-router-br │ ziti-edge-router      │           1 │       1.9ms │       2.5ms │ Connected │     up │         4 │
│ 63YE0liebUFiOuThOjP5B3 │ ziti-private-red      │ ziti-edge-router      │           1 │       1.5ms │       2.0ms │ Connected │     up │         3 │
│ OsLduOUCwykMSa4VfcaWN  │ ziti-fabric-router-br │ ziti-edge-router-wss  │           1 │       1.7ms │       2.0ms │ Connected │     up │         4 │
╰────────────────────────┴───────────────────────┴───────────────────────┴─────────────┴─────────────┴─────────────┴───────────┴────────┴───────────╯
results: 1-6 of 6

So you can see the web request comes into router r/ziti-edge-router and traverses the link 5oTWKh6Hurr1UaAVacZiHR which is between ziti-fabric-router-br and ziti-edge-router.

Next it traverses the 20nJKIgwm4byEPDjKu9vkA link which is between ziti-private-blue and ziti-fabric-router-br

It exits the r/ziti-private-blue router and goes to the web server

1 Like

That makes sense, thanks for the great explanation!

For inspiration, you may be interested in one of the visualisations we provide in the NetFoundry console.