Replying to myself before someone else catches my egregious error... After going back to review what I actually did vs what I thought I did when enabling hyper-mode, I very much got it backwards re icmp redirects. You have to allow redirects to be sent to use hyper-mode. That's a step backwards and a calculated risk to take. I disallow ICMP redirects via firewall filter.
I'm academically curious why this is a requirement (allow icmp redirects to be sent) of hyper-mode. -Michael > -----Original Message----- > From: juniper-nsp <juniper-nsp-boun...@puck.nether.net> On Behalf Of > Michael Hare via juniper-nsp > Sent: Saturday, March 9, 2019 4:23 PM > To: Saku Ytti <s...@ytti.fi> > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Hyper Mode on MX > > 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/g > eneral/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- > n...@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp