วีดีโอ

As-salamu alaikum! You have an amazing voice, brother. Is that a Focusrite Scarlett USB audio interface in your videos? If so, how do you like it? Regarding VC upgrades... virtual-chassis on its own doesn't support a hitless upgrade process, but that's not unique to Juniper. Stacking, regardless of the vendor, requires every stack member to run the same version of code during normal operations. There is also a required reboot for any switch going through an upgrade, so hosts connected to that switch will lose connectivity. What does this all mean? Let's start with your requirement for "no impact". I've encountered folks that operate critical networks insisting that network-attached hardware cannot be offline even for a second. Think hospital networks, electrical grid IT networks, and similar. The thing is, if what you are plugging into the network only has one network interface, that device is not built for high-availability! To put it a different way, you can ensure no/minimal network disruption during an upgrade only if each device connected to the virtual-chassis has a minimum of 2 links (in a LAG), and those 2 links are connected to different switches. In this way, while one switch in the stack is upgrading and unavailable, the connected host can still function over the link to the other switch. To answer your question, you can upgrade the BK first, but all you'll be able to confirm is that it boots with the correct software. VC functions are very limited during the upgrade process, so there's no meaningful VC testing you can do post-upgrade. What I suggest is the NSSU process: www.juniper.net/documentation/us/en/software/junos/high-availability/topics/concept/nssu-ex-series.html Pay very close attention to the configuration requirements if you choose to use NSSU! When NSSU fails, it's almost always because one of the many prerequisites hasn't been met. This process will do a bunch of verification checks, upgrade the BK RE first, then start upgrading the VC line-cards one at a time. Finally, the RE (master) will switchover mastership to the BK and upgrade itself. I hope this helps!

Load balancing is dynamic. This page does a decent job explain the why/how of how this works in Junos: www.juniper.net/documentation/us/en/software/junos/evpn/topics/concept/evpn-vxlan-dynamic-load-balancing.html Regarding route-types, you'll find ESI values in Type-1, Type-2, Type-4, Type-5, and Type-7/8 route advertisements. You are correct to callout Type-1 routes as being associated with multi-homing as they are only generated when the ESI value is not all zeros (all zeros = single-homed interface). However, Type-4 routes also play a role. These "Ethernet Segment" routes are used for DF election and enable load-balancing of BUM traffic across the fabric. Together, Type-1 and Type-4 advertisements provide the EVPN control-plane with the programming it needs for load-balancing.

Not from me, unfortunately. Since I've moved to Nokia, I don't have entitlements to code any longer. I'd wager there are more current versions out there kicking around, but I wouldn't know where to look since I never had to get creative when it came to getting Juniper code. Good luck!

@@5minutejunosthanks for quick reply! Wishing The best on your new journey !

@@ivoschmidt_cz Thank you!

I absolutely will!

I will absolutely keep this channel live. I'll even answer questions, as I'm able. I'm so happy to hear that my videos were helpful and I hope some of the content on my new channel can do the same. Take care, be well, and thank you.

Nothing but the future ahead of me right now. After watching so many good people lose their jobs as different tech companies realigned their priorities (and in a few cases, clipped folks to pump the Opex numbers for short-term investor value), I feel incredibly fortunate to have been in a position to decide my own path. Take care, be well, and thank you.

Wow. That's incredible to hear. I really appreciate it. I'm curious who you mean by "we", and your username isn't giving anything away :) So far, Nokia's focus on R&D, quality, and automation vision have exceeded my already lofty expectations coming in. I was really happy at Juniper, so my move to Nokia was a 3-week process of discovery and self-reflection. My new channel will hopefully be enough of a blend of netops and Nokia stuff to remain broadly relevant to folks, regardless of their blend of vendors. I hope you can find some value. Don't be a stranger either way! Take care, be well, and thank you.

And thank you! It's no exaggeration when I say that running this channel has contributed more to my success over the last 7 years than any other single thing. It's one thing to learn the technology. Having a forum to tune my ability to communicate the value of that technology has been incredible for me. Take care, be well, and thank you (again). I hope you can join me on my new channel (which is code for "I hope my new channel remains relevant for folks like you")

@@5minutejunos NOOOOOoooooo!! I always wanted to go back to work with Juniper Devices because of YOU!!! again Thank you soo much!! I learn a lot from you!

Miss you too, buddy. I enjoyed Juniper. I miss people. You. Kyle. Mitch. Oliver. Greg. Jay... too many to list. Great people on a great team. Go f*ck sh*t up at HPE! (in a good way, of course) Take care, be well, and thank you.

And thank you for sharing the experience with me. Things like this are exactly why I created this channel in the first place. If I can spare one person a lost weekend troubleshooting a problem, it's worth it!

That is incredible praise! I appreciate the feedback.

Thank you for the positive feedback! It's a labor of love. Time consuming, but absolutely worth the understanding it gives me of the technology. And I really do like helping others learn and understand these concepts.

I'm a Juniper FTE. I can't do side-hustle stuff like this and keep my job. Sorry, but I'm hoping the video series alone gets you where you need to be. That's why I created it!

@@5minutejunos yes the video was great. I am a Cisco guy my whole carreer hoping to get confidence on this new Platform JunOS

It's called "presentify". I'm on a MAC, so if you're on PC, you'll need to find something different as Presentify was Mac-only last I checked. Good luck!

It's a solid question that I don't have a good answer to. I don't manage or admin the elevate community. Surely there must be some sort of account recovery workflow?

Thank you! These videos really help me with understanding the technology and I know that having step-by-step guides help those who go through the videos as well. Hopefully they fill the gap between "doing" and "understanding" Ha Ha Ha ;)

Fair enough, but now I actually work on the global security sales team, so explaining how service chaining works is my job :) I'll get something together in Q2, I promise.

ha! while I know this is almost certainly an agent or bot, I will say to other that might be reading this that my dream is to be in a position where creating content is my job, not a place where my job is content creation. Sound like a paradox? Nah, just that I'm a network engineer and videos are a way to connect with people and hopefully help folks out. If I ever run a channel that is large enough to be monetized, I'll take that bag and find a way to push it back into educating network engineers.

th-cam.com/video/xt3Z58MmGbc/w-d-xo.html

Should be a similar workflow, if not the same. There are two methods: - Upgrade each member separately: www.juniper.net/documentation/us/en/software/nce/nce-171-qfx-vc-upgade/index.html - Upgrade using NSSU: www.juniper.net/documentation/us/en/software/junos/junos-install-upgrade/topics/topic-map/install-software-on-qfx.html I don't have QFX platforms to test with, so I can't record a video for you. :(

It's a very capable PoE++ multi-gig switch, so if he has a home network and/or physical lab, that's a good place to start. They can be a bit noisy, so it really depends on his situation. Honestly, if he can sell it, he could convert the money into virtual lab hardware and an eve-ng pro subscription. That might be his best option if he's looking to build a lab since he can get a whole lot more mileage out of virtualization than he can with a single switch designed for aggregation/core campus networking.

Excellent! Thanks for watching.

Thanks!!!

Oh jeez, you're too kind. Thank you!

I'm looking forward to it. DC and big, chunky firewalls go hand-in-hand, so I'm hoping I can add some real value.

Thank you! More videos on the way, I'm sure. Just with a security slant.

Praise from Caesar!!!

If it was all about efficacy, we would already be the leader. The selection of a firewall vendor is emotional in a way that other parts of the network are not. I'm hoping my own perspective on how to build trust with Enterprise customers can deliver value.

Yes, it's a good thing. I'm excited to add my perspective to our security strategy!

You are welcome!

What type of device are you using? I believe you need something that supports traffic-control-profile in COS to define a per-unit shaping-rate. The EX3400 I used in the video, as well as the EX2300-24MP I have now, don't support this syntax. A per-unit scheduler would do it as well, but that's going to be Trio (MX) and my guess is that you're landing your microwave link on a switch?

Working on the 4.2.1 content right now. Most of it's done and I"m literally going through the type-5 multi-node HA service chaining documentation this week! Stay tuned

Updated 4.2.1 series is uploading this week!

Thanks for the response! I'll cover it in the series. What's your urgency?

​@@5minutejunos No urgency, just wanna learn some apstra stuff, so i can do it if my company has the opportunity to sell apstra

I'll look into it. I know the channel has been stale for a while, but I'm currently building an Apstra 4.2 lab and planning a new series. If I can fit in some PVLAN stuff, I will!

I came to know 20.3 is needed to try again, if anyone has 20.3 for vqfx please let me know thx

This made my day. Thanks, Calvin!

i am also having the same issues, i used 20.2 R1 version, my settings are as follows. on the edit node for a spine in eve topology: First Eth MAC Address: 50:00:00:13:30:00 from shell: i set the serial:serialid="VM0000133000" show chassis hardware shows:Serial number : 15056017554 , rebooted after changing the serial in shell but still .. Apstra picked the serial as 500000133000 from onboard devices section but in blueprint, no devices shows the system id/serials. How can i fix this?

Sorry to take so long on getting back to you. The "fix" in this case is to stop using vQFX and start using vEX. The newest versions of our virtual switching platforms do not require this hacky system-id mess to work properly. I'm releasing a new series that uses vEX, so I can tell you it's solid. You can download it here: support.juniper.net/support/downloads/?p=vjunos