Trouble connecting to Management port with either direct or switched ethernet connection

[Tim_Black]

I have a windows 10 host with an ethernet interface (configured with static ip 192.168.1.2/24) that is directly connected to the Management Port of an X440G2-12p-10G4. Both sides of physical connection have their 1G link lights on. Via serial console on this switch, I have set an ip address on the Mgmt vlan of 192.168.1.100/24. But from the windows machine I cannot ping nor telnet the switch at 192.168.1.100. Can you help me diagnose the reason why?

From the windows host, I see:
C:\>ipconfig
Windows IP Configuration
Ethernet adapter VirtualBox Host-Only Network:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::593a:8176:d2a:d8e8%18
IPv4 Address. . . . . . . . . . . : 192.168.56.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter Ethernet 2:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::1c19:e5e6:9b2:4aa5%12
IPv4 Address. . . . . . . . . . . : 192.168.1.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
C:\>ping 192.168.1.100
Pinging 192.168.1.100 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.1.100:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.8.1 172.16.8.60 25
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
172.16.8.0 255.255.255.0 On-link 172.16.8.60 281
172.16.8.60 255.255.255.255 On-link 172.16.8.60 281
172.16.8.255 255.255.255.255 On-link 172.16.8.60 281
192.168.1.0 255.255.255.0 On-link 192.168.1.2 281
192.168.1.2 255.255.255.255 On-link 192.168.1.2 281
192.168.1.255 255.255.255.255 On-link 192.168.1.2 281
192.168.56.0 255.255.255.0 On-link 192.168.56.1 281
192.168.56.1 255.255.255.255 On-link 192.168.56.1 281
192.168.56.255 255.255.255.255 On-link 192.168.56.1 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.56.1 281
224.0.0.0 240.0.0.0 On-link 172.16.8.60 281
224.0.0.0 240.0.0.0 On-link 192.168.1.2 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.56.1 281
255.255.255.255 255.255.255.255 On-link 172.16.8.60 281
255.255.255.255 255.255.255.255 On-link 192.168.1.2 281
===========================================================================
Persistent Routes:
I included the VirtualBox Host-Only adapter in the list bc its network is in the ballpark, but I believe this to be irrelevant since, well, it's a different network from the EXOS switch's Mgmt network.

From the switch I see:

* X440G2-12p-10G4.2 # show vlan
-----------------------------------------------------------------------------------------------
Name VID Protocol Addr Flags Proto Ports Virtual
Active router
/Total
-----------------------------------------------------------------------------------------------
Default 1 10.0.0.1 /24 ------------T--------------- ANY 2 /16 VR-Default
Mgmt 4095 192.168.1.100 /24 ---------------------------- ANY 1 /1 VR-Mgmt
-----------------------------------------------------------------------------------------------
* X440G2-12p-10G4.3 # show switch
SysName: X440G2-12p-10G4
SysLocation:
SysContact: support@extremenetworks.com, +1 888 257 3000
System MAC: 00:04:96:9B:9B:E2
System Type: X440G2-12p-10G4
SysHealth check: Enabled (Normal)
Recovery Mode: All
System Watchdog: Enabled
Current Time: Wed Sep 26 00:34:25 2018
Timezone: [Auto DST Disabled] GMT Offset: 0 minutes, name is UTC.
Boot Time: Tue Sep 25 20:32:43 2018
Boot Count: 23
Next Reboot: None scheduled
System UpTime: 4 hours 1 minute 41 seconds
Current State: OPERATIONAL
Image Selected: secondary
Image Booted: secondary
Primary ver: 22.1.1.5
Secondary ver: 21.1.2.14
patch1-2
Config Selected: primary.cfg
Config Booted: primary.cfg
primary.cfg Created by ExtremeXOS version 21.1.2.14
272505 bytes saved on Tue Sep 25 20:32:07 2018
* X440G2-12p-10G4.4 # show mgmt
VLAN Interface with name Mgmt created by user
Admin State: Enabled Tagging: 802.1Q Tag 4095
Description: Management VLAN
Virtual router: VR-Mgmt
IPv4 Forwarding: Disabled
IPv4 MC Forwarding: Disabled
Primary IP: 192.168.1.100/24
IPv6 Forwarding: Disabled
IPv6 MC Forwarding: Disabled
IPv6: None
STPD: None
Protocol: Match all unfiltered protocols
Loopback: Disabled
NetLogin: Disabled
OpenFlow: Disabled
QosProfile: None configured
Flood Rate Limit QosProfile: None configured
Ports: 1. (Number of active ports=1)
Untag: Mgmt-port on Mgmt is active
Any ideas what I am doing wrong here, and what I should check next? Is there some other step to enabling the Mgmt port over ip on these switches?

