Controllerless Networks

This is a remote site I'm experimenting with, so I'm trying REALLY hard not to accidentally cut off access to the APs.

The network runs off of an Aruba 2930f switch, configured flat on VLAN1 for the moment. No routing. Main ISP router is plugged into port 1. Second ISP router is plugged into port 24.

Step 1 of this little side project is to try establishing a segregated Guest Wireless network that feeds from the second ISP.

To that end, I've created VLAN200 untagged on ports 20 through 24. Ports 20 through 23 are also tagged on VLAN1. The switch picks up a DHCP address from the second ISP router on this VLAN, and I've configured an IP helper address for the ISP's DHCP server (not pingable).

Those three ports have AP-505s plugged into them and have static IPs with the management VLAN set to VLAN1. The Virtual Controller does not have a separate IP assigned.

So, I wanted to keep things simple and use the regular 'Magic Network' to do a standard NAT through an IP address assigned by the second ISP's router. That doesn't seem to be happening. As far as I can tell, the APs are still trying to route the traffic through their Static IPs.

I'm pretty sure I could set the APs to DHCP, remove the VLAN1 tags on their ports, and the setup would work, but I would VERY much like to retain management access to the APs from my remote computer. It doesn't have a second NIC, and going through setting up another PC on that VLAN or trying to route is just so tedious... ;)

I know this is a little non-standard, as the 2930f can't do Virtual Routing, but is there something elementary that I'm missing?

If this is successful, Step 2 will be to try setting up a full access WiFi on VLAN1. Then properly separating out VLANs for their respective roles.

You can't use magic VLAN for that setup...nor do you need to since the APs have access to VLAN 200 and can drop clients on that network. Based on your current setup, put the APs on untagged VLAN 1, tag VLAN 200, drop guests in VLAN 200 and let that device handle DHCP for guest clients.

This is a remote site I'm experimenting with, so I'm trying REALLY hard not to accidentally cut off access to the APs.

The network runs off of an Aruba 2930f switch, configured flat on VLAN1 for the moment. No routing. Main ISP router is plugged into port 1. Second ISP router is plugged into port 24.

Step 1 of this little side project is to try establishing a segregated Guest Wireless network that feeds from the second ISP.

To that end, I've created VLAN200 untagged on ports 20 through 24. Ports 20 through 23 are also tagged on VLAN1. The switch picks up a DHCP address from the second ISP router on this VLAN, and I've configured an IP helper address for the ISP's DHCP server (not pingable).

Those three ports have AP-505s plugged into them and have static IPs with the management VLAN set to VLAN1. The Virtual Controller does not have a separate IP assigned.

So, I wanted to keep things simple and use the regular 'Magic Network' to do a standard NAT through an IP address assigned by the second ISP's router. That doesn't seem to be happening. As far as I can tell, the APs are still trying to route the traffic through their Static IPs.

I'm pretty sure I could set the APs to DHCP, remove the VLAN1 tags on their ports, and the setup would work, but I would VERY much like to retain management access to the APs from my remote computer. It doesn't have a second NIC, and going through setting up another PC on that VLAN or trying to route is just so tedious... ;)

I know this is a little non-standard, as the 2930f can't do Virtual Routing, but is there something elementary that I'm missing?

If this is successful, Step 2 will be to try setting up a full access WiFi on VLAN1. Then properly separating out VLANs for their respective roles.

Or manually define it in the AP using a local DHCP scope? I would say the intent of the ISP would be to only provide their addresses to one or two clients per location, or a NAT-capable router. In this case, the ISP's router isn't providing local DHCP. It's coming from another server upstream.

You can't use magic VLAN for that setup...nor do you need to since the APs have access to VLAN 200 and can drop clients on that network. Based on your current setup, put the APs on untagged VLAN 1, tag VLAN 200, drop guests in VLAN 200 and let that device handle DHCP for guest clients.

This is a remote site I'm experimenting with, so I'm trying REALLY hard not to accidentally cut off access to the APs.

The network runs off of an Aruba 2930f switch, configured flat on VLAN1 for the moment. No routing. Main ISP router is plugged into port 1. Second ISP router is plugged into port 24.

Step 1 of this little side project is to try establishing a segregated Guest Wireless network that feeds from the second ISP.

To that end, I've created VLAN200 untagged on ports 20 through 24. Ports 20 through 23 are also tagged on VLAN1. The switch picks up a DHCP address from the second ISP router on this VLAN, and I've configured an IP helper address for the ISP's DHCP server (not pingable).

Those three ports have AP-505s plugged into them and have static IPs with the management VLAN set to VLAN1. The Virtual Controller does not have a separate IP assigned.

So, I wanted to keep things simple and use the regular 'Magic Network' to do a standard NAT through an IP address assigned by the second ISP's router. That doesn't seem to be happening. As far as I can tell, the APs are still trying to route the traffic through their Static IPs.

I'm pretty sure I could set the APs to DHCP, remove the VLAN1 tags on their ports, and the setup would work, but I would VERY much like to retain management access to the APs from my remote computer. It doesn't have a second NIC, and going through setting up another PC on that VLAN or trying to route is just so tedious... ;)

I know this is a little non-standard, as the 2930f can't do Virtual Routing, but is there something elementary that I'm missing?

If this is successful, Step 2 will be to try setting up a full access WiFi on VLAN1. Then properly separating out VLANs for their respective roles.