followed below instruction for setup of homeassistant:

https://help.mikrotik.com/docs/display/ ... eAssistant

with above, am unable to add homekitbridge to IOS as an accessory (Since they reside on different Networks. HA on its own bridge/ip based on above instruction and homelan devices on the main bridge/vlans).
please let me know if you have a working setup or pointers to get it to work. thanks

Put the VETH on the bridge.

Put the VETH on the bridge.

if main bridge had VLANs(each serving to clients with its own DHCP server), then just assigning an unused address from any of the VLAN (specifically that would have homekit devices) work? i remember trying this and it did not (meaning, it was not reachable via http://<ip>:8123 eventhough HA started fine and could get into its shell and check via ifconfig. internet access from inside container also seemed not there even though dns was passed as a param for container). are there additional VETH port settings to be done (like VLAN ID or anything else).
did not seem like firewall issue as i log all the forwarded packets and accept anything relevant that was requesting access.
i was seeing ROS trying to add dynamic arp entry for the ip and says status as failed (also no mac address)

also, separately, if i had a streaming VLAN and IoT VLan, how do we get VETH port to see both traffic (on RB450GX4 ) for auto discovery? (use mDNS to reflect from one vlan to another vlan where HA would reside?)

I'm no expert on VLANs, but as far as I can tell, RouterOS's veth mechanism has no awareness of VLANs. Indeed, we have a nearly-opposite statement in the first caution box in the MACVLAN section of the docs.

I presume packets from a VETH arrive at the routing layer untagged, and you could then add bridge filter rules that add tags as needed based on source IPs.

I also don't see a way to give a container multiple interfaces, in order to put it on multiple VLANs. I think you'd have to set up inter-VLAN routing to get traffic from one side of the VLAN barrier to the other. To support HASS auto-discovery, I'd put the server container on the IoT network, then allow connections in from the non-IoT networks that need to access the HASS UI, API, etc.

have requested support to provide sample configuration for vlan aware veth ports in a single bridge configuration with multiple vlans (from homeautomation perspective even the matter server is expected to be on same network as ha/devices)

You can treat VETH the same as a ether1 etc ports. So it can use in your "main" (or only) bridge, and using vlan-filtering=yes. Possible to make a trunk (e.g. /interface/bridge/vlans as a tagged=), or, an access or hybrid port by setting a PVID etc. The same as any other ethernet port living in /interface/bridge/port.

True, there is only network interface allowed to each /container. But you can, largely, achieve the same by providing a VLAN trunk, theoretically. And, there are a couple mDNS containers floating around on the forum that take use a "trunk". But since this is not how "normal docker" works... a VLAN trunk might not work for "pre-built" containers like homekitbridge etc.

But you can use your "normal LAN" (or likely some VLAN), with a VETH if it's a bridge port in "main" bridge. There is no need for the seperate "docker" bridge shown in some /container examples, like Pi-Hole – there it just need to receive routed IP traffic for DNS, so it being isolated is a good thing. By homekitbridge etc DO need broadcast/multicast access to entire LAN with devices – so the separate bridge approach is just wrong.

The only exception here... is that you need to statically configuration the IP address for a VETH based on subnet/gateway of the untagged network. DHCP may work too, but you're likely better off configuring a static IP in VETH – since that IP get's "injected" into the /etc/host... files inside the container before it boots. This might mean you'd want to create a DHCP reservation if VETH is bridged to VLAN with DHCP.

Indeed, we have a nearly-opposite statement in the first caution box in the MACVLAN section of the docs.

LOL. @tangent, You're the one who pointed out RouterOS MACVLAN !== Docker MACVLAN a while back: viewtopic.php?t=198122&hilit=VETH#p1021128
It's possible they clarified in the MACVLAN docs based your commentary there... We now know it MACVLAN cannot be used in a container based on your doc link. Since MACVLAN's /ip/address belongs to the router, there be no IP to use in /container....

...

Also why DHCP stuff gets confusing... since the docker image needs a dhcp-client... but most expect "docker" will take care of the IP so they don't include dh-client or something. On RouterOS, it will only use the VETH's IP as the IP address inside a container. e.g. VETH does NOT query any bridged interface via DHCP to get the IP address to passalong– it use JUST what you type into VETH's IP only.

Since /container does respond to ARP, if you add/enable some dhcp-client inside the container, or change its IP container config via UI/shell. It work (assuming the VETH was bridged for the subnet used). I don't know all the rules if VETH will reassign IP if container is restarted, changed, etc – why it's best to set the right IP for container in VETH when setting up the container (and before starting it first time).

You can treat VETH the same as a ether1 etc ports. So it can use in your "main" (or only) bridge, and using vlan-filtering=yes. Possible to make a trunk (e.g. /interface/bridge/vlans as a tagged=), or, an access or hybrid port by setting a PVID etc. The same as any other ethernet port living in /interface/bridge/port.

True, there is only network interface allowed to each /container. But you can, largely, achieve the same by providing a VLAN trunk, theoretically. And, there are a couple mDNS containers floating around on the forum that take use a "trunk". But since this is not how "normal docker" works... a VLAN trunk might not work for "pre-built" containers like homekitbridge etc.

But you can use your "normal LAN" (or likely some VLAN), with a VETH if it's a bridge port in "main" bridge. There is no need for the seperate "docker" bridge shown in some /container examples, like Pi-Hole – there it just need to receive routed IP traffic for DNS, so it being isolated is a good thing. By homekitbridge etc DO need broadcast/multicast access to entire LAN with devices – so the separate bridge approach is just wrong.

The only exception here... is that you need to statically configuration the IP address for a VETH based on subnet/gateway of the untagged network. DHCP may work too, but you're likely better off configuring a static IP in VETH – since that IP get's "injected" into the /etc/host... files inside the container before it boots. This might mean you'd want to create a DHCP reservation if VETH is bridged to VLAN with DHCP.

1. how would this look like in a RB450GX4 setup where in my limited understanding it is not recommended to work with /interface/bridge/vlan section or the bridge vlan filtering checkbox on the bridge (and instead to use switch chip section /interface/ethernet/switch instead where you cannot control VETH ports that are added)
2. have already tried adding veth to main bridge with ip set on veth as one of unused IoT vlan scope address. that did not work from connectivity standpoint (not accessible via url )(Eventhough container starts fine and seen as listening on its port with the veth ip set)
3. so, your suggestion is to have IoT devices be issued DHCP address served off Main bridge interface (untagged by extension- as opposed to a Vlan interface hanging off the main bridge interface) with the VETH also now being in same subnet/address space?.
my problem with this is that am forced to get streaming/IoT all into one subnet and now have to find an mDNS to reflect this into my phone device VLAN.(my current mDNS container nicely reflects printer from Iot VLAN into home/office/guest VLAN and streaming ones to home/guest VLAN .so , have to find a new one now)

1. Yes, if using the "/interface/ethernet/swtich" way of configuration VLANs, you cannot "bridge" the VETH. You need to use the "Bridge VLAN Filter" method for VLANs. And, also correct, on some devices using the bridge vlan filtering will lose hardware offloading. But on RB450GX4, I'm not sure bridge hw offload is broken by using VLAN filtering, but dunno.

2. A /container default network will only deal with untagged packets, just like any other OS. If using bridge vlan filtering, and VETH is a port on it... the PVID is what going to control what's untagged to container via the VETH in bridge. So, if VETH is using IoT VLAN's PVID, the IP address should be in that range. The key detail however VETH is mapped in /interface/bridge/vlan, whatever VLAN is untagged is what you'd need to use in VETH. Keep in mind someone time the containers do not like changing the VETH IP after they've started – I don't know about HA specifically, but changing IP/VLANs/etc on same containers instance can cause all sorts of problems.

3. I'm not sure DHCP has much do about this, but I haven't looked inside HA. But the underlying issue is a lot of controlled items need some kinda broadcast or multicast discovery to find things (mainly mDNS or SSDP), so HA needs to be in the same LAN (or VLAN) where those things live to keep things simple. Assuming firewall isn't block inter-vlan routing, the HA should be able to add device from other subnet/VLANs. But discovery is limited to the LAN where HA container is running on. Why Mikrotik's example of a seperate bridge is kinda bad, since it likely not find all the common automation things since they typically found via mDNS or SSDP. And there is no simple "proxy" or "repeater" service to do that — technically possible with another mDNS repeater container and/or bridge filter and/or IGMP Proxy – but if you keep your automation and HA sever in ONE VLAN, you avoid all that. The UI/web/app uses unicast IP to access the server, so you could still access HA if it lived in some IOT VLAN.

Now, it be technically possible to modify the HA Dockerfile to add the vlan drivers, and any associate IP config for additional VLAN. But it's non-trivial to re-build HA container image unless you were familiar with docker/etc builds already. But if HA is given a trunk, it should be able to find devices on multiple networks directly IF the /container's VETH was configured as trunk on bridge (e.g. /interface/bridge/vlan tagged=veth-ha ...) thus no need a seperate proxy/reflector/IGMP things.

have requested support to provide sample configuration for vlan aware veth ports in a single bridge configuration with multiple vlans (from homeautomation perspective even the matter server is expected to be on same network as ha/devices)

I be curious what they say. Since the example in docs likely get you HA running, but not particularly usable for most automation. Or, make HA configuration a rather manual affair. The example like should show using the defconf's default bridge with VETH as a port IMO.

Once you have additional VLANs.... It could also be firewall rules that are getting in the way of things working. While VETH is essentially raw ethernet to container, all the normal IP etc traffic rules are still enforced on egress/ingress to a VETH.

here is support response till now and my response back to them:
Support:
***
/container mounts
add dst=/config name=ha_config src=/usb1/ha_config
/interface bridge
add admin-mac=78:9A:18:A9:E8:C7 auto-mac=no comment=defconf name=bridge port-cost-mode=\
short
add name=ha vlan-filtering=yes
/interface veth
add address=172.19.10.2/24 gateway=172.19.10.1 gateway6="" name=veth2
/interface vlan
add interface=ha name=vlan10.ha vlan-id=10
/container
add envlist=ha_env interface=veth2 logging=yes mounts=ha_config root-dir=/usb1/ha workdir=\
/config
/interface bridge port
add bridge=ha interface=veth2 pvid=10
add bridge=ha interface=ether7 pvid=10
/interface bridge vlan
add bridge=ha tagged=ha vlan-ids=10
/ip address
add address=172.19.0.1/24 interface=ha network=172.19.0.0
add address=172.19.10.1/24 interface=vlan10.ha network=172.19.10.0
***
my response:
in your config ,

a) would this type of configuration be applicable even for rb450gx4 ? (Reason i ask is remember reading in manual not to use bridge vlan filtering for this switch chip)

