ā12-30-2022 11:41 AM - edited ā12-31-2022 08:54 AM
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.
ā12-30-2022 09:37 PM
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.
ā12-30-2022 11:37 PM - edited ā12-30-2022 11:40 PM
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
ā12-31-2022 03:49 AM
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
ā12-31-2022 04:54 AM
That can't be the issue.
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?
ā12-31-2022 05:46 AM
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.
ā12-31-2022 05:56 AM
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:
@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#
ā12-31-2022 06:11 AM
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?
ā12-31-2022 06:16 AM - edited ā12-31-2022 06:18 AM
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.
ā12-31-2022 06:39 AM
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?
ā12-31-2022 06:41 AM - edited ā12-31-2022 06:42 AM
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?
ā12-31-2022 07:35 AM
Hello,
--> system mtu routing 1998
What if you change that value to 1500 ?
ā12-31-2022 07:45 AM
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?
ā12-31-2022 08:45 AM
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.
ā12-31-2022 08:54 AM
@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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide