IP / Gateway mismatch = lockout? 1

[jdelgado244]

Hello,

One of the technicians today set up a standalone (non-pc) unit to have:

IP: 192.168.9.20
Mask: 255.255.255.0
Gateway: 192.168.1.1

When it made the changes he was unable to get back in. The unit does have a RS-232 port, but we haven't been able to successfully get a prompt from it. Also there is no reset button. If I connect a laptop to the LAN port, what settings should i have to connect? I was thinking about setting the laptop IP to match what the unit had for its gateway, but that didn't work. Any help would be appreciated.

Thank you.

 

[burtsbees]

Use a crossover cable, set the IP address of the comp that you can get to 192.168.9.19 255.255.255.252---the gateway won't matter for a directly connected link like this.

What device is this? It seems it does not have a route to the gateway device...if you have a hop in between (I.E. router) with 192.168.9.0/24 on the inside interface, and 192.168.1.0/24 on the outgoing interface, this in fact would work.

Burt

 

[VinceWhirlwind]

In the absence of a working default GW, ethernet connectivity will work fine if you use another device with an IP address in the same subnet, patched to the same LAN segment.

So, configure your laptop with 192.168.9.177 and patch it to a switch port in the same VLAN as your DEVICE.
LAPTOP will compare the destination address to its subnet mask and realise it's on the same subnet and broadcast an ARP request asking for the DEVICE's MAC address.
DEVICE will see the ARP request and reply with its MAC address.
LAPTOP will encapsulate the packet in a frame with that MAC address as the destination address.
DEVICE will receive the frame, break it, and get the IP packet.

 

[burtsbees]

Well sure, if you wanted to break it down like that...show off...lol

Burt

 

[VinceWhirlwind]

I find it helps to show people how simple it is and that there's no black magic involved - might help them *not* jump to the "there's a network problem" conclusion next time.

 

[burtsbees]

Seems the more experiance users USUALLY jump into "it's a network problem". For example, I had a customer this weekend trying to set the IP address of an RSA card in an IBM server but was unable to ping. They were pinging through a few Cisco switches, and they're set up with many vlans, port mac-address-security sticky commands, acl's, specific static routes/route maps, etc. Myself, being experienced, suggested that they eliminate all that is possible to cause problems and connect straight to a laptop via crossover cable. That worked, of course, so now they know it's a "network issue", though they think it is something faulty. As convoluted as things are (including multicast PIM configs, IOS firewall/CBAC configs, etc.) between the node and the server when initially testing things, it seemed like common sence to eliminate all these factors. Their tech doing this was very experienced from a very prominent financial firm, but that doesn't mean the troubleshooting skills are always there...K.I.S.S.

Burt