cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11773
Views
26
Helpful
24
Replies

Mesh Trunking

James Drake
Level 1
Level 1

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.

Questions:

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 7.2.111.3)

2 Accepted Solutions

Accepted Solutions

Ok..So after having RAP and MAP set perfectly using:

> RAP and MAP should be in the same vlan and it need not be in the vlan 1.

> You can use preferred parent command to make MAP to join a particular RAP or use different BGN.

It will behave like this on 7.2:

## With Vlan tranparent enabled:

RAP and MAP switch port configured exactly same.

No configuration needed on RAP and MAP.

Only native vlan will be able to communicate across RAP and MAP switch.With 7.2 code vlan tags are stripped and only the native VLAN traffic is successful in communicating across the.So if vlan 262 is the native vlan and vlan 20 and 30 are allowed vlan on the RAP Switchport and MAP switchport , then only vlan 262 will be able to communicate across the mesh.

https://tools.cisco.com/bugsearch/bug/CSCub63054

In 7.0 and from 7.5 , this has started behaving correctly. So here with Vlan tranparent enabled, RAP and MAP switchport configured properly and in the same way , all the vlans including native vlan will be bridged transparently.

##With vlan Tranparent disabled i.e vlan tagging enabled:

Rap and MAP switchport configured in the same way.

MAP interface configured in the same way i.e with same native and allowed vlans.GUI>AP>Mesh>Gigabit 0

RAP-No configuration needed:Automatic using vlan registration

With this configuration in place , all the allowed vlans will be able to communicate across the bridge. Native vlan will not communicate across the bridge by design to avoid loops.

Regards

Dhiresh

View solution in original post

Hi James,

Yes you are correct , you upgrade to 7.5.102.0 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.

Regards

Dhiresh

View solution in original post

24 Replies 24

Amjad Abdullah
VIP Alumni
VIP Alumni

Hi James,

I am a bit busy to look for the whole post you put. but as a general guide, I recommend you go over and over the following section:

http://www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70mesh.html#wp1542630

you'll find useful answers. I can copy the following from the above link:

"The RAP must always connect to the native VLAN1 on a switch. The RAP's primary Ethernet interface is by default, which is the native VLAN1."

now, you can use BGN (Bridge Group Names) to limit MAP to RAP association.

A MAP connects only to RAPs on same BGN. So, you can configure BGN accordingly on RAPs and MAPs to limit what MAPs connects to what RAPs.

HTH

Amjad

Rating useful replies is more useful than saying "Thank you"

Rating useful replies is more useful than saying "Thank you"

Amjad,

Thank you.

So according to this documentation, the RAPs MUST be on VLAN1, but the MAPs CANNOT be on VLAN1?

Edit: Also, can you expand on this statement:

A configured VLAN on a MAP Ethernet port cannot function as a Management VLAN

Thanks

I think I have more questions than answers right now..lol.

I just noticed that our 1 AP that is bridging correctly is attached to a remote switch that has an incorrect management ip address. The incorrect IP causes it to be on a different subnet that the management address of the AP. The AP that I'm trying to get to bridge is on the same subnet as the switch its connected to. Does the AP and the switch have to be on different management subnets?

Back finally,

James, make sure that you have your RAP having Normal and your MAP has trunk one.

Make sure switches in both MAP and RAP sides are configured with same native and allowed VLANs.

Make sure that the native VLAN you choose is the management VLAN for MAPs and RAPs, not the management VLAN of the switches. add the management IPs of the switches to the allowed list in both RAP and MAP. I think this answers your question "Does the AP's management interface have to be in the native VLAN?". The answer is "Yes".

Cisco Doc is extreamly confusing and I am not even sure if it is free of mistakes.

Let us know how it goes.

Regards,

Amjad

Rating useful replies is more useful than saying "Thank you"

Rating useful replies is more useful than saying "Thank you"

An update. Thanks help Amjad. That worked. The issue we ran into was that everything worked except the WAPs that are connected to the switch. We are pretty sure it is because they are on the same VLAN as the MAP and the frames are being dropped.

Since the MAP had already been configured for and associated with the WLC, we thought that it would work to get it on a different VLAN so that we can leave the majority of the devices on the current management VLAN (the management VLAN of all of the devices on the campus), but once the IP was changed, it would not connect to the WLC.

Now waiting on maintenance to get the MAP down so that I can console in and change the IP back, then figure out a plan from there.

Thank you for updating us James.

I wish you all the best with getting the MAP down. I hope it is not in a difficult place.

Rating useful replies is more useful than saying "Thank you"

Rating useful replies is more useful than saying "Thank you"

Haha,

2 stories up and off the edge of a pretty steep cliff. Thats why I'm not going up myself.

Hi James,

What is your WLC image version?

> RAP and MAP should be in the same vlan and it need not be in the vlan 1.

> You can use preferred parent command to make MAP to join a particular RAP or use different BGN.

Once MAP and RAP are up , communication between different VLANs across the RAP switch and MAP switch will depend upon the WLC image version.

Regards

Dhiresh

WLC is 5508 on 7.2.111.3

Ok..So after having RAP and MAP set perfectly using:

> RAP and MAP should be in the same vlan and it need not be in the vlan 1.

> You can use preferred parent command to make MAP to join a particular RAP or use different BGN.

It will behave like this on 7.2:

## With Vlan tranparent enabled:

RAP and MAP switch port configured exactly same.

No configuration needed on RAP and MAP.

Only native vlan will be able to communicate across RAP and MAP switch.With 7.2 code vlan tags are stripped and only the native VLAN traffic is successful in communicating across the.So if vlan 262 is the native vlan and vlan 20 and 30 are allowed vlan on the RAP Switchport and MAP switchport , then only vlan 262 will be able to communicate across the mesh.

https://tools.cisco.com/bugsearch/bug/CSCub63054

In 7.0 and from 7.5 , this has started behaving correctly. So here with Vlan tranparent enabled, RAP and MAP switchport configured properly and in the same way , all the vlans including native vlan will be bridged transparently.

##With vlan Tranparent disabled i.e vlan tagging enabled:

Rap and MAP switchport configured in the same way.

MAP interface configured in the same way i.e with same native and allowed vlans.GUI>AP>Mesh>Gigabit 0

RAP-No configuration needed:Automatic using vlan registration

With this configuration in place , all the allowed vlans will be able to communicate across the bridge. Native vlan will not communicate across the bridge by design to avoid loops.

Regards

Dhiresh

Thanks Dhiresh,

My biggest problem right now is that devices that are on the same management VLAN as the mesh (switches and indoor APs) won't communicate over the bridge unless it is in "Normal" mode. Switching it to trunk allows devices on other VLANs to communicate, across the bridge, but we lose the switch's management interface, and the indoor APs can't reach the WLC.

Dhiresh Yadav wrote:

In 7.0 and from 7.5 , this has started behaving correctly. So here with Vlan tranparent enabled, RAP and MAP switchport configured properly and in the same way , all the vlans including native vlan will be bridged transparently.

If I'm reading this correctly, if we upgrade to 7.5 and use VLAN transparent, all of our VLANs will bridge the mesh?

James,

This is a good link to look at. It explains Ethernet bridging in detail.

http://phasedcoexistence.blogspot.com/2011/12/cisco-mesh-ethernet-vlan-tagging.html?m=1

Sent from Cisco Technical Support iPhone App

-Scott
*** Please rate helpful posts ***

Thanks Scott,

That is the document that has gotten me as far as I am now. The hard part is this is a campus where the network has been up and working for years, then mesh was installed a few months ago, and it was working fine, now the company wants to figure out how to get VLANs to trunk over mesh. The network was never designed for trunking over mesh, so thats why I think I'm running into so many issues. All of the devices on the campus are in the same managment subnet, and on many of the trunks, the native VLAN is the management VLAN.

Excellent post SCOTT. 

My bank costumer wants the switchports in access Mode ( security rules ). My doubt is if the swtichports in both sides are in ACCESS MODE, Can i forward 2 or more vlans?? Or necessarily in trunk mode??

Thanks you!!!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: