I took remote connection to client computer and gained access to the Hex S
Added the vlan_bridge interface to the /bridge vlan > tagged port.
Was still able to ping and it dynamically displayed as tagged ports. I waited a minute as device was still accessible, took it out of safe mode. then re-enabled safe mode via winbox.
Then I modified the bridge_interface PVID (vlan-filtering=yes), I had PVID set to 10 (untagged network). I changed it back to default “1”
This broke my connection and lost ping/access to mikrotik Hex S. Even in safe mode, device not coming back. Not seeing it via MAC address neighbors. Just screwed self and now client going to be upset. port #5 is untagged as outputs POE 48v to a VOIP phone, other switch ports are tagged as ethernet running down to a powerbox to light up engenius AP’s
I’ll probably now need customer to remove this Hex S from the outdoor enclosure it is in and perform a reset.. and some how walk them through for me to restore the config file I saved on device.
I also tried untagging port at upstream switch to see if. gain access. Nope
I’m assuming I broke it as I didnt add /interface vlan vlan-id= to the bridge_interface… as will need inter-vlan
If you haven’t disabled the mac-server, the client doesn’t need to excavate the device from the outdoor enclosure and can connect using Winbox to its MAC address rather than the IP address, on any port except the WAN by default. If, on top of that, the client has some other internet connection (a mobile one), you can use e.g. TeamViewer to do the necessary configuration yourself remotely rather than instructing the client what to click.
Mac-server is available - i used mac address to connect prior when I was onsite and locked myself out before.
Switch is not showing within winbox as mac neighbor. I’ll need client to go with laptop and unplug the phone (this is in port) and connect laptop via ethernet cable (just swapping with phone). As computer I’m remotely connected onto at moment is into the primary/core switch (same switch hex S hangs off). But I believe will need to be directly connected to Hex S for mac-neighbor to display.
Then I should be able to help via TeamViewer.
no cell reception at client site as a remote RV campground - hence need for WiFi throughout - was entire project. 90% of everything is working. Even MikroTik Hotspot setup with portal and Userman vouchers… Just the far side of campground was needing to use a PowerBox as no electrical available. This is problem - and making me feel defeated with the new vlan method. I’m use to just doing Trunk VLAN (Router on stick). Never done vlan on mikrotik as intended to act as a switch.
so for configuration sake it appears I need following:
/interface bridge vlan_master
add all my physical interfaces that need to be tagged, as tagged ports
add vlan_master bridge as tagged member
add untagged port that will be access port
add the list of VLAN ID’s..
within /bridge ports
add PVID=10 to the physical interface (as be access port mentioned above)
vlan_master (primary bridge), vlan-filtering=yes (was on before)
vlan_master PVID=10 (primary vlan ID and same vlan ID that is default for untagged traffic)
do I still need to:
/interface vlan
create ALL vlans to the vlan_master interface??? Or only create the untagged vlan (vlan 10)
I should of did a config export really fast prior to making changes and then lost access. Just been stressful and felt defeated.
almost about to pull trigger on 3 Netonix switches.. and call it a day. as need 48v and 24v. (hex S was doing 48v as phone attached), then downstream from that was the PowerBox that was doing 24v to 2 AP’s to handle far side…
I can’t confirm that.
I have a wAP ac configured in the way, that two vlans enter tagged in eth1 and leave to both wlan1 and wlan2 tagged as well.
The vlan untagging is done based on Access List on the wlan interfaces.
And only for one of the vlans I have a vlan interface on top of the bridge.
The same true for virtual interfaces - prior to setup mentioned above I had one of the vlans end on two virtual wlan interfaces, again with no connection to the bridge itself.
Both ways it works as intended.
So either this thing is device-dependent, or this doesn’t apply to wireless interfaces, as they can turn out to be that connection to cpu themselves.
What is the current timeframe? I’d need a drawing to tell you the right configuration, I’m unable to understand it clearly from your various posts, and I need to get moving in half an hour or so.
OK. Hope I haven’t forgotten anything. I don’t know into which of the VLANs you want to place the management IP address of the hEX S itself, so I refer to it as mgmt-vlan-id below. Adjust the name all-vlan-bridge and other names as you need.
Thanks Sindy! This is pretty much what I will have after fact. my missing component was I forgot (was naive to it) to have the vlan_master bridge interface set as tagged
you list 2 different add statements. I only had one large interface bridge vlan. Where I listed all vlan ID’s, and all the tagged and untagged. Will it let me create two? I create the untagged vlan ID seperate
Note: mgmt of device I want on the primary subnet which is VLAN 10 - which is also untagged. SO that is probably why I lost access to device as even though eth1 is trunk port, ingress is tagged.. I had interface=all-vlan-bridge PVID set to 10 and was working just fine. but when I changed that bridge PVID back to default ‘1’. I lost connection and it never rolled back.
I will create a secondary mgmt / access IP address and create the /interface vlan vlan-id=mgmt-vlan-id (88)
/ip route add dst-address=0.0.0.0/0 gateway=ip.addr.of.rb1100.in.vlan.10
(if the own IP address of the hEX S is in VLAN 10 of course)
All the VLANs on one line must have the identical tagged/untagged settings for all ports, and all member ports of the same VLAN must be on a single line. Which means that each VLAN with at least one untagged (access) port must have its own line. Hence two lines, one listing all the VLANs which have all member ports tagged, and an individual line for VLAN 10 which has one port untagged.
Well, that was the other way how to do it, which is out of the usual thinking about switches. On a normal switch, you cannot have tagless frames inside the switch. Here you can - if you set bridge’s pvid to 10, ingress packets tagged with VID 10 get untagged as they enter the bridge. So in that case, you attach the IP configuration for VLAN 10 directly to the bridge, not to /interface vlan.
In that case, the complete configuration would look as follows (differences highlighted, assuming that the IP configuration should stay in VLAN 10). /interface bridge
add name=all-vlan-bridge vlan-filtering=yes pvid=10
All the VLANs on one line must have the identical tagged/untagged settings for all ports, and all member ports of the same VLAN must be on a single line. Which means that each VLAN with at least one untagged (access) port must have its own line. Hence two lines, one listing all the VLANs which have all member ports tagged, and an individual line for VLAN 10 which has one port untagged.
Well, that was the other way how to do it, which is out of the usual thinking about switches. On a normal switch, you cannot have tagless frames inside the switch. Here you can - if you set bridge’s pvid to 10, ingress packets tagged with VID 10 get untagged as they enter the bridge. So in that case, you attach the IP configuration for VLAN 10 directly to the bridge, not to /interface vlan.
In that case, the complete configuration would look as follows (differences highlighted, assuming that the IP configuration should stay in VLAN 10). /interface bridge
add name=all-vlan-bridge vlan-filtering=yes pvid=10
But you can have only a single VLAN-ID untagged on a bridge of course.
This was the logic I was missing. I was struggling completely understanding prior to configuration as this is new to me since 6.41. I had general Idea prior my implementation but missed the aspect of including the ‘all-vlan-bridge’ interface as tagged port. Also now I know why need seperate /interface bridge vlan lines… I will work to implement this once I regain access to this mikrotik. Then I should be able to successfully configure the PowerBox Pro & everything will be working.
Only part of network (AP’s) that are NOT working are the ones associated to the MikroTik devices that I mis-configured. Anything attached to the Cisco switch is working fine.
I will add back PVID=10 to the all-vlan-bridge interface and correct the /bridge vlan settings.
Will this effect the eth1 being a trunk port? Considering its going to untag vlan 10 on ingress? What about vlan 10 traffic egress, that’ll re-tag and so the upstream Cisco will ingest it back as tagged traffic?
I’ll also create a secondary mgmt IP and set as a vlan (tagged). Just incase. As I think this will be fail-safe access if connectivity gets blipped as I make config changes.
Well, bridge can be a bit confusing due to it’s twin personality I already described in one of my previous posts.
So, if bridge is declared untagged (by setting PVID), then it’s the interface personality of bridge that acts as untagged, while switch-like personality of bridge still carries those packets tagged. Hence ether1 will carry those packets tagged as it exchanges packets with switch-like personality of bridge, not interface personality of bridge.
This is exactly the reason why, if one dives into VLANs, it’s better to declare bridge as tagged (by not defining PVID) and explicitly use /interface vlan whenever routerboard device needs to interact with that VLAN. For example: if you decide to change PVID of “untagged” bridge, then IP address associated to bridge will move over to another VLAN where it most probably doesn’t make any sense. This can happen with /interface vlan, but if name of this device resembles VLAN ID in some way, mistake is much easier to see (and avoid).
Thanks for this insight! Clears up the logic behind it in my head (made it click per say)…
I’ve yet to regain access to the Hex S device - Client unavailable for me. Hopefuly i Will regain using mac-neighbor and then I should be able to just /interface vlan vlan=10 name=mgmt-vlan interface=all-vlan-bridge
and it will regain access. as I set the bridge PVID=1 (returned to default) as before I had it PVID=10, which made the bridge interface itself untagged and why I had access.
I will create a secondary IP address on device in seperate vlan as well and assign appropriately
Untagging and tagging work symmetrically between ingress and egress on the same port, and depends on port pvid and bridge pvid combination. So if ether1 has pvid=1 and ether5 has pvid=10, the behaviour depending on pvid of the bridge will be the following:
bridge pvid=1:
on ether1, frames tagged with VID 10 stay tagged as they ingress to the bridge, and stay tagged as they egress from the bridge to the wire.
on ether5, tagless frames get tagged with VID 10 on ingress so become tagged on the bridge, and frames tagged with VID 10 get untagged on egress so they end up tagless on the wire
bridge pvid=10:
on ether1, frames tagged with VID 10 get untagged as they ingress to the bridge, and get tagged as they egress from the bridge to the wire. On the bridge itself they are tagless.
on ether5, tagless frames stay tagless as they ingress to the bridge, and stay tagless as they egress from the bridge to the wire.
In either case above, the line with vlan-ids=10 in /interface bridge vlan must follow the tagged/untagged membership of all ports involved as specified in /interface bridge port, so to stay consistent with the example above:
I am in line with Metod regarding this, I prefer to have everything tagged on the bridge itself like in the normal world of switching and set the pvid of the bridge to same unused VID, because handling one VID in a specific way is confusing. There are very special cases where this makes sense but this is not one of them.
This would be wrong because 192.168.88.251/24 would end up attached to the bridge itself so in VLAN 10. If you want it to be in VLAN 88, the last line must be /ip address=192.168.88.251/24 interface=vlan-mgmt.
When relying on Winbox to fix errors done on VLAN config: don’t. VLAN configuration, either done on bridge or switch chip, is L2 config and it is easy to cut your self from MAC winbox, which is L2 as well so VLAN config does affect it.
Default configuration limits MAC winbox access to interfaces, listed as members of /interface list LAN (and by default, that’s only bridge). So it is essential to add all VLAN interfaces (defined in /interface vlan) to this interface list until L2 configuration is done and verified. After that, when management access over IP (ssh, winbox, wahtever) is verified, one can remove excess VLAN interfaces from LAN list.
@Sindy - I will work to do regular bridging method as you have described. Set the ‘all-vlan-bridge’ interface PVID=1 or 3999 (unused vlan), then /interface bridge vlan i configure my vlan-ids and port assignment as well as you outlined.
I still need access. .hopefully will have regained by this evening or tomorrow morning. Hopefully direct connecting via port #5 (PVID=10 untagged) - this is where the VOIP phone was connected. Going to have client connect laptop to that ethernet cable by disconnecting phone. I believe winbox will detect device via mac address… from there I can remotely make the changes via TeamViewer (connect via wifi and set ethernet tcp/ip address without default g/w)
Metod’s warning is a valid one: I worked with the idea that you’ve kept the original bridge from the default configuration, which is a member of /interface list name=LAN, and have only renamed it. But if you have deleted it and/or moved all member ports away from it, there is no way to connect to the mac-server, and you’ll need an USB-to-serial adaptor (and maybe another one for the PC) and a null-modem serial cable to get in again (or a reset to factory default configuration, depending on what is easier to handle).