On 19 December 2015 at 10:21, Tom Storey <t...@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp