S! ALL! Here's my experience with trying to pass VLANS over Aeronet 350 bridges...this ties into this thread because we ran into issues when we tried to link bridges...
glossary: trunk = "switchport mode trunk" with ALL VLANS allowed. 802.1q encapsulation. I run a single DS1 into an office park. There I have a 2620 terminating the DS1 and using FE subinterfaces trunked to a 2950. This 2950 then has a trunk to the root 350 Bridge. Then from there we link to other Bridges (currently 6 others in hub-spoke) in other buildings. Each building has a 350 bridge trunked to a 2950. Clients then have Cat5 run to thier office CPE, usually a firewall. Each client has thier own unique VLAN. There may be more than 1 client per building (in fact, the most populous building currently has 4 clients, and there are over 15 in all). Like so: DS1---2620--[trunk]--2950--[trunk]--ROOT 350Br----350Br--[trunk]--2950--[VLAN x]--CPE So this is a hub and spoke with one "ring" around the hub. As long as we stay at this one "ring" level things are just fine. BUT if I do this: DS1---2620---2950---ROOT 350Br---350BR---350BR---2950---CPE A client signed on with us last summer in a building that had no line of sight to the root bridge's omidirectional antennae. So we tried to link them to the root by passing them through an existing bridge, thus creating a second "ring" tier. We tried it both using an existing bridge (that serviced a building through a 2950 etc) and a dedicated bridge we mounted just for this purpose. The result? SEGV whenever anything was plugged into the switch at "ring" level 2 (far end away from the root site). As soon as the interface in the client VLAN came up...POW...SEGV. The router would crash with a SEGV error. It would reboot and immediately crash again...and again...ad infinitum The output was run through Cisco's output interpreter...sent to TAC along with all configs...nada. Note that "VLAN1" was able to traverse the network just fine. I could console into the switch at ring-level 2 and go to any other switch in the office park. Once anything went across in an 802.1q tagged frame though, indeed as soon as an interface in the far switch NOT in VLAN1 came up, the router crashed. Notes of interest: 2620 was using 12.2.5d originally. I could get it to NOT crash if I went to 12.1.17 BUT no traffic would cross to the far switch AND the router and its local switch would not talk on VLAN 1. Unacceptable. All switches were VTP clients except the root, which is in server mode. All VLANS showed up on all switches including the far switch. I set the MTU to a low value, to no effect, thinking maybe the 802.1q tags (4 extra bytes) could be an issue. Nada. No VLAN capability was configured on the 350 bridges. The far 350 cannot communicate with the root 350 so it is not looping anything. All associations seemed proper, i.e. far-to-middle, middle-to-root. All "parent" listings seemed proper. Bridge "IOS" was everything from 11.23 up (we tried em all in matched sets, i.e. all 11.23 or all 12.0 etc). The only interfaces assigned to the VLAN in question were the FE subinterface on the 2620 and a single port on the far switch. No other switches had any ports in this VLAN (trunk ports excepted, of course). All links are at 60% level or greater and are supporting a full 11Mbps. A port on the "middle" switch was configured to be in the same VLAN as the client and it could NOT talk to the client. The middle bridge has an omnidirectional antennae, so the "one at a time" rule does not apply...or does it? Still, we did use a separate dedicated bridge as the middle of the chain to no avail. TAC swears that this should work because the 350 bridge is functionally a hub. GIGO rules apply. It is unaware, nor does it care about the VLAN tagging or anything else. It should just relay anything and everything. Anyone got any suggestions? I'm open :) Oh yeah...I "fixed" it by placing the far 350 at the other end of the building where it could get LOS to the root...once the leaves fell off the trees on the intervening ridge. Spring is coming though and with it, certain loss of LOS. Short of a "chainsaw-in-the-night" approach, it seems a DS1 to the client is my only answer. S! (Salute!) Brian Carroll CCNP, CCSE, MCSE, CCA Director of Professional Services Air Net Link LLC. ""Williamson, Paul"" wrote in message news:[EMAIL PROTECTED] > Anyone know the maximum number of Wireless AP's you can chain of a single > wireless bridge > ie > > Switch ---copper---> AP ~~~air~~~> AP ~~~air~~~> AP > > Does cisco make an AP that supports this > Thanks > -Paul > > > PLEASE READ: The information contained in this email is confidential > and intended for the named recipient(s) only. If you are not an intended > recipient of this email you must not copy, distribute or take any > further action in reliance on it and you should delete it and notify the > sender immediately. Email is not a secure method of communication and > Nomura International plc cannot accept responsibility for the accuracy > or completeness of this message or any attachment(s). Please examine this > email for virus infection, for which Nomura International plc accepts > no responsibility. If verification of this email is sought then please > request a hard copy. Unless otherwise stated any views or opinions > presented are solely those of the author and do not represent those of > Nomura International plc. This email is intended for informational > purposes only and is not a solicitation or offer to buy or sell > securities or related financial instruments. Nomura International plc is > regulated by the Financial Services Authority and is a member of the > London Stock Exchange. Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.408 / Virus Database: 233 - Release Date: 11/8/02 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66470&t=66270 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
