I have two WLC 4402 connecting to core sw1 and core sw2 separate.
native vlan 4(management) & vlan28(ip cctv camera)
WLC<---trunk allow vlan 4--->core switch<---trunk allow vlan 4,28--->edge switch <--trunk allow vlan 4,28-->RAP<<<backhaul so,no config>>>MAP<-access vlan28->camera
The WLC , RAP & MAP is vlan4 and the camera is vlan28.
The core switch virtual gateway address is 10.80.4.254 and the edge switch ip default gateway is 10.80.4.254.
I'm able to ping all the devices UNTIL when i do switching(or you can say transfering) the RAP or the MAP to the other WLC ,the only device i couldn't ping was the ip camera.The failover fails.
The WLC,RAP,MAP& camera ip address was static.
what possible reason it is nt working ? As appreciation,5 star rating to anyone could solve the problem.
Change the following:
WLC<---trunk allow vlan 4--->
WLC<---trunk allow vlan 4,28--->
and see what happens. The wlan to vlan mapping will only work if the WLC can see the vlan on the wired side to map to.
many switchport level settings are not in affect due to the ap proxy back to the controller
wow the reply was fast thks ericgarnel =)
ok i acted ur request,
swport trunk native vlan 4
swport trunk allowed vlan 4 ,28
arghh...it's nt working still
You said many switchport level settings are not in affect due to the ap proxy back to the controller.What do you mean by level setting ?? ok i show u the edgeswitch side config.
EDGESWITCH#show int fa0/40 switchport
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1(default)
Trunking Native Mode VLAN: 4 (WLANmgmt)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: 4,28
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
here's another 1
Port Mode Encapsulation Status Native vlan
Fa0/40 on 802.1q trunking 4
Port Vlans allowed on trunk
Port Vlans allowed and active in management domain
Port Vlans in spanning tree forwarding state and not pruned
I don't know what did i done wrongly , it works fine but the failover just couldn't work for the camera.
P.S : On the WLC , i enable the vlan transparent and apply then i disable back again and apply(under the mesh option)..n the camera is working .
The WLC version was 5.2.157
I need mre advise n question ..hopefully we can learn this problem n solve em tgt.
on the port that connects to the WLC,
just have the following:
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlans 4,28
and see if that works and if it does, you can add the other commands back in one by one until it breaks again. Also, I'm not sure how affective vlan pruning is on the WLC trunk as the pruning needs to be on both ends of trunk and I don't believe that the WLC has pruning capability.
Also, the switchports that connect to the APs need to be in access mode and in a subnet/vlan that is accessible by the ap-management interface or in the same vlan/subnet as the ap-management interface.
Though prob has yet to solve , but anyway here's the rating =)
appreciate it ..
If the prob is somehow solved i will clarify in the forum
I don't have an answer for you, but I'm trying to make sure your design is understood:
You are doing bridging across your Mesh link, right? So the Camera in vlan 28, is actually hard wired into your MAP.
But there is no switch between camera and map? So the "native" vlan of the ethernet port on the MAP should be VLAN 4 if that is the vlan of the MAP itself.
If this is true, what you are saying is that when you fail the link from one wlc to the other, the configuration to allow vlan 28 as the native vlan out the map is what is failing....? (so in theory, the client may actually be in vlan 4, but talking with a vlan 28 address).
Basically, I've seen issues with HREAPs, for example, that when defined with vlan mappings, they may lose these mappings when moving between controllers that are not identically configured.
this could be a bug..?
Unless of course the camera on the map in vlan28 is a wireless camera, at which point ignore everything I've written..
Still assuming this is ethenet bridging across the Mesh:
Have you tried configuring the ethernet bridging mode to being Trunk instead of Access, and then setting the native vlan to 28 for the MAPs ethernet port?
Maybe the access vlan information is not correctly passing during fail-over, but maybe trunk vlan information is?
However, if you say you can make it work by enabling vlan transparent mode and then disabling it again, that implies to me your vlan mapping is correct but the AP just isn't correctly doing it (untill the setting is configured again).
i think there might be a bug from somewhere ? ...ok anyway i acted from your request(thks weterry) n did 3 things.
RAP : native id vlan4
trunk id vlan28
MAP : native id vlan28
RAP : native id vlan28
MAP : native id vlan28
RAP : native id 28
MAP : access vlan28
3 Results: Failover fails...it's still the same.However 1 thing i forgot to mention, when i change the MAP (let's say i switch the MAP from WLC 2 to WLC1) the failover for camera has no problem.BUT...but if i change the RAP ,
the failover for camera doesn;t work.
juz for info.After you click the interface ,from there is a dropdown for setting normal,trunk or access mode.If you choose trunk , you can fill in the info for Native vlan ID and trunk ID.
Personally, I think its a bug in the OS ver. I have a similar problem and haven't seen a fix or much discussion on this unique problem. I have both IP cameras on the ethernet gi1 of the RAP & MAP 1522. Since my cameras are not that critical (and doesn't get reboot/failover as often), I came up with a quick fix by toggling the physical gigabitethernet1 port from "Access" mode to "Normal" mode and THAN doing the reverse of switching back to "Access". Somehow, it works in my case. Am considering upgrading to a different OS to see if its fixed.