How to reproduce the bug: # ip link show 1: lo: ... 3: eth1: ... Let's create dot1Q interface and attach it to netns A: # ip link add link eth1 name eth1.10 type vlan id 10 # ip netns add A # ip link set dev eth1.10 netns A # ip netns exec A ip link show 1: lo: ... 21: eth1.10@if3: ... Now let's create dummy interface with ifIndex=3 in netns A: # ip netns exec A ip link add dummy1 index 3 type dummy # ip netns exec A ip link show 1: lo: ... 3: dummy1: ... 21: eth1.10@dummy1: ... 'ip link show' dispays invalid information about parent interface, but there are no problems with traffic
It doesn't look a bug. Interfaces are per namespace. ip link is reporting what it sees.
(In reply to Stephen Hemminger from comment #1) 'ip link show' displays invalid information about parent interface when parent interface located in different netns. It looks like a bug Is there any way to obtain netns information for parent interface? I think 'ip link' should show smth like this: 21: eth1.10@eth1(default ns) or 21: eth1.10@if3(another ns)
When you passed the eth1.10 to another namespace, the iflink index (parent) was no longer valid in that namespace. The iflink is informational only and not used for actual packet receive/transmit. When you created another device with a forced ifindex you created an association the iflink which was invalid now referenced a bogus device. The only thing I can say is, don't blame ip command it is showing what the kernel thinks is going on. Also, don't create devices with forced ifIndex, it is a good way to screw things up. The bug is a case of garbage in, garbage out.
I used forced ifIndex only to make a simple example to show the problem. The same problem in bug #66691 (without using forced ifIndex)