Improve readability of mermaid diagrams and a couple small edits about the scope of stub networks.

[ubedan]

It was very difficult to read the top 3 mermaid diagrams. Made the block backgrounds darker to make the text legible.

Made a minor edit that stub networks don't go over a physical nic in the 3rd diagram.

A proposed edit to make it even more clear that stub network traffic only communicates with other vnics on the same stub on the same sled.

[davepacheco]

I'm not sure what's going on here but I find the change in colors in this PR notably harder to read. In case it helps, on "main" it looks like:

In this PR it looks like:

It's now dark text on dark background that I find harder to read. Or maybe you're using dark mode so the text is light? Maybe we should be specifying both the background and text colors?

I think the label change from cxgbe0 -> etherstub looks right. Thanks for catching that.

[davepacheco]

Suggested change

	* an etherstub `underlay_stub0` with a VNIC `underlay0` over it. Every underlay# vnic can only connect to other underlay# vnics on the same sled.
	* an etherstub `bootstrap_stub0` with a VNIC `boostrap0` over it. Every bootstrap# vnic can only connect to other bootstrap# vnics on the same sled.
	* an etherstub `underlay_stub0` with a VNIC `underlay0` over it. Every underlayN VNIC can only connect to other underlayN VNICs on the same sled.
	* an etherstub `bootstrap_stub0` with a VNIC `boostrap0` over it. Every bootstrapN VNIC can only connect to other bootstrapN VNICs on the same sled.

But I think this is more confusing than helpful. In a sense, the underlayN VNICs are only virtually "physically" connected to the other underlayN VNICs. But at the IP level, they have connectivity to the underlay interfaces on other sleds. So I think someone might read that sentence and think "the underlay interfaces aren't connected to other sleds", which is wrong.

[ubedan]

Even though the Data path between components on different sleds section lower in the document makes it clear that the gz's underlay0 will forward the packet, it seems like it might help to state it here as well.

Perhaps something like a new paragraph: just below:

Each stub network by itself is only able to communication between vnic's in the respective stub network unless port forwarding is enabled in the global zone, which it is.

or

an etherstub underlay_stub0 with a VNIC underlay0 over it. Every bootstrapN VNIC can only connect to other bootstrapN VNICs on the same sled unless the global zone is setup to forward packets, which it is.

[davepacheco]

That still reads pretty misleading to me. It's not until you get to end of the sentence that you realize the whole sentence is actually irrelevant for the use case we're writing for.

We could add: "The underlayN VNICs are only directly connected to each other. They rely on IP-level forwarding (explained shortly) to provide connectivity beyond the etherstub network." and the same thing for the bootstrapN VNICs.

I'd prefer not to unless you or somebody else found this point confusing though. The text already said this above, and there's nothing in the output here that reinforces that point. I think it's potentially more confusing to sort of pre-introduce the IP-level concerns before we really get to them. Not a big deal either way though.

[david-crespo]

Confirming your guess: in dark mode the text is white. A better solution (if possible) would probably be to leave the background colors as-is and make the text always black (at least for the lighter-background nodes).

before

after

[davepacheco]

A better solution (if possible) would probably be to leave the background colors as-is and make the text always black (at least for the lighter-background nodes).

Sounds good to me.

[ubedan]

I apologize... I thought I'd combine everything but accidentally closed this...

I have a compete diff (patch), or I could make a new pull request.

[davepacheco]

I apologize... I thought I'd combine everything but accidentally closed this...

I have a compete diff (patch), or I could make a new pull request.

I think either is fine. I'm not sure if you've pushed everything you wanted but the current version doesn't seem to have the updates to the bullet points. Also, it uses a lot of inline HTML and a classDef. The classDef seems much more readable. Can we just do that?