Connect to switches with the same IP

Question

We used to have one site with one Cisco switch to which a RANCID server was connected to take configuration backup.

A new site was opened, and we have another switch on this new site. The sites have the same IP network addressing, and we cannot change it, seriously.

We have a task to connect a second switch to the RANCID server, and this gives us a bit of a headache as the IP network addresses of the switches are the same.

The RANCID server connects to the switches via telnet (security is not important).

So, the question is - how to connect the RANCID server to both switches without making any changes on switches (minor changes can be done on switches only as last resort)?

It seemed to me that one of the solutions is to install a router between switches and RANCID Server and perform NAT port forwarding:

But we cannot do it as ports connected to the switches should be in the same subnet.

I thought about using PBR, but in any case both interfaces cannot be in the same subnet.

From one point of view it seems pointless to have on both interfaces the same subnet because "how will the router know to which interface to send packets", from another point I don't want the router to know where to send packets because I can manually specify what to do with packets that, for example, fall under PBR access-list

Could you please advise if there is solution of this problem of connecting RANCID to switches with the same IP?

Answer 1

When companies merge, they often have this problem with overlapping addresses. Cisco has NAT Outside Source which helps to solve the problem. You can do an Internet search for "cisco ip nat outside source" to find information such as Sample Configuration Using the ip nat outside source list Command.

Introduction

This document provides a sample configuration with the ip nat outside source list command, and includes a brief description of what happens to the IP packet during the NAT process. You can use this command to translate the source address of the IP packets that travel from outside of the network to inside the network. This action translates the destination address of the IP packets that travel in the opposite direction—from inside to outside of the network. This command is useful in situations such as overlapping networks, where the inside network addresses overlap addresses that are outside the network. Let us consider the network diagram as an example.

Note: this should really only be a temporary situation, and you should strive to resolve the conflict. This is not something you want to maintain as a long term solution.

Another possible solution is to create VLANs on the switches just for the RANCID server connections, and you can set up different IP addresses for the switches on the server VLANs. This will not affect the switches and the existing LAN addressing, it just adds new addressing specifically for the server connections.

Answer 2

If the RANCID server is really on the same L2 segment as both switch management interfaces (which I sort of doubt, but maybe you make this work via some OOB tunnel magic), and it's a *nix host with iptables/ipfw/etc., then you can do something reasonably horrible like:

• Add a static ARP entry for each switch on the RANCID server using the real switch management MAC address.

  • Give them completely different IP addresses. We'll call them (MAC-A, IP-A), and (MAC-B, IP-B)

• Configure the RANCID server to talk to IP-A and IP-B (say 192.168.1.1 and 192.168.1.2, or some subnet you're not otherwise using)

• Mangle outgoing packets to IP-A and IP-B to rewrite dst_ip to be 10.0.0.1
• Mangle incoming packets to match src_mac of MAC-A and MAC-B and rewrite src_ip to be IP-A and IP-B, respectively, so the RANCID process will be happy

This will only work if your RANCID server is on the same L2 segment as the switch management interfaces (and you're using telnet - this won't work with any protocol that has any modicum of security awareness). And it's horrible.