Unable to telnet to Catalyst switches on different subnets

My problem is this: I have two Catalyst switches (a 2950 LRE and a

2950T) on remote subnets that I cannot telnet or http to. While the subnets are remote (different cities), they are all connected through the Internet via VPN tunnels. I can ping the switches from my subnet (192.168.1.x, the switches are on subnets 192.168.7.x and 192.168.9.x), but I cannot telnet or http to them.

Making things more interesting: if I take remote control of a user's computer (RDP or SMS remote tools) that is on the same subnet as the switch, I CAN telnet or http to the switch!

No other devices seem to have this problem (HP switches, which are basically rebadged Cisco switches, or a older Cat1900, and no Cats on my local subnet). I thought it might be some weirdness with the VLANs, but all my equipment is set to VLAN1, Cisco and non-Cisco alike.

Here are the configs for the two switches (modified for my protection, natch)

SWITCH ON THE 192.168.7.X SUBNET

------------------------------------------------------------------------------------------ sh run Building configuration...

Current configuration : 2436 bytes ! ! Last configuration change at 12:26:29 EST Wed Dec 28 2005 ! NVRAM config last updated at 12:26:29 EST Wed Dec 28 2005 ! version 12.1 no service pad service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Cat2950T ! enable secret xxxxxxxxxx ! clock timezone EST -5 ip subnet-zero ! ip domain-name xxxxxxxxx ! spanning-tree mode pvst no spanning-tree optimize bpdu transmission spanning-tree extend system-id ! ! ! ! interface FastEthernet0/1 ! interface FastEthernet0/2 ! interface FastEthernet0/3 ! interface FastEthernet0/4 ! interface FastEthernet0/5 ! interface FastEthernet0/6 ! interface FastEthernet0/7 ! interface FastEthernet0/8 ! interface FastEthernet0/9 ! interface FastEthernet0/10 ! interface FastEthernet0/11 ! interface FastEthernet0/12 ! interface FastEthernet0/13 ! interface FastEthernet0/14 ! interface FastEthernet0/15 ! interface FastEthernet0/16 ! interface FastEthernet0/17 ! interface FastEthernet0/18 ! interface FastEthernet0/19 ! interface FastEthernet0/20 ! interface FastEthernet0/21 ! interface FastEthernet0/22 ! interface FastEthernet0/23 ! interface FastEthernet0/24 ! interface GigabitEthernet0/1 ! interface GigabitEthernet0/2 ! interface Vlan1 ip address 192.168.7.5 255.255.255.0 no ip route-cache ! ip default-gateway 192.168.7.1 ip http server

(bunch of snmp stuff deleted)

! line con 0 line vty 0 4 password yyyyyyyy login line vty 5 15 password yyyyyyyyyy login ! ntp clock-period 17179946 ntp server 192.168.1.81 ! end

------------------------------------------------------------------------------------------

SWITCH ON THE 192.168.9.X SUBNET

------------------------------------------------------------------------------------------- Current configuration : 1485 bytes ! version 12.1 no service pad service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname CiscoCat2950LRE ! enable secret xxxxxxxxxxxxxxx ! 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

(bunch of snmp stuff deleted)

! line con 0 line vty 0 4 password yyyyyyyyy login line vty 5 15 login ! ! end

------------------------------------------------------------------------------------------------------

As you can see, no access-lists blocking anything. As I said, I can ping OK, and SNMP queries (I deleted all the SNMP stuff above to make this long post a bit shorter) are returned w/ no problems. The VPNs are working OK, and there's nothing in the firewall rules (SonicWALL firewalls) to block anything on the VPN. And as I said, telnet and http work fine as long as I'm on a computer that's on the same subnet.

I've never come across this sort of problem with Cisco equipment, but I've always played in pure Cisco environments, not one with a mix of Cisco and non-Cisco equipment like this.

Anyone? Anyone? Bueller?

Reply to
ttripp
Loading thread data ...

It seems that switches are ok, so problem could be somewhere on the path between your network and remote network where switches resides... If you are able to connect to the HP devices are you sure that there is no some ACL's along the path that blocks communication with cisco equipment explicitly?

B.R. Igor

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

Reply to
Igor Mamuzic

The only places any ACL's would be located are on the SonicWALL firewalls, and I've rechecked those; no ACL blocks anywhere.

Reply to
ttripp

You might have a problem with your default gateway command - the 'default gateway' command only sets the DGW for the console. It's the 'ip route' command that determines routes for the interfaces.

If you can ping the router, the 'ip route' is correct. If you can't telnet, you need to fix your 'default gateway'.

----------------

----------------

-----------------

----------------------------

Reply to
Telus

Sorry - you said SWITCHES... The default-gateway command is the only option on switches...

If they were routers, it would matter. In this case it doesn't.

Please disregard my post.

Reply to
Telus

when you connect to them via console, what shows a "sh line"? Do you have free lines available? Outherwise you have to clear them. In this case also use sercive tcp-keepalives.

bye andre

Reply to
Andre Janssen

If by console, you mean a serial cable plugged into the actual console port, then I don't know. One switch is about 3 hours drive from me, and the other is about 9 hours, so...

On the other hand, if you mean by telnet, I'll have to look, but I don't think that could be the problem, as I couldn't telnet into them from a local or a remote subnet if there weren't any lines available.

Reply to
ttripp

Configure loging buffered if it is not already configured (i.e logging buffere 10000 debug)

On the switch vty lines, configure an extended access list that permits any any and logs

Try telnetting to switch. If nothing is logged then the packets are not making it to the switch in question

Reply to
Merv

youa may also have someone to powercycle the switch.

andre

Reply to
Andre Janssen

Great Giggaly-Wiggaly. POWERCYCLE! Of all the dumb, useless...

Oh, wait. It worked.

Actually, I used a local PC to telnet to the switches and performed a "reload" command. It worked for one of the switches (the LRE). It worked for a moment with the 2950T, but after about a minutes I lost connectivity.

Why it should work one minutes, then stop the next, is the next great question.

Reply to
ttripp

And the LRE switch is gone again. I had about 10 minutes worth of telnet access, and now I've lost it.

Why? Why, why, WHY? Oh, and why?

Reply to
ttripp

Have you tried identifying vlan1 as the management interface? This should be default, but sometimes forcing it is required. If you can get to the clients on the LAN (through the switch) its strictly a management problem which usually is one of two things: the management interface isn't setup or is missconfigured, or you don't have your DG setup correctly. This case the DG looks fine. Try this:

Switch#conf t Switch(config)#int vlan1 Switch(config-subif)#management Swtich(config-subif)#end

Just a thought....

~Ryan

Reply to
rdymek

One more thing I thought of....

You mentioned all your equipment (Cisco and Non-Cisco) are on VLAN1. By default, all your switch ports are in fact set for VLAN1 on the Cisco equipment, *however* with ISL encapsulation. ISL is Cisco proprietary, so I doubt your Non-Cisco equipment recognizes the Cisco ports as being part of VLAN1. This may not be the problem though; it all depends on the switch layout/design. But for piece of mind, in a mixed environment like this, I'd turn everything on to IEEE standards so you don't have any of the Cisco proprietary encapsulations being used.

However, I don't know how it's configured with LRE switches - from what I know (could be outdated knowledge), 802.1q IEEE tagging is only supported on Fast Ethernet switch ports. But some things to look into at least. Maybe some vlan debugging may help.

If you do enable IEEE 802.1q tagging, EVERYTHING must use that standard. If you try and mix it up, you'll end up with lots of weirdness and hard to troubleshoot problems with your vlans. The router would also need to be configured for 802.1q.

To enable IEEE 802.1q tagging on a switch interface:

switch# switch(config)#int switch(config-subif)#encapsulation dot1q switch(config-subif)#end

of course, since you're only running VLAN1, the vlan Id would simply be

1 (please note, the vlan ID is only the number, without the word "VLAN" proceeding it).

Again, may be totally off track, but I'm just throwing some other ideas not mentioned out there.

~Ryan

Reply to
rdymek

Working with your first post...

I don't see a "management" command anywhere. It doesn't appear in the

2950LRE documentaton I have and the switch won't accept it.

As for as the ISL/.1q c> One more thing I thought of....

Reply to
ttripp

More on this issue; I've managed to get the LRE switch mentioned (and a second LRE switch I didn't mention) to consistantly accept telneting from a remote subnet by setting the vtp mode to "transparent", essentially disabling vtp.

This hasn't worked so far for the 2950T, however.

Reply to
ttripp

I tried using an access-list to log telnet activity to the 2950T's vlan

1 port and this is what I get:

Jan 05 08:25:52 192.168.7.15 local7.info 33: 14:22:01: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.1.132(0) ->

192.168.7.15(0), 1 packet

So, if I'm reading that right, the switch is getting telnet traffic routed to it.

Reply to
ttripp

Curious - Your switch config above for the 7 subnet shows an IP of

192.168.7.5, yet this log shows access to 192.168.7.15. Have you changed IP's since you posed the origonal config?

I do realize that you have not manually configured anything with VLAN's so it'd be easy to think that its not the issue. However, on all Cisco switches, you'll notice every port is part of a VLAN (VLAN 1 by default). Of course, since thats its native VLAN, VLAN tagging won't be happening on these switches. I don't know how the HP switches will react though. You said they're set to VLAN 1 as well (I don' t know if maybe they'll tag the packets, while the Cisco eqiupment won't). Just some things to think through.

You also mentioned that turnning VTP mode to transparent on, on the LRE "fixed" the issue. Something else that could pose an issue is if your HP switches are in the same VTP domain, your LRE will be set as a VTP server by default. So that could also be causing some weirdness (hence why setting it to transparent fixed it).

At this point, Cisco would recommend updating your IOS on the switches. Have you tried this? Its possible you've got some sort of bug you're encountering.

Also, can you try and diagram out your design? You mentioned the use of HP switches as well as Cisco switches, but really I'm not 100% clear on the actual layout. Will you please diagram the connectivity from the router out through the LAN?

~Ryan

Reply to
rdymek

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.