"ip a" command on a guest VM shows UNKNOWN status
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Medium
|
Eric Desrochers | ||
Trusty |
Fix Released
|
Medium
|
Eric Desrochers | ||
Xenial |
Fix Released
|
Medium
|
Eric Desrochers | ||
Artful |
Fix Released
|
Medium
|
Eric Desrochers | ||
Bionic |
Fix Released
|
Medium
|
Eric Desrochers |
Bug Description
[Impact]
"ip a" command on a guest VM shows UNKNOWN status.
[Test Case]
* Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK.
* Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example:
2: eth0: <BROADCAST,
.....
[Regression Potential]
* Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_
* The patch has been first accepted in net-next, then move into Linus's git.
[1] - VIRTIO_NET_F_STATUS
Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config.
[Other Info]
* Linus: https:/
* Net-next:
https:/
[Original Description]
It has been brought to our attention the following bug :
-------
Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK.
Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https:/
static inline bool netif_oper_up(const struct net_device *dev)
{
return (dev->operstate == IF_OPER_UP ||
dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}
Code Ref:
1. https:/
2. https:/
3. https:/
Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated.
-------
Changed in linux (Ubuntu Trusty): | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Eric Desrochers (slashd) |
description: | updated |
description: | updated |
Changed in linux (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Artful): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Xenial): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Trusty): | |
status: | In Progress → Fix Committed |
tags: |
added: verification-done-artful verification-done-trusty verification-done-xenial removed: verification-needed-artful verification-needed-trusty verification-needed-xenial |
tags: |
added: kernel-fixup-verification-needed-bionic removed: verification-needed-bionic |
tags: | added: verification-needed-bionic |
For qemu and upstream DPDK, support is present for the VIRTIO_NET_F_STATUS capability, and as such should not experience the "UNKNOWN" operstate issue; jvosburgh checked qemu and don't see this issue when running it, but haven't set up DPDK to verify it's behavior.
The opencontrail vrouter source code does not support VIRTIO_ NET_F_STATUS, which dovetails with the prior analysis that suggests that this lack of support would lead to the operstate UNKNOWN.
jvosburgh also examined the virtio specification itself. It indicates that if VIRTIO_NET_F_STATUS is not available, the "link should be assumed active."