How to change the IP address of a remote switch that has been misconfigured?

[kenglong]

I'm the new IT guy in this company. Previously, a  WS-C2924M-XL  switch in our main office had been upgraded and the old switch was installed in our branch office 300 miles away. This switch was originally configured with an ip address, netmask, and default gateway that matched our main office network. It was never changed or even wiped before shipping to the remote location. I can see it from the remote router with sh cdp nei det and am able to verify the wrong ip address.

Of course, I can't access the switch via the vty's because of the misconfiguration and there's no one at the branch office with the necessary skills to reset the switch. Is there any way to avoid a 600 mile round-trip drive to plug into the console port?

Thanks,

Ken Long, CCNA

Albuquerque, NM - USA

[Richard Burts]

Ken

If we knew a bit more about the situation we might be able to give you better suggestions. It sounds like at the remote site is a router which you can access, and that the router connects directly to this switch that is configured with a wrong IP address. If that is the case then I would suggest this approach to fixing the problem:

- log in to the remote router.

- change the IP address of the interface connecting to the switch so that it appears to be in the same subnet as the switch management vlan.

- then when the router and the switch are in the same vlan you should be able to telnet or SSH to the switch.

- when you are able to login to the switch which appears to be on the same subnet you should be able to configure its default gateway and then its IP address and mask to be the correct IP and mask.

- that will break the connection from the remote router to the switch.

- configure the router interface with the correct IP and mask, so that you are once again in the same subnet.

- now the switch should work locally and remotely.

HTH

Rick

[paul driver]

Hello

Following on from Richards suggestion, maybe also adding a secondary addressing on the routers interface attaching the switch would assist.

Another way if its a switch to switch connection is accessing it via its mac address

You will need to know the base mac address of the switch in question and its login password.

config t
cluster enable MAC
sh cluster  candidates ( this will show possible mac- addresses which can be accessed- verified by sh cdp neighbours)

cluster member 10 mac-address 0000.0000.1111 password XXX ( enable password of remote switch)

sh cluster members ( this will show you devices you have added to the clustering)

rcommand 10 ( access the switch)

res

Paul

 

[Richard Burts]

Paul

I had originally thought of using a secondary address on the router to establish that both devices were in the same subnet (and to reduce the impact to any other devices that connect through that router interface). But then I realized that the telnet or SSH packets from the router would use the primary IP address as the source address and the mis-configured switch would regard the packet as from a remote network. So it could not establish a connection to a remote since its default gateway is not correct.

Perhaps an option to consider is to combine both approaches (depending on aspects of the remote environment that we do not yet understand). If there are other devices connected in the remote subnet then perhaps Ken could configure an IP address as primary in the subnet that matches the "incorrect" switch and configure a secondary address that matches the other devices in the remote subnet?

HTH

Rick

[Jon Marshall]

We really need to know more about the setup.

If the router provides WAN connectivity and the LAN interface of that router is the default gateway of the clients then Rick's suggestion will effectively take down the site while you readdress.

Paul's secondary IP address suggestion wouldn't.

However whether either would work depends on where you access the router from. If you access it from the main office and the source IP is from the same subnet as you are temporarily assigning to the LAN interface of the router (either Rick or Paul's way) then i suspect as soon as you assign the IP to the LAN interface you will lose connectivity because the router now thinks that subnet is local.

So you need to make sure when you access the router your source IP is not from the same subnet as the one on the switch.

If you can do this then i would try Paul's suggestion of using a secondary IP as this way you do not cut off your remote office while trying to connect to the switch.

If you can get into the switch then as stated simply -

a) change the IP address and subnet mask to one from the original LAN interface subnet of the router. This will disconnect you from the switch.

b) log back into the switch and set the default gateway to the router interface IP

c) remove the secondary IP address,

Jon

[Richard Burts]

Jon

Welcome to the conversation :)

Excellent point about the potential impact of configuring the subnet on the remote router to match the subnet at the main site. So I will modify my suggestion to be that Ken configure the interface address of the router interface to be a /30 subnet with the switch IP and the router IP in that subnet and the remainder of the subnet routed back to the main site.

I continue to believe that while secondary addressing is an attractive alternative (in terms of reducing impact on other devices at the remote site) there is the problem of what address the router will use as the source address of telnet or SSH to the switch.

HTH

Rick

[Jon Marshall]

Rick

Yes, i forgot that telnet does not allow a secondary IP to be used although there is a web page showing how it can be done but i am hesitant to suggest it as -

a) never tried it

b) it's getting really complicated what with all the other configuration needed.

Using a smaller subnet mask would work for connectivity between the router and the switch but it still means that if the router is the default gateway for clients then we have broken that connectivity ie. the site is down while the readdressing takes place.

This may or may not be a problem but if the router is a default gateway, regardless of which subnet at the main office is used to access it, then i think it's important Ken understands downtime is needed to make the change.

Jon

[Richard Burts]

Jon

Referring back to the beginning of your original post - yes we need to understand more about the environment at the remote site. If we understood more about it we could assess the potential impact of the various alternatives.

As I think more about this I continue to believe that the optimum solution combines elements of both approaches. We need the router primary IP to be in the same subnet as the switch IP to allow the telnet or SSH to be established. If Ken also configured the router original IP as a secondary address then it minimizes the impact on other devices and their default gateway.

HTH

Rick

[kenglong]

Thank you everyone for your help and suggestions. I am encouraged by the thought that this may be possible after all.

The remote router can be accessed from the internal network via a VPN connection, from our WAN ip address, and from my home. I think I can do the "change ip address trick" while remoted in from my home which is on a completely different network from any of the business networks. Plus, I can do this late at night when no one is at the remote branch using the network.

So, the plan is to SSH to the remote router from home, change the ip address of the inside interface to match the network of the mis-configured switch, telnet to the switch, make the corrections, and finally change the inside interface of the router back to the proper ip address. I don't see any reason why I might lose my connection to the remote router by doing it from home. But, just in case, I'll see if I can simulate this in Packet Tracer first.

I'll check back in after this is all done and report what happened.

Thanks!

[0115aaaaa]

Ken writes "the remote router can be accessed from the internal network via a VPN".  We can't tell if the VPN terminates "outisde" this LAN we're talking about re-IP'ing, or "inside."  I'd go with the more cautious approach of adding a secondary IP on the LAN interface.

Yes, the source IP could be a different IP; but if the new "secondary" IP assigned to the router is the old switch's default-gateway (and not just some random IP from that subnet) then reply traffic should return  OK. (this assumes that the mgmt interface had a default gateway)

One other solution I'll mention is that you can run a console crossover cable from the CON port of that switch to the AUX port of your router (if it has one), and reverse telnet to it: use a cisco router as a 1-port terminal server.  You may need to mail them a cable, if they don't have a person who can use a crimper.