Saku/Franz- I admit I didn't know what vlan padding was going into enabling hyper mode (or frankly even this conversation) and made an educated guess at relative safety at the time based on lab work (simplified production test) and a slow production roll out.
In case of the hyper mode feature, it looks like Juniper docs now do a better than average job explaining constraints. Sorry if this URL was already shared in this thread https://www.juniper.net/documentation/en_US/junos/topics/reference/general/hypermode-unsupported-commands.html In this case, Franz, it appears you would have had to had configured "set interfaces interface-name gigether-options pad-to-minimum-frame-size" and that the commit parser wouldn't even let you try to enable hyper-mode if you had it set. In fact, I do remember being forced to add "set system no-redirects" to our config at the time. I say forced but in reality it was a good change to make at any rate. I think I verified this one with lo0 counters (memory is failing me) to make sure I could safely add without changing expected behavior. -Michael > -----Original Message----- > From: Saku Ytti <s...@ytti.fi> > Sent: Friday, March 8, 2019 11:11 AM > To: Michael Hare <michael.h...@wisc.edu> > Cc: Franz Georg Köhler <li...@openunix.de>; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Hyper Mode on MX > > Hey Michael, > > > I have used successfully used hyper mode on MPC4E in M2K for a few > years with little regrets. I chose to do this as I didn't have the > equipment to > do line rate testing and I do a significant amount of counters on untrusted > ports. As others have suggested, you need to know feature limitations. We > certainly do .1q as well as double tagging so the vlan padding feature is not > what you think it is. > > What do you and Franz think it is? What I think it is > > a) IP packet comes in to a router, and the packet is 41B or smaller > b) router sends the IP packet out via VLAN encapped interface, adding > VLAN to the 41B, for packet of 45B > c) 45B is invalid ethernetII payload size, frame may get dropped in L2 > transport > > I read hypermode as victim of Trio's success. Juniper has been able to > use same microcode for over decade now. Obviously after 10 years of > development any code base is in dire need of spring cleaning. But you > can't fix code without breaking code. So I think hypermode is just > Juniper's strategy to rewrite Trio microcode and pay up some technical > debt they have, but in a way that they release it to the market > staggered, without single flag day. > You could say Cisco is doing the same right now, because in ASR9k > history first time are introducing non-microcode compatible lookup > engine, forcing them to rewrite all forwarding plane code. Just JNPR > isn't forced to do it, they just choose to do it. > > -- > ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