b) are there assumptions to the setup you have mentioned.

1.in your example , do you assume ether 7 on ha bridge to have all IoT devices and the main bridge to not carry any vlan10 traffic? is there any tradeoff that hardware offload would be disabled?

2. in your example, which bridge do you anticipate other vlans be (like home/office VLANs). if they are on main bridge, can vlan10 be made to reflect on the home/office VLANs in main bridge ? let me know what you think

Both @tangent and I, both wondered why Mikrotik always shows a separate bridge. @tangent write this up here:

Put the VETH on the bridge.

On this one...

a) would this type of configuration be applicable even for rb450gx4 ? (Reason i ask is remember reading in manual not to use bridge vlan filtering for this switch chip)

You may be right based on https://help.mikrotik.com/docs/display/ ... Offloading but I'm not sure that true in latest V7 versions. I don't use the rb450gx4 boards, so I dunno for sure.

Personally, I'd re-try the process using bridge vlan filtering, using the VETH as untagged port on your IOT VLAN in the bridge. And re-create the HA container. And see if the bridge you do actually lose the "H" on next to the ports. And check the speeds regardless to see if any different from before. In some cases, a lot of traffic has to go via the CPU anyway, so losing hardware offload may not be devastating (now if you a NAS or other high-bandwidth traffic within your network.... you'd want hardware offload). I say this, since I'm pretty sure there is NO good way to bridge a VETH to the hardware switch port.

