# Ignition Hub & Spoke Device Connection

**URL:** <https://forum.inductiveautomation.com/t/ignition-hub-spoke-device-connection/47137>\
**Category:** Ignition\
**Created:** [May 26, 2021, 12:00pm UTC](https://forum.inductiveautomation.com/t/ignition-hub-spoke-device-connection/47137 "2021-05-26T12:00:08Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![danblibby](https://avatars.discourse-cdn.com/v4/letter/d/5e9695/32.png) [@danblibby](https://forum.inductiveautomation.com/u/danblibby)\
**Post date:** [May 26, 2021, 12:00pm UTC](https://forum.inductiveautomation.com/t/ignition-hub-spoke-device-connection/47137/1 "2021-05-26T12:00:08Z")

</div>

Good morning,  
Is there any downside and/or benefit to having a device connection on the local gateway(Spoke) as well as the same device connection on a central gateway (Hub)?

Our current system utilizes a Hub & Spoke architecture with all of the device connections residing on the local gateway (Spoke). However; all remote connections and remote operations get funneled through the Hub project.

In the event that the local (Spoke) is turned off or loses connection we also lose the ability to operate via the Hub.

If I am not mistaken would it not be better to have these device connections on both gateways for operational redundancy? Would the only downside be extra traffic?

Thanks

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 26, 2021, 12:16pm UTC](https://forum.inductiveautomation.com/t/ignition-hub-spoke-device-connection/47137/2 "2021-05-26T12:16:10Z")

</div>

Most device connections are polling query/response TCP connections. Those are very sensitive to network latency, and use substantial bandwidth. Expect a device connection from the hub to have a dramatically higher load factor for the same tags. Routing through a local OPC server eliminates both problems. (OPC subscriptions only report changes to subscribers.) A secondary problem that a local spoke solves is comms load on the device itself. Many devices only have so much bandwidth to _process_ messages, aside from the network traffic. A second connection can impact the first connection.