I thought my knowledge of nsswitch would never be useful outside of NIS but here OmniOS proved me wrong :))))

antranigv: one place to check for persistent new-style configs is under /etc/ipadm and /etc/dladm

Technically you can edit those files too, but with a caveat that you'd better ungracefully reset the system afterwards (graceful stopping of respective networking services saves their active config)

A safer alternative is to `beadm clone ...` a new environment, edit the files there, and activate it to reboot into it

All that assuming you too don't figure out how to reliably force the CLI tools to do what you want :D

jimklimov well, all is working fine! I have rebooted and everything is working to my liking

I do have a question tho

I am creating vnics from etherstub, but I didn't need it connect to any bridge. why is it working then?

weee I got all the things I needed working

With respect to your bridge question, why did you expect to need the bridge?

There aren't a lot of times you actually need 802.1D per se.

rmustacc On other operating systems I'd create a bridge (say bridge0) and then create other ethernet devices (say tap interface, epair on FreeBSD) and then attach them to the bridge

But are you actually enabling bridge PDUs and spanning tree?

rmustacc nope!

rmustacc so in this case, the VNICs are created from the etherstub and the rest is routing, right?

Without knowing what you've created and what's running on what I can't really say.

rmustacc wait wait, don't leave, lemme paste :D

I wasn't.

rmustacc here you go! gist.github.com/antranigv/4bce33cb61a2b02239a0a758c3965ed4

So what's happening here is that a packet arrives in on vioif0 and gets delivered to the global zones netstack. The global zone presumably has forwarding enabled. That will then based on your routing table see that there is 10.10.0.0/24 out internal0.

So the packet will be forwarded to internal0 which will perform ARP to discover 10.10.0.80 and then send it there, because it's a virtual L2 segment.

The way I think of an etherstub is a dumb, unmanaged L2 switch.

rmustacc internal0 or vnic0? I was not able to "configure" internal0

oh you mean vnic0/internal0

got it

Sorry, I meant the IP address internal0 on vnic0.

and VNICs on the physical interfaces require VLAN

I hadn't noticed the overlapping bridge name.

I should delete that

VNICs on a physical interface don't require a vlan.

Unless you require it for some reason.

That is, that isn't specific to the vnic design.

interesting, so I can do `dladm create-vnic -l vioif0 public0` ? hmmm

But your circumstances may require it, in which case you can just specify -v to ensure it performs vlan tagging.

Yes.

The question is do you need a different actual L2 interface for that.

and then pass public0 to the zone and set a public IP. neat!!!

doing the same with FreeBSD involved bridges

Yes, that would work, depending on how you get that IP address.

If something is handing it out to you via dhcp or other things, it may get more nuanced.

nah, just routing via the ISP.

cool

It mostly depends on how you want your management and system access to be done.

then what's the Usecase of bridge?

If you only have on public IP address and that's how you access the system.

If you need 802.1D bridges with spanning tree, trill, etc.

so connecting a 802.1D physical switch to illumos

where STP continues to talk

okay, that's nice too

Yes. But I find that's pretty uncommon.

That is that you need the illumos system to participate in STP.

But there are cases.

rmustacc thank you very much! learned awesome things here and at #SmartOS Discord

antranigv: we're also on IRC's #smartos . Also, #illumos exists here for things that transcend the distros (e.g. device support, and other illumos-y things).

danmcd btw, your talk from a decade ago helped me build this box in our hackerspace.

danmcd I would also like to contribute, for example, yesterday I noticed somethign with dladm, but not sure if it's considered a bug or not.

danmcd lemme ping you at #illumos, I don't want to spam here :)

Greetings Earthlings...   I'm trying to sort out how to setup PXE installation of OmniOS. I have read all the docs but my PXE/TFTP install server is Linux (Rocky8) and the environment is UEFI. If I PXEboot the OmniOS kernel, as per the documentation, I get bad magic number on attempting to load the kernel from the PXE client. I believe I have to

chainload the OmniOS kernel because it isn't a Linux kernel, but I can't seem to get it right. Does anyone know the magic recipe to PXEBoot/UFEI OmniOS kernel from a Linux boot server? Here is the "bad magic number" grub.cfg entry from the PXE server:

 menuentry 'OmniOS Install' {

  kernel (tftp)/omnios/omnios-r151048.unix -B install_media=10.0.0.1/repos/omnios/omnios-r151048.zfs.xz

  initrd (tftp)/omnios/omnios-r151048.miniroot

 }