ETC RPU IP conflict

[MrMurdoch]

Hi,

I have a RPU running as Primary connected to a Ion desk as backup and a RVI as client, as well as a RFR base station and remote. All are in the 10.101.10.XX range. When I connected a Ipad using iRFR - BTS app yesterday it ran fine, no issue. When I came in this morning after last nights show I connected as usual but got a message on the RPU that read "IP conflict", looked like a standard windows alert box with a "OK" button. After playing with the app settings a bit and trying to get it to connect I realised the desk had not connected to the RPU. I went into the RPU's network settings to find that it had all defaulted to 0.0.0.0

The IP, Mask, and gateway all read 0.0.0.0 After trying many combinations of things off and on I found that even just the Desk and only the desk being on the network and putting the ip back to 10.101.10.2 (the desk being 10.101.10.1 and the Ipod being 10.101.10.4) still gave a "IP conflict" alert and reset all my network settings (in the RPU). It was only after setting the desk to IP 10.101.10.5 that I was able to connect the RPU to the network without issue. Its like the address is unable to be used, like the RPU has disallowed that particular address.

Not really a network engineer but I've never heard of this happening before, a IP conflict locking down a particular address in a range at the device level.

Any information would be great.

Cheers.

 

[robartsd]

What is the address of the network switch? x.x.x.1 is often assigned to a switch or router.

 

[lightman02]

Are you using DHCP?

 

[MrMurdoch]

What is the address of the network switch? x.x.x.1 is often assigned to a switch or router.

Im unsure of the routers ip but it wasnt a problem using the desk as x.x.x.1 up until the ipad was introduced.

 

[MrMurdoch]

Are you using DHCP?

No, Static IP.

 

[Amiers]

Sounds like something else was holding the IP. I would say someone else was connected to that network at one time and the router was still holding that IP addy. That generally happens when other devices connect and aren't static. Really the best way to solve this is to keep your static IPs in the triple digits 100's plus.

 

[robartsd]

Sounds like something else was holding the IP. I would say someone else was connected to that network at one time and the router was still holding that IP addy. That generally happens when other devices connect and aren't static. Really the best way to solve this is to keep your static IPs in the triple digits 100's plus.

For my home network, I like to set up address reservations for my devices in the DHCP server configuration. This way my devices get the same address via DHCP every time they connect (and visting devices don't get my addresses). It is a good idea to make sure that your DHCP doesn't hand out the addresses you assign manually.

I wonder if the iPad was assigned x.x.x.1 before you configured the static address.

 

[lightman02]

The 10.101.10.1 is your gateway, you shouldn't use .1

 

[Brandon Merkle]

I was just going to say, my bet is on the gateway. Another thing you can do is go into the setting menu from the shell, maintenance button, and open Concert or GCE. That will load all your devices on the network and allow you to look at their IP configs. Should give you your answer.

 

[robartsd]

The 10.101.10.1 is your gateway, you shouldn't use .1

I've seen gateways that default to the last address in a sub net instead (x.x.x.254). There is no rule that says x.x.x.1 is the gateway, but .1 seems to be the most common practice.

 

[lightman02]

The .255 is the broadcast address.

 

[robartsd]

The .255 is the broadcast address.

Yes, that is why the router that defaulted to the last address used .254. (Also networks aren't required to support broadcasts and the subnet may be a size other than /24, so in theory .255 and .0 can be valid host addresses - but would not be recommended.)

My point was simply that the gateway address can and does vary from the .1 address on some networks.

FWIW, I've also seen routers with DHCP servers that default to using .100-.199 for dynamic addresses, so a blanket statement to start static addresses at .100 can sometimes be wrong too. The bottom line is you have to know your network to use static addressing.

 

[lightman02]

Agreed, sorry I misread your previous message.

 

[icewolf08]

The better question here is why did ALL of the devices dump their configured static IP addresses? That shouldn't happen at all, even if there is an address conflict.

I would suggest configuring the system using the IP addressing scheme that ETC uses. Only change from the norm if you have multiple of a device type. ETC used to have a list on their website that had the IP addresses that the factory assigns specific devices. For instance, sensor dimmers are usually 10.101.101.X, consoles are up around 10.101.9X.XX.

So, I have my network configured with ETC hardware in the IP ranges that they use, then I have my iRFR devices, NAS, router in the 10.101.1.XXX range. WAPs are in 10.101.4.XXX, guest hardware goes in 10.101.2.XXX, etc. This makes it easy to keep track of what devices are where, and to be able to limit what devices can talk to eachother. It also allows me to serve DHCP to guest devices, but keep resident devices on static IPS with no conflicts.

 

[Chris15]

The better question here is why did ALL of the devices dump their configured static IP addresses? That shouldn't happen at all, even if there is an address conflict.

IP devices that play nicely with others are required to make an ARP broadcast and await a response before using an IP address, Static or Dynamic.
The idea is that it should not use the IP if it gets a response to the broadcast, in which case it might default to a 0.0.0.0 address.
If there is a router involved, it may have old data in its MAC cache that is registering as in use and so the router is repsonding "No, you can't use that" and the console is obeying.
That should be in the realm of reboot the router and things should behave better...