route from wrong nic under k8s calico env

[superscari]

nics
https://github.com/superscari/abc/blob/master/BAA8E356-39C9-44db-8A38-B0D9A11F011A.png
route -n
https://github.com/superscari/abc/blob/master/DINGTALK_IM_993349831.JPG
when routing to 10.10.120.162 by " iface, _, preferredSrc, e := router.Route(v4Ip)",
i found that the result was all the infos of cali93e400*** nic.

by the way,i commented some code in routing.go (line 219-221):
/*if i != iface.Index-1 { return nil, fmt.Errorf("out of order iface %d = %v", i, iface) }*/

so how can i get the correct nic returned

[charles-d-burton]

I'm experiencing the same issue when the iface looks like this:

10: vethPNSPCO@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether fe:ce:e0:b2:9c:15 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fcce:e0ff:feb2:9c15/64 scope link
       valid_lft forever preferred_lft forever

This is on a host with a lot of bridged interfaces for LXC containers able to DHCP directly on the network.

[charles-d-burton]

I modified line 216 to output the index that it's receiving and it's giving a mismatch on the index.

if i != iface.Index-1 {
      return nil, fmt.Errorf("out of order iface %d = %d", i, iface.Index)
}

Which now shows me why the error is happening:

2019/12/27 17:43:29 router error: out of order iface 8 = 10

So I think the index check should ensure that it's not zero as the docs on net.Interface explain that the iface should never be zero but I don't see anything about a guarantee on the iface index matching the position in an array.

number of ifaces 16
2019/12/27 17:49:45 router error: out of order iface 8 = 10

Which that number of interfaces is correct, I just have some number missing from what I believe are ephemeral ifaces. For instance, my server skips iface 9 entirely which speaks to the earlier point that there is no guaranteed order of the iface number matching the index position in an array.

8: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:59:b9:46 brd ff:ff:ff:ff:ff:ff
10: vethPNSPCO@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether fe:ce:e0:b2:9c:15 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fcce:e0ff:feb2:9c15/64 scope link
       valid_lft forever preferred_lft forever

[superscari]

I modified line 216 to output the index that it's receiving and it's giving a mismatch on the index.

if i != iface.Index-1 {
      return nil, fmt.Errorf("out of order iface %d = %d", i, iface.Index)
}

Which now shows me why the error is happening:

2019/12/27 17:43:29 router error: out of order iface 8 = 10

So I think the index check should ensure that it's not zero as the docs on net.Interface explain that the iface should never be zero but I don't see anything about a guarantee on the iface index matching the position in an array.

number of ifaces 16
2019/12/27 17:49:45 router error: out of order iface 8 = 10

Which that number of interfaces is correct, I just have some number missing from what I believe are ephemeral ifaces. For instance, my server skips iface 9 entirely which speaks to the earlier point that there is no guaranteed order of the iface number matching the index position in an array.

8: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:59:b9:46 brd ff:ff:ff:ff:ff:ff
10: vethPNSPCO@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether fe:ce:e0:b2:9c:15 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fcce:e0ff:feb2:9c15/64 scope link
       valid_lft forever preferred_lft forever

great

[metarsit-nutonomy]

@charles-d-burton I saw you closed the PR, did you have a workaround for this?

[charles-d-burton]

@metarsit-nutonomy Yeah, I forked the code and fixed it. I forgot to put up a PR though so I'd have to sync everything at this point. I'll try to get around to it at some point. It's possible that it was fixed too.