Can only access switch via HTTP?

[Brendan Marmont]

Have a strange issue, I am unable to access a 3560 switch in a remote location using ssh or even ping it for that matter. I can access it by http and from what I can see everything is setup correctly.

I can ping another switch on the same subnet.

Software Version 12.2(53)SE2-IP-BASE-CRYPTO

Telnet is not a valid transport.

The switch is a detectable neighbor from the core switch. The interfaces are setup as DOT1Q trunks.

GW is setup correctly and clients hanging off the switch are having no reported issues.

Anyone have some hints on what I can try?

Thanks in advance,

Brendan

[cadet alain]

Hi,

Maybe you've got an ACL configured.

Can you post config of the switch as well as topology indicating from where you're trying to access the switch.

Regards.

Alain

[Brendan Marmont]

Thanks Alain,

There are no ACLs on the access switches.

I'm trying to access from the core switch in the remote location. I can access the switch via http from the data centre in my local zone.

Can't give you the config as I can't get to the switch

All access switches share a simlar config like below, some output ommited.

version 12.2
service password-encryption
!
hostname net11
!
aaa new-model
!
aaa session-id common
clock timezone UTC 12
system mtu routing 1500
authentication mac-move permit
ip subnet-zero
ip domain-name

ip name-server 10.100.0.117
!
spanning-tree mode pvst
spanning-tree etherchannel guard misconfig
spanning-tree extend system-id
!
vlan internal allocation policy ascending
vlan dot1q tag native
!
ip ssh authentication-retries 2!
!
Interface range FastEthernet0/1-48
switchport access vlan 90
switchport mode access
switchport voice vlan 190
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
priority-queue out
mls qos trust device cisco-phone
mls qos trust dscp
auto qos voip cisco-phone
macro description cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
!
interface GigabitEthernet0/4
switchport trunk encapsulation dot1q
switchport mode trunk
srr-queue bandwidth share 10 10 60 20
queue-set 2
priority-queue out
mls qos trust dscp
auto qos voip trust
macro description cisco-switch
spanning-tree link-type point-to-point
!
interface Vlan1
no ip address
!
interface Vlan28
ip address 10.100.28.10 255.255.255.0
!
ip default-gateway 10.100.28.1
ip classless
ip http server
ip http secure-server
!
line con 0
password 7
logging synchronous
line vty 0 4
password 7
length 0
transport input ssh
line vty 5 15
password 7

length 0
transport input ssh
!
end

[Fabio Francisco]

Just my 2c

Have you checked the core switch any ACL blocking the http traffic?

[Richard Burts]

Brendan

What I notice in the config that you posted is the the configuration of the vty lines allows only SSH access. If for some reason the remote switch does not have valid RSA keys generated then SSH will fail and produce approximately the symptoms that you describe.

From HTTP can you do show ip ssh, or can you display the RSA keys - or even better can you generate/re-generate the RSA keys?

HTH

Rick

[Brendan Marmont]

But I should be able to ping the device in the first instance, RSA keys wouldn't prevent this would they.

Thanks

Brendan

[Brendan Marmont]

Thanks Rick, there is no specific ACL that relates to this switch.

Cheers

[Richard Burts]

Brendan

I have not suggested that an ACL was the problem. That was Alain and Fabio.

I did mis-read your post. I thought that you could ping but could not SSH to the switch. And for that symptom I believe that the RSA key is a very plausible explanation. But in reading more carefully it does appear that you can neither ping nor SSH. And RSA keys are not a good explanation for that symptom. For that symptom it sounds like the switch either has no default gateway or an invalid default gateway configured. Perhaps when you access it via HTTP you could check on the default gateway for that switch. I know that you say that clients connected to the switch have no problem. But that does not say anything about the default gateway on the switch. The clients do not use the switch default gateway. The only thing that uses the switch default gateway is the switch itself.

I am also curious about your statements about accessing the switch via HTTP. It is not clear to me whether the HTTP access is working from your remote location or is from somewhere close to the switch. Perhaps you can clarify.

And it also makes me wonder if you might be able to access the switch via SSH if you were on a device that is locally connected?

HTH

Rick

[Brendan Marmont]

Thanks Rick,

I'm accessing the switch via http from a remote location, the cisco express setup view shows me the DG being correct. Tried to ssh by rdc to a local machine, it also fails.

I am actually going to fly down there tomorrow and have a look what is  going on via the console to sort out, will post my findings.

Thanks again,

Brendan

[Richard Burts]

Brendan

At the risk of seeming either pedantic or picky (either of which might be accurate) I would like to make sure that I am understanding the symptoms:

- from your remote location SSH to the switch fails.

- from your remote location ping to the switch fails.

- from your remote location HTTP to the switch works.

If those are true then there is something in the environment that we are not understanding.

If HTTP from remote does work then it would seem to establish that IP connectivity is not a problem. In my experience when there is IP connectivity and some appliations do work (HTTP) and other applications do not work (ping and SSH) then frequently there is an ACL or a firewall that is intercepting some traffic. Is there any possibility of an ACL or a firewall impacting this traffic?

HTH

Rick

[jimmysands73_2]

Did you make sure

!

interface Vlan28

ip address 10.100.28.10 255.255.255.0

!

was up?  That is the management IP looks like.

[Richard Burts]

If Brendan can successfully HTTP to the switch then that would be pretty good proof that the management interface was up and reachable. I agree with you that the failure of SSH and failure of ping would make more sense if there were an IP connectivity problem. But if HTTP does work then it is not a problem with IP connectivity.

HTH

Rick

[Brendan Marmont]

Thanks everyone for your input,

Ended up being a duplicate IP on VLAN28

All working fine and accessible now

[Richard Burts]

Brendan

Thanks for posting back to the thread and telling us what the problem turned out to be. That is a very interesting problem. I am a bit puzzled how HTTP worked but SSH and ping failed when the problem was a duplicate address. But the important thing is that you found the problem and fixed it. Congratulations

HTH

Rick