I want to change a customers vlan setup, without going onsite. How can I do this without loosing connection to the unit?

This customer has a hAPac as single access point in their office, also serving as a local switch. It's connected to a RB450g serving as a router. Now their extending their office (more than double the area), and need more APs. So I would like to setup CAPSMAN. If I manage to convert the existing access point from stand alone to caps remotely, I can send the new preconfigured APs by mail. If not, I'll need to get onsite. I have sstp access to the RB450g, and access the hAPac by IP through that tunnel.

Trouble is, they use a company wlan and a guest wlan. Hence the port connected to the RB450g has two vlans. Current setup is two vlans with eth1 as masterport. Vlan-guest, wlan1-guest and wlan2-guest are members of bridge-guest. Vlan-int, wlan1-int, wlan2-int and eth2 are members of bridge-int. Eth2 is masterport for eth3-5.
To make wlans managed by CAPSMAN use vlan, the vlans need to use the bridge as master, not the ports. Hence there is a need to change vlan masterport from eth1 to a new bridge-trunk. Also there will be need to configure vlans on the switch in order to get this working.

How can this be done without going onsite? I don't see how to get through this without loosing connection to the unit.

The way I normally would do this is to create a wlan-config that I connect to, then configure the switch and bridge while connected to wlan. Then connect with cable to configure wlan. That approach can't be done when I'm not onsite.

I want to change a customers vlan setup, without going onsite. How can I do this without loosing connection to the unit?

Mail them a pre-configured unit.

It's possible but can be a bit dicey. It all comes down to planning. This can be made extensively easier if you can get a second physical connection between the two RouterBoards. That second connection could be setup with say a /30 and you could use that IP to reconfigure the rest of the unit.

If that's not possible then you're looking a dicey change.

You can leverage scripting to do a larger bit of reconfiguration. This is helpful if normally you'd drop connection before you would normally finish. You upload the script to the RouterBoard and launch it from their all the while hoping you got it right enough to at least be able to connect again.

I can ask them to connect a second cable, but as this unit only has one switch chip, it's still a major chance of loosing connection when doing the switch config.

Just two weeks ago I went to a customer to setup two wAPac's and a hAPac as capsman with vlan. The customer had a rb750gl as router, with no vlans configured. Before I went there, I downloaded the 750 config, and put it into a test-750 I have at home. Then I configured vlans, tested that they were working as expected, exported, and wrote a script based on the export. Then I reverted to test-750 back to the customers running config and tested that the script worked as expected. Then I configured the accesspoints with capsman, and tested that everything was working.
So, onsite with the customer, I ran my script on their 750 and lost connection. I had to reset and restore from backup. Then I read the script line by line, and manually did what the script said in winbox. That worked.
With the vlans configured on the router it was time to connect the AP's. First the hAP running capsman. It started up fine and wlan was working and I could connect to it with winbox. Then I connected one wAPac. At the very moment it was finished booting all ip traffic through the 750 stopped. Neither the hAP or pc's connected to eth2 (port without vlans) could ping the router nor each other. I could, however login to the hAPac if my pc was connected to its wlan interfaces. And I could login to the wAPac if my pc was connected to its wlan interface. That way I could see that the wAPac found capsman on the hAPac. The wAPac had the wlans running. But the capsman did not list the wAPac as a CAP. And, the wAPac chose the same frequencies as the hAPac was using.
I disconnected this wAPac. Just a few seconds after, everything else in the network started working again.
Then I tried the other wAPac - exactly the same problems.

Then I put my test-750 between the wAPac's and the customers router - network problems gone, but both wAPac's still insisted on using the same frequencies as the hAPac.

After spending 10 hours on trying to connect three preconfigured accesspoints in the customers network, I swapped the wAPac's for two hAPac's I just happened to have in my car. They worked as expected.

Conclusion: I will not configure vlan remotely by script and hope I will be able to connect! Remote config must be done in safe mode, hence the steps has to be done in an order that makes sure I'm not getting disconnected.

Just pull the second port out of the switch chip and make it a point to point routed link. (master-port=none)

Also VLANs are far less of a chore in the 6.41rc.

The way I read the new bridge/vlan implementation, the hardware offloading will be disabled once vlan is enabled on most devices. Hence anything vlan will be software. I don't think that will be a good idea.
Also I have no idea of how to do the setup when a unit should run be configured as a caps with multiple SSIDs (requires vlan under bridge) with tagged vlans on one port AND the other ports configured as untagged for one of the vlans unless the vlans are configured in the switch menu. So we're back to the same issue.

Setting one port as standalone (master-port=none) doesn't really solve anything. I will need to change the switch vlan setting for that port and switch-cpu, and once I do change one of those settings, the unit will be unreachable to do the other setting.

However, I do think I have a solution.
1) ship new APs. vlan preconfigured, but wireless (caps) not configured
2) when customer have connected them, configure a config wlan on the existing AP. Don't put it in a bridge. Give it an IP outside all used subnets.
3) configure wlan on one of the new APs as client, connect it to the config wlan, give an IP in the config subnet range
4) configure routing to the config subnet via the AP acting as client
5) connect to the existing AP using its ip of the config wlan
6) do the ports configurations
7) connect using the IP of cabled interface
do the wlan config

Nope, not at all. If you set master-port to none on a port it is no longer part of the switch-cpu bridge and will not be effected by the cut-over. It is just a routed port on the router. In the new bridge methodology you simply don't make that port a bridge port until you have restored connectivity to the bridge based VLAN SVIs.

As far as HW offloading, my understanding is the goal is to leverage the underlying hardware for you. This means you can do VLANs on a 750Gr3 (hex, no VLAN support in switch chip) the same way you would on a CRS (switch menu) and RouterOS dynamically toggles the features on and off for you.

As far as how to do VLANs, the bridge area of the wiki contains how to do them and regardless anything past 6.41 is going to require it when it goes GA so it probably wouldn't hurt to migrate now.

/interface bridge=br1 vlan-filtering=no pvid=1
/interface bridge port add bridge=br1 interface=ether1 pvid=11
/interface bridge vlan add vlan-ids=1 untagged=br1
/interface bridge vlan add vlan-ids=11 untagged=ether1 tagged=br1

If you read the wiki, the table shows that offloading will automatically be disabled once you make use of vlan, unless you are using a crs3xx.
https://wiki.mikrotik.com/wiki/Manual:S ... Offloading

I also though taking a port out of switch would make me able to do switch vlan config without loosing connection. Then I locked my self out. Maybe this behavior is different, depending on which unit / switch chip / ros you are using.

That's a listing of what they have currently, my understanding is the trend will be to take everything in the switch chip menu and move it to hw enabled bridges over time.

I hope so too. But as off today that is not the case.

Yup, all depends on your CPU usage levels I suppose.