Same interface, different OID index?

RouterOS General
1

I am having problems with SNMP interfaces indexes.
I’m making a script that periodically checks the status of some variables, including traffic on the physical interface “ether1”.

I have two identical RB1100x2, with the same version of RoS (6.15) with the original names of interface (“ether1”).

RB number one:

[root@RB1] > interface ethernet print 
Flags: X - disabled, R - running, S - slave 
 #    NAME   				 MTU MAC-ADDRESS       ARP                                                  
 0 R  ether1 				1500 D4:CA:6D:E9:E9:31 enabled
 1 R  ether2 				1500 D4:CA:6D:E9:E9:32 enabled
      ether3 				1500 D4:CA:6D:E9:E9:33 enabled
 3 R  ether4 				1500 D4:CA:6D:E9:E9:34 enabled
 4 R  ether5 				1500 D4:CA:6D:E9:E9:35 enabled
 5 R  ether6 				1500 D4:CA:6D:E9:E9:36 enabled
 6 R  ether7 				1500 D4:CA:6D:E9:E9:37 enabled
 7 R  ether8 				1500 D4:CA:6D:E9:E9:38 enabled
 8 R  ether9 				1500 D4:CA:6D:E9:E9:39 enabled
 9 R  ether10				1500 D4:CA:6D:E9:E9:3A enabled
10    ether11				1500 D4:CA:6D:E9:E9:3B enabled
11    ether12				1500 D4:CA:6D:E9:E9:3C enabled
12 R  ether13				1500 D4:CA:6D:E9:E9:3D enabled

RB number two:

[root@RB2] > interface ethernet print 
Flags: X - disabled, R - running, S - slave 
 #    NAME    				 MTU MAC-ADDRESS       ARP    
 0 R  ether1  				1500 D4:CA:6D:E9:E8:E3 enabled
 1    ether2  				1500 D4:CA:6D:E9:E8:EF enabled
 2    ether3  				1500 D4:CA:6D:E9:E8:E5 enabled
 3    ether4  				1500 D4:CA:6D:E9:E8:E6 enabled
 4    ether5  				1500 D4:CA:6D:E9:E8:E7 enabled
 5 R  ether6  				1500 D4:CA:6D:E9:E8:E8 enabled
 6 R  ether7  				1500 D4:CA:6D:E9:E8:E9 enabled
 7    ether8  				1500 D4:CA:6D:E9:E8:EA enabled
 8    ether9  				1500 D4:CA:6D:E9:E8:EB enabled
 9    ether10 				1500 D4:CA:6D:E9:E8:EC enabled
10    ether11 				1500 D4:CA:6D:E9:E8:ED enabled
11    ether12 				1500 D4:CA:6D:E9:E8:EE enabled
12 R  ether13 				1500 D4:CA:6D:E9:E8:EF enabled

However, the indexes are different:

[root@RB1] > interface print oid
Flags: D - dynamic, X - disabled, R - running, S - slave
0 R name=.1.3.6.1.2.1.2.2.1.2.3 mtu=.1.3.6.1.2.1.2.2.1.4.3 mac-address=.1.3.6.1.2.1.2.2.1.6.3 admin-status=.1.3.6.1.2.1.2.2.1.7.3 oper-status=.1.3.6.1.2.1.2.2.1.8.3 bytes-in=.1.3.6.1.2.1.31.1.1.1.6.3 packets-in=.1.3.6.1.2.1.31.1.1.1.7.3 discards-in=.1.3.6.1.2.1.2.2.1.13.3 errors-in=.1.3.6.1.2.1.2.2.1.14.3 bytes-out=.1.3.6.1.2.1.31.1.1.1.10.3 packets-out=.1.3.6.1.2.1.31.1.1.1.11.3 discards-out=.1.3.6.1.2.1.2.2.1.19.3 errors-out=.1.3.6.1.2.1.2.2.1.20.3

root@RB2] > interface print oid
Flags: D - dynamic, X - disabled, R - running, S - slave
0 R name=.1.3.6.1.2.1.2.2.1.2.2 mtu=.1.3.6.1.2.1.2.2.1.4.2 mac-address=.1.3.6.1.2.1.2.2.1.6.2 admin-status=.1.3.6.1.2.1.2.2.1.7.2 oper-status=.1.3.6.1.2.1.2.2.1.8.2 bytes-in=.1.3.6.1.2.1.31.1.1.1.6.2 packets-in=.1.3.6.1.2.1.31.1.1.1.7.2 discards-in=.1.3.6.1.2.1.2.2.1.13.2 errors-in=.1.3.6.1.2.1.2.2.1.14.2 bytes-out=.1.3.6.1.2.1.31.1.1.1.10.2 packets-out=.1.3.6.1.2.1.31.1.1.1.11.2 discards-out=.1.3.6.1.2.1.2.2.1.19.2 errors-out=.1.3.6.1.2.1.2.2.1.20.2

I search in the forum for similar situations, but I found nothing with specific solution. Just the idea that the index depends on the name of the interface, but the idea here seems not to work.
Indexes need to be consistent because I need monitor 100 RBs with a only one script, only change IP.
Which condition can affect the index change?

PS: is there any way to get the transmitted and received bytes in an interface via API?

Greetings.

2

Do they have the same ROS version and board firmware loaded?

3

Yes.

RB1
version: 6.15
build-time: Jun/12/2014 12:25:29
model: 1100AHx2
current-firmware: 3.02
upgrade-firmware: 3.10

RB2
version: 6.15
build-time: Jun/12/2014 12:25:29
model: 1100AHx2
current-firmware: 3.02
upgrade-firmware: 3.10

4

This is another case with a RB450G (v5.25), which verifies that the names of the interfaces do not seem to affect the indices.

