cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2166
Views
1
Helpful
24
Replies

Not able to SSH or telnet to Switch(2nd) Which is in Port-channel

san ju.
Level 1
Level 1

Hello All,

In my organization, we have two switches, SW1 (Nexus 6001) and SW2 (Catalyst 3750), connected via a Portchannel. Ports 23 and 24 are utilized in the port-channel setup on both switches. Everything was functioning well, but today morning I encountered an issue, I couldn't log in to the second switch (SW2) using telnet or SSH. Surprisingly, I'm receiving ICMP responses from SW2 when pinging it from switch1.

To address this, I've cross-checked the VLAN configuration on the Port-channel and the VTY settings on SW2 using the configuration backup from the previous day. Additionally, I've reviewed the ACL on the VTY, confirming that it permits access to SW2 from my LAN IP. 

After running the "show log" command on sw1, I discovered an error message indicating:

 

 

 

 entry number 42647: ETHPORT-3-IF_UNSUPPORTED_TRANSCEIVER
Transceiver on interface Ethernet1/24 is not supported

 

 

 

despite having applied the service unsupported-transceiver globally." Also its been there for a while!.

I'm currently at a loss on how to proceed with troubleshooting this connectivity issue.

I would greatly appreciate any assistance.

Config reference:

 

 

 

LAXSWTCHNX01# sho run int po1
version 7.3(5)N1(1)

interface port-channel1
  description TRUNK to LAXSWTCH02
  switchport mode trunk
  switchport trunk allowed vlan 1,10-13,16-20,92-93,95-96,99-200,300,333,444,500-550,700-701,900
  speed 1000
  duplex full

LAXSWTCHNX01# sho port-channel sum
--------------------------------------------------------------------------------
Group Port-       Type     Protocol  Member Ports
      Channel
--------------------------------------------------------------------------------
1     Po1(SU)     Eth      LACP      Eth1/23(D)   Eth1/24(P)

LAXSWTCHNX01# sho run int Eth1/23-24

version 7.3(5)N1(1)

interface Ethernet1/23
  description TRUNK TO LAXSWTCH02
  switchport mode trunk
  switchport trunk allowed vlan 1,10-13,16-20,92-93,95-96,99-200,300,333,444,500-550,700-701,900
  speed 1000
  duplex full
  channel-group 1 mode active

interface Ethernet1/24
  description TRUNK TO LAXSWTCH02
  switchport mode trunk
  switchport trunk allowed vlan 1,10-13,16-20,92-93,95-96,99-200,300,333,444,500-550,700-701,900
  speed 1000
  duplex full
  channel-group 1 mode active
 
================
SW2

interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 1,10-13,16-20,92,93,95,96,99-200,300,333,444
 switchport trunk allowed vlan add 500-550,700,701,900
 switchport mode trunk

 

 

 

Temporarily shut down one member port (ignore it)!!

Thanks,

Menon

24 Replies 24

So there is FW.

Check vlan use to forward traffic from FW to SW  and vlan use return traffic from SW and FW.

This vlan mismatch make FW drop the tcp.

MHM

Menon

Thanks for additional information. Just checking assumptions: you are attempting ssh and telnet to 10.5.6.2 and not specifying source address or any other parameter?

When you attempt ssh and telnet do you get any response or prompt or anything?

HTH

Rick

Hello Richard,

I attempted to connect via SSH/Telnet to 10.5.6.2 without specifying any parameters, but there was no prompt. We've dispatched one of our ground staff to the location, and currently, we've gained access to the switch. Now, we're awaiting the staff report. Thank you very much for your valuable time dedicated to helping us.

Thanks for your support!!!

Hello MHM,

The problem has been resolved, and now we're reviewing the RC. Thanks for your time and support regardless.

Thanks for your support!!!

Menon

Thanks for the update. Glad the problem is resolved. Can you tell us what the problem was? Or failing that can you tell us what you did to resolve it?

HTH

Rick

We currently didn't have RC data from the switches, and the logs and usage appear normal. We suspect this issue might have occurred due to bugs or something, as the switches became accessible once they came back up from restart.

Thanks.

Menon

Thanks for the update. Interesting that restart fixed the problem.

HTH

Rick

Friend 

You are so so welcome 

Have a nice day 

MHM

Ping success telnet/ssh is drop

Issue can be

1- if you access use telnet/ssh and you ask to add password and ping is success then connection is OK and password andor rsa key is missing in SW (it can happened if domain change)

2- if you access use telnet/ssh and you never ask to enter password and ping success then connection is not good' WHY? Because telnet/ssh use l4 tcp and it need handshake and match syn/ack' the main reason here there is FW (randomize tcp syn/ack) or there is asymetric routing' the icmp not effect but tcp if receive incorrect syn/ack then it drop session.

That all case 

Good luck 

Have a nice weekend 

MHM

Thanks for the information will check that!!

Menon.

Review Cisco Networking for a $25 gift card