-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Time sync issue between SONiC and FRR stack #13046
Comments
@nmoray-ebay is the issue in seen master branch? |
Yeah @madhupalu |
@nmoray-ebay can you confirm if this issue can be resolved if you restart BGP? |
No @gechiang as there is no time sync between the bgp container and host. |
@madhupalu @gechiang ...I already have the fix for this issue. We can resolve this issue by mounting host's /etc/localtime and /etc/timezone on the bgp container. |
@gechiang Thanks for triaging the issue. @nmoray-ebay please raise a PR and add myself and @gechiang for code review. |
Sure @madhupalu. Thanks! |
@gechiang : |
@gechiang @zhangyanzhao |
@madhupalu @gechiang..PR has been raised. [https://github.com//pull/13852] |
#### Why I did it To fix the timezone sync issue between the containers and the host. If a certain timezone has been configured on the host (SONIC) then the expectation is to reflect the same across all the containers. This will fix [Issue:13046](#13046). For instance, a PST timezone has been set on the host and if the user checks the link flap logs (inside the FRR), it shows the UTC timestamp. Ideally, it should be PST.
#### Why I did it To fix the timezone sync issue between the containers and the host. If a certain timezone has been configured on the host (SONIC) then the expectation is to reflect the same across all the containers. This will fix [Issue:13046](sonic-net#13046). For instance, a PST timezone has been set on the host and if the user checks the link flap logs (inside the FRR), it shows the UTC timestamp. Ideally, it should be PST.
Description
There is a time sync issue between SONIC and the FRR stack. For instance, Inside vtysh, "Show interface status" CLI output and FRR log always shows the UTC timestamp which does not match with the SONIC in case a specific time zone is configured on the SONIC side.
Steps to reproduce the issue:
Describe the results you received:
LOGS:
root@SN2100-Leaf1:
# show clock# timedatectl set-timezone America/Los_Angeles ========> configured as PST ( using set timezone)Wed 14 Dec 2022 09:47:17 AM UTC
root@SN2100-Leaf1:
root@SN2100-Leaf1:
##root@SN2100-Leaf1:
root@SN2100-Leaf1:
## show clockroot@SN2100-Leaf1:
Wed 14 Dec 2022 01:48:12 AM PST
root@SN2100-Leaf1:
# config interface shutdown Ethernet0# config interface startup Ethernet0root@SN2100-Leaf1:
root@SN2100-Leaf1:~# vtysh
Hello, this is FRRouting (version 7.5.1-sonic).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
SN2100-Leaf1# date
% Unknown command: date
SN2100-Leaf1# show int Ethernet0
Interface Ethernet0 is up, line protocol is down
Link ups: 1 last: 2022/12/14 06:35:42.89. ====> shows UTC timestamp
Link downs: 6 last: 2022/12/14 09:48:48.29
vrf: default
index 748 metric 0 mtu 9100 speed 0
flags: <UP,BROADCAST,MULTICAST>
Type: Unknown
HWaddr: 1c:34:da:36:f8:00
Interface Type Other
Interface Slave Type None
root@SN2100-Leaf1:/var/log/frr# tail -5f zebra.log
Dec 14 09:48:37.953850 SN2100-Leaf1 ERR bgp#zebra[35]: [EC 4043309093] netlink-dp (NS 0) error: Network is down, type=RTM_NEWNEXTHOP(104), seq=165, pid=2957759799
Dec 14 09:48:37.954253 SN2100-Leaf1 ERR bgp#zebra[35]: [EC 4043309074] Failed to install Nexthop ID (6) into the kernel
Dec 14 09:48:48.306387 SN2100-Leaf1 ERR bgp#zebra[35]: Extended Error: Carrier for nexthop device is down
Dec 14 09:48:48.306387 SN2100-Leaf1 ERR bgp#zebra[35]: [EC 4043309093] netlink-dp (NS 0) error: Network is down, type=RTM_NEWNEXTHOP(104), seq=169, pid=2957759799
Dec 14 09:48:48.306529 SN2100-Leaf1 ERR bgp#zebra[35]: [EC 4043309074] Failed to install Nexthop ID (6) into the kernel
Describe the results you expected:
Expecting a time sync between SONIC timezone and the FRR stack so that there will not be any confusion while interpreting the logs.
Output of
show version
:The text was updated successfully, but these errors were encountered: