Re: Cisco port config for AP - DHCP lease Native VLAN requirement?

mac1234 · ‎08-27-2018

I am currently migrating from Cisco access switches (3750's) to Juniper access switches (ex3400's). I have a 4402 controller with many AP's operating in local mode. I am simply trying to understand the AP behavior I am seeing as I do have a working config. I was hoping someone could analyze the below and offer insight into what is happening.

On my cisco switches, the interface configs for my AP's are as follows:

interface GigabitEthernet1/0/2
 switchport access vlan 20
 switchport mode access
 no mdix auto
 spanning-tree portfast
 spanning-tree guard root

I plug AP into the interface, it pulls an IP address from DHCP (windows server on another vlan) and associates with the WLC no problem.

Now on Juniper switches, you configure interfaces as either access or trunk just like with cisco. So my interface config on Juniper is set as an access interface and it is assigned to vlan 20. I basically match the Cisco interface config show above.

The problem however is this: when I plug the AP into the Juniper switch, the AP cannot attain an address via DHCP. Now, worht noting is other devices, ie Computers, printers, etc, can receive DHCP addresses just fine, so DHCP config is working, just not for AP's.

After some research, to fix this issue, I have to set the Juniper Interface as a trunk port allowing vlan 20 and then I have to specifically specify the Native VLAN as 20 on the interface. Once this is done, the AP is able to obtain an DHCP address and associates to the WLC.

It appears that in order for the AP to pull a DHCP address, it is reliant on the native vlan being specifically specified.

What I don't understand, and this is my question, is why then does the AP work just fine on the Cisco switch where the port is set as an access interface via the swicthport access vlan command? Does switchport access vlan x, imply that the stated vlan x is the native vlan? I thought native vlan only applied to trunks? Do AP's rely on the native vlan while other devices (computers, printers, etc) don't? Again if this is the case, isn't native vlan only relevant to trunks? Lastly, why are other devices pulling DHCP addresses just fine, does anyone know difference in AP DHCP lease behavior compared to other devices?

Hope this is clear what I am asking.

RichardAtkin · ‎08-27-2018

Unfortunately what you’re saying doesn’t add up... there’s definitely something wrong somewhere.

A Native VLAN on a Trunk and an interface configured as an Access Port are the same thing in this scenario - the switch accepts a frame without any .1Q tag info and forwards it on to whatever the Native/Access VLAN is for that interface.

An AP requests DHCP in the same way as everything else - it is not special or unusual at all. If it works for a PC it will work for an AP.

You haven’t mentioned how your network migration is working. Do the new/old switches use the exact same VLANs and Subnets so you can run new and old in parallel, or are they different in some way?

In order for the AP to find the WLC it needs to be able to use DNS, DHCP or Broadcast based discovery, with the former being the easiest / most common. Does the DHCP lease include a DNS Server address? Can you resolve ‘CISCO-CAPWAP-CONTROLLER.your-ap-local-domain’ from the AP’s subnet and using info provided by an AP DHCP lease?

Also, have you checked the AP doesn’t have a static address? Reset it by holding the MODE button down, plug in the PoE, then release the button after 15 seconds.

Finally, monitor the console output of the AP to find out what it’s doing and post it up here.

mac1234 · ‎08-28-2018

@RichardAtkin wrote:

A Native VLAN on a Trunk and an interface configured as an Access Port are the same thing in this scenario - the switch accepts a frame without any .1Q tag info and forwards it on to whatever the Native/Access VLAN is for that interface.

-This was my understanding which is why I found the behavior I am seeing odd.

You haven’t mentioned how your network migration is working. Do the new/old switches use the exact same VLANs and Subnets so you can run new and old in parallel, or are they different in some way?

-Same vlans and subnets, simply migrating to new hardware (cisco to juniper) via lift and replace. Juniper config simply mirrors what the cisco switch had.

In order for the AP to find the WLC it needs to be able to use DNS, DHCP or Broadcast based discovery, with the former being the easiest / most common. Does the DHCP lease include a DNS Server address? Can you resolve ‘CISCO-CAPWAP-CONTROLLER.your-ap-local-domain’ from the AP’s subnet and using info provided by an AP DHCP lease?

-yes this works

Also, have you checked the AP doesn’t have a static address? Reset it by holding the MODE button down, plug in the PoE, then release the button after 15 seconds.

-No statics in use

Unfortunately what you’re saying doesn’t add up... there’s definitely something wrong somewhere.

Ah, there is more to this. Turns out this AP issue is not the only problem I have run into, it turns out there are some other odd issues with DHCP after all. Example, I plug a PC into a port with vlan 10. PC receives an IP without issue, all working. However, if I then move this PC to another port on a different vlan, eg. vlan 20, the PC is then unable to pull an DHCP address from vlan 20. This same behavior occurs in the opposite, such as, if I plug a PC into a port with vlan 20, an address is received. If I then move it to a port with vlan 10, same problem, no address received.

So there is some general underlying issues going on here not just affecting the AP's and I suspect what the issue is.

Now here is where the issue likely lies, and maybe someone can hypothesize as to why:

This juniper switch is currently connected via a single port trunk to the existing Cisco switch that it will be replacing. So the Cisco 3750 is still connected to our core switch stack via a trunk and then the juniper is "hanging off" the Cisco switch via a 1gb port configured as a trunk.

So all traffic from the juniper has to first traverse the trunk to the Cisco and then traffic is sent over the cisco trunk back to the core.

Not sure why this trunk config I have set would cause issues, but my suspicion is that this trunk from the juniper to the cisco is the root cause of the issue. Either by causing some sort of forward table issues?? or perhaps native vlan issue of some sort?