[j-nsp] Hyper Mode on MX

[Michael Hare]

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-bounces at puck.nether.net> On Behalf Of
> Michael Hare via juniper-nsp
> Sent: Saturday, March 9, 2019 4:23 PM
> To: Saku Ytti <saku at ytti.fi>
> Cc: juniper-nsp at 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 <saku at ytti.fi>
> > Sent: Friday, March 8, 2019 11:11 AM
> > To: Michael Hare <michael.hare at wisc.edu>
> > Cc: Franz Georg Köhler <lists at openunix.de>; juniper-
> nsp at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp