Here's the concept: I can configure a Juniper switch port to use MAC based dot1x, and Clearpass, so that it assigns devices to the proper VLANs. I'd like use this setup with the "expansion ports" on an AP-303H.
As an example, If I plug a small 5-port POE unmanaged "dumb" switch into a dot1x Juniper network port, then I can plug an AP-303H in to the dumb switch, and it gets assigned to our AP VLAN, and tunnels its wifi traffic to our Mobility Controller.
I can plug an Avaya VoIP phone in, and it gets assigned to the voice_vlan, and gets dialtone. I plug in a student or staff wired computer, and it gets put on the proper Internal or Student VLAN.
From the Juniper switch point of view, it sees all the MACs of all these devices, passes them to Clearpass for VLAN assignment, and then internally tags those MACs for the specified VLANs. The effect is that I can have all these devices simultainiously connected to the one Juniper port, and have them all be on different VLANs.
Can I configure the AP-303H so that its E1, E2, and E3 ports work the same way, and use it in place of the dumb switch? That is, I don't want to specify _any_ VLANs for any of the device ports on the AP, because I don't want the AP adding tags for those VLANs. Instead, I want AP to take all the packets from any item that is plugged into one of its ports, and switch the packets from that MAC out its E0 "uplink" port. The AP shouldn't do any VLAN tagging, because the Juniper switch port will do that for all the packets it sees. And, vice-versa for the packets that the Juniper port feeds to the AP's E0 port: the AP should switch them to E1, E2, or E3 based on the MAC. (Of course, only port E3 has POE, so the VoIP phone can only work if it plugs in there, but otherwise, any device should work on any port.)
Basically, I want the AP to treat its expansion ports as if they are an unmanged switch.
Is this configuration possible for the AP-303H?
How do I get it to pass along the packets from its external ports without trying to put 802.1q tags on them, and without passing them down its tunnel to the Mobility Controller?
In the 303H scenario, where does the Juniper switch reside?
The Juniper port is on the floor's access switch; it was a regular office wall jack that I need to plug 303H into, to expand our wifi coverage. Usually our wired ports are set for dot1x on the juniper, so that any connected user user devices go into the proper VLANs. (But this is just device recognition via MAC auth, not full-blown 802.1X auth with a username and password.)
For our ceiling-mounted APs (the bulk of our fleet) we usually config the relevant switch port (also on this same Juniper) just as an Access port on the AP VLAN, as we're mostly using AP-215 and AP-315 that don't have extra ports. For those APs, it is simple to just set the port to the AP VLAN and use tunneled mode.
However, for the AP-303H's that I've used so far, I've had to set the port to be in trunk mode with all the necessary VLANs for the wired prot, and with the AP VLAN as native, so that an AP can find the controller as soon as it is plugged in.
However, since the dot1x on the Juniper can identify the AP, I don't need the port to be native or access on the AP VLAN; it can just be a default dot1x port, and then detect the AP.
(Note that in my example, the "dumb switch" is just for proof-of-concept of having a bunch of stuff hit the same port without needing to tag any of their packets--not using the dumb switch at all in the real deployment.)
SO: The present case is a single wall jack that goes to the Juniper switch, and the switch does MAC-based dot1x to decide what VLAN devices go into. But, with just the single port, it is usually just one device at a time, or else a VoIP phone with a computer plugged into it.
Adding a dumb switch to this Juniper port lets me plug in several things at once, with the port sorting which VLAN goes with which device, packet by packet.
I'd like it if the 303H could plug in to this same port and "just work", with the AP being recognised and sent to the AP VLAN, and all other things just going to the Juniper port that the AP is plugged in to.
The first stage works, because if I plug the 303H in, it gets recognized and assigned to the AP VLAN and tunnels to the controller, so wireless access works properly.
But I don't know how I might configure the other AP ports so that packets from them do not get tagged, and also so that these packets don't go down through the tunnel to Mobility Controller, but hit the local Juniper port.
Is there a setting to have it tunnel all the AP and wifi client traffic, but bridge all the wired port traffic? I can make that happen if I specify VLANs for the wired ports, but not if I want to leave their traffic all untagged.
Maybe I'm missing something easy: basically I want the AP to just output anytraffic that comes in P1-P3 out via P0, to the Juniper switch.
Essentially, the AP is connected to a switch port that acts as if it is several different ports, one port per incoming MAC.
The wired port profile applied to the E1-E3 ports is what you're looking for. This determines whether it's tunneled of bridged, trunked or untagged, etc.
Thanks very much!
So if I just set them all to the same arbitrary VLAN ID (e.g. 1) and mark them as access ports, and set the E0 to tunneled (for my AP traffic) and the rest to bridged, it should work basically as a dumb switch, yes? That was my hope. First try didn't work, but I'll double-check the "tunneled" settings for E1 - E3, and maybe pick a VLAN other than 1.
If all the ports are access rather than trunk, I think whatever VLAN the 303H thinks they are shouldn't matter, because it won't be tagging any packets, right? But is it best if I pick, say, my AP VLAN, or an unused VLAN? Does it in fact matter?
@skbohrer wrote:Thanks very much! So if I just set them all to the same arbitrary VLAN ID (e.g. 1) and mark them as access ports, and set the E0 to tunneled (for my AP traffic) and the rest to bridged, it should work basically as a dumb switch, yes? That was my hope. First try didn't work, but I'll double-check the "tunneled" settings for E1 - E3, and maybe pick a VLAN other than 1. If all the ports are access rather than trunk, I think whatever VLAN the 303H thinks they are shouldn't matter, because it won't be tagging any packets, right? But is it best if I pick, say, my AP VLAN, or an unused VLAN? Does it in fact matter?
If the port is marked access, I don't believe it will accept tagged traffic.
The Juniper switch downstream between the 303H and the client devices will need to handle the EAP/802.1X component to authenticate users. Then it's essentially a trunk (if multiple VLANs are needed) between the 303H and the Juniper, and out the uplink side of the 303H to the wired infrastructure. VLANs shouldn't be arbitrary, they'll need to match up on both sides of the 303H.
Ah, so if any of the devices that get plugged into the 303H try to tag their traffic (e.g. the VoIP phones sometime do that) then the phone has to have a trunk port to accept those packets? I'm not sure what the basic dumb switch does if you feed it tagged packets, but I assume it just passes them through.
My idea for "arbitrary" VLAN was that if I just want the AP-303H to pass packets without messing with them at all, then it wouldn't need to know what VLAN it was actually connected to, as it would leave all its packets untagged. But, you are correct that it would need all its ports on the _same_ arbitrary VLAN, as otherwise it would feel the need to tag any packets that appeared to cross between different VLANs.
I wonder if I tell it has trunk ports on all VLANs on E3 and E0 if it will then accept and pass through potential tagged packets, without needing to be set for the specific VLANs. We use a different voice-vlan on each floor, and the switches know which one they are using, but I'm hoping to not have to tell every 303H which voice-vlan it is on.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.