Wireless Access

Hi i am trying to figure out how to get my bridged vlan to pass client info to the controller if its even possible. They pull an IP fine and have internet access so its not that they arent getting one. In the end i will have it tunneled and set up correctly but this is how i need to keep it for the migration process. This is at a school the admin and academic used to be on an instant setup but have since been moved to a controller. Now the bridged academic network will not show the ip of the client. I have attached a picture of the setup. I am not sure what i am missing. I have created rules on the fortigates to allow traffic between the networks allowing the academic 192.x.x.x to talk to both the controller and the aps subnet but it didnt help. Any ideas?

With a bridged WLAN, the switchport that the AP is connected to needs to have a tagged VLAN (trunk port with that VLAN allowed) matching the Virtual AP Vlan you have your client assigned to.

It does The switch ports are trunk with the native being APs Vlan 1000 and the Academic Vlan 2 as a member.

Is the Virtual AP VLAN 2?

Like this?

Yes.

Last thing:

What is the default gateway for VLAN  2?  Do your switches have that VLAN trunked all the way through to the router for VLAN 2 and does the router have a helper address on that interface pointing to the DHCP server?

Bridged VLANs are not tunneled back to the controller and require your switched infrastructure to provide connectivity.

The fortigate shown in the picture is both the router and dhcp for the academic network. I forgot to add where the controller was so i attached a new picture.

Can you plug into an access port on the juniper that is on VLAN 2 and get an ip address?

Yes the clients connectivity is not the issue everything is working fine. Its just that they dont show the ip in the controller.

One client of mine is having the same issue, all clients(155) on the controller are showing as 0.0.0.0, the APs forwarding mode is bridge too.

All clients can authenticate and have full navegation, why the APs are not giving back the  IP/ARP table to the controller ?

Controller is a VMC on 8.2

I could never get it to show the IP no matter what i did with bridged fowarding. Was told it was a limitation of bridged setup. Finally abandonded that and figured out how to change the bridged ssid to tunneled for my setup. What is the reason you have it bridged?

not sure you had cpsec+campus bridge or RAP, but the latter works for me. Here is a bridge user on a RAP using eap-sim, with dhcp allocated by the poe switch powering the AP, it shows the correct IP:

(c7010) #show user-table
172.16.100.8  9a:fb:e2:11:22:33  1666070100000001@wlan.mnc001.mcc666.3gppnetwork.org  bridge-nat-whatsapp  00:00:00    802.1x            ap315    Associated(Remote)  rap-bridge-dot1x/c8:b5:ad:11:22:33/a-HT  dot1x-srv08  bridge              

why to use bridged ? it's a somewhat contentious subject and there are quite a lot of unsupported things compared to using Instant. But the reasons that often come up are the so called "local break out" (e.g. the core does not have to carry the load) and reusable IP address space (no core DHCP required).

tl;dr; These days using controller based RAP + bridge is a hard justification against using Instant, but it does work if you need it to.

I did have others setup with bridge that work just fine.

The reason to use the bridge for this client in specific was because the vlans of the wireless did not exist on the virtualization hypervisor.

However, on this month will be necessary to implement RAP with others APs, so is mandatory to create the vlans now, and the bridge setup will change to tunnel.

But this problem with IPs look like more a bug than a limitation, I cant see why the APs having the ARP and IP tables, performing the authencation and etc are not giving back to the controller this kind of basic information.

And about the limitation of the bridge setup, I think is more like a question about Aruba is not willing to invest on the code and on this kind of implementation, because the APs on Instant Mode are able to do almost everything that a controller do, why we will loose functions if the traffic dont go to the controller ?

If you thing there is a bug, please open a TAC case so that they can look at your setup.

"And about the limitation of the bridge setup, I think is more like a question about Aruba is not willing to invest on the code and on this kind of implementation, because the APs on Instant Mode are able to do almost everything that a controller do, why we will loose functions if the traffic dont go to the controller ?"

Aruba's Guidance is to have everything tunneled to a controller and if you need a site that is bridged locally you should use instant.  It is less costly to run things on an IAP without the cost of a hardware controller and licenses if you want everything bridged.  That makes much more economic sense for the customer.  If you go against that guidance, it is more costly.

I understand your point Jopseh.

But this guidance exist because as the system is as is, not the other way around, (the system is because of the guidance). On this case(bridge setup+VMC) there are instances where you dont need all the site to be bridge, only particular ssids, and is more costly to have more than one, and differents, managament/monitoring enviroment(instant and ArubaOS) just because you will need a fully capable/enabled bridge setup.
And when I say that Aruba is not willing to "invest" on the code for this case, is because this kind of change is costly and not priority comparing to others more relevant needs, I guess.

I would like to open the TAC case, but because of the circustances(the next weeks future change bridge to tunnel, the client was convinced of the necessity to create the vlans on the Hypervisor network because of the RAPs) and the workload and limitations of the client, I prefer not create this stress.

But I am pretty sure that this behavior is a ''bug'', because  there was others instances(otherds clients/networks) where I did implement others ssids as a bridge and never lost the visibility of the wireless clients IP.