Question for network admins

Started by dbuerer, May 21, 2019, 09:09:08 PM

Previous topic - Next topic

dbuerer

Manufacturer working on a new Building Management Control Protocol.  Due to the need to address many nodes rapidly, and, TCP/IP being too slow for the task, we are researching other methods.  However, we would like to be as friendly as possible to the IT team in the building?

How do you guys feel about multi-cast UDP?  Would that commonly be allowed through corporate routers?

deanwebb

Before we do IP multicast, is there not a quick way to have these devices do DHCP? That allows the device to request an IP address automatically. Then, on the DHCP server side, reserve those addresses for each device so they are essentially static.

Do these devices use non-IP protocols for other communications?

Back to the multicasting, yes, those can go through the routers. It's basically how companies do video streaming of all-hands meetings and events like that.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

Otanx

So why do you think TCP/IP is too slow for the task? You can have your server do things in parallel. If you have 120 BMS devices that need updates that take 1 second each that takes 2 minutes doing it one at a time. However, if you have your server connect to 30 at a time it would only take 4 seconds up update them all.

With multicast you are going to run into other issues. How do you know the end device got the update? You can not assume that the network is delivering 100% of the packets you send. Now you need to poll the devices in some way to make sure they all are in the expected state. Then what happens if it isn't? Do you send a unicast update to those devices? Do you re-multicast the update? Both of those have issues that need to be addressed.

Also not all networks support multicast. I would say most could with medium and large sized business customers that would have a BMS, but you will run into many that don't have it setup because they have not had a use case for it. And while I would like to think that all network engineers could setup multicast you will run into some that can't do it, or do it wrong and cause issues that will then be blamed on your gear.

-Otanx

Dieselboy

From previous experiences, if you have a large or reasonable number of devices that a server needs to communicate with frequently and that server does not re-use TCP connections; you can easily and quickly run out of TCP ports on the server side. Microsoft (not sure what the default is in 2016 or 2012) had a limit on the number of TCP connections that it would use. Something like 1024 - 5000. So if you have all of them in TIMEWAIT then you've ran out of ports and things will grind to a halt until one of the ports frees up by exceeding the time wait timeout value. I believe Redhat Linux does not have this limitation (by default).

Could this be your slow experience with TCP issue?

wintermute000

#4
Most enterprise net-engs know somewhere between squat and diddly all re: multicast. I've only ever had to touch it twice in the wild, and the last time involved reading extremely long books again
Industrial networks, HA HA HA HA HA

If you want your product to be deployed widely, avoid even if it is technically the better solution.
FWIW I have a hard time believing a BMS system will overwhelm unicast TCP/IP, unless you're talking about concurrently streaming dozens of 4k UHD streams or something like that.

Note multicast L2 may work without explicit configuration depending on model/OS of switches . However if improperly configured it will melt down the L2 domain due to excessive flooding. Again you'll have to cross the bridge of getting people to actually learn how to configure multicast. L2 multicast however is a lot less work than actually routing it at L3.

Dieselboy

Quote from: wintermute000 on June 04, 2019, 06:24:31 AM

If you want your product to be deployed widely, avoid even if it is technically the better solution.
FWIW I have a hard time believing a BMS system will overwhelm unicast TCP/IP, unless you're talking about concurrently streaming dozens of 4k UHD streams or something like that.


Same here... thats why I was thinking about tcp port exhaustion. Hopefully, we'll find out :)


Quote from: wintermute000 on June 04, 2019, 06:24:31 AM
Industrial networks, HA HA HA HA HA

:XD:

wintermute000

#6
TBH in many ways its a bit like STP - just do the 'defaults' and stand back, it generally works.


- Haz normal routing working
- Do RPs
- Turn on PIM sparse-mode on every L3 interface
- Turn on IGMP snooping on every switch
- Profit

The trouble begins when dealing with
- WAN
- Security devices - ever ask a FW guy about how their box deals with multicast?
- Multi-domain


But yeah a ton of companies I've seen haven't implemented multicast at layer-3.

deanwebb

Me security.

Me no like multicast. GRRR!  :evil:
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.