Bug 75911

Summary:	iproute2: 'ip link/address show' displays invalid parent interface name due to per-netns interface indexes
Product:	Networking	Reporter:	Sergey V. Lobanov (sergey)
Component:	Other	Assignee:	Stephen Hemminger (stephen)
Status:	REJECTED INVALID
Severity:	normal
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.14	Subsystem:
Regression:	No	Bisected commit-id:

Description Sergey V. Lobanov 2014-05-11 11:59:58 UTC

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

Comment 1 Stephen Hemminger 2014-05-11 18:02:44 UTC

It doesn't look a bug.

Interfaces are per namespace. ip link is reporting what it sees.

Comment 2 Sergey V. Lobanov 2014-05-12 02:52:03 UTC

(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)

Comment 3 Stephen Hemminger 2014-05-13 04:12:16 UTC

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.

Comment 4 Sergey V. Lobanov 2014-05-13 06:00:40 UTC

I used forced ifIndex only to make a simple example to show the problem. 

The same problem in bug #66691 (without using forced ifIndex)