If Mikrotik has some discovery proxy/repeater/etc, this be a lot simplier... As a separate bridge be fine if they did... e.g. since you could "copy" the discovery things to the HA bridge. But as it stands now... doing the cross-VLAN/bridge discovery (e.g. using SSDP, mDNS, etc.) all involve some tomfoolery today.

i was able to configure it with bridge vlan filtering on main bridge and get it to work.
Hardware offload turned off. switching speeds(same vlan iperf) dropped from about 950 to 880 Mb/sec .Routing speeds (Across vlan iperf) remains the same ~740 Mbps(as expected).
for VETH-ha, had to make pvid=<iotvlan> and add it to untagged ports(dynamically done by ROS) for the vlanid to get it to work

Followup question: i see that ROS containers can have multiple addresses

"Starting from 7.11beta5 version multiple addresses and ipv6 addresses can be added:
interface/veth add address=172.17.0.3/16,fd8d:5ad2:24:2::2/64 gateway=172.17.0.1 gateway6=fd8d:5ad2:24:2::1"

wondering if i have 2 vlans(Streaming tagged and IoT tagged VLAN) that i want HA to discover for devices, how would configuration look like. what would be PVID of the veth interface. is there a different way to configure it?

You can use multiple IP addresses, true.

But they are still in same VLAN/bridge as the VETH is using. So it's NOT a way to get into multiple Layer2 VLANs.

thanks Amm0/tangent for your replies.