-
Notifications
You must be signed in to change notification settings - Fork 607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FeGW] TCP diameter Gx/Gy links failure #7496
Comments
It's not only affecting Gx/Gy TCP, the same logic is also used for s6a/swx & other diameter based protocols TCP or SCTP. |
Is there a workaround that could be taken on this issue? From a naive perspective the diameter client could raise a signal for service restart when it detects the usage of closed network connection. |
@uri200 , @themarwhal any thoughts and further insights about this issue? |
Hey @ekowtaylor this is not a simple feature. It will require code changes on all our diameter clients and testing to see HA is not impacted (which I am not even sure if it is possible). This should be planned for 1.7 and try to backport it to 1.6 if ready earlier |
@emersonacuna the issue may be coming from the vm where FEG is running. Per what I can see, this message is triggered when a socket is closed and feg tries to write on it. The reason for closing that socket is not known to the feg because there is nothing on the log that indicates an error. Can you include the syslog when this issue happens? Can you also include the version you are using (1.5? 1.5.1?) so I can try to build a custom binary please? |
@emersonacuna can you confirm that FEG is running at the ip |
Hi @uri200 yes. IPs of FeG are these ones: FeG Active 10.30.26.55 / FeG Backup 10.30.26.57. All the info i sent you is for FeG Backup. BTW, our current version is 1.4, but we are planning to upgrade 1.5.1. |
…ma#7496) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
…ma#7496) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
…ma#7496) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
…ma#7496) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
…ma#7496) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
…) (#7637) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
…) (#7637) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
…) (#7637) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
…) (#7637) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
@ekowtaylor this issue was closed. Waiting for the update to be installed at @emersonacuna setup to confirm |
…ma#7496) (magma#7637) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com> Signed-off-by: Ramon Melero <ramonmelero@fb.com>
…ma#7496) (magma#7637) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
…ma#7496) (magma#7637) Signed-off-by: Evgeniy Makeev <evgeniym@fb.com>
Federated LTE Network
Describe the Issue
Diameter links Gx/Gy are configured with TCP port to a DRA. Randomly, these links are getting down from time to time. The way we get back the links is with a manual restart of services of dockers. The links does not drop off at the same time, there is no patron of time.
The S6a link is configured with SCTP port and never happens this issue.
Expected behavior
Links must estable all the time, otherwise will generate alarms in the DRA's side.
Additional context
Attached the logs of session_proxy docker and the traces of Gx and Gy. Consider these info:
Gy (TCP port 5112) down time -> 02/06 21:46
Gx (TCP port 5111) down time -> 03/06 06:52
Each pcap file name ends with the interface name that got down within that capture
GxGy_down.zip
The text was updated successfully, but these errors were encountered: