cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1143
Views
0
Helpful
15
Replies

[SOLVED] Having big trouble with Catalyst ME 3400!

I have managed to reset to factory defaults a Catalyst ME 3400, but no matter what I did, I could not get it to respond to pinging.

 

 

 

 

CISCO#show run
Building configuration...

Current configuration : 3562 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname CISCO
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
system mtu routing 1998
ip subnet-zero
ip domain-name ahlat.com.tr
!
!
!
crypto pki trustpoint TP-self-signed-96207744
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-96207744
 revocation-check none
 rsakeypair TP-self-signed-96207744
!
!
crypto pki certificate chain TP-self-signed-96207744
 certificate self-signed 01
[redacted]
  quit
!
!
!
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
!
!
vlan internal allocation policy ascending
vlan dot1q tag native
!
vlan 2
 name VLAN_PCS
!
vlan 3
 name VLAN_WIFI
!
vlan 4
 name VLAN_VOIP
!
vlan 5
 name VLAN_CAMS
!
vlan 6
 name VLAN_A
!
vlan 7
 name VLAN_B
!
vlan 8
 name VLAN_C
!
vlan 9
 name VLAN_D
!
vlan 10
 name VLAN_E
!
vlan 11
 name VLAN_F
!
vlan 12
 name VLAN_G
!
vlan 13
 name VLAN_H
!
ip ssh time-out 60
ip ssh version 2
!
!
interface GigabitEthernet0/1
 switchport mode trunk
!
interface GigabitEthernet0/2
 switchport access vlan 3
 switchport mode trunk
!
interface GigabitEthernet0/3
 switchport mode trunk
!
interface GigabitEthernet0/4
 switchport mode trunk
!
interface GigabitEthernet0/5
 switchport mode trunk
!
interface GigabitEthernet0/6
 switchport mode trunk
!
interface GigabitEthernet0/7
 switchport mode trunk
!
interface GigabitEthernet0/8
 switchport mode trunk
!
interface GigabitEthernet0/9
 switchport mode trunk
!
interface GigabitEthernet0/10
 switchport mode trunk
!
interface GigabitEthernet0/11
 switchport mode trunk
!
interface GigabitEthernet0/12
 switchport mode trunk
!
interface GigabitEthernet0/13
 port-type nni
 switchport mode trunk
!
interface GigabitEthernet0/14
 port-type nni
 switchport mode trunk
!
interface GigabitEthernet0/15
 port-type nni
 switchport mode trunk
!
interface GigabitEthernet0/16
 port-type nni
 switchport mode trunk
!
interface Vlan1
 ip address 192.168.2.8 255.255.255.0
!
ip default-gateway 192.168.2.1
no ip http server
ip http secure-server
ip classless
!
!
!
!
control-plane
!
!
line con 0
 speed 115200
line vty 0 4
 login
line vty 5 15
 login
!
end

 

 

 

What am I missing? Please help.

 

 

"This new learning amazes me, Sir Bedevere. Explain again how sheep's bladders may be employed to prevent earthquakes." King Arthur
15 Replies 15

Richard Burts
Hall of Fame
Hall of Fame

Thanks for posting the config. I find it unexpected that all ports are configured as trunks. Can you tell us what is connected to the switch? And can you tell us what you are attempting ping from?

It might be helpful to post the output of show arp from the switch.

HTH

Rick

All ports are configured as trunks because this is going to be a backbone switch.

I am pinging from a Windows 10 machine.

 

Ethernet adapter Broadcom:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
   Physical Address. . . . . . . . . : 00-10-18-B1-0C-02
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.2.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 127.0.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

 

The card is connected to the Port 1 of the switch via a patch cable, which I am sure works.

This is the command I issue:

 

C:\>ping -t -w 500 -S 192.168.2.2 192.168.2.8

 

This is the ARP cache of the switch:

 

CISCO#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.2.8             -   0023.05bc.03c0  ARPA   Vlan1

 

 

 

"This new learning amazes me, Sir Bedevere. Explain again how sheep's bladders may be employed to prevent earthquakes." King Arthur

Hello,

Vlan 1 is the native Vlan by default. If you need to use a trunk for your connection, set it to something else, your PC NIC might not be able to read native Vlan traffic:

interface GigabitEthernet0/1
switchport mode trunk
--> switchport trunk native vlan 999

That can't be the issue.

Untitled-1.png

As a matter of fact, it used to work before I reset the switch.

Yo don't see any problems with my configuration, I presume?

 

"This new learning amazes me, Sir Bedevere. Explain again how sheep's bladders may be employed to prevent earthquakes." King Arthur

Thanks for the additional information. The show arp from the switch shows clearly that the switch is not seeing the PC. To help figure out the issue would you post the output on the switch of these commands:

show interface status

show interface trunk

I would suggest as a test: if PC is connected to port 1 then configure port 1 as an access port in vlan 1.

I notice that the PC is configured with an IP address and mask but does not have a default gateway. That should not matter for a local ping, but I would suggest that you configure a default gateway on the PC.

HTH

Rick

Actually, the switch DOES see the PC. I have pfSense installed as a virtual machine, with the DHCP server enabled on the relevant interface.

When I do this on the switch:

CISCO#config term
Enter configuration commands, one per line.  End with CNTL/Z.
CISCO(config)#interface Vlan1
CISCO(config-if)#ip address dhcp
CISCO(config-if)#end

I see this on the pfSense VM:

selahattin_cilek_0-1672494903449.png

 


@Richard Burts wrote:

I would suggest as a test: if PC is connected to port 1 then configure port 1 as an access port in vlan 1.


I tried that too, but it did not work.

 

CISCO#show interface status

Port      Name               Status       Vlan       Duplex  Speed Type
Gi0/1                        connected    1          a-full a-1000 10/100/1000BaseTX
Gi0/2                        notconnect   1            auto   auto Not Present
Gi0/3                        notconnect   1            auto   auto Not Present
Gi0/4                        notconnect   1            auto   auto Not Present
Gi0/5                        notconnect   1            auto   auto Not Present
Gi0/6                        notconnect   1            auto   auto Not Present
Gi0/7                        notconnect   1            auto   auto Not Present
Gi0/8                        notconnect   1            auto   auto Not Present
Gi0/9                        notconnect   1            auto   auto Not Present
Gi0/10                       notconnect   1            auto   auto Not Present
Gi0/11                       notconnect   1            auto   auto Not Present
Gi0/12                       notconnect   1            auto   auto Not Present
Gi0/13                       notconnect   1            auto   auto Not Present
Gi0/14                       notconnect   1            auto   auto Not Present
Gi0/15                       notconnect   1            auto   auto Not Present
Gi0/16                       notconnect   1            auto   auto Not Present
CISCO#show interface trunk

CISCO#

 

"This new learning amazes me, Sir Bedevere. Explain again how sheep's bladders may be employed to prevent earthquakes." King Arthur

Thanks for the additional information, which is very interesting. My comment that the switch was not seeing the PC was based on the fact that there was no entry in the switch arp cache for the PC. The information from pfSense does indicate that there is some communication. So I will ask you to test again with this revised approach:

- on the switch enable debug for arp

- on the PC do the ping

- on the switch quickly do a show arp and then look for any debug output. Post the results.

When you mentioned testing from a PC I assumed that it was from a simple PC. But now it is clear that the PC has VMs running. I wonder if there is something in the VM that is impacting communication with the switch?

HTH

Rick

Got this:

 

 

CISCO#
*Mar  1 00:36:47.227: IP ARP: rcvd req src 192.168.2.2 0010.18b1.0c02, dst 192.168.2.8 Vlan1
*Mar  1 00:36:47.227: IP ARP: ignored gratuitous arp src 192.168.2.2 0010.18b1.0c02, dst 192.168.2.8 0023.05bc.03c0, interface Vlan1
*Mar  1 00:36:47.227: IP ARP: sent rep src 192.168.2.8 0023.05bc.03c0,
                 dst 192.168.2.2 0010.18b1.0c02 Vlan1
CISCO#

 

And this on the PC:

 

C:\Users\prodigy>arp -a

Interface: 192.168.2.2 --- 0x8
  Internet Address      Physical Address      Type
  192.168.2.8           00-23-05-bc-03-c0     dynamic
  192.168.2.28          00-23-05-bc-03-c0     dynamic
  192.168.2.101         00-23-05-bc-03-c0     dynamic
  192.168.2.255         ff-ff-ff-ff-ff-ff     static
  224.0.0.22            01-00-5e-00-00-16     static

 

PS: 192.168.2.28 was mistakenly configured.

 

"This new learning amazes me, Sir Bedevere. Explain again how sheep's bladders may be employed to prevent earthquakes." King Arthur

Thank you for the additional test. The output is quite surprising. The switch does see the arp request, does send an arp response (so the PC has an arp entry for switch) but switch does not create an arp entry for the PC. The surprising part is "ignored gratuitous arp src 192.168.2.2". I have 2 questions about that:

1) why does the switch believe that this was gratuitous arp?

2) if it was gratuitous arp then why does the switch respond to it?

It is sounding like something buggy in the switch code. Is there any possibility that in doing the reset you wound up running a version of code different from what it had been running?

HTH

Rick


It is sounding like something buggy in the switch code. Is there any possibility that in doing the reset you wound up running a version of code different from what it had been running?

I might have, I tried a lot to get it reset to factory defaults. Is there a remedy for that? Can I update it?

"This new learning amazes me, Sir Bedevere. Explain again how sheep's bladders may be employed to prevent earthquakes." King Arthur

Hello,

--> system mtu routing 1998

What if you change that value to 1500 ?

I managed to get it working, though I have no idea why it works.

First, I did this:

CISCO#write erase

After reboot, when it asked me if I'd like to proceed with basic management setup, I said "no":

Would you like to enter basic management setup? [yes/no]: no

Then, magically, it started to respond to ping requests.

This is the running configuration:

CISCO#show run
Building configuration...

Current configuration : 1381 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname CISCO
!
boot-start-marker
boot-end-marker
!
enable secret 5 [redacted]
enable password [redacted]
!
no aaa new-model
system mtu routing 1998
ip subnet-zero
ip routing
!
!
!
!
!
!
!
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
!
!
vlan internal allocation policy ascending
!
!
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
 shutdown
!
interface GigabitEthernet0/3
 shutdown
!
interface GigabitEthernet0/4
 shutdown
!
interface GigabitEthernet0/5
 shutdown
!
interface GigabitEthernet0/6
 shutdown
!
interface GigabitEthernet0/7
 shutdown
!
interface GigabitEthernet0/8
 shutdown
!
interface GigabitEthernet0/9
 shutdown
!
interface GigabitEthernet0/10
 shutdown
!
interface GigabitEthernet0/11
 shutdown
!
interface GigabitEthernet0/12
 shutdown
!
interface GigabitEthernet0/13
 port-type nni
!
interface GigabitEthernet0/14
 port-type nni
!
interface GigabitEthernet0/15
 port-type nni
!
interface GigabitEthernet0/16
 port-type nni
!
interface Vlan1
 ip address 192.168.2.8 255.255.255.0
!
no ip http server
ip http secure-server
ip classless
!
!
!
!
control-plane
!
!
line con 0
line vty 0 4
 password [redacted]
 login
line vty 5 15
 password [redacted]
 login
!
end

Does anyone have an idea why it worked this time? What is the difference?

 

"This new learning amazes me, Sir Bedevere. Explain again how sheep's bladders may be employed to prevent earthquakes." King Arthur

While there are several things that are different, I believe that the most important difference is that in this configuration the switch interfaces are access ports and in the earlier configuration they were trunk ports.

HTH

Rick


@Richard Burts wrote:

While there are several things that are different, I believe that the most important difference is that in this configuration the switch interfaces are access ports and in the earlier configuration they were trunk ports.


All the ports are now in trunk mode, and it still works. I guess we'll never know why it would get an IP from DHCP but not respond to ping requests. Maybe it just would not communicate on the IP level, for some curious reason.

I have managed to upgrade to upgrade to "me340x-metroipaccessk9-mz.122-55.SE12.bin", by the way.

Thank you very much and wish you all good luck.

 

"This new learning amazes me, Sir Bedevere. Explain again how sheep's bladders may be employed to prevent earthquakes." King Arthur
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card