Discussion:
[j-nsp] Rationale behind "set chassis aggregated-devices ethernet device-count"
Phil Mayers
2013-08-23 12:30:33 UTC
Permalink
Just for curiosity - why is this a "thing" in JunOS? Why doesn't the
platform just let you configure the aeX interfaces and figure out the
"count" itself?

It's such a specific thing to have to do I feel sure there's a reason,
but can't for the life of me guess what :o)
Saku Ytti
2013-08-23 13:37:18 UTC
Permalink
Post by Phil Mayers
Just for curiosity - why is this a "thing" in JunOS? Why doesn't the
platform just let you configure the aeX interfaces and figure out
the "count" itself?
I'd love to hear this.

I also find it rather strange that we need to configure tunnel PFE in trio
platforms. As I understand trio implements legacy-hardware's limitation, so
you actually do push tunneled packets inefficiently across fabric to
specific PFE for decap/encap, rather than to do the obvious and do
encap/decap at the trio where packet happens to hit, saving lookup and
fabric round-trip.
--
++ytti
Phil Mayers
2013-08-23 16:38:34 UTC
Permalink
Part of it probably has to do with SNMP. Pre-allocating the count
keeps the SNMP index ID's from changing when devices are
added/removed. ae0 is always index blah. A lot of tools are very
dependent upon the SNMP index ID.
I don't think so TBH. Having just snmpwalk'ed a JunOS box, the aeX
interfaces and sub-ints ifindex values appear allocated sequentially:

IF-MIB::ifDescr.521 = STRING: ae0
IF-MIB::ifDescr.522 = STRING: ae0.32767
IF-MIB::ifDescr.524 = STRING: ae1
IF-MIB::ifDescr.529 = STRING: ae0.1
IF-MIB::ifDescr.530 = STRING: xe-1/0/0.1
IF-MIB::ifDescr.531 = STRING: ae0.11
IF-MIB::ifDescr.532 = STRING: ae0.10
IF-MIB::ifDescr.533 = STRING: ae0.9
IF-MIB::ifDescr.534 = STRING: ae0.8
IF-MIB::ifDescr.535 = STRING: ae0.7
IF-MIB::ifDescr.536 = STRING: ae0.6
IF-MIB::ifDescr.537 = STRING: ae0.5
IF-MIB::ifDescr.538 = STRING: ae0.4
IF-MIB::ifDescr.539 = STRING: ae0.3
IF-MIB::ifDescr.540 = STRING: ae0.2
IF-MIB::ifDescr.541 = STRING: xe-1/0/0.11
IF-MIB::ifDescr.542 = STRING: xe-1/0/0.10

So, unless I'm misunderstanding what you mean, it's not doing anything
interesting here.
Doug McIntyre
2013-08-23 17:04:05 UTC
Permalink
Post by Phil Mayers
Part of it probably has to do with SNMP. Pre-allocating the count
keeps the SNMP index ID's from changing when devices are
added/removed. ae0 is always index blah. A lot of tools are very
dependent upon the SNMP index ID.
I don't think so TBH. Having just snmpwalk'ed a JunOS box, the aeX
IF-MIB::ifDescr.521 = STRING: ae0
IF-MIB::ifDescr.522 = STRING: ae0.32767
IF-MIB::ifDescr.524 = STRING: ae1
IF-MIB::ifDescr.529 = STRING: ae0.1
IF-MIB::ifDescr.530 = STRING: xe-1/0/0.1
IF-MIB::ifDescr.531 = STRING: ae0.11
IF-MIB::ifDescr.532 = STRING: ae0.10
IF-MIB::ifDescr.533 = STRING: ae0.9
IF-MIB::ifDescr.534 = STRING: ae0.8
IF-MIB::ifDescr.535 = STRING: ae0.7
IF-MIB::ifDescr.536 = STRING: ae0.6
IF-MIB::ifDescr.537 = STRING: ae0.5
IF-MIB::ifDescr.538 = STRING: ae0.4
IF-MIB::ifDescr.539 = STRING: ae0.3
IF-MIB::ifDescr.540 = STRING: ae0.2
IF-MIB::ifDescr.541 = STRING: xe-1/0/0.11
IF-MIB::ifDescr.542 = STRING: xe-1/0/0.10
So, unless I'm misunderstanding what you mean, it's not doing anything
interesting here.
But imagine the case, where you start with needing 4 LAGs, so that is
what you set. Then you add in 10 SFPs for various things, and then you
add in 4 more LAGs, then you remove 4 SFPs for some other project.

What do your SNMP indexes look like now? And hopefully your
/var/db/dcd.snmp_ix file doesn't get corrupt and the indexes have
to be recomputed at that point..

Back to the original question, there probably is some resources taken
up by having the LAGs there. And if you just do max # right away, you do
have all those new interfaces to gather stats on if your SNMP queries
just do a bulk walk of all interfaces.
Phil Mayers
2013-08-23 17:14:39 UTC
Permalink
Post by Doug McIntyre
But imagine the case, where you start with needing 4 LAGs, so that is
what you set. Then you add in 10 SFPs for various things, and then you
add in 4 more LAGs, then you remove 4 SFPs for some other project.
What do your SNMP indexes look like now? And hopefully your
/var/db/dcd.snmp_ix file doesn't get corrupt and the indexes have
to be recomputed at that point..
Sorry, but I've not understood what point you're trying to make here.
That adding and removing interfaces will change which ifindex values are
allocated? Well.... yes, obviously ;o)

(IMNSHO, software that assumes persistent ifindex values is broken and
should be thrown away)
Post by Doug McIntyre
Back to the original question, there probably is some resources taken
up by having the LAGs there. And if you just do max # right away, you do
have all those new interfaces to gather stats on if your SNMP queries
just do a bulk walk of all interfaces.
That might be a reasonable explanation, but you could equally well argue
that putting the interface into the IF-MIB when it's not defined under
the "interfaces" stanza (as JunOS does) is dumb.
Kevin R. Cullimore
2013-08-23 20:01:55 UTC
Permalink
Post by Doug McIntyre
Post by Phil Mayers
Part of it probably has to do with SNMP. Pre-allocating the count
keeps the SNMP index ID's from changing when devices are
added/removed. ae0 is always index blah. A lot of tools are very
dependent upon the SNMP index ID.
I don't think so TBH. Having just snmpwalk'ed a JunOS box, the aeX
IF-MIB::ifDescr.521 = STRING: ae0
IF-MIB::ifDescr.522 = STRING: ae0.32767
IF-MIB::ifDescr.524 = STRING: ae1
IF-MIB::ifDescr.529 = STRING: ae0.1
IF-MIB::ifDescr.530 = STRING: xe-1/0/0.1
IF-MIB::ifDescr.531 = STRING: ae0.11
IF-MIB::ifDescr.532 = STRING: ae0.10
IF-MIB::ifDescr.533 = STRING: ae0.9
IF-MIB::ifDescr.534 = STRING: ae0.8
IF-MIB::ifDescr.535 = STRING: ae0.7
IF-MIB::ifDescr.536 = STRING: ae0.6
IF-MIB::ifDescr.537 = STRING: ae0.5
IF-MIB::ifDescr.538 = STRING: ae0.4
IF-MIB::ifDescr.539 = STRING: ae0.3
IF-MIB::ifDescr.540 = STRING: ae0.2
IF-MIB::ifDescr.541 = STRING: xe-1/0/0.11
IF-MIB::ifDescr.542 = STRING: xe-1/0/0.10
So, unless I'm misunderstanding what you mean, it's not doing anything
interesting here.
But imagine the case, where you start with needing 4 LAGs, so that is
what you set. Then you add in 10 SFPs for various things, and then you
add in 4 more LAGs, then you remove 4 SFPs for some other project.
What do your SNMP indexes look like now? And hopefully your
/var/db/dcd.snmp_ix file doesn't get corrupt and the indexes have
to be recomputed at that point..
Back to the original question, there probably is some resources taken
up by having the LAGs there. And if you just do max # right away, you do
have all those new interfaces to gather stats on if your SNMP queries
just do a bulk walk of all interfaces.
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
I had assumed It had to do with statically-allocated resources assigned
during the boot sequence as well. I'll note for the record that
baby/non-ISP SRXs take many, MANY more minutes to boot when you max out
the device-count parameter.

