Juniper QFX 10G ports discovered as 4.29G
Just FYI, the 10G ports on a QFX 5100 running latest JunOS are being reported with a speed of 4.29Gbps, which I assume is likely the actual returned value being constrained by a 32-bit container?
Not a critical thing for us to fix - I was actually disabling polling for all of our Juniper vcp stacks in Observium (most of them take > 300s to complete a polling cycle) but noticed this as I was going through them and figured I'd pass it along.
Cheers,
Aaron
Aaron,
That's the maximum value for ifSpeed - "normally" one would expect ifHighSpeed to be filled with the correct speed (it's in Mbps instead of bps) - and we should be using that if available. Could you perhaps check with a debug run (or snmpwalk) if that is being returned and we are somehow ignoring it?
Tom
On 16/10/2015 20:51, Aaron Finney wrote:
Just FYI, the 10G ports on a QFX 5100 running latest JunOS are being reported with a speed of 4.29Gbps, which I assume is likely the actual returned value being constrained by a 32-bit container?
Not a critical thing for us to fix - I was actually disabling polling for all of our Juniper vcp stacks in Observium (most of them take > 300s to complete a polling cycle) but noticed this as I was going through them and figured I'd pass it along.
Cheers,
Aaron
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi,
please send me debug from poller debug for this device: ./poller.php -d -m ports -h <your_device>
On Fri, Oct 16, 2015 at 9:51 PM, Aaron Finney aaron.finney@openx.com wrote:
Just FYI, the 10G ports on a QFX 5100 running latest JunOS are being reported with a speed of 4.29Gbps, which I assume is likely the actual returned value being constrained by a 32-bit container?
Not a critical thing for us to fix - I was actually disabling polling for all of our Juniper vcp stacks in Observium (most of them take > 300s to complete a polling cycle) but noticed this as I was going through them and figured I'd pass it along.
Cheers,
Aaron
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Define “latest” Junos version ? 13.2X51-D38 / 14.1X53-D30 ?
I have 20 QFX 5100 ( 48S and 96S ) in production and I don’t have any issues like that :)
Raphael
2015-10-16 21:12 GMT+02:00 Mike Stupalov mike@observium.org:
Hi,
please send me debug from poller debug for this device: ./poller.php -d -m ports -h <your_device>
On Fri, Oct 16, 2015 at 9:51 PM, Aaron Finney aaron.finney@openx.com wrote:
Just FYI, the 10G ports on a QFX 5100 running latest JunOS are being reported with a speed of 4.29Gbps, which I assume is likely the actual returned value being constrained by a 32-bit container?
Not a critical thing for us to fix - I was actually disabling polling for all of our Juniper vcp stacks in Observium (most of them take > 300s to complete a polling cycle) but noticed this as I was going through them and figured I'd pass it along.
Cheers,
Aaron
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
-- Mike Stupalov http://observium.org/
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Ah, latest in 13.x train...13.2X51-D38.
Question - what are your polling times like for your 96s? Do you have any stacks with > 2 members? Our QFXs are marginally better, but our ex4550's and 4200's with > 2 members all take over 300s to poll. We have a few hundred 3300's deployed as well, which we've written off as a lost cause for bulk polling. :)
Also, debug sent.
Aaron
On Fri, Oct 16, 2015 at 2:40 PM, Raphael Maunier raphael.maunier@gmail.com wrote:
Define “latest” Junos version ? 13.2X51-D38 / 14.1X53-D30 ?
I have 20 QFX 5100 ( 48S and 96S ) in production and I don’t have any issues like that :)
Raphael
2015-10-16 21:12 GMT+02:00 Mike Stupalov mike@observium.org:
Hi,
please send me debug from poller debug for this device: ./poller.php -d -m ports -h <your_device>
On Fri, Oct 16, 2015 at 9:51 PM, Aaron Finney aaron.finney@openx.com wrote:
Just FYI, the 10G ports on a QFX 5100 running latest JunOS are being reported with a speed of 4.29Gbps, which I assume is likely the actual returned value being constrained by a 32-bit container?
Not a critical thing for us to fix - I was actually disabling polling for all of our Juniper vcp stacks in Observium (most of them take > 300s to complete a polling cycle) but noticed this as I was going through them and figured I'd pass it along.
Cheers,
Aaron
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
-- Mike Stupalov http://observium.org/
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Envoyé de mon iPhone
Le 17 oct. 2015 à 01:50, Aaron Finney aaron.finney@openx.com a écrit :
Ah, latest in 13.x train...13.2X51-D38.
Question - what are your polling times like for your 96s? Do you have any stacks with > 2 members?
I really like Juniper but I don't trust any vendor on stacking technology. There is always something wrong during upgrade / services issue. So I don't have any stack in production and I will not ! 96s are pretty fast. I'm only doing layer3 and mpls raw interfaces on my qfx, no layer 2 ( layer2 is bad :) )
On a previous release I had a nice bug. I was able to snmp read if-out and if-in traffic and I was able to see the traffic locally with monitor interfaces but snmp-get was polling a value of zero. I had to upgrade. I had to upgrade to the latest 14.x train because of mpls bugs and feature I needed that was only available in 14.x at that time ( mostly mpls ). So I don't have any experience on 13.x train since the bug I had :)
Our QFXs are marginally better, but our ex4550's and 4200's with > 2 members all take over 300s to poll.
Still no stack but bugs. For some reason, some ex4550 ( I have 12 in production ) don't send any if information. I have the exact same release / same firewall filter and one ex is showing his interfaces and the other one have his interfaces popping up and down on Observium.
I upgraded to the latest 12.3R11 and still the same issue. I don't have time to debug it, but there is weird things ^^ The only equipment reporting bugs like that are juniper ex
We have a few hundred 3300's deployed as well, which we've written off as a lost cause for bulk polling. :)
Same here. A nice feature will be to have 2 pokers or 2 method. Bulk once every like 12 hours and poll snmp stats when you want. This will help a lot because bulk is really killing the cpu ^^
Also, debug sent.
Aaron
On Fri, Oct 16, 2015 at 2:40 PM, Raphael Maunier raphael.maunier@gmail.com wrote: Define “latest” Junos version ? 13.2X51-D38 / 14.1X53-D30 ?
I have 20 QFX 5100 ( 48S and 96S ) in production and I don’t have any issues like that :)
Raphael
2015-10-16 21:12 GMT+02:00 Mike Stupalov mike@observium.org:
Hi,
please send me debug from poller debug for this device: ./poller.php -d -m ports -h <your_device>
On Fri, Oct 16, 2015 at 9:51 PM, Aaron Finney aaron.finney@openx.com wrote: Just FYI, the 10G ports on a QFX 5100 running latest JunOS are being reported with a speed of 4.29Gbps, which I assume is likely the actual returned value being constrained by a 32-bit container?
Not a critical thing for us to fix - I was actually disabling polling for all of our Juniper vcp stacks in Observium (most of them take > 300s to complete a polling cycle) but noticed this as I was going through them and figured I'd pass it along.
Cheers,
Aaron
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
-- Mike Stupalov http://observium.org/
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
--
Aaron Finney | Network Engineer 888 East Walnut Street, 2nd Floor | Pasadena, CA 91101 office: +1 (626) 466-1141 x6035
Watch how we make online advertising simple: http://bit.ly/Ent_vid www.openx.com | follow us on: Twitter Facebook LinkedIn
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On Fri, Oct 16, 2015 at 10:31 PM, Raphael Maunier <raphael.maunier@gmail.com
wrote:
Envoyé de mon iPhone
Le 17 oct. 2015 à 01:50, Aaron Finney aaron.finney@openx.com a écrit :
Ah, latest in 13.x train...13.2X51-D38.
Question - what are your polling times like for your 96s? Do you have any stacks with > 2 members?
I really like Juniper but I don't trust any vendor on stacking technology. There is always something wrong during upgrade / services issue. So I don't have any stack in production and I will not ! 96s are pretty fast. I'm only doing layer3 and mpls raw interfaces on my qfx, no layer 2 ( layer2 is bad :) )
On a previous release I had a nice bug. I was able to snmp read if-out and if-in traffic and I was able to see the traffic locally with monitor interfaces but snmp-get was polling a value of zero. I had to upgrade. I had to upgrade to the latest 14.x train because of mpls bugs and feature I needed that was only available in 14.x at that time ( mostly mpls ). So I don't have any experience on 13.x train since the bug I had :)
Just a sort of side note..."stacking" in JunOS is NOT an afterthought, unlike everyone else. It's merely a different physical layer for what they're already doing in the big MX and EX chassis routers, and that overall topology goes back to the previous generation M series. Very well proven, very robust. Rarely do you see bugs that are related to stacking itself in JunOS (I actually cannot recall any) and that's because of what it is. When strange things happen they behave as configured. It's not remotely like a lot of others "stacking" implementations. It really is 1st class citizen with a control plane designed for this type of work from the get go.
For JunOS a "stacked" configurations really are just more ports being handled the same way it already handles the hardware. There's never been any sort of monolithic (which isn't the right term but I can't think of a better one) JunOS where the control plane CPU is tightly coupled to the forwarding plane. It's always been loosely coupled with an independent forwarding and control plane.
Its still a bad idea, though, since it introduces a lot of additional surface area for software bugs and indeed a larger device for human error to cause fail.
Adam's rule #1 of networking is : don't stack!
Adam.
Sent with AquaMail for Android http://www.aqua-mail.com
On 17 October 2015 19:28:32 Michael Loftis mloftis@wgops.com wrote:
On Fri, Oct 16, 2015 at 10:31 PM, Raphael Maunier <raphael.maunier@gmail.com
wrote:
Envoyé de mon iPhone
Le 17 oct. 2015 à 01:50, Aaron Finney aaron.finney@openx.com a écrit :
Ah, latest in 13.x train...13.2X51-D38.
Question - what are your polling times like for your 96s? Do you have any stacks with > 2 members?
I really like Juniper but I don't trust any vendor on stacking technology. There is always something wrong during upgrade / services issue. So I don't have any stack in production and I will not ! 96s are pretty fast. I'm only doing layer3 and mpls raw interfaces on my qfx, no layer 2 ( layer2 is bad :) )
On a previous release I had a nice bug. I was able to snmp read if-out and if-in traffic and I was able to see the traffic locally with monitor interfaces but snmp-get was polling a value of zero. I had to upgrade. I had to upgrade to the latest 14.x train because of mpls bugs and feature I needed that was only available in 14.x at that time ( mostly mpls ). So I don't have any experience on 13.x train since the bug I had :)
Just a sort of side note..."stacking" in JunOS is NOT an afterthought, unlike everyone else. It's merely a different physical layer for what they're already doing in the big MX and EX chassis routers, and that overall topology goes back to the previous generation M series. Very well proven, very robust. Rarely do you see bugs that are related to stacking itself in JunOS (I actually cannot recall any) and that's because of what it is. When strange things happen they behave as configured. It's not remotely like a lot of others "stacking" implementations. It really is 1st class citizen with a control plane designed for this type of work from the get go.
For JunOS a "stacked" configurations really are just more ports being handled the same way it already handles the hardware. There's never been any sort of monolithic (which isn't the right term but I can't think of a better one) JunOS where the control plane CPU is tightly coupled to the forwarding plane. It's always been loosely coupled with an independent forwarding and control plane.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
I fully agree...mostly.
We did recently hit a serious PR with 12.3R10 which causes the spid process to core dump when fragmented UDP or NFS packets transit a VCP interface on the 4550s. No spid = no forwarding of is-is traffic until it's back up (ouch). Fixed in 12.R11.
Software upgrades are another thing. As long as you accept reality, it's mostly manageable. Like the fact that ISSU is something the devil created, which should never be spoken of aloud lest it appear.
On Saturday, October 17, 2015, Michael Loftis mloftis@wgops.com wrote:
On Fri, Oct 16, 2015 at 10:31 PM, Raphael Maunier < raphael.maunier@gmail.com javascript:_e(%7B%7D,'cvml','raphael.maunier@gmail.com');> wrote:
Envoyé de mon iPhone
Le 17 oct. 2015 à 01:50, Aaron Finney <aaron.finney@openx.com javascript:_e(%7B%7D,'cvml','aaron.finney@openx.com');> a écrit :
Ah, latest in 13.x train...13.2X51-D38.
Question - what are your polling times like for your 96s? Do you have any stacks with > 2 members?
I really like Juniper but I don't trust any vendor on stacking technology. There is always something wrong during upgrade / services issue. So I don't have any stack in production and I will not ! 96s are pretty fast. I'm only doing layer3 and mpls raw interfaces on my qfx, no layer 2 ( layer2 is bad :) )
On a previous release I had a nice bug. I was able to snmp read if-out and if-in traffic and I was able to see the traffic locally with monitor interfaces but snmp-get was polling a value of zero. I had to upgrade. I had to upgrade to the latest 14.x train because of mpls bugs and feature I needed that was only available in 14.x at that time ( mostly mpls ). So I don't have any experience on 13.x train since the bug I had :)
Just a sort of side note..."stacking" in JunOS is NOT an afterthought, unlike everyone else. It's merely a different physical layer for what they're already doing in the big MX and EX chassis routers, and that overall topology goes back to the previous generation M series. Very well proven, very robust. Rarely do you see bugs that are related to stacking itself in JunOS (I actually cannot recall any) and that's because of what it is. When strange things happen they behave as configured. It's not remotely like a lot of others "stacking" implementations. It really is 1st class citizen with a control plane designed for this type of work from the get go.
For JunOS a "stacked" configurations really are just more ports being handled the same way it already handles the hardware. There's never been any sort of monolithic (which isn't the right term but I can't think of a better one) JunOS where the control plane CPU is tightly coupled to the forwarding plane. It's always been loosely coupled with an independent forwarding and control plane.
Very well buggued. I had lots of issues using VC and also bug on MCLAG. If I need to do a VC with any vendor, I will need 4 equipments 2*2VC and redundancy on the server / router side. I had in production around 20 QFX5100 on a single customer and most of the bug we had : VCHASSIS with SNMP / Upgrade / RPD / split. I also had in production around 50 MX's on one single network really stable with no issue except on issu and when I tried the Vchassis stuff :) I'm a a Juniper guy / shop, but I also know the limitation and try to not play with Fire
But this ML is not the right place to troll on this topic ^^
2015-10-17 20:28 GMT+02:00 Michael Loftis mloftis@wgops.com:
On Fri, Oct 16, 2015 at 10:31 PM, Raphael Maunier < raphael.maunier@gmail.com> wrote:
Envoyé de mon iPhone
Le 17 oct. 2015 à 01:50, Aaron Finney aaron.finney@openx.com a écrit :
Ah, latest in 13.x train...13.2X51-D38.
Question - what are your polling times like for your 96s? Do you have any stacks with > 2 members?
I really like Juniper but I don't trust any vendor on stacking technology. There is always something wrong during upgrade / services issue. So I don't have any stack in production and I will not ! 96s are pretty fast. I'm only doing layer3 and mpls raw interfaces on my qfx, no layer 2 ( layer2 is bad :) )
On a previous release I had a nice bug. I was able to snmp read if-out and if-in traffic and I was able to see the traffic locally with monitor interfaces but snmp-get was polling a value of zero. I had to upgrade. I had to upgrade to the latest 14.x train because of mpls bugs and feature I needed that was only available in 14.x at that time ( mostly mpls ). So I don't have any experience on 13.x train since the bug I had :)
Just a sort of side note..."stacking" in JunOS is NOT an afterthought, unlike everyone else. It's merely a different physical layer for what they're already doing in the big MX and EX chassis routers, and that overall topology goes back to the previous generation M series. Very well proven, very robust. Rarely do you see bugs that are related to stacking itself in JunOS (I actually cannot recall any) and that's because of what it is. When strange things happen they behave as configured. It's not remotely like a lot of others "stacking" implementations. It really is 1st class citizen with a control plane designed for this type of work from the get go.
For JunOS a "stacked" configurations really are just more ports being handled the same way it already handles the hardware. There's never been any sort of monolithic (which isn't the right term but I can't think of a better one) JunOS where the control plane CPU is tightly coupled to the forwarding plane. It's always been loosely coupled with an independent forwarding and control plane.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
participants (6)
-
Aaron Finney -
Adam Armstrong -
Michael Loftis -
Mike Stupalov -
Raphael Maunier -
Tom Laermans