# Incorrect redundant gateway routing - fixed in 7.9.14

**URL:** <https://forum.inductiveautomation.com/t/incorrect-redundant-gateway-routing-fixed-in-7-9-14/34334>\
**Category:** Ignition\
**Created:** [April 30, 2020, 6:00pm UTC](https://forum.inductiveautomation.com/t/incorrect-redundant-gateway-routing-fixed-in-7-9-14/34334 "2020-04-30T18:00:14Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![driverk](https://avatars.discourse-cdn.com/v4/letter/d/aca169/32.png) [@driverk](https://forum.inductiveautomation.com/u/driverk)\
**Post date:** [April 30, 2020, 6:00pm UTC](https://forum.inductiveautomation.com/t/incorrect-redundant-gateway-routing-fixed-in-7-9-14/34334/1 "2020-04-30T18:00:14Z")

</div>

In the 7.9.14 release notes:

> > Fixed an issue where routing to redundant remote gateways can end up targeting the incorrect gateway based on disconnect/reconnect timing.\<\<

Is this issue long-standing in the 7.9.x line? I am asking because we may be a related problem in 7.9.6. In some odd cases, redundancy can detect a primary node problem, switch to backup, then quickly switch back to the primary.

This leads to a situation where we have to reset some components such as tag providers in order to resume normal operation.

---

<div class="post-metadata">

**Author:** ![salbrechtsen](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/salbrechtsen/32/18660_2.png) [@salbrechtsen](https://forum.inductiveautomation.com/u/salbrechtsen)\
**Post date:** [May 4, 2020, 4:19pm UTC](https://forum.inductiveautomation.com/t/incorrect-redundant-gateway-routing-fixed-in-7-9-14/34334/2 "2020-05-04T16:19:40Z")

</div>

I’m wondering the same thing. We’ve seen redundancy toggling as well on 7.9.9.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [May 4, 2020, 4:39pm UTC](https://forum.inductiveautomation.com/t/incorrect-redundant-gateway-routing-fixed-in-7-9-14/34334/3 "2020-05-04T16:39:00Z")

</div>

Yes, it’s a longstanding issue that affects basically the entire 7.9 and 8.0 line(s) without the fix.

---

<div class="post-metadata">

**Author:** ![driverk](https://avatars.discourse-cdn.com/v4/letter/d/aca169/32.png) [@driverk](https://forum.inductiveautomation.com/u/driverk)\
**Post date:** [May 4, 2020, 4:44pm UTC](https://forum.inductiveautomation.com/t/incorrect-redundant-gateway-routing-fixed-in-7-9-14/34334/4 "2020-05-04T16:44:40Z")

</div>

Thanks, PGriffith! We will make it a priority to qualify this release for deployment.

---

<div class="post-metadata">

**Author:** ![salbrechtsen](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/salbrechtsen/32/18660_2.png) [@salbrechtsen](https://forum.inductiveautomation.com/u/salbrechtsen)\
**Post date:** [May 4, 2020, 4:49pm UTC](https://forum.inductiveautomation.com/t/incorrect-redundant-gateway-routing-fixed-in-7-9-14/34334/5 "2020-05-04T16:49:58Z")

</div>

Thanks!

Can you share some more details as to what the issue is? Is there a workaround for those of us that haven’t upgraded yet?

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [May 4, 2020, 8:19pm UTC](https://forum.inductiveautomation.com/t/incorrect-redundant-gateway-routing-fixed-in-7-9-14/34334/6 "2020-05-04T20:19:34Z")

</div>

I don't think so, unfortunately; it's low-level internal code. From the fix:

> Here was the heart of the problem:
> 
> - Routes to redundant pairs (that are directly connected) are managed in a special way
> - The normal routing logic is/was interfering with that (which isn't exactly bad, except...)
> - when a disconnect occurred, the "redundancy refresh" command was timing out. If the connection was reestablished before that timeout, normal routing would disconnect the route to master, but the refresh (after the timeout), would think the master was good still, and not re-establish the route.