[j-nsp] MTU on switch interfaces

[Saku Ytti]

On 19 December 2015 at 10:21, Tom Storey <tom at snnap.net> wrote:
> Was always my understanding that JunOS MTU figures were on-the-wire
> frame sizes, whereas Cisco was always payload sizes, with requisite
> headers accounted for automagically.

Preamble, SFD, DMAC, SMAC, EType, Payload, CRC, IFG
7B             1B     6B,       6B,       2B,       1500B,    4B,    12B

L3 = Payload =1500B
L2 = L3 + DMAC, SMAC, EType, CRC = 1518B
L1 = L2 + Preamble, SFD, IFG = 1538B

JunOS and IOS-XR MTU use some bastard L2-but-no-CRC-lol size, because
plausibly CRC was out of reach for the HW in question (done in
MAC/PHY), so it was convenient for programmer to implement it like so,
never mind the operator confusion it causes.

Then whole another question is, what do SNMP and CLI interface bps
rate, policer and interface bandwidth count? Well, funnily enough,
there is no direct answer. SNMP is specified so that it should report
L2 rate. Rest of them are platform dependant, sometimes configurable
(ES+ policer counts L2, but overhead can be added, JNPR policer
correctly counts L1 as does ES20) often it's hard to know.
I'm right now struggling to figure out what is JNPR WAN-PHY interfaces
reporting, the reported capacity of interface is missing WIS and
Ethernet encoding overheads, so your LACP sizes are WAY of from true
achievable L1 ethernet rate, and thus your RSVP capacity is way off.
And no clue what the heck is 'output rate' measuring in JNPR.

Personally, I'm only ever interested in L1 rate and bandwidth (so
policer, bps rate in CLI and interface bandwidth all should report L1
rate), I'd also hope for enterprise MIB giving rate in L1 instead of
the broken L2 rate standard MIB. Then my graph would show actual
utilisation. For some protocols, like ethernet, you can quite reliably
reconstruct the actual rate by doing (pps*overhead)+bps in your
graphing tool. For others, like ATM, not possible.

-- 
  ++ytti