Mailing List Archive

> On 7/03/2019, at 10:40 PM, Franz Georg Köhler <lists@openunix.de> wrote:
>
> Hello,
>
> I wonder if it is gererally a good idea to enable HyperMode on MX or if
> there are reasons not do do so?
>
> We are currently running MX960 with FPC7.

https://www.juniper.net/documentation/en_US/junos/topics/concept/forwarding-options-hyper-mode-overview.html <https://www.juniper.net/documentation/en_US/junos/topics/concept/forwarding-options-hyper-mode-overview.html>

There are a bunch of features you cannot use if you enable hyper mode.

--
Nathan Ward

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

By the way HyperMode is only useful if you expect some very high throughput with very small packets (none of the MPCs are linerate using very small packets, but HyperMode brings it closer).
Your Junirepresentative may show you a linerate performance/packet size graph with/without HyperMode to help the decision.

Note: not your case, but HyperMode is useless on MX204, though (that has some other throughput limitations, discussed in this mailing-list and in Juniper KB).

> Le 7 mars 2019 à 12:18, Nathan Ward <juniper-nsp@daork.net> a écrit :
>
>> On 7/03/2019, at 10:40 PM, Franz Georg Köhler <lists@openunix.de> wrote:
>>
>> I wonder if it is gererally a good idea to enable HyperMode on MX or if
>> there are reasons not do do so?
>>
>> We are currently running MX960 with FPC7.
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/forwarding-options-hyper-mode-overview.html <https://www.juniper.net/documentation/en_US/junos/topics/concept/forwarding-options-hyper-mode-overview.html>
>
> There are a bunch of features you cannot use if you enable hyper mode.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Thu, Mar 07, 2019 at 12:31:48PM +0100, Olivier Benghozi <olivier.benghozi@wifirst.fr> wrote:
> By the way HyperMode is only useful if you expect some very high
> throughput with very small packets (none of the MPCs are linerate
> using very small packets, but HyperMode brings it closer).

Thanks.
While we actually don't need that performance really I was wondering if
would be a good idea to enable it on new installations preventively.

* Padding of Ethernet frames with VLAN.
Isn't that a very basic functionality and would break ethernet
switching?

* Node Virtualization
This is Junos Node Slicing?



Best regards,

Franz Georg Köhler
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Junos Fusion is not supported when hyper-mode is enabled.



-----Original Message-----
From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> On Behalf Of Franz Georg Köhler
Sent: 07 March 2019 12:46
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Hyper Mode on MX

On Thu, Mar 07, 2019 at 12:31:48PM +0100, Olivier Benghozi <olivier.benghozi@wifirst.fr> wrote:
> By the way HyperMode is only useful if you expect some very high
> throughput with very small packets (none of the MPCs are linerate
> using very small packets, but HyperMode brings it closer).

Thanks.
While we actually don't need that performance really I was wondering if would be a good idea to enable it on new installations preventively.

* Padding of Ethernet frames with VLAN.
Isn't that a very basic functionality and would break ethernet switching?

* Node Virtualization
This is Junos Node Slicing?



Best regards,

Franz Georg Köhler
_______________________________________________
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

> Franz Georg Köhler
> Sent: Thursday, March 7, 2019 11:46 AM
>
> On Thu, Mar 07, 2019 at 12:31:48PM +0100, Olivier Benghozi
> <olivier.benghozi@wifirst.fr> wrote:
> > By the way HyperMode is only useful if you expect some very high
> > throughput with very small packets (none of the MPCs are linerate
> > using very small packets, but HyperMode brings it closer).
>
> Thanks.
> While we actually don't need that performance really I was wondering if
> would be a good idea to enable it on new installations preventively.
>
In short No,
You need to know exactly what you're doing when enabling this feature.

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Franz-

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.

Re MX204, I read that line rate thread differently. I thought hypermode actually increased PPS on the ingress processing side but I 100% agree that hypermode does NOT affect the WO queue difference on the MX204. So in short I think there is some benefit in enabling hypermode on MX204 but not the full benefit of a native MPC7 if you have a especially complex ingress ACL policy?

-Michael

> -----Original Message-----
> From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> On Behalf Of
> Franz Georg Köhler
> Sent: Thursday, March 7, 2019 3:40 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Hyper Mode on MX
>
> Hello,
>
> I wonder if it is gererally a good idea to enable HyperMode on MX or if
> there are reasons not do do so?
>
> We are currently running MX960 with FPC7.
>
>
> Best regards,
>
> Franz Georg Köhler
> _______________________________________________
> 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

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

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 <saku@ytti.fi>
> Sent: Friday, March 8, 2019 11:11 AM
> To: Michael Hare <michael.hare@wisc.edu>
> Cc: Franz Georg Köhler <lists@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

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

Hey Michael,

> 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.

I think it is just config parsing problem. By manually disabling icmp
redirects the parser reads this as 'you are using redirects, this is
incompatible with hyper-mode'

I don't think you need the FW filter, as hyper-mode does not support
redirects (now, it will later) they are just no-op. But doesn't hurt
either.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp