Can you use a 3600 for an Ethernet bridge??

[thefranmanatt]

Can you use a Cisco 3600 to do a P2P bridge? Using the MAP's ethernet port  to connect to a remote LAN?  On that remote LAN can you have  lightweight APs that connect to a controller on the RAP side?

[Saravanan Lakshmanan]

Yes, 3600 on MAP/Bridge mode supports ethernet bridging.

Yes, you can connect AP behind 3600 on MAP, however it is not suggested running capwap over ethernet bridge which is unreliable due to latency.

[Saravanan Lakshmanan]

Can you use a 3600 for an Ethernet bridge??

http://www.cisco.com/en/US/docs/wireless/controller/7.0MR1/configuration/guide/cg_mesh.pdf

Check - Converting Indoor Access Points to Mesh Access Points

Ethernet bridging has to be enabled for the following two scenarios:

1. When you want to use the mesh nodes as bridges.

2. When you want to connect Ethernet devices such as a video camera on the MAP using its Ethernet port.

Wireless Backhaul:

In a Cisco wireless backhaul network, traffic can be bridged between MAPs and RAPs. This traffic can

be from wired devices that are being bridged by the wireless mesh or CAPWAP traffic from the mesh

access points.

Guidelines For Using Voice on the Mesh Network

• Voice is supported only on indoor mesh networks in release 5.2, 6.0, 7.0, and 7.0.116.0. For

outdoors, voice is supported on a best-effort basis on a mesh infrastructure.

other factors to note:-

#you would be running on backhaul using A radio which is prone to DFS.

#CAPWAP may not tolerent enough with AWPP convergence on MAP roaming.

#CAPWAP is more latency sensitive than voice.

[thefranmanatt]

I am having issues with the bridge's Ethernet port.  It connects up at a 1000/full but never grabs an IP address.  With the same configuration on a 1242 to 1131 bridge it is working. I ran out of time to test it anymore after I got the 1242/1131 bridge working.

I wasn't aware the CAPWAPs was more latency sensitive than voice.  I am kind of shocked I haven't read that anywhere.  Of course I haven't done mesh until now.  Is there any tweaks to the CAPWAP tunnels that can be adjusted?  Or will adjusting the "TCP Adjust MSS" help?  Can I use flexconnect over the bridge?

The goal is to have single P2P links from the head end out to clusters.  In the cluster their will be one 3600 just for the P2P. It will connect to a i3010 switch that will connect to 3 - 3600s with ant2566 antennas that provide guest access.  We want to use 3600 and there isn't public release of a-IOS for the 3600s yet.

thanks for the help

[thefranmanatt]

http://www.ciscopress.com/articles/article.asp?p=1409813&seqNum=4

there is a good link on set up ethernet bridges on WLCs

[thefranmanatt]

CSCud41334

Symptom: Ethernet bridged clients of Mesh APs (MAPs) do not work. Conditions: When an Ethernet bridged client is  plugged to the Ethernet port of a MAP before the MAP joins the  controller, then the client will not work. This caveat occurs for Cisco  1140, 3500, and 3600 (all indoor mesh APs), and not on Cisco 1552  (outdoor mesh AP). Workaround: Ensure that the bridged client is not  plugged into the Ethernet port of the MAP and reload the MAP. The MAP  must join the controller before the client plugs into the MAP Ethernet  port.

[Saravanan Lakshmanan]

Thanks for sharing it.

On that remote LAN can you have  lightweight APs that connect to a controller on the RAP side?

//capwap encapsulation on bridged traffic is not supported by Cisco but it may work.CAPWAP over MAP Ethernet port is currently not a supported design, irrespective of local or flexconnect mode.

[thefranmanatt]

Even though CAPWAP over CAPWAP is not supported it does work (unless you run in to the bug I posted above, LOL). 

Word on the street is that Cisco is working to fix this issue though or at least say it is supportable.  In the short term they are not recommending using a-IOS in WGB mode.  Which kind of defeats the purpose of having a Controller

[Saravanan Lakshmanan]

Even though CAPWAP over CAPWAP is not supported it does work (unless you run in to the bug)?

//Bug is about any wired device that's connected behind MAP doesn't get ip and not about capwap over capwap support. And wired clients behind ethernet bridging were always supported and this bug applicable only on 7.3, you can use 7.2 code instead.

why not recommended to use aios on wgb mode??

I think, capwap over capwap is not a right terminology.

AP(trying to join wlc) connected behind MAP, MAP can see the incoming packet and dump to the bridge irrespective of capwap or ethernet traffic. And MAP doesn't encapsulate the connected AP's capwap traffic on its backhaul capwap data payload directed to its joined WLC, it'll be useless(no high availability) to do capwap over capwap since the backhaul capwap terminates at MAP joined WLC, However if WLC thinks this AP(coming behind MAP) trying to join different wlc and can forward the discovery/join request to the wired off of capwap that may have route access to target wlc.

If MAP could differentiate the source of capwap from private/bridge vlan or its native(that used to join) vlan. if implemented, The capwap over capwap could be like the AP behind MAP can get ip from MAP's native vlan to join the WLC. And capwap over bridge could be like when using VLAN off of WLC i.e, bridged vlan.

[thefranmanatt]

Interesting thinking about this more.  How does the MAP talk to the controller?  Does it just talk to the RAP and then the RAP has a CAPWAP tunnel back to the controller? I know the RAP will dump the bridge ethernet traffic on the switch and not forward it up to the controller (through the CAPWAP tunnel).  So is it CAPWAP between the RAP and the MAP. 

I am pretty sure when I spoke with Cisco they were calling it CAPWAP over CAPWAP but that was a couple months ago.  We tend to avoid doing any kind of mesh at the different places I have worked at for the last 8 years.  So I don't have to mess with it much.  As for the WGB comment.  If I invest in a lightweight controller network I don't want to have to configure aIOS APs.

[Saravanan Lakshmanan]

http://www.cisco.com/en/US/docs/wireless/controller/7.0MR1/configuration/guide/cg_mesh.html

For the backhaul, there is only one type of encapsulation, encapsulating MESH traffic. However, two types of traffic are encapsulated: bridging traffic and CAPWAP control and data traffic. Both types of traffic are encapsulated in a proprietary mesh header.

In the case of bridging traffic, the entire packet Ethernet frame is encapsulated in the mesh header. (see Figure 9-62).

[thefranmanatt]

interesting.  I am going to ask my Cisco guy about this.

[Saravanan Lakshmanan]

Local or hreap mode AP joining using ethernet bridging behind MAP is not cisco supported until 7.4, it may/may not work but unsupported.

[Scott Fella]

The MAP joins the mesh via the RAP and the communication to the WLC will always pass through the RAP to the WLC.

I did test the Ethernet bridging a few months ago and did run into that issue in which it did not work. I know with the older code and using the 1131's I had that working in a lab, but that was 3-4 years ago and that was when indoor mesh was first available.

Sent from Cisco Technical Support iPhone App