2nd TCP/IP port needed

Thomas Hayes

Okay, after rebooting several hundred systems across campus today I really think that AMX needs to add the second LAN port on their controllers. The other company already has a second LAN port on theirs. My reasoning for this move is today a hacker found a way to turn off random ports on our network routers across campus. The fix was easy, just turn the port back on, but it also required all the techs and staff to run across the campus to reboot the switch, controller and touch panel. If AMX could add the 2'nd LAN port it would allow the system to still function regardless of the network functionality.

ericmedley

Thomas Hayes wrote: »

Okay, after rebooting several hundred systems across campus today I really think that AMX needs to add the second LAN port on their controllers. The other company already has a second LAN port on theirs. My reasoning for this move is today a hacker found a way to turn off random ports on our network routers across campus. The fix was easy, just turn the port back on, but it also required all the techs and staff to run across the campus to reboot the switch, controller and touch panel. If AMX could add the 2'nd LAN port it would allow the system to still function regardless of the network functionality.

Hmmm. perhaps you could write a routine to look for good network activity and have a periodic reboot from the program if it looses connection.

I have a few clients with really bad networks that we can do nothing about. I reboot their master as a matter of course every night at 4AM. It just seems to keep that system honest. Touch panels are a different matter, obviously.

I've always kinda wanted something like that on the touch panels. Something along the lines of, "if no connection to master for X minutes/hours, reboot every Y minutes for Z times." My systems do report to me when something is offline for too long. So, I can be a little proactive.

Thomas Hayes

I have done this already for normal network glitches and it works fine however no code will work when the network switch port has been shutdown.

Thomas Hayes

Sometime back I asked AMX if they could add a function to the G4 panels that would auto reboot if connection was lost for a 'x' time frame.

vining

While a 2nd IP port would be nice setting up a network spanning tree to provide a redundant loop between all your layer 2 switches should the primary path fail could be useful for this type of facility.

Thomas Hayes

This already exist.

Hedberg

Couldn't you just install a cheap VPN firewall router to isolate your AMX network?

The real problem, it seems to me, is when you are required to use the customer's network for the AMX equipment. In those cases, I don't see how a dual port master would help.

Maybe I'm missing something.

Spire_Jeff

Using the router idea, you could even configure the processor as the DMZ on the router and this would give you direct access to the processor, unfortunately, this will complicate the abililty to connect to the touch panels directly.

Jeff

Hedberg

A Cr*tron-like dual port configuration would prevent you from getting to the touch panels at all, I think.

But, if it were VPN, couldn't you access everything on the LAN side of the router via VPN?

Spire_Jeff

You could VPN, but if you want to stick with the cheap routers, I'm not sure how easy this is. You could also do port forwarding I suppose... if the router supports it.

Jeff

Thomas Hayes

Cheap routers are not an option, the IT department wants managed switches. My idea was a second LAN would allow the panel to be hooked to it on a subnet while the controller was on the main LAN. The problem was the router/switch ports being shutdown that the controllers are connected to. Doing this the controller lost connection to the panel. Without seeing our network design it can be a little hard to understand what I'm trying to convey.

vining

You need a network like this:

Auser

Hedberg wrote: »

A Cr*tron-like dual port configuration would prevent you from getting to the touch panels at all, I think.

Incorrect - you can manually forward individual ports from one interface to devices on the network to which the other interface is connected. Clumsy, but it works.

Hedberg

Auser wrote: »

Incorrect - you can manually forward individual ports from one interface to devices on the network to which the other interface is connected. Clumsy, but it works.

Didn't know that. Have done one or two C*tron systems which had dual port cards, but never actually used more than the one port. It appears that the C*tron system with dual port card will do NAT between the ports.

annuello

I'm no network expert, but I'd be more inclined to address the actual issue: A hacker is turning off your router ports. Adding additional NICs to endpoints may give them twice as many ways to cause trouble, and frankly does not address the non-AMX issues that your network would also be experiencing.

I always thought multi-NIC systems were for bridging between various networks. Given that your IT dept uses managed switches, they may then require full access to your AMX gear if (theoretically) the AMX had multi NICs. The AMX would also have additional processing load to cope with the traffic on both NICs. Double the cable infrastructure and double the switching ports... $$$ No, I'd rather stick with the one NIC in the AMX, and get your network secured properly. I guess network security policies/practices is a topic for another thread.

One feature request/suggestion that I have put to AMX is an "NI-700" that runs on PoE. That way our/your network guys can power-cycle the AMX from the managed switch, rather than have you running all over the place. This would obviously require a redesign of the NI-700, which would have to take into consideration how much current can be drawn from PoE. Accessories would be the tricky part (AXlink keypads, PIRs on the I/O +12v, etc), but I'm sure the base CPU could be powered off PoE. It would be nice if we could also power one AXlink keypad and 200mA (for PIR) off the I/O, all via PoE. This would cover our basic classroom setup, unless we migrate to the DVX-2100.

Roger McLean
Swinburne University

Thomas Hayes

After a several busy days of resetting the systems across campus things are now stable. After a longer discussion and reviewing the issue we had the IT department is going to build us a private network. It seems because my systems span the whole campus that they were open to issues across the campus. Even with the network setup simular to the diagram that Vinni showed( that is what we basically have here now) there were holes. The only systems that did not go down were ones that are already on a private network. The new network will be a physical one.