Showing results for 
Search instead for 
Did you mean: 
James Drake

Mesh Trunking

I recently inherited a campus-wide mesh network of 6 RAPs and 14 MAPs. We have 4 remote switches bridged through MAPs. As-is, the network is working, but there are some things that we would like to clean up and future-proof on the LAN.

In their current state, most of the remote switches are using only 1 VLAN. We would like to separate this traffic as we do in the rest of the network. I've been having issues getting trunks set up over the air. As many have said, Cisco's documentation is very confusing. I've gained some insight from Scott's powerpoint, but I'm still having trouble making it work. Here is a sample portion of what we have and what we are trying to accomplish. (All management interfaces are in VLAN 95)

Current state:

[CORE] ->[SWITCH-NATIVE95] -> [RAP(Interface Normal)]~~~~~~~~~~~~[MAP-(Interface Normal)] -> [REM-SWITCH-NATIVE95]

In this state, anything in VLAN 95 connects to the rest of the network, but anything outside of VLAN 95 does not. If I flip the MAP's interface to trunk, with a Native VLAN of 95, I can ping everything in other VLANs, but lose connectivity to the switch.

This is what I tried today, with 95 and my other VLANs as allowed VLANs (on the switch and the MAP):

[CORE] -> [SWITCH-NATIVE999] -> [RAP(Interface Normal)]~~~~~~~~~~~~[MAP-(Trunk-Native999)] -> [REM-SWITCH-NATIVE999]

This also resulted in no connectivity to the switch. I also noticed that the MAPs that normally connect to this RAP all chose to connect elsewhere.

I have read that RAPs' interfaces should always be set to normal and you will get a warning when trying to set it to trunk. I attempted to set it to trunk and got no warning, so I tried this:

[CORE] -> [SWITCH-NATIVE999] -> [RAP(Trunk-Native999)]~~~~~~~~~~~~[MAP-(Trunk-Native999)] -> [REM-SWITCH-NATIVE999]

I got the same result as with the interface set to normal. Also could not get the MAP to reliably connect to the same RAP to do a controlled test.


What am I doing wrong? How do the interfaces have to be set to trunk over the air?

I was consoled into [REM-SWITCH] and didn't get any VLAN misconfig messages, but I did notice the RAP going up and down intermittently via NCS. Could SpanningTree be an issue?

Does the AP's management interface have to be in the native VLAN?

Is there any way to force a MAP to connect to a particular RAP?

(Cisco AIR-CAP1552I Access points, WLC-5508 ver


Hi James,

Yes you are correct , you upgrade to and everything will start working with Vlan transparent mode enabled.

It is  simple.Let me throw some more light on that. Before you proceed for ethernet bridging:

1) Enable Ethernet bridging on Mesh APs (RAP and MAP) otherwise ethernet ports  will be disabled by default.

2) Once you have done that . next is to decide if you want vlan tranparent mode to be enabled or disabled.Both result in vlans bridged across the mesh network.

3) By default , Ethernet ports of MAP and RAP would be in  "Normal mode".

Now after above points , You need to decide which mode you want to choose:

>>If you choose Vlan Tranparent to be enabled on Wireless>mesh page, No further configuration on RAP and MAP is needed. Vlan tags are not processed and forwarded from the MAP switch to RAP switch Tranparently.You just need to configure RAP switchport and MAP switchport with with a native vlan and allowed vlans in a exactly same way.Native vlan should be the Management vlan of the RAP and MAP.All the vlans would be tranparently forwarded.

Expect this in 7.0 and 7.5.In 7.2 allowed vlans configured on the RAP and MAP switch switch will not work because of the bug I mentioned.

>>If you choose vlan tranparent mode to be disabled , You are asking MAP and RAP to process the vlan and hence you will need to configure them now.

###RAP and MAP switchport configuration would be same.

###MAP ethernet port on the WLC to be configured as Trunk with same configuration as that of RAP and MAP switchport.

With this configuration in place , you will be able to ping the" allowed vlan " ip addresses from the RAP switch to MAP switch.RAP and MAP ip address is in Native vlan and will work fine but you cannot ping native vlan ip address present on the MAP switch from the RAP switch. Native vlan is not allowed to bridge across the MESH network with vlan tranparent disabled.

Hope this helps.



View solution in original post

Thanks for that information Dhiresh. We were planning to upgrade the controller in this location this year. This information may prioritize this upgrade!

Amjad and Scott, thanks to you two also. We ended up getting TAC involved with that MAP that we took down because things just didn't make sense. The TAC engineer agreed that the errors we were getting were unusual and that our settings looked correct. We wiped the MAP and started from the ground up, configuring it with TAC watching and we still had some issues, though it seemed to be moving in the right direction. We will keep working through these issues also.

One more question Dhiresh,

If we use VLAN transparent on 7.5, and the switches' native vlan on both sides are the same VLAN as the MAP and RAP management VLAN, will the remote switch and its indoor access points have to be on a different VLAN than the native/MAP's management VLAN?

If the native VLAN is vlan100. The MAP and RAP's management are both on vlan100. I need to know if the MAP or RAP will drop or pass frames if there are devices on the MAP/bridged side on vlan100.


Yes.Once the Native vlan starts communicating across the bridge i.e you are able to ping any Native vlan ip address on MAP switch from RAP switch , You can have any thing in Native vlan on MAP switch.



Awesome! This may be the answer to all of our problems!

VLAN trunking across mesh has been very stable for a few weeks now!

Thanks again Dhiresh!

That good to know. v7.5 is deferred and if v7.4.121.0 didn't fix your issue and v7.5 did , that's good for you. If it isn't broke, no need to upgrade:)

Sent from Cisco Technical Support iPhone App

*** Please rate helpful posts ***
James Drake

An update.

On Friday, after speaking with TAC, I learned that the issue with my stranded MAP was most likely because of a bug with 7.2.x.x. I was given a small maintenance window to perform the upgrade from 7.2 to 7.5. After the 7.5 install, the stranded MAP was able to associate and is working correctly. I will have to dig into the trunking later this week. Snow and ice has kept me out of the office, and offsite.

there are many mesh ap related bugs between 7.2 and 7.4, where 7.4 code have open mesh bugs that were least affecting. you can check fron appropriate rne.



I have the same drawback. I would like your support to solve it


[CORE vlan 980, 970, 940]switcport mode trunk-switch trunk vlan native 980 ] -> [RAP(Interface Normal ip vlan 980)]~~~~~~~~~~~~[MAP-(Interface Normal ip vlan 980)] -> [SWITCH DISTRIBUTION-switcport mode trunk-switch trunk vlan native 980]


[CORE (VLAN 980,960,970,940)] -> [SWITCH-ip manager] -> [RAP(bridge-Native980)]~~~~~~~~~~~~[MAP-(Bridge-Native980)] -> [REM-SWITCH-ip manager (switchport trunk native vlan 980/switch port mode trunk)]

Content for Community-Ad