MikroTik

I've just worked through all the subtleties and published them here.

Enjoy!

In your article it says:

"The only trick that seems to matter is that you DO have to connect the Ethernet cable from the router straight into the host's copper Ethernet port. You can't put a switch between it and the router, not even a MikroTik brand switch."

I am curious if you tried a non-managed (vlan-transparent) switch?

I haven't tried, and I did read your footnote 2 "Don't ask me why; I tried it both ways, and that's how it is. If you know why — or, better, how to get around this limitation — I'd love to hear about it."

Because what doesn't make sense to me, is how would it work through the MikroTik bridge interface and the VM bridge/virtual switches?

Managed switches are much less transparent than unmanaged ones that usually operate in vlan-transparent mode, have no extra processing (IGMP snooping, xSTP, CDP, LLDP etc.).

If you have an unmanaged switch made in the last 10 - 15 years, most will pass ethernet frames as is whether they have vlan tags, bpdu, cdp, etc. It would at least be worth trying to see if it works.

I thought I saw someone even recommending putting switch between the router being netinstalled and a windows computer. I wasn't able to find what I thought I remembered, but possibly it was this in the ROS documentation:

https://help.mikrotik.com/docs/display/ROS/Netinstall

Thanks to your prompting, I did try a dumb switch, and it did work, but that led me to the question, "Why?"

I quickly tracked it down to the Trusted setting on bridge ports in my CRS328, all disabled except for the one port toward my DHCP provider. NetInstall includes a BOOTP step, which is the predecessor to DHCP, so in retrospect, it makes perfect sense that disabling "Trusted" on a bridge port would prevent netinstall from getting started.

Only the port toward the netinstall-cli host needs to be marked Trusted if you use a RouterOS device as a switch between the server and this second RouterOS device you're netinstalling. Continuing to consider the target port "untrusted" is probably a very good thing if your default configuration includes a DHCP server, since you don't want it confusing the rest of the LAN.

I did try a dumb switch, and it did work, but that led me to the question, "Why?"

I quickly tracked it down to the Trusted setting on bridge ports in my CRS328

Thanks for testing it and better, finding the root cause.

Like you, I like to know why when things don't behave the way I expect them to.

added link from netinstall article.

Thanks, anav.

You should mention the key distinction between the two approaches: mine uses a Linux VM from the command line, whereas the other article assumes you have a Windows VM and want to use the netinstall GUI.

I'm half-tempted to ask you to remove the other link, though. It ticks every item on my list of myths except disabling WiFI, and that only because it doesn't apply to a VM. I suspect my list of myths apply just as well to the Windows GUI method. If so, promulgating these myths makes the other guide pointlessly misleading. If for some reason one or more are true — that is, you really do have to set a static IP, switch the VM to the 192.168.88.1/24 subnet, and/or use a direct copper connection to make the Windows method work — I'm tempted to say it isn't worth it relative to mine even for folk a-scairt o' the CLI. All that faffing about has a cost.

If for some reason one or more are true — that is, you really do have to set a static IP, switch the VM to the 192.168.88.1/24 subnet, and/or use a direct copper connection to make the Windows method work — I'm tempted to say it isn't worth it relative to mine even for folk a-scairt o' the CLI. All that faffing about has a cost.

What is also bad is that the instructions for switching the ip address to static are incomplete; the ip address doesn't get changed until you "OK" on the ethernet properties screen. I know, because I wasted time "troubleshooting" a problem when I assumed I had changed my adapter's ip address, but it had not ever been changed. I always verify it is correct with ipconfig /all after making a change, but before continuing with whatever needed the ip address changed.

The documentation has two hints that you don't have to use a static address. But they recommend it for people that are not familiar with netinstall.

Following are the two places in the netinstall docs that give the hints (and the second shows what I consider to be misleading at best, that #6 is what "changes the ip address". It does not. Don't take my word for it, try it yourself and use ipconfig to verify what the address is after #6 and then again after you press "OK" on the parent Ethernet properties window.

I'm half-tempted to ask you to remove the other link, though

Done!