This is a similar problem to this one, which doesn't seem to have a solution:
https://community.extremenetworks.com/extreme/topics/connectivity-to-a-switch-x440

Thanks,
Tim

p.s. This is an aside from my problem statement, but FWIW I am using the Management port intentionally here because this switch (and many other EXOS switches like it at my company) will be used for network automation in test environments (dynamically turning ports on/off, creating vlans, etc to form various network topologies for the DUTs to be connected to) and:
(a) I want to guarantee the test machines will have dedicated, unfettered access to the switches in the case of botched switch configuration at test runtime, so we have a guaranteed way to reset configuration, and
(b) I want to save a "normal" port by using the Mgmt port, since in some cases we may be using small port count switch variants (like the one in this example) that are like to fill up in the test.

[Tim_Black]

The findings in my previous post have turned out to be neither here, nor there. I just got into work for the first time since filing this issue and checked the connection myself, and I have confirmed that the problem all along was that the physical ethernet connection wasn't correct! This explains why my outgoing pings appeared to succeed but there was no response, and also explains why I could not ping from the PC. I have been home sick the last few days and although I asked a coworker to check this connection a couple days ago, the mis-connection was not detected.

I apologize to anyone who followed this thread. Even though it turned out not to be a configuration issue, the process of investigating configuration on these switches was a useful learning experience for me.

Thanks again,
Tim

[Tim_Black]

Regarding item 3. in my previous post, I reviewed the command I was using before to try and delete the route on vr-mgmt and think I see why it was rejected.

I was using:
configure iproute delete default 192.168.1.1to try to remove a default route for a specific VirtualRouter (VR-Mgmt), which doesn't make sense.

Instead I learned I should use this command, which specifies specifically which VirtualRouter the default route is for:
configure iproute delete default 192.168.1.1 vr "VR-Mgmt"I know this succeeded, bc afterwards I get:
* X440G2-12p-10G4.7 # sho iproute vr "VR-Mgmt"
Ori Destination Gateway Mtr Flags VLAN Duration
#d 192.168.1.0/24 192.168.1.100 1 U------um--f- Mgmt 2d:0h:38m:33s

[Tim_Black]

Thanks Roy. Before I open a case, I want to finish investigating this bc i feel very close: I have a very similar setup in another location (linux machine with direct connection to Mgmt port of same EXOS model X440G2-12p-10G4) that is working fine, and I've compared their configurations, and the only differences are:

1. The working switch has extra config for the 10G ports (13-16) "configure ports auto off speed 10000 duplex full". This seems unrelated.
2. The not-working switch has configured an ipaddress on Default vlan: "configure vlan Default ipaddress 10.0.0.1 255.255.255.0" This also seems unrelated.
3. The not-working switch configures a default route for VR-Mgmt which as I've reported, I cannot delete: "configure iproute add default 192.168.1.1 vr VR-Mgmt"
4. The working switch is running ver 21.1.5.2 and the non-working switch is running 21.1.2.14.

I still can't believe 3 isn't the culprit, but as I mentioned before I haven't been able to successfully remove this default route (which shouldn't be necessary since the Mgmt port doesn't support routing anyway).

Also before opening a case, I'm going to make sure I can get management access through the Default Vlan/VR and one of the "normal" ports. From there I should be able to update Firmware to latest, and then reverify the problem. If it's a faulty Mgmt port, it should fail even with newer Firmware, and I imagine that would be one of the first things GTAC would do.

[Roy_Noh]

Hello Tim,

It seems you've already checked configuration part and understood VR-mgmt notation.
We had some cases where Mgmt port is not working due to several reasons.
CRC error can be one of that as well as faulty Mgmt port.
But checking out CRC error on mgmt port requires a debug password which GTAC can provide you one.
Also if this problem is due to a H/W fault, you can claim an RMA for the device.
Kindly consider to open a case so that GTAC engineers can analysis the issue further.