Cannot telnet or web to a remote 2950 (LRE & T)

[troytripp]

I have an unusual problem related solely to Cisco 2950 LRE and T switches. If I try to telnet to a switch in a remote location (on a different subnet), or if I try to use the web browser to connect to the switch, it times out. I can ping to switch OK from my local subnet. If take control of a computer on the remote subnet (using mstsc), I CAN telnet or http to the switch from that remotely-controlled PC.

If I reboot the switch, I might have a few minutes where I can telnet from my subnet to the switch, but it always goes away after a few minutes.

I do not have this problem with other switches on remote networks (I have an old Cisco 1900 and a couple of HP 2824s), and I do not have this problem with a 2950LRE on my local subnet.

I've used an access list to check if the remote switches are seeing the telnet requests, and they are seeing the traffic; they just don't respond if the telnet request is from outside their local subnet. There are no access lists blocking telnet anywhere.

I should point out that these remote switches are on VPNs running across DSL lines. The only thing I can think of is that the asynchronous connection is somehow goofing up http and telnet, but I really don't know how, given that every other piece of equipment at these remote sites (SonicWALL firewalls, HP switches, WinXP desktops, and of course that old Cisco 1900), is responding to telnet just fine.

Any ideas? Thanks.

[glen.grant]

Not sure what would cause something like that unless you have duplicate addresses or something on the switches . Make sure the addresses and masks are correct along with the default gateway on the switches.

[troytripp]

Here's my config:

Current configuration : 2442 bytes

!

version 12.1

no service pad

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Cat2950LRE

!

logging buffered 10000 debugging

enable secret xxxx

!

clock timezone EST -5

ip subnet-zero

!

!

spanning-tree mode pvst

no spanning-tree optimize bpdu transmission

spanning-tree extend system-id

!

!

!

controller LongReachEthernet 0

!

!

interface GigabitEthernet0/1

!

interface GigabitEthernet0/2

!

interface LongReachEthernet0/1

cpe type CISCO575-LRE

flowcontrol receive on

flowcontrol send on

!

interface LongReachEthernet0/2

flowcontrol receive on

flowcontrol send on

!

interface LongReachEthernet0/3

flowcontrol receive on

flowcontrol send on

!

interface LongReachEthernet0/4

flowcontrol receive on

flowcontrol send on

!

interface LongReachEthernet0/5

flowcontrol receive on

flowcontrol send on

!

interface LongReachEthernet0/6

flowcontrol receive on

flowcontrol send on

!

interface LongReachEthernet0/7

flowcontrol receive on

flowcontrol send on

!

interface LongReachEthernet0/8

flowcontrol receive on

flowcontrol send on

!

interface Vlan1

ip address 192.168.10.5 255.255.255.0

no ip route-cache

!

ip default-gateway 192.168.10.1

ip http server

logging 192.168.1.83

snmp-server community public RO

*** Deleted a bunch of SNMP stuff to shorten the post***

!

line con 0

line vty 0 4

password mypassword

login

line vty 5 15

password xxxx

login

!

ntp clock-period 17179866

ntp server 192.168.1.81

!

end

If there's anything wrong with it, I can't find it.

[Richard Burts]

Charles

I am somewhat confused about what you describe and what is in the config. You say that:

I should point out that these remote switches are on VPNs running across DSL lines.

but I do not see anything in the config that relates to that. So would I assume that there is some other device between the switch and the DSL? Could that device be related to the problem?

HTH

Rick

[troytripp]

My WAN is composed of VPN tunnels that run across DSL lines and terminate at SonicWALL firewalls. As far as the switches are concerned, all they see is the inside interface of the SonicWALL, which they see as a gateway. As I pointed out in the original post, no other devices on the network have a problem with telnet with this configuration; it's only the Cisco 2950 switches that have an issue.

Maybe there's something about telneting across DSL or through the VPN tunnels that gives the 2950 switches problems, but I cannot figure out what it could be.

My network looks something like this:

----===============-----

where === indicates the VPN tunnel and --- indicates an Ethernet connection.

[lgijssel]

It would be interesting to know how you have interconnected all your equipment. You did not accidentally use the 1900 to attach an LRE port to?

On the "good old" 1900, there is a feature called broadcast limitation. If you have connected as above or if the 2950-LRE is in any way daisy-chained via the 1900 you will run into exactly this issue.

What b'cast limitation effectively does is blocking all broadcasts to 10Mb access-ports. This includes ARP requests, resulting in exactly the problems you describe. It is only a small chance but please check your 1900 config menu to see if this feature is active. If is is, please disable it!

Regards,

Leo

[troytripp]

None of these switches is connected to another. The 1900 is on the 192.168.13.x subnet, while one of the 2950LREs is on the 192.168.7.x subnet, and the two switches are about 80 miles apart. The only "connection" is a virtual one on the VPN.

[Richard Burts]

Charles

Thanks for the additional information. When you attempt to telnet do you get any response (prompt for password) or does it just hang?

I can not think of anything about telnetting accross DSL or through VPN tunnels that would disrupt telnet, other than the possibility that the configuration of traffic to be protected by the VPN might not include telnet. I think this is possible but not so likely.

Is there possibly anything in the SonicWALL that might be preventing the telnet attempt?

HTH

Rick

[troytripp]

If I reload the switch, then immediately telnet to it, I can connect. If I log off and try to telnet again, I get nothing.

I've used ACLs to check if the switch is actually seeing the telnet request, and in both cases, where I can successfully telnet and when I can't, the ACL shows the switch sees the attempted telnet. Why it fails at that point, I can't tell.

There's nothing about the SonicWALLs that I can find that would be causing the problem. I can't rule it out, but when telnet works to other devices, but not the 2950s, I'm leaning towards the problem being with the 2950s.

[Richard Burts]

Charles

If you can successfully telnet immediately after reloading the switch then I would agree that it pretty much takes the SonicWALL out as the source of the problem.

If you can successfully telnet immediately after reloading but can not telnet later then it sounds a bit like something is timing out (perhaps ARP perhaps mac-address-table) or is being incorrectly learned. Is it possible to access the switch and check the content of ARP cache and mac-address-table while the problem is on-going?

When you are not able to telnet to the switch, are you still able to ping it from your remote location?

HTH

Rick

[troytripp]

I'm able to ping the switch at all times, regardless of whether or not I can telnet to it.

If there was a problem with ARP, then ping should fail, right?

Also, if ARP was the problem, I shouldn't be able to ping or telnet to the switch from a PC on the switch's local network. It's only when I telnet to the switch from my local network (a remote network from the switch's perspective) that I have a problem, and rebooting causes the problem to go away, temporarily. I can always ping the switch, either from its local network or from a remote network.

For giggles, I've tried telneting from one 2950 to another, and that doesn't change the situation, so I don't think its some weirdness with Cisco's implementation of telnet.