Re: [j-nsp] Hyper Mode on MX
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
Re: [j-nsp] Hyper Mode on MX
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 On Behalf Of > Michael Hare via juniper-nsp > Sent: Saturday, March 9, 2019 4:23 PM > To: Saku Ytti > 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 > > Sent: Friday, March 8, 2019 11:11 AM > > To: Michael Hare > > Cc: Franz Georg Köhler ; 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
Re: [j-nsp] Old JunOS upgrade path
On Sun, Mar 10, 2019 at 4:30 PM Tom Beecher wrote: > was when it was shut down. ( Hopefully. :) ) When you upgrade it, the > process only modifies certain components. Any OS upgrade process like that This is not true, the upgrade is fresh install. It is not like you do upgrade on your laptop FreeBSD or Linux. Equivalent on your laptop would be that you keep your config in directory /config, have that in partition you don't touch then reinstall new FreeBSD on your system partition and remount that /config partition. You just lost all the programs you've installed outside base system and any other changes you've done outside /config. Your laptop FreeBSD doesn't know what exists in the system what data has been changed, what has been installed it can't just steamroll the installation with new, so it'll reinstall new stuff on top of old one for the things it knows about. Juniper doesn't have this problem, they know what is the state of the system so they can just streamroll it and they do. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
This was, and still is, the most accurate answer in the thread. To expand on it further Cisco IOS images are standalone binary images. Each time the device is powered on, it loads the image it is configured too, and executes it. The entire operating system is encapsulated in this image file, and it's execution is completely independent of any image is has executed previously, or will in the future. You don't really 'upgrade' a Cisco IOS device ; you just tell it to load a different image. Junos is a complete operating systems. Just like your home computer, each time the device loads, it is loading the complete OS in the state that it was when it was shut down. ( Hopefully. :) ) When you upgrade it, the process only modifies certain components. Any OS upgrade process like that will have restrictions and dependencies that dictate where you can upgrade from based on where you are now. You always have an option to do a clean install of the version you want, but that is a complete removal and replacement of the entire OS. Cisco NX-OS is the same way. I've watched our datacenter guys have to do the exact same intermediate upgrade, X -> Y -> Z , if the version gap was large enough that X -> Z was not doable. Exact same reason as JunOS. On Fri, Mar 8, 2019 at 4:14 PM Gert Doering wrote: > Hi, > > On Fri, Mar 08, 2019 at 01:17:44PM -0700, Eldon Koyle wrote: > > Many (most?) network operating systems are an image file that the > > switch either writes over a partition (ie. block-level copy) or boots > > directly (ie. initrd/initramfs) with a separate partition for a config > > file. Junos is a full BSD operating system that installs packages to > > partitions on the device, runs upgrade scripts, etc. > > So? > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ > 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
Re: [j-nsp] Old JunOS upgrade path
On 9/Mar/19 11:18, Saku Ytti wrote: > So Gert's question 'y tho?' is very much valid, and the most obvious > reasons is because Juniper doesn't want to increase the product cost > to cover lab testing from any-to-any, as it would mean ever increase > money and time cost to release. By setting some fixed rules, they have > fixed amount of work to test the upgrade. I doubt Cisco has actually > formally supported any-to-any on classic IOS either. You may be right. I have a dinner planned with some Juniper folk that seem to have clue. I'll definitely ask this question and see what lands. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
