S! ALL! Anyone have any experience passing 802.1q tagged packets over 350 bridges? Here is my sad sad story...
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---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 (or plug into a port not assigned to any VLAN, ergo, in VLAN 1 and use telnet) into the switch at ring-level 2 and go (telnet) 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. Spanning-tree was turned off on ALL switches in the park to no effect. 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 radio 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 signal. 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. --- 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=66587&t=66587 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