Michael Loftis
2013-08-23 17:00:03 UTC
Permalink
Heh, thats what I get for making an assumption!
Post by Phil Mayers
Part of it probably has to do with SNMP. Pre-allocating the count
keeps the SNMP index ID's from changing when devices are
added/removed. ae0 is always index blah. A lot of tools are very
dependent upon the SNMP index ID.
I don't think so TBH. Having just snmpwalk'ed a JunOS box, the aeX
IF-MIB::ifDescr.521 = STRING: ae0
IF-MIB::ifDescr.522 = STRING: ae0.32767
IF-MIB::ifDescr.524 = STRING: ae1
IF-MIB::ifDescr.529 = STRING: ae0.1
IF-MIB::ifDescr.530 = STRING: xe-1/0/0.1
IF-MIB::ifDescr.531 = STRING: ae0.11
IF-MIB::ifDescr.532 = STRING: ae0.10
IF-MIB::ifDescr.533 = STRING: ae0.9
IF-MIB::ifDescr.534 = STRING: ae0.8
IF-MIB::ifDescr.535 = STRING: ae0.7
IF-MIB::ifDescr.536 = STRING: ae0.6
IF-MIB::ifDescr.537 = STRING: ae0.5
IF-MIB::ifDescr.538 = STRING: ae0.4
IF-MIB::ifDescr.539 = STRING: ae0.3
IF-MIB::ifDescr.540 = STRING: ae0.2
IF-MIB::ifDescr.541 = STRING: xe-1/0/0.11
IF-MIB::ifDescr.542 = STRING: xe-1/0/0.10
So, unless I'm misunderstanding what you mean, it's not doing anything
interesting here.
--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
Morgan McLean
2013-08-23 19:21:01 UTC
Permalink
Also, if software is smart it updates its SNMP indexes it has on record...I
know every custom script I've done checks to make sure its still looking at
the right interface, and if not it updates for it or marks the interface as
lost.

Curious about the line as well....its annoying.

Morgan
Post by Michael Loftis
Heh, thats what I get for making an assumption!
Post by Phil Mayers
Part of it probably has to do with SNMP. Pre-allocating the count
keeps the SNMP index ID's from changing when devices are
added/removed. ae0 is always index blah. A lot of tools are very
dependent upon the SNMP index ID.
I don't think so TBH. Having just snmpwalk'ed a JunOS box, the aeX
IF-MIB::ifDescr.521 = STRING: ae0
IF-MIB::ifDescr.522 = STRING: ae0.32767
IF-MIB::ifDescr.524 = STRING: ae1
IF-MIB::ifDescr.529 = STRING: ae0.1
IF-MIB::ifDescr.530 = STRING: xe-1/0/0.1
IF-MIB::ifDescr.531 = STRING: ae0.11
IF-MIB::ifDescr.532 = STRING: ae0.10
IF-MIB::ifDescr.533 = STRING: ae0.9
IF-MIB::ifDescr.534 = STRING: ae0.8
IF-MIB::ifDescr.535 = STRING: ae0.7
IF-MIB::ifDescr.536 = STRING: ae0.6
IF-MIB::ifDescr.537 = STRING: ae0.5
IF-MIB::ifDescr.538 = STRING: ae0.4
IF-MIB::ifDescr.539 = STRING: ae0.3
IF-MIB::ifDescr.540 = STRING: ae0.2
IF-MIB::ifDescr.541 = STRING: xe-1/0/0.11
IF-MIB::ifDescr.542 = STRING: xe-1/0/0.10
So, unless I'm misunderstanding what you mean, it's not doing anything
interesting here.
--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Thanks,
Morgan
Michael Loftis
2013-08-23 16:14:21 UTC
Permalink
Part of it probably has to do with SNMP. Pre-allocating the count
keeps the SNMP index ID's from changing when devices are
added/removed. ae0 is always index blah. A lot of tools are very
dependent upon the SNMP index ID.
Post by Phil Mayers
Just for curiosity - why is this a "thing" in JunOS? Why doesn't the
platform just let you configure the aeX interfaces and figure out the
"count" itself?
It's such a specific thing to have to do I feel sure there's a reason, but
can't for the life of me guess what :o)
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
Loading...