Tunnel server configuration between Primary and Robots hub

[Purneswara Rao Konda]

Hi community,

One of my customer is planning to configure three tier architecture like primary, proxy and robots hub however each tier has firewall in between so I would like to ask what is the best practices to configure tunnel server and where exactly we need to configure tunnel server to properly setup three tier architecture? Can any one suggest please!

Regards,

Eshwar

------------------------------
Regards,

Eshwar
------------------------------

[Jim Christensen]

My recommendation is to configure the proxy (mid-tier) hub as the tunnel
server and the Primary and robot hubs to be clients.

[Garin Walsh]

Agreed with "configure the proxy (mid-tier) hub as the tunnel server and the Primary and robot hubs to be clients"

Also, while overall slower to interact/connect, I highly recommend setting up the secure hub/robot too. With multiple tiers, the propagation of the hub list data is slowed and so you will see a huge increase in the amount of churn and accessible/nonaccessible hubs in your network. With the secure hub configuration, most of the churn is eliminated.

[Purneswara Rao Konda]

@Jim Christensen and @Garin Walsh, Thank you for your valuable sugeestion.

If we configure secure hub as you suggested, so queues will be created separately for each message subject or QOS messages and alarms into one queue and other messages into another queue. Kindly suggest as this is critical aspect because messages efficiently transport to next tier. 

Thank you in advance.

------------------------------
Regards,

Eshwar
------------------------------

[Jim Christensen]

Alarms should be a separate queue. QOS DEFINITION, QOS MESSAGES, AND QOS BASELINE another queue. Basically separate queues for each message subject. In my opinion, the most critical is having the alarm messages separated.Sent from my T-Mobile 5G Device

[Garin Walsh]

Just to argue the other side of the coin,

If you separate the alarms from the data into separate queues, and if one of those queues gets significantly backed up then you create a situation where for a period of time the alarm will say one thing and the data say something else which will create confusion to a user if they notice.

The OS isn't mentioned but if this is Windows then you also have the subscriber issue - each tunnel and each queue will cost a "subscriber" and because Windows is using the handle notification event to manage these, when you reach 64 subscribers and queues, it changes to a round robin methodology which is significantly more costly in resource consumed and responsiveness. So if you use a queue for each subject then you will use subscribers rapidly. Also you have to maintain chronology of messages that are related - like ensuring the QOS_DEFINITION subject is processed before the QOS_MESSAGE messages that are dependent on that definition.  

Also, if you have many queues, you have many things to keep track of and maintain. 

What we wound up doing (we have 5 levels of hubs/tunnels/queues because of volume and number of hubs) is that between the outermost (leaf node) hub and the first inbound hop (affectionately referred to as tunnel proxy) the queue subject is "*" - with thousands of hubs if Broadcom adds a new subject (like the probe_discovery one) then we don't have to worry about touching all the outermost hubs with an update to accommodate. Plus the volume from a single hub is going to be small relative to everything else. On the tunnel proxy, the data is separated into two queues: QOS related and not QOS related subjects. At the next hop, the alarm data is pealed off and given to multiple nas instances. nas replication gets the alarm data to the central hub and the remaining messages are forwarded to the central hub via a queue for QOS related subjects and a queue for everything else minus the alarm subjects.

This works for us but it is certainly not how the system started out and kind of grew organically to this point. Expect that whatever you decide, that something is going to come along to coerce a change to it.