Re: [j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?
Hi Saku, > So 80% of time, work needed to compete for access to the CPU. Yes. I hesitated because when I compare the ping results and vFP CPU utilization plus microkernel threads CPU usage during the route churn and without the route churn, then while CPU utilization clearly increased, it did not *seem* to increase enough to explain such drastic RTT fluctuation and even some packet loss. On the other hand, I have absolutely no idea how the microkernel schedules its processes/threads or how the virtualized forwarding plane distributes those four CPU cores it has. Graphical representation of the output of "show linux cpu usage" PFE CLI command can be seen here: https://i.imgur.com/f1vMAn4.png and https://i.imgur.com/vm5nr2S.png. First graph represent CPU cores utilization under normal conditions. Second graph represents CPU cores utilization during the route churn. Those four CPU cores are the host machine CPU cores where the quemu virtualizes the forwarding plane. > If I understood your explanation right (I may not have): At this point, I was focusing on the ICMP "echo request" message only. Network topology seen from Linux is following: vcp-vmx1[vcp-int-vmx1] <-> [2]br-int-vmx1[3] <-> [vfp-int-vmx1]vfp-vmx1[ge-0.0.9-vmx1] vcp-vmx1 is RE running Junos and vcp-int-vmx1 is em1 interface in Junos. br-int-vmx1(Linux bridge) serves the similar purpose to integrated switch in SCB seen with the "show chassis ethernet-switch" command in Junos. vfp-int-vmx1 is the line-card Ethernet interface used by microkernel to communicate with RE. ge-0.0.9-vmx1 represents the ge-0/0/9 seen in Junos which is directly connected to TAP device ge-0.0.9-vmx1: martin@PC:~$ sudo ethtool -i ge-0.0.9-vmx1 driver: tun version: 1.6 firmware-version: expansion-rom-version: bus-info: tap supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no martin@PC:~$ So when I execute the "ping 10.55.55.1 source 10.55.55.2 count 1" command in RE, then the ICMP "echo request" package travels out from the RE via vcp-int-vmx1 interface, through the Linux bridge into the line-card via vfp-int-vmx1 and then to ge-0.0.9-vmx1 in host machine which has 10.55.55.1 configured. I did packet capture simultaneously on vfp-int-vmx1 and ge-0.0.9-vmx1 interfaces. Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNIPER-POWER-SUPPLY-UNIT-MIB no such object
Hello, I have an MX240 running 15.1R6.7. I am looking to monitor a few power supply related items and I observe that juniper has an snmp mib related to power - "JUNIPER-POWER-SUPPLY-UNIT-MIB". It looks to conveniently group all the stuff I care about and so I have tried to poll this mib and all I get back is 'no such object'. I can certainly poll objects from other juniper mibs, so it just makes it look to me like this is some snmp issue either the mib isn't enabled on the router or my running junos code doesn't support. While researching this, I came across another thread which confirms that there is power supply information available from FruName/FruState, which I have been able to poll: JUNIPER-MIB::jnxFruName.2.1.0.0 = STRING: PEM 0 JUNIPER-MIB::jnxFruName.2.2.0.0 = STRING: PEM 1 JUNIPER-MIB::jnxFruName.2.3.0.0 = STRING: PEM 2 JUNIPER-MIB::jnxFruName.2.4.0.0 = STRING: PEM 3 JUNIPER-MIB::jnxFruState.2.1.0.0 = INTEGER: online(6) JUNIPER-MIB::jnxFruState.2.2.0.0 = INTEGER: online(6) JUNIPER-MIB::jnxFruState.2.3.0.0 = INTEGER: empty(2) JUNIPER-MIB::jnxFruState.2.4.0.0 = INTEGER: empty(2) The POWER-SUPPLY-UNIT mib has better information however, such as utilization and so forth, while the above is just 'yeah it's ps is inserted and is online'. So, I am wondering if there is any way to enable access to this mib (if it is indeed supported on mx240). Otherwise, as in the case also sometimes with C branded products which also don't always provided needed info via SNMP but which do on the cli, I would likely have to resort to parsing the CLI output of "show chassis power", which would be a touch ugly. show chassis power PEM 0: State: Online AC input: OK (1 feed expected, 1 feed connected) Capacity: 1590 W (maximum 1590 W) DC output: 200 W (zone 0, 4 A at 50 V, 12% of capacity) PEM 1: State: Online AC input: OK (1 feed expected, 1 feed connected) Capacity: 1590 W (maximum 1590 W) DC output: 200 W (zone 0, 4 A at 50 V, 12% of capacity) PEM 2: State: Empty Input: Absent PEM 3: State: Empty Input: Absent System: Zone 0: Capacity: 1590 W (maximum 1590 W) Allocated power: 920 W (670 W remaining) Actual usage: 400 W Total system capacity: 1590 W (maximum 1590 W) Total remaining power: 670 W Thanks. Mike- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LACP is not running between two VMX
❦ 25 avril 2019 09:31 +01, : > I haven't tried MC-LAG, but I used standard LAG (with LACP). > The problem I faced was that the standard Linux bridges (usually used to > simulate virtual p2p links between vMX-es won't forward BPDUs including LACP > (and I did not find a way to hack around at that time) You can play with /sys/class/net/br0/bridge/group_fwd_mask. Well, in fact, you can't: hat:/sys/class/net//bridge/group_fwd_mask Date: January 2012 KernelVersion: 3.2 Contact:net...@vger.kernel.org Description: Bitmask to allow forwarding of link local frames with address 01-80-C2-00-00-0X on a bridge device. Only values that set bits not matching BR_GROUPFWD_RESTRICTED in net/bridge/br_private.h allowed. Default value 0 does not forward any link local frames. Restricted bits: 0: 01-80-C2-00-00-00 Bridge Group Address used for STP 1: 01-80-C2-00-00-01 (MAC Control) 802.3 used for MAC PAUSE 2: 01-80-C2-00-00-02 (Link Aggregation) 802.3ad Any values not setting these bits can be used. Take special care when forwarding control frames e.g. 802.1X-PAE or LLDP. -- Go not to the elves for counsel, for they will say both yes and no. -- J.R.R. Tolkien ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LACP is not running between two VMX
> omar sahnoun > Sent: Wednesday, April 24, 2019 8:55 AM > > Hello all, > > I tried to mount a MC-LAG between two VMXs (using EVE-NG). I note that > the lacp protocol is not operational. > I did some research (including on this forum). The explanations I find are a > little complicated. That's why I post this message. If anyone among you has a > simple solution for this problem. > I haven't tried MC-LAG, but I used standard LAG (with LACP). The problem I faced was that the standard Linux bridges (usually used to simulate virtual p2p links between vMX-es won't forward BPDUs including LACP (and I did not find a way to hack around at that time) However then I started to use OVS instead of Linux bridges and there's a settings to enable BPDU forwarding and that did the trick. So what I had was all ~50 interfaces of all ~30 vMX-es connected to a single OVS where putting two ports on the same VLAN creates a virtual p2p link between a pair of interfaces/nodes (very easy to change topology add/remove links or nodes) -this OVS has BPDU forwarding enabled so now I can bundle any links between any two vMX-es I'm then using another OVS for the internal VCP-VFP connections, and another one for FXP interface and connectivity outside of the lab. Disclaimer, I never used the juniper scripts to define and start VMs and connectivity, I created the VM configs and the whole lab setup myself (later automated with ansible). adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?
hey, Please let me know if anything was unclear or if someone has other ideas or theories. Been following this thread and do not have anything to contribute at this point but wanted to say I (and I hope many others) appreciate this type of proper debugging given the tools we have available these days. -- tarko ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
