Skip to content
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

7060CX-32S eth0 interface coming up after ~2 minutes #16

Closed
prsunny opened this issue Oct 23, 2017 · 2 comments
Closed

7060CX-32S eth0 interface coming up after ~2 minutes #16

prsunny opened this issue Oct 23, 2017 · 2 comments

Comments

@prsunny
Copy link

prsunny commented Oct 23, 2017

eth0 interface is found to be coming up only after ~2 minutes.

Tested with the following version of Sonic image:
admin@str-7060cx-acs-10:~$ show version
SONiC Software Version: SONiC.HEAD.287-2a56479

Please find the timelines below: (Note: T2 is 1 minute 53 second AFTER T1)

Time & Event

T0 - 0 sec - Executed reboot
T1 - 48 sec - Login prompt
T2 - 1 min 54 second - eth0 is UP

@prsunny
Copy link
Author

prsunny commented Oct 24, 2017

In the case of image upgrade, eth0 is coming up after ~1 minute 35 sec after getting the login prompt.

admin@str-7060cx-acs-10:~$ show version
SONiC Software Version: SONiC.HEAD.295-c74007b
Distribution: Debian 8.9
Kernel: 3.16.0-4-amd64

@Staphylo
Copy link
Member

There are two reasons why this could happen.

The first one is if there is no DHCP server available. In this case the networking service would hang until dhclient timeout (1min). Given that the default minigraph for Arista platform doesn't provide a <ManagementIPInterfaces> section, dhclient is invoked twice during the first boot which is aligned with the timing.

The second possibility which I think is the one hitting here is due to the udevadm settle command in the networking service /etc/init.d/networking
Given that the pmbus driver take a while to be loaded we moved their initialization in the background. However loading new drivers continue to generate udev events which is what udevadm settle is waiting until it ends.

Few solution from there would be

  • Avoiding the udevadm settle on Arista platforms
  • Adding a timeout to the command
  • Finding a way to avoid for networking unrelated events
  • Replacing the command by something like udevadm settle --exit-if-exists /sys/class/net/eth0

I'm currently investigating the 3rd solution as it seems to be the less invasive but I'm not totally sure about the feasibility.

prsunny pushed a commit to sonic-net/sonic-buildimage that referenced this issue Oct 31, 2017
* [Arista]: Fix the udev waiting in networking start

This change is to fix the issue in aristanetworks/sonic#16
For the checking condition used, it is only applied to Arista switches

Signed-off-by: Boyang Yu <byu@arista.com>

* [Arista]: Correct for PR comments

Signed-off-by: Boyang Yu <byu@arista.com>
@prsunny prsunny closed this as completed Nov 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants