SRX

I'm using cacti to graph bandwidth usage via SNMP. When a PPPoE interface reconnect, the spped value on that interface become large, sometime larger than physical speed (ex 284Mbps on 100Mbps interface).

# show interfaces pp0 unit 0
apply-macro "VNPT FTTH";
ppp-options {
    pap {
        local-name xxxxxxxxxxx;
        local-password "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; ## SECRET-DATA
        passive;
    }
}
pppoe-options {
    underlying-interface fe-0/0/7.0;
    idle-timeout 360;
    auto-reconnect 5;
    client;
}
family inet {
    negotiate-address;
}

# show snmp
name GWVN0002;
description "Juniper Internet Gateway";
contact "xxxxxx@xxxxxxxxxxx.com";
community xx-public {
    authorization read-only;
} 

 

I'm using JunOS 12.1X44 D45.2 on SRX210HE2. Does anyone has same trouble? If this is a JunOS bug, how do I report to Juniper? Thanks and best regards.

Hey,
could you please check this out :
clear interfaces statistics all
and then reconnect the pppoe interface .
and then show me the output of this command after you see large output at the graph:
show interfaces statistics <interface under the pppoe> detail

Hello ,

 

It looks to be a cosmetic bug , but inorder to confirm this , please connect to CLI and try to monitor the interface traffic to check if the statistic are correct or not .

 

So when you reconnect the PPOE interface , open a duplicate terminal or console and try :

 

> monitor interface traffic

 

And capture the realtime traffic hitting each interface and check if that matches with the SNMP monitoring graph . With this we can confirm its a bug or actually we are hitting with that amount of traffic .

Make sure you capture the CLI session .

Traffic statics seems return right values...

 

# monitor interface pp0.0
GWVN0002                          Seconds: 207                 Time: 20:46:38
                                                          Delay: 1/1/19
Interface: pp0.0, Enabled, Link is Down
Flags: Hardware-Down Point-To-Point SNMP-Traps 0x4000
Encapsulation: PPPoE
Local statistics:                                             Current delta
  Input bytes:                 114635449                                [0]
  Output bytes:                 26822474                                [0]
  Input packets:                  574913                                [0]
  Output packets:                 579670                                [0]
Remote statistics:
  Input bytes:                         0 (0 bps)                        [0]
  Output bytes:             647296453678 (0 bps)                        [0]
  Input packets:                       0 (0 pps)                        [0]
  Output packets:              567620336 (0 pps)                        [0]
Traffic statistics:
  Input bytes:                 114635449                                [0]
  Output bytes:             647323276152                                [0]
  Input packets:                  574913                                [0]
  Output packets:              568200006                                [0]
Protocol: inet, MTU: 1488, Flags: Protocol-Down 0x1000000

# monitor interface traffic detail
GWVN0002                          Seconds: 256                 Time: 20:51:24

Interface    Link     Input bytes        (bps)      Output bytes        (bps)
 ge-0/0/0      Up     15989768449      (90768)      154289356883    (4276992)
 gr-0/0/0      Up               0          (0)                 0          (0)
 ip-0/0/0      Up               0          (0)                 0          (0)
 lsq-0/0/0     Up               0          (0)                 0          (0)
 lt-0/0/0      Up               0          (0)                 0          (0)
 mt-0/0/0      Up               0          (0)                 0          (0)
 sp-0/0/0      Up               0          (0)                 0          (0)
 ge-0/0/1      Up   3690412322039    (5178616)     1311911760871     (125208)
 fe-0/0/2    Down               0          (0)                 0          (0)
 fe-0/0/3    Down               0          (0)                 0          (0)
 fe-0/0/4    Down               0          (0)                 0          (0)
 fe-0/0/5      Up        24057740          (0)          26388548        (112)
 fe-0/0/6      Up          497341          (0)          24250551        (112)
 fe-0/0/7      Up            9710          (0)          25209404          (0)
 fxp2          Up               0                      205633000
 gre           Up               0                              0
 ipip          Up               0                              0
 irb           Up               0                              0
 lo0           Up       589973326                      589973326
 lsi           Up               0                              0
 mtun          Up               0                              0
 pimd          Up               0                              0
 pime          Up               0                              0
 pp0           Up    188667027772    (4835152)     3648486176933    (5491208)
 ppd0          Up               0          (0)                 0          (0)
 ppe0          Up               0          (0)                 0          (0)
 st0           Up               0          (0)                 0          (0)
 tap           Up               0                              0
 vlan          Up   3648781228454    (5494120)     1417892189580    (4834096)






Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^D

Only SNMP get wrong values...

Hello ,

 

The CLI shows the tarffic in Bytes per second and the graph shows it on bits per seconds , So there is a converstion difference between the CLI and the graphical value .  Also kindly let me know if the CLI value was taken on that instance where we saw the traffic burst ?

 

Is there was way in the SNMP monitoring tool to change the graphical values to Bytes per second and check .

The graph uses Cacti's math to convert from byte to bit. It's correct because ISP set bandwidth for that interface is 30Mbps, its value never over except when it reconnect.

 

Note:

- I've also noticed that It happend when the virtual PPPoE interface down and router try to reconnect.The physical ethernet still up.

- I tried to unplug the physical ethernet and replug to force PPPoE reconnect, SNMP value was correct in this case.

Hello ,

 

Thanks for the update .  Look like some kind of cosmetic bug thats been hit . We can confirm if we have the SNMP traceoptions enabled during the disconnect and check the value returned .

I'm not sure what is SNMP traceoptions, but I think I can provide cacti SNMP logs if needed.

Hello ,

 

I was looking for the logs :

 

[edit snmp]

traceoptions {
              file <files number> <match regular-expression> <size size> <world-readable | no-world-readable>;
              flag flag;no-remote-trace;
             }

@joses: Thanks so much for your help. Please check my device's tracelog in attachment.

Hello ,

 

Thanks for the traceoptions files . I checked and found that the input and output rates are optimal and not matching our huge value .

But after checking and comparing the logs , i found that  when the Client queries for OID "ifInOctets" and "ifOutOctets"  , I see the value to be matching the huge amount like  1.3GB , but this is not the rate but the total amount of packets counts cumulative .

 

So I am not sure that the SNMP client is mis interpreting  the total count to be the rate of traffic ..

Thanks for your hint. Please check my attachment:

- ifInOctets reset value between minute 37 and 38

- ifOutOctets doesn't, that's why its speed did not become huge

- cacti seems misundestand the negative delta value (C4)

 

It seems this bug comes from both:

- cacti: treat negative number as huge value

- JunOS: reset the ifInOctets value but not do as same for ifOutOctets.

 

Could you please report this issue to JunOS developers so they can fix this issue or implement feature/option to reset these values.

Hello ,

 

Your understanding is correct . I will try to open a PR with engineering regading this ,but if you can open a JTAC ticket with suitable logs and information shared in the ticket , it will be much more easy and fast .

 

Hi Sam,

 

I tried to open a JTAC case, they denied due my device doesn't come with support contract!

Could you please help me this isse, since this is not for me, it's for all using JunOS.

 

Thanks again.

Truong.