MPLS TE Bug?

RouterOS Forwarding Protocols
1

Hi folks,

I’ve been playing with MPLS TE with some CCRs.
The problem is that when I try to set interface’s max reservable bandwidth to 10G, it shows that the remaining bandwidth is only 1410Mbps.


[admin@R3] > mpls traffic-eng interface export 
# jan/02/1970 15:02:54 by RouterOS 6.43rc44
#
# model = CCR1072-1G-8S+
/mpls traffic-eng interface
add bandwidth=10Gbps interface=sfp-sfpplus2

[admin@R3] > mpls traffic-eng interface print  
Flags: X - disabled, I - invalid 
 #   INTERFACE                                                 BANDWIDTH  TE-METRIC REMAINING-BW
 0   sfp-sfpplus2                                                 10Gbps          1   1410.0Mbps

If I set the max reservable bandwidth up to 4G, it accepts and show me the right amount of remaining bandwidth:


[admin@R3] > mpls traffic-eng interface export 
# jan/02/1970 15:04:08 by RouterOS 6.43rc44
#
# model = CCR1072-1G-8S+
/mpls traffic-eng interface
add bandwidth=4Gbps interface=sfp-sfpplus2

[admin@R3] > mpls traffic-eng interface print  
Flags: X - disabled, I - invalid 
 #   INTERFACE                                                 BANDWIDTH  TE-METRIC REMAINING-BW
 0   sfp-sfpplus2                                                  4Gbps          1      4.0Gbps

Tested in CCR1072, CCR1036 and CRS212 with stable, current and RC versions of RouterOS. All with the same behaviour.

It looks like some mess with signed/unsigned variable?

2

It looks like some mess with 32 bit variable.
Write to Mikrotik support.

3

Yes, currently it is not possible to set 10G value, since it is administrative value you can choose lower numbers, it does not have to represent actual bandwidth.

4

Ok, but it would affect the actual traffic right?

What if the sum of tunnels passing by that interface is greater than the maximum reservable bandwidth? The tunnel would go down? It would go through another path if avaliable?

Before finding this issue, I was wiresharking and OSPF is propagating the right value:





So my question is: Does it affect traffic engineering or it’s just a presentation mistake? Should I write to support as @sid5632 suggested?

Thanks!

5

It will not affect traffic, because this value does not represent actual traffic on interface (unless you are using auto bandwidth limitation feature).

6

Right. What if I want to use it? Do you plan to fix this bug any time soon?

7

Yeah this is one of those things where it’s kinda surprising that it hasn’t been fixed yet. Does changing the variable type that stores this number from an integer to a double cause an issue within the calculation script?

8

Maybe hardware limitation? Let’s wait for a response from MT guys…

9

I personally have my doubts that this has to do with hardware, but it very well may have to do with the differing CPU architectures that Mikrotik runs RouterOS on. I don’t know if the MIPS/PPC architectures that they have can “do” a 64-bit integer. We’re all sure and positive that x86, ARM, Tilera can though. In theory it should be trivial to just concatenate two 32-bit integers together but that’s up to the CPU archs.

10

Hey @mrz can you tell us if this fix is in your roadmap?

11

Any official news about it?

12

Any plans to fix this bug?