[admin@RB450G] > interface ethernet print
Flags: X - disabled, R - running, S - slave 
 #    NAME                                  MTU MAC-ADDRESS       ARP                              
 0 R  ether1-gateway                       1500 D4:CA:6D:E7:C3:2C enabled                          
 1 R  ether2-master-local                  1500 D4:CA:6D:E7:C3:2D enabled                          
 2 RS ether3-slave-local                   1500 D4:CA:6D:E7:C3:2E enabled                          
 3 RS ether4-slave-local                   1500 D4:CA:6D:E7:C3:2F enabled                          
 4 RS ether5-slave-local                   1500 D4:CA:6D:E7:C3:30 enabled

[admin@RB450G] > interface print oid
Flags: D - dynamic, X - disabled, R - running, S - slave
0 R name=.1.3.6.1.2.1.2.2.1.2.1 mtu=.1.3.6.1.2.1.2.2.1.4.1 mac-address=.1.3.6.1.2.1.2.2.1.6.1 admin-status=.1.3.6.1.2.1.2.2.1.7.1
oper-status=.1.3.6.1.2.1.2.2.1.8.1 bytes-in=.1.3.6.1.2.1.2.2.1.10.1 packets-in=.1.3.6.1.2.1.2.2.1.11.1 discards-in=.1.3.6.1.2.1.2.2.1.13.1
errors-in=.1.3.6.1.2.1.2.2.1.14.1 bytes-out=.1.3.6.1.2.1.2.2.1.16.1 packets-out=.1.3.6.1.2.1.2.2.1.17.1 discards-out=.1.3.6.1.2.1.2.2.1.19.1
errors-out=.1.3.6.1.2.1.2.2.1.20.1

1 R name=.1.3.6.1.2.1.2.2.1.2.2 mtu=.1.3.6.1.2.1.2.2.1.4.2 mac-address=.1.3.6.1.2.1.2.2.1.6.2 admin-status=.1.3.6.1.2.1.2.2.1.7.2
oper-status=.1.3.6.1.2.1.2.2.1.8.2 bytes-in=.1.3.6.1.2.1.2.2.1.10.2 packets-in=.1.3.6.1.2.1.2.2.1.11.2 discards-in=.1.3.6.1.2.1.2.2.1.13.2
errors-in=.1.3.6.1.2.1.2.2.1.14.2 bytes-out=.1.3.6.1.2.1.2.2.1.16.2 packets-out=.1.3.6.1.2.1.2.2.1.17.2 discards-out=.1.3.6.1.2.1.2.2.1.19.2
errors-out=.1.3.6.1.2.1.2.2.1.20.2

2 R name=.1.3.6.1.2.1.2.2.1.2.3 mtu=.1.3.6.1.2.1.2.2.1.4.3 mac-address=.1.3.6.1.2.1.2.2.1.6.3 admin-status=.1.3.6.1.2.1.2.2.1.7.3
oper-status=.1.3.6.1.2.1.2.2.1.8.3 bytes-in=.1.3.6.1.2.1.2.2.1.10.3 packets-in=.1.3.6.1.2.1.2.2.1.11.3 discards-in=.1.3.6.1.2.1.2.2.1.13.3
errors-in=.1.3.6.1.2.1.2.2.1.14.3 bytes-out=.1.3.6.1.2.1.2.2.1.16.3 packets-out=.1.3.6.1.2.1.2.2.1.17.3 discards-out=.1.3.6.1.2.1.2.2.1.19.3
errors-out=.1.3.6.1.2.1.2.2.1.20.3

3 R name=.1.3.6.1.2.1.2.2.1.2.4 mtu=.1.3.6.1.2.1.2.2.1.4.4 mac-address=.1.3.6.1.2.1.2.2.1.6.4 admin-status=.1.3.6.1.2.1.2.2.1.7.4
oper-status=.1.3.6.1.2.1.2.2.1.8.4 bytes-in=.1.3.6.1.2.1.2.2.1.10.4 packets-in=.1.3.6.1.2.1.2.2.1.11.4 discards-in=.1.3.6.1.2.1.2.2.1.13.4
errors-in=.1.3.6.1.2.1.2.2.1.14.4 bytes-out=.1.3.6.1.2.1.2.2.1.16.4 packets-out=.1.3.6.1.2.1.2.2.1.17.4 discards-out=.1.3.6.1.2.1.2.2.1.19.4
errors-out=.1.3.6.1.2.1.2.2.1.20.4

4 R name=.1.3.6.1.2.1.2.2.1.2.5 mtu=.1.3.6.1.2.1.2.2.1.4.5 mac-address=.1.3.6.1.2.1.2.2.1.6.5 admin-status=.1.3.6.1.2.1.2.2.1.7.5
oper-status=.1.3.6.1.2.1.2.2.1.8.5 bytes-in=.1.3.6.1.2.1.2.2.1.10.5 packets-in=.1.3.6.1.2.1.2.2.1.11.5 discards-in=.1.3.6.1.2.1.2.2.1.13.5
errors-in=.1.3.6.1.2.1.2.2.1.14.5 bytes-out=.1.3.6.1.2.1.2.2.1.16.5 packets-out=.1.3.6.1.2.1.2.2.1.17.5 discards-out=.1.3.6.1.2.1.2.2.1.19.5
errors-out=.1.3.6.1.2.1.2.2.1.20.5


I can’t find the logic of ordering of indices :frowning:

5

I’m still searching, but I cant find the logic, in the wiki there is no useful information on this topic.
Someone found something?

If they are ordered randomly, it would be good made a fixed order in a future software update.
For example, order by physical interface appearance or by mac address or name or something predictable.