Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Other Discussions
  3. IT & Infrastructure
  4. Joining networks with IP conflicts (programmable router?)

Joining networks with IP conflicts (programmable router?)

Scheduled Pinned Locked Moved IT & Infrastructure
questionsysadmintestingbeta-testinghelp
5 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N Offline
    N Offline
    normanS
    wrote on last edited by
    #1

    I am working on a project which is made up of 3 separate networks, each of which has a custom data communications device which is used to communicate between the separate networks. The final configuration will be as follows: NetA having 3 devices, IP 10.2.10.1, 10.2.10.11, 10.2.10.12, attached to a hub. NetB having 3 devices, IP 10.2.10.1, 10.2.10.21, 10.2.10.22, attached to a hub. NetC having 3 devices, IP 10.2.10.1, 10.2.10.31, 10.2.10.32, attached to a hub. The device in all nets with IP 10.2.10.1 is the data comms unit - once we get production equipment, the IP address will be fixed, but we can set the IP on the prototype equipment. For convenience during development, we have connected all the devices to a single network, including a Test PC (IP X.X.X.99) which talks to one PC on each of the networks (X.X.X.11, X.X.X.21, and X.X.X.31). To prevent IP clashes, we change the IP address of the prototype comms devices to X.X.X.1, X.X.X.2 and X.X.X.3. The problem is that now we want to start testing using the production comms devices and have just realised (oops) that we are going to have IP clashes. One solution is to fit 3 network cards to the test PC, and route messages to NetA, NetB, and NetC via these different network cards. Unfortunately we can't do this. The second solution is to use "some sort of programmable router". (It's in inverted commas because I'm just guessing what we need.) NetA, NetB, NetC and TestPC would connect to ports on the "programmable router". The router would be programmed to implement the following rules: Messages on NetA, NetB, or NetC addressed to 10.2.10.99 would be routed to the test PC. Messages on NetA, NetB, or NetC to any other IP address would be ignored by the "programmable router". Messages from TestPC to 10.2.10.11 would be routed to NetA by the "programmable router". Messages from TestPC to 10.2.10.21 would be routed to NetB by the "programmable router". Messages from TestPC to 10.2.10.31 would be routed to NetC by the "programmable router". Messages from TestPC to any other IP address would be ignored by the "programmable router". Network loadings are low (a few percent.) Delays in the routing between the networks are not critical up to a few milliseconds. How easy is it to do this? What equipment do I need? Any suggested manufacturer & model numbers? What is the rough cost?

    S 1 Reply Last reply
    0
    • N normanS

      I am working on a project which is made up of 3 separate networks, each of which has a custom data communications device which is used to communicate between the separate networks. The final configuration will be as follows: NetA having 3 devices, IP 10.2.10.1, 10.2.10.11, 10.2.10.12, attached to a hub. NetB having 3 devices, IP 10.2.10.1, 10.2.10.21, 10.2.10.22, attached to a hub. NetC having 3 devices, IP 10.2.10.1, 10.2.10.31, 10.2.10.32, attached to a hub. The device in all nets with IP 10.2.10.1 is the data comms unit - once we get production equipment, the IP address will be fixed, but we can set the IP on the prototype equipment. For convenience during development, we have connected all the devices to a single network, including a Test PC (IP X.X.X.99) which talks to one PC on each of the networks (X.X.X.11, X.X.X.21, and X.X.X.31). To prevent IP clashes, we change the IP address of the prototype comms devices to X.X.X.1, X.X.X.2 and X.X.X.3. The problem is that now we want to start testing using the production comms devices and have just realised (oops) that we are going to have IP clashes. One solution is to fit 3 network cards to the test PC, and route messages to NetA, NetB, and NetC via these different network cards. Unfortunately we can't do this. The second solution is to use "some sort of programmable router". (It's in inverted commas because I'm just guessing what we need.) NetA, NetB, NetC and TestPC would connect to ports on the "programmable router". The router would be programmed to implement the following rules: Messages on NetA, NetB, or NetC addressed to 10.2.10.99 would be routed to the test PC. Messages on NetA, NetB, or NetC to any other IP address would be ignored by the "programmable router". Messages from TestPC to 10.2.10.11 would be routed to NetA by the "programmable router". Messages from TestPC to 10.2.10.21 would be routed to NetB by the "programmable router". Messages from TestPC to 10.2.10.31 would be routed to NetC by the "programmable router". Messages from TestPC to any other IP address would be ignored by the "programmable router". Network loadings are low (a few percent.) Delays in the routing between the networks are not critical up to a few milliseconds. How easy is it to do this? What equipment do I need? Any suggested manufacturer & model numbers? What is the rough cost?

      S Offline
      S Offline
      Sebastian Schneider
      wrote on last edited by
      #2

      Don't! Really, just don't! You could probably achieve this my manually configuring a L3-switch, and somehow preventing it from updating the ARP-table/MAC-cache or routing-table, but I cannot give you a model or make. You would be routing to individual hosts, and you absolutely need to make sure that the 10.2.10.1 devices never ever send even a single bit to any system. Otherwise, the switch might "learn" a new address for 10.2.10.1 and send all packages there. Then somewhere else, then to the first one again, and so on. As an alternative: Try configuring one system with the shared IP-address, give unique IP-addresses to the three systems (thus solving the name clash problem), and then have your new system translate the network addresses based on criteria only you know (NAT!). Cheers Sebastian

      Cheers, Sebastian -- Ceterum censeo, borlandem esse delendam.

      N 1 Reply Last reply
      0
      • S Sebastian Schneider

        Don't! Really, just don't! You could probably achieve this my manually configuring a L3-switch, and somehow preventing it from updating the ARP-table/MAC-cache or routing-table, but I cannot give you a model or make. You would be routing to individual hosts, and you absolutely need to make sure that the 10.2.10.1 devices never ever send even a single bit to any system. Otherwise, the switch might "learn" a new address for 10.2.10.1 and send all packages there. Then somewhere else, then to the first one again, and so on. As an alternative: Try configuring one system with the shared IP-address, give unique IP-addresses to the three systems (thus solving the name clash problem), and then have your new system translate the network addresses based on criteria only you know (NAT!). Cheers Sebastian

        Cheers, Sebastian -- Ceterum censeo, borlandem esse delendam.

        N Offline
        N Offline
        normanS
        wrote on last edited by
        #3

        Thanks for the response. I agree - whatever the solution, it will have to be manually configured, and we will have to ensure that it never ever "learns" like a normal router or switch. The 10.2.10.1 devices are used to transmit and receive messages, so one of them has to be active on each of the 3 nets. The 10.2.10.1 device only talks to computers in the net it is on. Only the TestPC has to be able to talk to computers on all 3 nets. I have never worked with these networking thingys, so let's see if I understand the NAT idea. We connect the test PC (maybe using a cross-over network cable) to one port on a NAT. NetA, NetB, and NetC connect to 2nd, 3rd, and 4th ports. Then we set up the NAT to implement the rules in my original posting? Or is a NAT a 2-port device, in which case we need 2 or 3 of them? I will read up on NATs and see if I can work out how to use one. I am sure I could implement my rules programatically, using a PC with 3 or 4 networks cards as a bridge (wrong term, maybe), but I would far prefer to buy something off the shelf.

        S 1 Reply Last reply
        0
        • N normanS

          Thanks for the response. I agree - whatever the solution, it will have to be manually configured, and we will have to ensure that it never ever "learns" like a normal router or switch. The 10.2.10.1 devices are used to transmit and receive messages, so one of them has to be active on each of the 3 nets. The 10.2.10.1 device only talks to computers in the net it is on. Only the TestPC has to be able to talk to computers on all 3 nets. I have never worked with these networking thingys, so let's see if I understand the NAT idea. We connect the test PC (maybe using a cross-over network cable) to one port on a NAT. NetA, NetB, and NetC connect to 2nd, 3rd, and 4th ports. Then we set up the NAT to implement the rules in my original posting? Or is a NAT a 2-port device, in which case we need 2 or 3 of them? I will read up on NATs and see if I can work out how to use one. I am sure I could implement my rules programatically, using a PC with 3 or 4 networks cards as a bridge (wrong term, maybe), but I would far prefer to buy something off the shelf.

          S Offline
          S Offline
          Sebastian Schneider
          wrote on last edited by
          #4

          NAT stands for "Network Address Translation". That is what almost every device interconnection the internet and a LAN will do. Take, for example, a consumer router. The router connects to the internet and gets assigned a single IP. That would mean that only one computer could use the internet at the same time. The router, being a NAT-device, solves this problem. To the "Internet", it seems there is only one device: the router, which "owns" the IP-address assigned to it. When any computer from inside the LAN sends a request to any internet ip, the router will replace the LAN-address (i.e. 192.168.0.2) with it's own IP and send the request out. It will then store all information necessary to map the incoming replies (IPs, Ports, Sequence Numbers) and use those to distribute the incoming replies accordingly. You will have to do something similar in order to be able to make the networks visible to each other. And yes, I'd call that computer a "bridge" :) You need to filter the TCP/IP packets, though. Really, there is no simple solution to your problem. Actually, you might save yourself a lot of trouble if you just assign those devices different IP-addresses, or "test" them idependantly. Setting up three test environments might - in the end - be a LOT cheaper than buying / programming a solution for your problem.

          Cheers, Sebastian -- Ceterum censeo, borlandem esse delendam.

          N 1 Reply Last reply
          0
          • S Sebastian Schneider

            NAT stands for "Network Address Translation". That is what almost every device interconnection the internet and a LAN will do. Take, for example, a consumer router. The router connects to the internet and gets assigned a single IP. That would mean that only one computer could use the internet at the same time. The router, being a NAT-device, solves this problem. To the "Internet", it seems there is only one device: the router, which "owns" the IP-address assigned to it. When any computer from inside the LAN sends a request to any internet ip, the router will replace the LAN-address (i.e. 192.168.0.2) with it's own IP and send the request out. It will then store all information necessary to map the incoming replies (IPs, Ports, Sequence Numbers) and use those to distribute the incoming replies accordingly. You will have to do something similar in order to be able to make the networks visible to each other. And yes, I'd call that computer a "bridge" :) You need to filter the TCP/IP packets, though. Really, there is no simple solution to your problem. Actually, you might save yourself a lot of trouble if you just assign those devices different IP-addresses, or "test" them idependantly. Setting up three test environments might - in the end - be a LOT cheaper than buying / programming a solution for your problem.

            Cheers, Sebastian -- Ceterum censeo, borlandem esse delendam.

            N Offline
            N Offline
            normanS
            wrote on last edited by
            #5

            ((Formatting updated.)) Thanks Sebastian I did some reading up on NATs, and I am trying to find someone in our IT department who knows how to set them up to implement my filter requirement. But we may have found a much easier and cheaper solution. We can't change the IP of the comms device, which is the same (10.2.10.1) on each network. We don't have control of the test PC software, but we can tell it the IP of the devices it must communicate with. We can change the setup of the PCs in each network which talk to the test PC, and we can change the hardware configuration of the test PC (add more network cards.) The solution is this: Set the IPs of the PCs which talk to the test PC to 10.2.10.11 (on NetA), 10.2.20.21 (on NetB), and 10.2.30.31 (on NetC), with netmasks all set to 255.255.0.0. Install 2 extra network cards into the test PC, and set the 3 IP addresses to 10.2.10.9, 10.2.20.9. and 10.2.30.9, all with netmasks = 255.255.255.0. The first network interface connects to NetA (with 10.2.10.11 etc.) The second network interface connects to NetB (with 10.2.20.21), and the third to NetC (with 10.2.30.31). That's it - as long as the software on the test PC is "well behaved", and is talking to network via Windows calls rather than talking directly to the card, Windows routes the messages sent by the test PC software to the three network cards according their destination IP address. I hope to find a spare network card this morning to test this idea - I'll post the results.

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups