Menu ▾ ▴

#2517 repeated OID in ipCidrRouteTable on Darwin13

macOS
open
nobody
darwin13 (1) ipCidrRouteTable (1)
5
2014-08-18
2013-12-10
Bill Fenner
No

Running net-snmp 5.7.3.pre1 on Darwin13, with a simple "snmpwalk <agent>", a given row is returned twice:

IP-FORWARD-MIB::ipCidrRouteDest.127.0.0.0.255.0.0.0.0.127.0.0.1 = IpAddress: 127.0.0.0
IP-FORWARD-MIB::ipCidrRouteDest.127.0.0.1.0.0.0.0.0.127.0.0.1 = IpAddress: 127.0.0.1
IP-FORWARD-MIB::ipCidrRouteDest.134.170.24.161.0.0.0.0.0.192.168.1.1 = IpAddress: 134.170.24.161
IP-FORWARD-MIB::ipCidrRouteDest.147.28.0.35.0.0.0.0.0.192.168.1.1 = IpAddress: 147.28.0.35
IP-FORWARD-MIB::ipCidrRouteDest.157.55.56.140.0.0.0.0.0.192.168.1.1 = IpAddress: 157.55.56.140
IP-FORWARD-MIB::ipCidrRouteDest.162.210.130.3.0.0.0.0.0.192.168.1.1 = IpAddress: 162.210.130.3
IP-FORWARD-MIB::ipCidrRouteDest.162.210.130.3.0.0.0.0.0.192.168.1.1 = IpAddress: 162.210.130.3
Error: OID not increasing: IP-FORWARD-MIB::ipCidrRouteDest.162.210.130.3.0.0.0.0.0.192.168.1.1
 >= IP-FORWARD-MIB::ipCidrRouteDest.162.210.130.3.0.0.0.0.0.192.168.1.1

Discussion

  • Bill Fenner

    Bill Fenner - 2013-12-10

    Frustratingly, this is only sometimes repeatable. It is the same oid when it does happen, but after restarting the agent with -DALL I was not able to repeat this.

     

  • Niels Baggesen

    Niels Baggesen - 2013-12-10

    Does it happen with inetCidrRouteTable too (yes, I noticed it was not consistent)?
    What does your actual routing table look like?

     

  • Bill Fenner

    Bill Fenner - 2014-07-08

    Yup, it happens with inetCidrRouteTable too. I just tried again with the top of the V5-7-patches branch.

    IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["157.55.130.160"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"] = INTEGER: 5
IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["157.56.53.41"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"] = INTEGER: 5
IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["162.210.130.3"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"] = INTEGER: 5
IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["162.210.130.3"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"] = INTEGER: 5
Error: OID not increasing: IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["162.210.130.3"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"]
 >= IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["162.210.130.3"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"]

    and a different spot in the ipCidrRoute table:

    IP-FORWARD-MIB::ipCidrRouteDest[192.168.1.0][128.0.5.4][0][6.0.0.0] = IpAddress: 192.168.1.0
IP-FORWARD-MIB::ipCidrRouteDest[192.168.1.0][136.0.5.4][0][6.0.0.0] = IpAddress: 192.168.1.0
IP-FORWARD-MIB::ipCidrRouteDest[192.168.1.1][0.0.0.0][0][6.0.6.0] = IpAddress: 192.168.1.1
IP-FORWARD-MIB::ipCidrRouteDest[192.168.1.4][0.0.0.0][0][6.0.6.0] = IpAddress: 192.168.1.4
IP-FORWARD-MIB::ipCidrRouteDest[192.168.1.4][0.0.0.0][0][6.0.6.0] = IpAddress: 192.168.1.4
Error: OID not increasing: IP-FORWARD-MIB::ipCidrRouteDest[192.168.1.4][0.0.0.0][0][6.0.6.0]
 >= IP-FORWARD-MIB::ipCidrRouteDest[192.168.1.4][0.0.0.0][0][6.0.6.0]

    I see at least a couple of problems with the ipCidrRoute data:

    1. 0.0.0.0 and other nonsensical netmasks (128.0.5.4?)

    2. also bogus nexthops, e.g., 6.0.0.0, 6.0.6.0

    3. The route for 192.168.1.4 is actually an ARP entry

    One very plausible reason that we're having trouble reading this routing table is that I have two connections to the same subnet - one wired, one wireless (because I'm too lazy to turn off wireless when I plug into the Thunderbolt monitor that has an Ethernet connection). The routing table looks kinda "interesting":

    192.168.1          link#5             UCS             5        0     en6
192.168.1          link#10            UCSI            4        0     en1
192.168.1.1        0:1f:90:70:8b:dd   UHLWIir        35     1103     en6   1170
192.168.1.1        0:1f:90:70:8b:dd   UHLWIir         1        2     en1   1170
192.168.1.4        90:72:40:9:3c:f7   UHLWI           0        0     en6   1080
192.168.1.4        90:72:40:9:3c:f7   UHLWI           0        0     en1   1080
192.168.1.5        90:72:40:9:3c:f7   UHLWIi          1  8729223     en6   1175
192.168.1.5        90:72:40:9:3c:f7   UHLWI           0        0     en1    906
192.168.1.13       127.0.0.1          UHS             4     1705     lo0
192.168.1.14       127.0.0.1          UHS             0       18     lo0
192.168.1.17       b4:c:25:17:f9:10   UHLWI           0        0     en6   1163
192.168.1.17       b4:c:25:17:f9:10   UHLWI           0        0     en1   1163
192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI          0       18     en6

    On the inetCidrRouteTable side, there are entries for destinations that are not in my routing table:

    127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH             14   103879     lo0
162.210.130.3      192.168.1.1        UGHS            0        0     en6
169.254            link#5             UCS             2        0     en6

    but

    IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["127.0.0.0"][8][SNMPv2-SMI::zeroDotZero.1][ipv4]["127.0.0.1"] = INTEGER: 1
IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["127.0.0.1"][32][SNMPv2-SMI::zeroDotZero.1][ipv4]["127.0.0.1"] = INTEGER: 1
IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["134.170.18.206"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"] = INTEGER: 5
IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["157.55.130.160"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"] = INTEGER: 5
IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["157.56.53.41"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"] = INTEGER: 5
IP-FORWARD-MIB::inetCidrRouteIfIndex[ipv4]["162.210.130.3"][32][SNMPv2-SMI::zeroDotZero.5][ipv4]["192.168.1.1"] = INTEGER: 5

    These extra destinations are destinations that I have TCP connections with, so they appear to be route caches (used to share TCP connection data between multiple TCP connections) - "route get <destination>" shows, e.g.,

    forbin:Applications fenner$ route get 134.170.18.206
   route to: bn1msgr1011409.gateway.edge.messenger.live.com
destination: bn1msgr1011409.gateway.edge.messenger.live.com
    gateway: 192.168.1.1
  interface: en6
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0      2976         0         5         0      1500         0

    I think the more I look at this, the more mysteries there are.

     

  • Bill Fenner

    Bill Fenner - 2014-08-18

    I looked at this a little more based on donatilo mentioning it on #net-snmp. The loop returning the same object is almost definitely due to the use of CONTAINER_KEY_ALLOW_DUPLICATES. The routing table is the only part of the system that sets this flag. While this allows duplicates to be inserted into the binary container, it doesn't handle them when trying to getnext. Imagine the following container contents:

    A B C D D E F <= contents
1 2 3 4 5 6 7 <= pos

    Let's do a getnext of D. Our binary search returns pos 4, cool. Now let's increment the iterator to pos 5 and return that value. Oops, we returned D again!

    If CONTAINER_KEY_ALLOW_DUPLICATES is set, we need more code (not yet clear to me where) to handle the getnext handling in the face of duplicates.

    A straightforward resolution would be to stop setting CONTAINER_KEY_ALLOW_DUPLICATES, but of course that re-introduces the performance problem that it was trying to solve.

     

Log in to post a comment.