WLSM Connectivity

[mmelbourne]

I'm trying to achieve connectivity between the WLSM and the remainder of the network (having already done this succussfully in the lab). I've setup up a simple VLAN (VLAN 2) on the Sup720, and done a 'wlan module 2 allowed-vlan 2' to add VLAN 2 to the trunk between the Sup720 and the WLSM. The WLSM is configured with the basic ipaddr and gateway parameters under the 'wlan vlan 2' interface.

I can ping the Sup720 from the WLSM and vice-versa without a problem (and the WLSM LCP is up), but I can't ping (or telnet to, etc), the WLSM from

anywhere outside the local switch in which the WLSM blade resides (or vice-cersa). I can ping all the connected VLAN interfaces on the Sup720 from the WLSM, so the obvious things like the default gateway on the WLSM are correct.

The odd thing is if I do a 'clear mac-address-table dynamic', I get one successful ping (presumably until the switch learns the location of the

MAC address of the WLSM), and then no connectivity again.

I have tried downgrading to 1.2.2 from 1.3.1 and the same occurs, and I've even tried rebooting the entire chassis.

The only difference is that the lab Cat6k has one Sup720, whereas the production switches have two, running SSO. We're running 12.2(18)SXD4.

[mmelbourne]

Just discovered that if I reload the Standby Supervisor, the connectivity is restored, until the Standby Supervisor comes online again, at which point it behaves as described above.

Could this be an issue with 12.2(18)SXD4; I can't find any relevant bugs.

[cmetzger]

There are some caveats with pinging and the WLSM.

Check out http://www.cisco.com/univercd/cc/td/doc/product/wireless/wlsmdig.htm

Troubleshooting Commands—Caveats

There are some current limitations about some commands that can be used to troubleshoot an implementation of the WLSM. These limitations exist because of the lack of rewrite engine functionality on the WLSM blade, and major changes in the hardware architecture would be needed to overcome them. These limitations are the following:

•When the supervisor operates in compact mode, it is not possible to ping the IP address of the WDS from the wireless client.

•When the supervisor operates in compact mode, it is not possible to ping the local tunnel interface from the supervisor CLI.

Although you should be able to ping the WLSM from anywhere in your wired network ok. Sounds maybe like a routing issue.

I have sounds like an almost identical setup in our lab right now and ours works fine except for the above ping caveats.

[mmelbourne]

Thanks. I'd seen these caveats, but they didn't describe my setup. It's more that just 'ping' connectivity, it's any connectivity (I can't telnet to the WLSM, for example). It's not a routing issue because it works if I pull out the Standby Supervisor.

The only bug which might be relevant, is CSCee10005: "Catalyst 6500 with supervisor engine 720 and service modules may experience connectivity issues between the service modules and the rest of the network in certain scenarios".

Which code revision are you running on the Cat6k?

[micahcox]

Are you using VTP in the rest of your network and have you allowed VLAN 2 to be propagated (IE, configured the VLAN in VTP if you use it?)

[cmetzger]

Running 12.2.18-SXD4.

Hmmm...any chance you have another SUP720 you can through in 6500 in the lab?

You did create the vlan interface, right? I know stupid question, but I had to ask.

[mmelbourne]

Thanks, but I' now sure I'm hitting CSCee10005 and its associated Field Notice:

http://www.cisco.com/en/US/products/hw/modules/ps2706/products_field_notice09186a00804093ee.shtml

We are using cross-Supervisor Distributed EtherChannel and were seeing issues when packets to and from the Service Module were not L3 switched to other VLANs.

I temporarily disabled the distributed EtherChannel and packets were correctly routed to and from the WLSM via the configured management VLAN, so it appears there was nothing really wrong with the configuration.

[eheston]

We had the same problem, but we're using two 6509s with box redundancy (no Sup redundancy). We used Workaround 4 from the above document (thanks for the help); we pointed the default gateway on each WLSM to the Sup720 on the other 6509. Everything stared working instantaneously.