Harry Styles is one ex-boyband member who's been making it on his own lately and then some. With everyone drooling over the new video for watermelon sugar he's definitely the center of attention. Fans speak highly of Harry like how humble he's remained despite all of the fame and fortune. But we can't forget the fact that he's the richest member to come from the band One Direction and affords himself luxury most of us can only dream of. Out of all the 1D boys he leads the pack for expensive purchases like homes, his car collection and crazy designer clothing. Although Harry's been hired as the face for Gucci campaigns in the past we know he also likes spending his money on wardrobe from them. In fact none of his eye-catching outfits are cheap. Harry's own homes across the US and the UK and his latest purchase in Hampstead gives him the chance to create a trophy mansion considering he already spent over 13 million dollars on neighboring properties. Most of Harry's cars cost seven figures in his collection includes an Audi, Ferrari, classic Mercedes and more. Not to mention the custom motorcycle he's often seen driving around town. And when he's taking a break from work he loves to vacation in style whether it's vacationing with friends like Adele and the Caribbean or chilling on luxury yachts in St. Bart's Harry knows how to travel. Harry's tells us the richest member to come from boy band One Direction surpassing all four others and right before the group announces split Forbes declared them the highest paid celebrities under 30. Harry's also said to be the third richest British celebrity at the time of this recording and since signing a solo deal with Columbia Records in 2016 his bank account has only increased. Harry's estimated net worth is said to be 86 million US dollars. What's going on guys and girls I'm Kara and welcome back to a new series titled The Millionaire Life here for you on Famous Entertainment. In these vids we're gonna be taking an in depth look at the luxury lifestyles of the rich and famous but unlike our other series not everyone will make the cuts. This is for those who have made money into the hundreds of millions even billions of dollars and are living like kings and queens of today. I guess for Harry it's an exception but he's pretty close to the 100 million dollar mark so we'll let it slide. We did a couple vids like this on the likes of Kylie Jenner and Kanye West and I'll link them at the end. As always I need you guys to keep suggesting who to do next in those comments down below, follow me over on Instagram and subscribe if you're new. Now let's get into Harry Styles Millionaire Life here on Famous Entertainment. We're gonna skip Harry's come up story since I know you guys are familiar but let's take a look at his business portfolio so we can pinpoint the sources of revenue that made him a multi-millionaire. Of course one direction is to thank for bringing Harry to mega fame status. The boy band was declared one of the highest paid celebrities before they split up by Forbes earning 130 million dollars in 2015 alone beating the likes of Taylor Swift and Lady Gaga. In 2014 the boys were walking away with 280k per day. Like I said Harry is the richest member to come out of 1D and he was the highest paid as well. Now there's the revenue from his thriving solo career considering his debut album topped the charts with 230 thousand album units earned in the first week alone. Aside from album sales there's also the money from the concerts. Harry's 90 show world tour sold almost 1 million tickets and the first leg of the tour sold out in 29 seconds. I'll also note that he raised 1.2 million dollars in charity donations from those ticket sales too. Outside of music Harry has earned money for his acting role in the war drama Dunkirk. It was one of the top grossing box office films of 2017 bringing in 500 million dollars worldwide and we also know he wants to star in more films in the future. And did we mention his fashion credentials? Harry has grabbed the attention of designers fronting two menswear campaigns for Gucci in autumn winter 2018 and cruise 2019 with both becoming social media sensations thanks to his cute co-stars like dogs pigs and chickens. Styles also founded the company has publishing limited back in 2014 alongside Irish accountant Alan McEvoy as additional income from his real estate investments which I'll show you guys in a bit. With all that money what does Harry spend it on? It's no doubt that one of his favourite ways to spoil himself is on his unique wardrobe. Harry is a fashion lover and goes all out when it comes to his clothing which are mostly high on designer pieces. For instance this toxic people sweater he wore in Ellen is Mark Jacobs and Magda Archer and it goes for about 1.5k.  Of course every time Harry rocks suits he only wears the best. Not only did he model for Gucci he also wears the brand all the time like when he wore this custom suit and shirt by them covered in glitter. Then there was this Dior home suit he wore out on the town and some others on his stage performances like the black glitter Saint Laurent suit and another custom Gucci one this time in vintage red and blue. For Harry's first Rolling Stone cover he wore this rock and roll outfit while quoting the clashes Paul Simone by saying pink is the only true rock and a lot of people a lot of fans want to know about your your fashion inspiration and and how that translates to on the stage and your music. Can you talk about what goes to that or if anything it's just just you it comes natural it's organic. I don't know if it's I don't know if it's necessarily one person in particular. I think you know music and fashion and they just you supposed to have fun with them and I think it's supposed to be fun and playful and I think it's people who I kind of grew up listening to like Elvis and David Bowie and Stones and people like that. It's like you know it's part of the show because it's fun. As co-chair of the 2019 Met Gala all eyes were on Harry to dial it up and that he did. The singer wore a lacy sheer top with a bow and black trousers designed by none other than Gucci's creative director Alessandro Another way that Mr. South treats himself is by going on vacations. He may not be able to travel much right now thanks to the global pandemic but before he was visiting some nice places. He likes to go away to tropical spots when he's not home in London or working in Hollywood and has been doing so for years. Who remembers when he went to St. Bart's with Kendall Jenner? Not to mention he rented a luxury yacht there so we know he goes all out. To ring in the New Year Harry joined friends Adele and James Corden and went to St. Thomas in the Caribbean. Although the three friends enjoyed the beaches and sun, Harry also shared the wealth. One lucky bartender at the Caribbean fish market in St. Thomas received a massive tip of $2,020 from Harry in spirit of the New Year. How sweet. This wasn't the only time Harry's proven he was a giver. He's been known to donate a portion of his wealth to support causes he believes in like in 2018 when he gave 42k to help the times up movement. During Harry's last world tour he gave 1.2 million from the proceeds towards 62 charities around the world such as those supporting the LGBTQ plus community, children's hospitals, food banks and much more. He's always been interested in doing good and making a difference so that's one thing I really respect about Harry. What Harry's put most of his $86 million fortune into seems to be his real estate. Back in 2012 he bought his first home at the young age of 18 in London for around 4 million. This place clocked in at 2,300 square feet with four beds and three baths and was known as Harry's Party Pad. He expanded his real estate portfolio across the pond as well buying a Hollywood Hills home in 2016 but he sold that soon after for 6 million. Additionally, a few years ago Harry bought an $8.4 million loft in the Tribeca neighborhood of New York City and a building much loved by celebrities. His neighbors include the likes of Justin Timberlake and Jennifer Lawrence and more. Harry's loft spans just under 3,000 square feet and the building offers great features like a gorgeous pool, extra security and even privacy from paparazzi. Aside from his first London home purchased aka Harry's Party Pad, he bought his next London property back in 2018 dropping over 10 million on a five bedroom Georgian style semi-home and this was only the beginning. More recently it's been reported that Harry's planned to create a multi-million dollar super mansion by combining his fancy mansion properties. He decided to buy up the neighboring home to his Georgian style semi-enhanced for about 5 million in cash and reports say he spent over 13 million in that same enclave. I'm not sure if Harry owns two or three neighboring properties but either way it seems he's working on building his trophy mansion or compound if you will. The latest purchase is a stucco fronted 18th century villa and wasn't advertised on the open markets. The singer is understood to be stepping up security after being stalked by a homeless man he had helped over several months and is building a fortress to ensure privacy. At least his homes are at the end of a super private road. Apparently now Harry's ready to start renovations and turn his cribs into one giant ten bedroom hangout boasting a games room and a movie theater. A major overhaul of the properties would likely cost a total of around 30 million or more but Harry's excited to make it happen. Aside from his incredible properties Harry also spends his millions on his car collection. He's been spotted out and about in various sports cars when he's not driving his motorcycle that is. The singer was only 18 when he was spotted driving a classic Ford Capri 1970. The same car was found rusting in an underground car park near his home some years later but when you've got as many wheels as Harry it's easy to forget the odd one. Some years back Harry spent just shy of 200k on a flash Ferrari California which he was seen driving around Beverly Hills.  Other cars in Harry's garage include the more spacious Range Rover and Audi R8 coupe worth over 100k and another vintage car his bright yellow classic Ferrari Dino. More recently the singer was spotted in LA driving his retro Mercedes-Benz SL Pagoda. This classic car would have cost Harry between 60k to 100k most likely. Alright that concludes this episode of The Millionaire Life. What did you guys think about Harry Styles luxury spending habits? Honestly for someone with 86 million I don't think he's too indulgent and let's not forget the man gives back a lot. Let me know in the comments down below as well as whose lifestyle is up next. My name is Kara and be sure to subscribe, find me on Instagram and I'll see you guys in another video. Bye!


Hello. Everybody hear me? Great. Well, welcome to the OpenStack Network Protocol Technical Contrast. My name is Joe Stevens. I work for HP. Thank you, everyone here. It's really great seeing all this turn out here for the presentation. I'm going to be talking about Network Protocol. So hopefully, that's what you came for, because that's what we're going to get into. This is not an HP presentation. This is just a community presentation voted on by you guys. So especially, thank you, because you're the ones who enabled me to get up here and do this. So that's pretty cool. Let's get into it. Welcome. We're going to be talking about four network protocols today. Flat networking, VLANs, GRE, and VXLAN. We're going to get into each one in a little bit of detail. This is a whopping 40-minute presentation. So as you can imagine, I'm going to probably talk pretty fast. That's one of the few benefits of being born in New Jersey. The Italian family is I have that ability. So forgive me if I'm going quick, but it should be at least interesting from that perspective. So what I decided to do when I came up with the idea for this session was to come up with a buyer's guide concept to network protocols in OpenStack. What I meant by that is we've got a lot of choices. We have all kinds of different options in OpenStack. Network protocols, certainly there's a bundle. But there's not a whole lot of info out there on why I might want to use one over another. So that's really what the main goal of the session is. I'm going to provide some base information for folks who maybe are new to OpenStack, networking and specific. We're going to abstract the protocols themselves and talk in detail about what the protocols do with relation to OpenStack. We'll be getting into some of the mechanical details. We don't have enough time to go into the nitty-gritty about everything. 40 minutes, right? We're going to find out why the heck there's so many choices to begin with. And that's a question I think that plagues us from the get-go is, can't you just tell me what the best one is and I'll use that? Well, sadly, that's a complicated answer. We're going to take a look at the potential costs and benefits of each one of these options. And we're focusing in this session, 40 minutes, 38 now, on the what and why, not so much the how. There's plenty of sessions that tell you how to configure VXLAN and et cetera. I'm looking at it from an architecture perspective. I hope you all too on why I would do one versus the other. And what do I get out of it when I make that choice? So it's 40 minutes. I'm going to keep it rolling. I talk fast. I'm going to try and get through a lot of content. I'm going to skid right into the end, hopefully at 40 minutes. And so I'll ask you to hold your questions till the very end. I'll be thrilled to go out afterward and we can talk about it as long as you want. But I won't have time to stop during the presentation. So hey, guys, we're here to have some fun. I hope you are too. All right, a little bit about what we won't talk about. We're not getting into hardware specifics. We're not talking about accelerator cards or offloading or any of that stuff. It's all really fascinating. There's actually some good stuff out on the vendor floor. You can talk to folks about that stuff. It certainly goes along with this discussion. I don't have time. We're not going to talk about DVR either. That adds a whole really cool element to the idea of how the protocols interact with OpenStack, but it actually, it'll make it way too long. That's a whole other topic to itself. We won't be going into how to configure, like I mentioned, and IP version six isn't on the list. So if you came looking for that, that's not where I'm headed. Let's get into it. The first step in avoiding a trap is knowing of its existence. Come on, has anyone heard that one before?  All right, well anyway, I think I just outnirted a whole room OpenStackers. Fuffer Howlett from Dune, Frank Herbert, right? So why did I have this in there other than you're supposed to have quotes in your presentation? Well, I put this in there for a reason. In OpenStack, we make a lot of choices, right? When we get down to the architectural decision making process of deploying OpenStack, we have a lot of things to think about. And sometimes, and I'm sure you've seen over this last couple of days, we write presentations on things we should have thought about before we did it, right? And network protocols is probably right there at the bottom. Once you've deployed OpenStack cloud and started having users get in there and running workloads, it's a little too late to decide you picked the wrong one because redoing it's going to be painful. So we want to avoid the trap because we know they're out there. And this is easy because there's some pretty easy decisions to make. So my philosophy in this little tiny topic is start with the end in mind. This slide will have a whole bunch of pretty words on the right side. And if you're into taking pictures of slides, I strongly suggest you take a picture of this one once the pretty words are in it. Because this one is one you can print out and use in your design planning for future clouds. So here's some questions to ask before you pick a protocol. Will you need multi-tenant support? This is a big question. A lot of people, of course, do what's OpenStack and not everybody does, right? So a lot of clients don't want that. It's an important detail. You need to know the answer to that. It will help you pick the protocol. What's going to be your scale? At the end of the day, when this cloud's in full production, are you thinking it's a little test bed thing? Is it going to have a dozen, maybe a dozen nodes in it? Not so big. Is it going to be a full-blown, kind of multi-tenant, large-scale, 1,000 nodes? That kind of deal, need to know this in advance. It affects the protocol. What type of utilization do you expect to see on your hypervisors? What the heck's that got to do with it? We're going to find out. It has a lot to do with the protocol. Do you need maximum network performance? Kind of goes hand-in-hand on the hypervisor topic. Some of these protocols are a lot happier than others with heavy workloads. And it will affect your goal at the end. And we'll take a look in depth. We're going to get answers to all of these, by the way. That's the point. How much admin time can your organization, or you personally, can you devote to maintaining address space? That sounds like fun, doesn't it? Everyone here has probably done it in their careers. But is it something you actually have a mechanism for and are capable of doing? What's the underlying topology? This is all software stuff, right? We're not supposed to know about that. Well, if you want to be successful as an architect, you might want to know what's going on behind the covers. And in this case, with the protocol, there is a embedded relationship between the protocol you choose and the gear you're running on it, potentially. How important is redundancy? Test, maybe not. Production, maybe so, right? Are there going to be multiple sites? That's a biggie, right? And that's going to drive some decisions on which protocol you choose as well. And what kind of inspection takes place? Small detail. If you work in a bank, maybe not so small. They're actually pretty interested in some sort of compliance and audit that can inspect packets that are traveling in and out of certain regions of their network. The protocol you pick may affect that ability, so your compliance guys might want to talk to you. My favorite question is, will this be a temporary test environment? The answer is nope. Never will be. OK, so just keep that in mind. Whenever someone tells you, hey, we're just going to do this temporarily, right? How many people have built something temporarily that has become then the running production environment? And I put that in there because don't think of your choices based on a decision you already know is wrong. So plan on it being production. Just plan on doing it right. I mean, unless you genuinely know you're tearing this thing down tomorrow, you're going to live with it. And you're going to live with these choices. Of course, I like to know what's for lunch today, too. So we'll find that out. And this is the worst possible speaking time to be is in between hungry people and lunch. So we're going to move on. Here we go. Oh, hold on. Wait, take a picture of that one if you're going to take a picture, because that actually, this is something that'll be handy. You need to know these questions before you pick a protocol. All right. Three, two, one. Gotcha. All right. So here's my OpenStack Protocol flimsy analogy number one. Protocols in OpenStack are much like a pyramid. Not really, but anyway. So the reason I brought this up is because I wanted a cool image to put in the background of the presentation, plus the fact that it is sort of like a pyramid. We build the protocols we're going to talk about more or less build on each other. I mean, not directly. It's a little flimsy in some cases. But we definitely start out with a base of understanding, and we add some pieces to it as we go along. And I'm going to try and do that in the next 33 minutes. So here we go. Flat networking. Protocol number one. Step to the plate. Flat networking. This is probably the most important detail about flat networking. It doesn't require VLAN aware switches. A lot of folks say, why would I even use that? That's a good reason. So I can go grab my off the shelf Best Buy Netgear switch, and I can plug it in. I can run my little lab on it. Using flat networking, everybody's happy. If I do that with a VLAN tagged network, not so happy, because the switch may or may not even ship the packets. It may see that as a garbage shucket in the box. So this is an important detail. If you're thinking about building a little lab, this is a good choice. Addressing space, we all know. IPv4, it's running out of dust. So we've got to the point where we've all managed that pretty well. We know the limits. Overlap in your addressing space is a manual problem. So this leads into our admin situation where who's going to deal with this? Someone has to track addresses. Wheel in the spreadsheet, Bobby. We've got to start filling it out.  I don't know. But it's a pain, and we need to do it if you're going to use flat networks. Now, good side, extremely easy to set up. Everybody in this room has used something that looks like IPv4 with no questions. We know it. It's older than half the people in this room. So it's easy to set up. Mature, been around since the 80s. I would ask for Shal Hansley. He was born after 1980, and I could already look around and kind of guess. Yeah, you get it. It's been around. We know it. It's the guts of all the other protocols. So if you know IPv4, you're going to add something to it as we move along. Now, a little bit about redundancy and resiliency. So I told you that was kind of an important detail. Flat networkings heavily rely on spanning tree protocol for link resiliency. So spanning tree, another very familiar age old concept, requires a loop-free topology within your network infrastructure. It does this. It uses calculation to create a loop-free topology by blocking the ports that may be causing the loop, which is really cool. It does this automatically for you, all on the background. Problem is, and then if one of those links fails, it can spin up that blocked link for you. And now you're back in business again, all automatic. That's awesome. I mean, it sounds good, at least. Well, the problem is it's really slow, right? It's generally speaking fairly slow convergence, results in network outages, and increased TCO. Why is there increased TCO? Well, those block ports aren't doing anything. They're blocked, right? So now I'm paying for some 40G port to sit there, not shipping traffic, right? Sooner or later, the CFO will probably think you're a hero if you can figure out a way around this. One of the advantages of flat networks in redundancy is it can use some layer 3 stuff out there that's for crossing boundaries, things like load balancers, multi-pathing, dynamic routing, clustering. All that stuff's kind of layer 3, works really well with IPv4. You're not going to have a limitation there. But it's important to know it happens at boundaries typically. I mean, there's alternatives, but typically at boundaries. Now, most of this stuff can be enhanced or overcome with time and money like anything else. This is kind of background, right?  But there are other protocols that don't have these problems to start with, so let's take a look. So the admin cost. We mentioned this earlier. You're going to be tracked and forced. Forcing the avoiding of overlap has to be done manually, right? Your VMAX has to be tracked and enforced so we can avoid overlap. We can't ship them out with the same VMAX. It's a manual approach. You're going to have a guy with a spreadsheet. Maybe it's an ops guy. Maybe it's you. I don't want to do this work. Maybe you like spreadsheets. But anyway, it's a pain, and you have to take care of it somehow. Now, as far as flat networks go in a multi-tenant environment, not the best choice. And you can see kind of why. Overlap of addresses could be a really serious problem, especially multi-tenant. Last thing you need to do is have on the same pipe someone writing two addresses, the same overlapping it. Now we have the whole network down for both of them, right? Another issue is it requires a tighter integration with your network infrastructure team. So it's really more traditional ops oriented, right? Slows the roll. I can't just jump up, spin up a new network dynamically through OpenStack, get going, and do all the cool stuff that makes OpenStack worth having.  Let me get this address. Maybe I've got to put in a ticket for somebody. And that kind of thing, right? So it's not exactly the SDN model. And address space, the address space is limited, right? And it has to be managed across tenants. Now that's just untenable in a multi-tenant environment, right? So now, if you're the actual only owner of all the tenants, that's one thing. But if you really have a multi-tenant environment, and you've got client A and client B, and they're different tenants, well, who the heck wants to now be managing the spreadsheets for both of them, right? That's not going to be fun. They'll fill out this form, please, right? Now, the upside. I don't beat up on old flat networks too bad. Generally, very, very fast, OK? So typically, least amount of CPU overheads steals less from your hypervisors, right? Doesn't do any extra manipulation. When we're shipping packets in the hypervisor, we're not doing a whole lot of them shipping packets. Typically, can achieve near-lying speed. If you have a 10G link, and you want to get 10G out of it, you can get 10G out of it right there, OK? So that's a big deal. And I think another thing is it's a known quantity. Everybody's been there and done that. We know IPv4. So again, I'm rushing through this piece, because we already get IPv4 kind of. So I want to get to the juicy stuff in the next 27 minutes. So pros, flat networking. Low overhead, really low overhead in the CPU on your hypervisor has high network performance. It'll run on all your IPv4, so you don't have to go buy new gear. You don't need VLN switching support. Honestly, put that in the back of your caps, guys, because if you come to the point where you need to do something and you just happen to have that whatever little d-link router or d-link switch sitting around, this will work, right? Negatives, scale's going to be limited, right? Address overlaps can happen, and then bad things happen from that. It's not really extensible like some of the others, which we'll see. And it does rely heavily on spanning tree. It's really kind of the only thing there that's doing anything for it. More admin required, right? And more admin equals kind of against the sort of concept that we're driving for here. So why would I use it? On the green side, single tenant, yeah, no problem. Small scale, easy to deal with. Protects investment in your network infrastructure. The CFO's happy again. And labs test small stuff. Not really big time, right? Negative multi-region deployments, it's going to fight you every step of the way if you're trying to do multi-region with flat networking. Larger scale, you get into massive management of addressing spaces and multi-tenant just makes it even worse. So there you go, flat networking in a nutshell. Groovy. All right, that was, I really wanted to do that quick because, well, 25 minutes left here, and we're not even through the juicy stuff yet. Virtual VLANs, right? Virtual Local Area Network, a little more mature. We all kind of know this one, too. It's going to be pretty quick. We'll get into the deal here. Video 2.1Q describes the standards. It doesn't encapsulate the original frame. This is sometimes a misnomer. Folks think that VLANs are like a tunnel or an encapsulation protocol. They're not. It actually is simply an insertion of a 32-bit header field right after the source MAC in the packet. So you're taking your packet, you're adding a little to it, and voila, one of those things is the VLAN ID. That's what creates a VLAN. So now, once that VLAN tag has been inserted, it can be inspected and stripped, kind of like in the airport, but probably less fun. And you have to use VLAN switches to do this, right? So it kind of varies how each vendor handles stuff. Some of them, the switch will see the frame, see that extra piece in the header and go, that's crap. Let's throw this whole frame out. We won't send the traffic. Some of them will send it anyway and who knows where it goes. But the message is it requires something that's generally VLAN-aware if we're to work right. Spanning tree, our old friend, the instances can be applied logically to individual VLANs. This is kind of a big deal. So one of the problems we said was traditional flat networking has problems with resiliency. VLAN kind of takes that and adds a little to it, right? So we have the ability to kind of spruce it up a bit, give it a little refresh. We can create individual spanning tree instances per VLAN. And there's some other good stuff like that. Still requires loop-free. Still requires blocked ports at some point. So you still have some of these problems. It's just a little nicer. It's an incremental step forward. Now, one of the other good things is you can ride, obviously, multiple VLANs over a single physical link. That's a huge plus, right, Trunks? We kind of all know about this stuff and going quick. And Max, really, punchline. Maximum number of VLANs, 4,094. That sounds like a really big number to a lot of people. I've heard that statement, well, I'm not going to use 4,000 of anything. That's amazing. I can do that in my life. Yeah, well, here's the rub on that. That may be true. Your whole environment may not use 4,094. However, your switch may only be good for 24. And that's a real rub that you need to check out, too. Individual switches within your topography, sometimes your top of rack switch that all your VMs are plugged into, they all are different, right? So each manufacturer and each product line these guys have, some are eight. Some are 128. Some are 1,024. It really depends. In the domain, you can have 4,094, but your gear may not be able to deal with anything bigger than a certain number. This is an important detail to know. So quick, little pitch on the packet itself. You've got a pretty straightforward layout. It's just, I promise I won't dwell on any of this. It's just inserting this little VLAN header. Everything else is exactly the way it came from God, right? So we just put that little header in there, tells you what the VLAN idea is, now you've got a VLAN frame. That's the end of it. Not too much to see there. Redundancy-wise, VLANs, spanning tree, still has to be loop-free. Spanning tree still calculates your topology. There's likely unused links. Most of the resiliency still comes at layer 2. There's some extra goodies that we can tie together to make things better, poor channeling and such. And some of those problems, again, can be overcome with time and money. You can spend time planning. You can spend time implementing. Tends to make your environment less flexible, that we're all here to achieve as flexible environments. So some of that stuff that we do in the background in traditional IT can be done, but it's kind of fighting your SDN model a little bit. You're kind of saying, all right, I'm not as dynamic as I really want to be. Multitenancy, hey, it's pretty good here, honestly. So it can be used. Maybe not the best choice, there's better. But it can be used. Overlap of addresses can still be a problem. Still has to be tracked. VLAN IDs have to be tracked and assigned across multiple tenants. So if you have more than one tenant, they can't just pick whatever VLAN they feel like using, because it's all running on your infrastructure. And the infrastructure will still see the same address. So we can't do that. Scale problem, 4094. It's a big number, but it's not all that big when you start adding up in a multitenant environment. Think about this, 100 VLANs in a tenant. Now I have 100 tenants, uh-oh, right? We got problems. Bottom line on VLANs. Logically, they're a pretty reasonable scale.  Multitenant support does work. It's not bad. It uses common concepts that have been there and done that idea, like I just mentioned before. Probably a brand in the rooms don't deal with VLANs at some point. Your infrastructure guys certainly have. No real learning curve, nothing, no magic here. And it performs. VLANs do perform, right? So in a high-performing environment where you need lots of bandwidth and you've got an application that wants to crank out, you know, something over the network, VLANs do pretty close to line speed, typically. But on the downside, you need VLAN switches. Maybe it's a downside, maybe it isn't. I think everybody who deals with, you know, enterprise-level gears, typically using VLAN switches, they have to be tracked, again, some kind of manual process that I don't want to do. They can't easily extend across regions. I mean, they can, don't get me wrong, it can be done, there's a way around, but it's not easy. It's not an easy way around, right? We realized for Unspanning Tree, like we mentioned, and you may have some dead links again. Again, that can be altered, time and money, just figure it out and you can make it work. But that's not a plus. So why would we use VLANs, right? So single-tenant, small, multi-tenant, for sure. Medium, large-scale, could be large, I mean, depends on your idea of large. Moderate utilization, protecting investment and network gear.  I mean, you know, hey, yeah, we're using this, you know, so he's happy again. This is an important detail for the success of your career, trust me. If you're using older server gear, it could slow down with CPU utilization. VLANs are not as picky about this. It's gonna be worse later, we'll see. Scale beyond 40.94, just out of the question. We're not doing it. If you've got lots of tenants, that's a bad sign. So if you're running into that, hey, I think potentially this is gonna be a large multi-tenant environment, we're gonna have lots of tenants. Well, that's an exponent, right? So it's gonna start getting bigger and bigger fast. You may hit that wall faster than you think. And if you need to get, again, if you need to get your local networks extended beyond layer three, that's tough. Now you get into some kind of weird bridging thing. There are vendors out there who have some cool technology around making that happen, but it's no fun, right, trust me. It's not gonna be fun to integrate with OpenStack. There we are. Not too bad. 18 minutes left, you're all still mostly awake. I think that guy's not, but, yeah, all right. GRE tunnel, right? Generic routing encapsulation. This is an old-time favorite, right? It's a oldie but goodie. And here's another quote, right? Why not? Anyone guess this one? Come on, somebody. Come on, save a lot of time if I just gave up and went mad now. Hitchhikers, thank you very much. Arthur Dent, Hitchhiker's guide to the galaxy, right? So what the heck are they thinking about GRE? When you start looking at this thing, you're going, ah, I don't know. And it kind of makes sense when they got it into OpenStack and then came up with something better, you know? So we'll see how it works out though. So general concepts of what GRE, if you're not familiar with it, it uses IP version four for transmission over the existing network infrastructure. This is a nice idea, right? So I don't need special transport gear. I don't have to have some wackadoodle VPN thing. I don't have to have any termination stuff. It's all done in software and it rides over your existing networks. This is good. It does create a tunnel between two virtual point-to-point links. This is not encrypted tunnel, okay? So a lot of folks kind of get that one, somewhat sideways, just because it's a tunnel doesn't mean it's encrypted. It just means it's stuffing something and something else and sending it down the road, right? And so that data is still clear text. It can still be read by anyone who can catch the packet. The payload packet is a layer three encapsulated packet within the GRE packet and it can be sent across your network traditionally. It's kind of a fun part, right? It does allow for overlap of IP addresses which is between tenants. This is a big deal we talked about, right? So we want to make sure we're not having to go and maintain our spreadsheets and see what everybody's IP address is. And this GRE will allow you to get away with that because it'll give you some of that isolation between tenants. Does allow for full use of all your goodies, your routing protocols, dynamic pathing, you know, load balancing, all that kind of good stuff can all be used with GRE as well. So again, the transport is just regular IPv4. Does scale better, arguably, than flat or VLAN networks. Because you have that ability to do some isolation, you can have overlapping addresses and therefore you can reuse stuff, right? So you're not getting anything new out of it but you're gonna use the old stuff more. So then potentially that comes like, eventually kind of teeters out where now the overhead of running too much GRE becomes a problem and it balances back again. But generally speaking can scale reasonably well. What does it look like under the covers? Well, again, we have a transmission network, okay? That's basically all this good stuff up here which just is your regular IPv4. And then we have the payload. The payload rather than being the normal payload of the packet is another packet, right? It's jammed down inside it. That was the original source packet, gets stuffed in the other one and then transmitted. So that's how we create the tunnel. We take a packet that hosts sent, we stuff it inside another packet and then we whiz that guy across a network when it arrives wherever it's landing. It gets unstuffed and all the host sees is this guy down below. So it arrives through the tunnel. But again, this is all clear just to make sure you get that one there. The data in here is not encrypted. It's just clear text. It just happens to be inside another packet. So redundancy in GRE. Well, it uses Layer 3 technology to communicate so all the goodies that go with Layer 3. You too can use. It can use multi-pathing, equal cost multi-pathing, all the good stuff that's kind of traditional WAN technologies and all that. It does use redundant, you can use redundant routers, gateways, all that good stuff. And it doesn't rely as heavily on spanning tree. Still at the underlying fabric, you got Layer 2 that's dealing with spanning tree. But because you can really now start to lean on things like dynamic pathing, you're less beholden to it. The admin cost, kind of auto magic, right? The configuration's pretty quick. It's not a big deal to set up. Doesn't require somebody with a spreadsheet to live their life tracking your addresses, which I think is great. And it kind of fits better in SDN, right? Sort of small-scale SDNs, very easy. You can dynamic, pick a dress, do what I want, make it happen. All this good stuff comes to life and I don't have to go and find the IT guy and put in a service ticket and wait for three days to get back in a network assigned. So, we're getting there. 14 minutes left, we've got some testing information. You're gonna love this piece, so get ready. Here it comes. Especially that guy, all right, yeah. NetworkKaracy.com to this test is an entirely subjective. I have absolutely no validation as far as the quality of the results presented here. However, I can say they were consistent with most of the other tests which I read. So, I think it's good for this, okay? That link will get you there. You're welcome to have copies of the PowerPoint and you can go and read the whole thing yourself, so. Here's what they did. They set up a simple test. Two servers, right? Two physical servers, open V-switch, running on each, couple of VMs on each job there, connected with a 10 gig ethernet switch and of course they established a GRI tunnel between the two. So, what happened? All right, well. We found that the processing of the mechanics of GRE, all that stuffing and unstuffing, takes some CPU time on the hypervisors. That's not really shocking, right? The overhead's low, it's not really that high, but importantly, it's required. That's a big deal, right? So, it's low, but required.  Like air, for instance. Yeah, bad things happen to you. So, software has a cost, right? So, when the CPU approaches saturation on the hypervisor, the ability to process GRE starts to slow, packets start to drop, throughput starts to suffer, phones start to ring, okay? So, I think it needs some kind of QOS, I don't know what's beyond me to talk about, but there isn't any at the moment. So, here's the deal, results. Baseline OVS bridge, what you're looking at on the left side of the screen is, the test conducted between the two servers as our sort of baseline that says, what does it look like without GRE, to make sure everything's working to start with? Well, they got throughput 9.3G, right? Pretty good, 10 gig link, they're at 93%, they were able to drive that pretty hard, that's impressive. Our sending servers CPU is clocking out at 70%, which means, it's sending everything it can send, and it's even got room to do more if there was more to send it could. Receiver, 82%, again, it's receiving everything, putting it away, waiting for more, beautiful. Turn on GRE, oh, bad times at the farm. All right, so now we're down to 23% of line rate, no one's happy. We have, our CPU on our sending server has now spiked up to 97%. Well, that's kind of crazy, huh? So it went up 27%, I'd argue it probably went up more than that, it's just that that's where the needle hits the end of the fire, and it says no more, right? So the server, the sending server is now slammed. It's running at full contention, it's got no more cycles to do anything, including packaging GRE and sending it out. So packets start to drop, when packets drop, 23%. So that's a bad sign. Now, you would expect this, that correspondingly, the receiving server is now down to 75%, so it's dropped. It's not doing as much as it used to, because it can't get the packets fast enough. So now it's saying, all right, come on, send me another one, I'm ready, you know? But it's not there yet. So this is a problem. I wouldn't say that this survey is the end all, be all, we don't know what kind of actual gear, I'm sure if you used slow servers versus new servers, you'd get a different result, not that kind of thing too, as you can imagine. But you get the idea. If you hit contention, problems are gonna start happening, something to keep in mind. I am so far behind, I can't even tell you. All right, so bottom line, GRE. Logically, it can handle a larger scale, good multi-tenant support, allows for some robust layer three features, right? It's pretty flexible, it's pretty quick, as far as configuration goes, runs on your existing infrastructure, and it's kind of DevOps, right? It's DevOps, it's very software-y.  High demand, network performance is gonna suffer, throughput's gonna be lower if you're at a high utilization. If you're low utilization, maybe that's not a problem, right? So where would we use this thing? Multi-tenant environments for sure, with medium expectations as far as your utilization goes. Areas where we wanna extend layer three to other areas, if we wanna get multi-region support, doesn't do a pretty decent job of that, right? Because of that encapsulation process, you can kind of shift packets around and the servers on the other side aren't so aware of what happened. Does protect investment in your network gear, I don't have to buy anything new. The bad side on use case, well, if you're gonna look for maximum performance on the network, this isn't gonna be it, right?  Older server gear, if you've got an environment that's made up of stuff that's a couple of generations back, well just imagine, now you've got that heavy workload and you're putting in on something that can't run fast to start with. That may not be good. And then of course, yeah, high utilization, stay away, right? Man, we're getting there. Look at that guys, nine minutes left before he pulls the hook. All right, VXLAN. So virtual extended local area network, this is the topic everyone came here to see. The future ain't what it used to be. No one's gonna get this one. Let's not sci-fi, see. Yogi bearer, right? Yeah, of course, yeah. The future ain't what it used to be. So this is the new shiny toy and the toy box, everybody wants to hear about this. Here's what it does for you in life. VXLAN, virtual extensible logical area network, local area network, defined by RC 7348. You notice there's like an extra digit in there from the original IPv4 one. So a lot of things have happened since then. And it was built largely to resolve issues created by virtualization. Here we are, virtualizing. Expands that data center limit of 4094 that was created by VLANs, which sounded like a big number at the time. And now we've upped our game to, anyone know? 16 million is the new limit, right?  Solves the multi-tenancy duplication of VLAN IDs and MACS, because it creates isolation, provides for a layer three overlay for separation rather than a layer two VLAN. So think like VLAN set layer three, right? It allows for all the goodies that have been developed along the way for layer three, multipathing, all that good stuff we talked about. That's all available. And it also forms, like GRE, non-encrypted tunnel, okay? All in the clear, just in a tunnel. How does it work in multi-tenants? Well, yeah, that's the point of this deal. So it provides network isolation between your tenant environments. That's an important point, right? Just like GRE kind of did, but better. If we use VLANs, we're limited to 4094, right? That's our kind of scale. VXLAN, 16 million VN IDs per domain. That's a lot bigger. I'm not sure you'd ever get away with that, but it's still a big number. We can use, if we use layer three networks, overlapping's gonna happen, and that's okay. Because VXLANs are isolated, so one tenant does not see the traffic of the other tenant. They can all ride over the same network, and everybody's happy. Yeah, yeah. So another problem that VXLANs addressed, which is something that maybe people don't know quite as much about, is the switch table spacing problem. Within hardware, originally, layer two switches were created for physical servers, right? And so a 48 port switch had the intention of having 48 thingies stuffed into it, and it learned those 48 thingies MAC addresses as they started to communicate. Well, then along came the idea of sticking a thousand thingies into one port, because now we have virtualization. The switch can no longer handle the amount of table space that's required for that to operate, right? Now, modern switches and where enterprise class stuff, they don't have a problem with this. But there are switches, I guarantee you, in your environment that have this problem, right? So they're gonna run into a situation where they run out of table space. Well, what happens when the switch runs out of table space? Stop sending packets. I don't know your address. That one goes off the corner. Next, oh, I don't know you either. So that's what happens. And so that's a problem. VXLANs actually solve that issue by that encapsulation process because your transport medium is the only thing that the switch is trying to learn rather than all the little VMACs of every single system in the deal there. So, yeah, we talked about, yeah, network out, you got it, you don't want that, that's bad. So, okay, VXLAN layout. VXLANs run over existing network infrastructure. This is another big plus. They can extend your layer two network by encapsulating it inside a layer three network, right? So this is really good stuff too. A little different in GRE, slightly different approach. The tunnel makes it look like your hosts are actually in the same layer two network, which is pretty cool. It creates a VXLAN segment or overlay. Sometimes you hear both those words. It means the same thing. Someone says segment, someone says overlay, that is the same piece of information. The VXLAN network identifier or VNI, which is like the VLAN number, right, but for VLXLANs, is a 24-bit ID, 16 million VNIs per domain. Only VMs within the same VNI with the same number are allowed to talk to each other. And duplicate MACs can be used as long as they're in separate VNIs, which is a cool part with virtualization because you can pick your VMAC, right? And so there's no body out there doing that for you. You could pick it. It could be the same. There's no problem. So is it a tunnel? Yeah, well, sort of. So essentially what happens is original layer two frame is encapsulated within a layer three of three VXLAN packet, right? The tunnel itself is stateless. So it is a tunnel, but it's a tunnel created every single time a packet's sent. That's a big deal. So each frame gets encapsulated individually, right? So no state. The tunnel has end points. End points are called VTAPs, right? VXLAN tunnel end points. This is another important detail to remember if you're working with those. I like the fact that it's a tunneled acronym. So it's an acronym within an acronym. VTAPs exist typically within a hypervisor that hosts the VMs. So the VTAP termination hardware's coming. I didn't want to talk about that now. Certainly not in the next four minutes. However, there's stuff to kind of help out with that. Right now it's all in the hypervisor all software, which is cool, it's dynamic, flexible, it does all kind of good things. The big point is the last item. The VM that generates the traffic doesn't know anything about the encapsulation, right? It's all handled outside of it. It just thinks I'm receiving and sending packets from a server that's sitting right next to me. Look at that. Anyway, so. There's it. You guys get the download. This is just a workflow that shows you exactly how the packets move across the network. I'm not gonna go into that right now because I've got about three minutes. So VX LAN frame format. Again, same concept, right? A little different than GRE. That guy down the bottom is our payload, right? Which is the original layer two frame. It's stuffed up inside a layer three packet with all the VX LAN goodies in it, okay? And that gets shipped out. And then when it gets received, it all comes back out again and the VM that's receiving it just gets this bit inside, all right? So that's why it thinks it's talking ethernet to the guy next to him. All right, oh man, you're gonna hang me if I don't get through this. This is the IETF posted a performance study on VX LANs and the impact using software to find networks. And here it is, right? By the way, the link to it's in there too.  It's very similar to the last test, right? Two servers, bit in the middle, yeah. Here's the plan, right? So what happened? When we ratchet this guy up to maximum, CPU with one VX LAN ID and use jammed up to, it added only about two to 10% overhead. That's not huge, right? A little more efficient, I think, than GRE is what's happening. No memory change, packet loss. Well, as expected, you start to saturate the CPU. This is still a mandatory object like oxygen. You need it to breathe. So if the server, if the hypervisor CPU runs out of space, start losing packets, right? So they experienced 2% packet loss, which kind of drove the throughput down. As you can see, 56% of line rate, right? It was max. So it's still kind of stinky, you know? I mean, that's not really that great. Now, there is some hardware coming that can hopefully do a little bit of that, maybe offload that out of the hypervisor and still be dynamic with the software controls that we want, but not create this bottleneck, or I shouldn't say bottleneck, but dependency. It's really the issue is it's a dependency. It's a cyclic issue. So if you've got a workload that does a lot of work, it's going to affect the network, right? If you've got a network that does a lot of work, it's going to affect the workload. Kind of goes hand in hand there. Bottom line, you can handle large-scale, 16 million VNI's can't be wrong. Multi-tenant support, you can use your layer of three goodies, right? It's extremely flexible, runs on existing infrastructure. Bad side, generates some CPU overhead. Throughput's not, it's not max, right? We don't know the max-scale problems yet, and that's one of the things I'm a little interested in, is what happens when we've got lots of VNI's running on the same hypervisor? Will we have any extra problems with the VTAP? Use cases, multi-tenant, right? Oh, don't hook me, don't hook me. Multi-tenant environments, we can extend across the boundaries. I'm going to skip right past this guys because I think there's something here you want to see. All right, let's get to the point, right? Remember this slide in the beginning. If you need multi-tenant support, right. VXLAN and GRE are going to do really, really well. VLAN's okay, right? Ultimate scale, if you're going to have a big scale, VXLANs can do that, that's its job.  What type of utilization?  You want to keep monitoring that and be proactive about it, because if you're using VXLAN or GRE, chances are you might see other problems. Admin time, if you don't have it, don't use the flat networks and VLANs because you're going to spend time administrating a really complex environment. What's your underlying topology? Most of these don't care except for VLANs. VLANs want to use VLAN switches and some of the other ones might use VLANs as well, so keep that in mind. Redundancy, is it important? We know how we can get there. Is there going to be multiple sites? VXLAN's going to win for that one, right? Because it's really good about pretending like it's a local system to each one. It's almost like it's VPNing to itself. Inspection, this could be an issue. Flat and VLANs are known topologies that you work really well with most inspection tools for your compliance officer might care about this. GRE and VXLAN, although they are not encrypted, might throw crap at the inspection tools that the inspection tools may not be able to read, right?  Yeah, there's a temporary? Yeah, never. And hey guys, let's get some lunch. Thank you.


The chopsticks have done more testing, the world's largest plane has flown yet again, and NASA might be running out of astronauts. Welcome, citizens of Earth, to another action-packed episode of Tomorrow News. We've got all of that and more coming up on this episode, so stay tuned as this is your episode of Tomorrow News, which is for the week of January 18th, 2022. We're heading straight down to Starbase to kick off this week's episode with the coverage of some load tests on Mechazilla. As we very maturely talked about on last week's live show available at the card in the corner, some interestingly shaped water-bangest bags were attached to the bar hooked between the two catch arms on the orbital launch tower to simulate different masses of different starship and super-heavy configurations landing on the arms. The wide bay has continued construction, and the third level is now well underway as it grows upward, something which is very exciting to see. If you don't know, this new building will be able to hold multiple different super-heavy boosters and starships as they are being constructed, or as they await the rollout to the pad. This unused nose cone has sadly reached the end of its life with it being picked up for scrapping. Even though the site down at Starbase has been growing and is continuing to grow quickly, you can't keep everything, and it was kind of pointless just having it sit there, so it had to go. The final part of Booster 3 has also been taken down to the scrapyard, with it being lifted off of Suborbital Pad A last Thursday, and following this, the water-bangest bags were removed from the chopsticks. Some new panels have been added to the Raptor engine shielding around the underside of Booster 4, and the aero covers around the helium tanks have been reattached. The ship's quick disconnect arm has had a crew sent up to it, presumably just to make sure that it was all right after the movement tests over the prior week. If anything did come loose, then I'm sure they could have sorted that out as well. Parts of Booster 7 have been popping up in the high bay with the methane tank starting to be stacked up. Booster 7 is believed to be one of the first, if not the first, new Booster to be built for Raptor 2, so hopefully the construction goes quite quickly because we are still yet to see a next-generation version of Raptor in the wild. One of the manufacturing tents at the production site has been lifted up and swung over into a new location, and I'm not too sure on the purpose of this, but I'm assuming it is to make more room for something else. Lastly from Texas this week, SpaceX's Libre LR-11000 crane has rolled over to ship number 20, and the load spreader attachment has been connected up as the Starship vehicle poised to be the first to reach orbital velocities awaits being lifted up. Jonathan McDowell tweeted some concerning data about a batch of Starlink satellites the other day, but looking like 12 of the satellites aboard version 1 launch 22 had not been raised to their 550km orbit, instead being held at 350km before being de-orbited entirely. That is 20% of the total payload not being operational, which is quite concerning, but it does seem to be a problem just related to this specific batch of satellites. The new versions of the Starlink satellites have been rolling out with lasers being used to increase the bandwidth available, so hopefully this won't happen again. We also have Starlink V2 coming soon, but as that is currently designed to launch exclusively on Starship, we'll just have to wait and see how that pans out. The plane with the largest wingspan ever built, officially known as the Scaled 351 Stratolauncher, registered under November 351 Sierra Lima, but affectionately known by everybody as Rock, made its third test flight last weekend, with one of the most notable parts of this test being the retraction and extending tests of the left main mid-gear, to get ready for their next test flight when Stratolauncher will be testing all of the landing gear. Taking off from runway 30 at the Mojave Air and Spaceport at 1648 Coordinated Universal Time, the NASA spaceflight livestream provided us with some fantastic shots of the aircraft taking flight, and as it disappeared into the Californian skies, we could still see where it was as, at its peak, it was being tracked by over 57,000 people on flight radar 24 alone. It's very interesting to see the crossover of the aircraft enthusiast and aerospace enthusiast communities as this is one of the largest aircraft in the world and is designed to carry rockets. A report released on January 11th by NASA's Office of Inspector General found that the agency's current 44 active astronauts in its corpse could soon fall below the minimum manifest requirement with the Artemis program coming online and the need to support the International Space Station and anything else that NASA wants to do. The astronaut corpse is currently at its smallest size since the 1970s and it is way off the nearly 150 astronaut peak in 2000. There is a 15% safety margin on the sides of the corpse as in the event that an astronaut is not available then they will need to be replaced and that number is actually down from 2014 when it was 25%. Continued attrition of the current corpse and demand for additional astronauts for the Artemis missions will have to be dealt with by the agency with their new class of astronauts having started training this life but they won't be ready to fly for two years. Because of this there is a chance that there won't be enough backup astronauts if something happens to a main astronaut or astronauts during the preparation for a mission. NASA could also be overestimating the time left available to train up the astronauts for Artemis II and Artemis III as there is only about two years until the former is intended to fly and there is a big difference between an Artemis mission and an ISS mission. For now we'll just have to wait and see how NASA responds to the report. It didn't explicitly say that NASA is running out of astronauts or that they will not have enough to support their future plans however it did recommend that NASA should reevaluate the 15% safety margin used for determining the size of the corpse, their lack of good astronaut demographic data and new guidance for evaluating training. I've left the 41-page PDF document in the description below if you want to give it a read. NASA is really doing well to make the headlines this week as they have announced that they are going to go ahead with a line of probe-class missions to fill the gap between the big flagship missions such as the James Webb Space Telescope and the smaller Explorer-class spacecraft with a cost cap of one billion US dollars excluding the launch international contributions and observer programs these missions would be similar to the new frontiers line of NASA planetary science missions. The latest Astrophysics Decadal Survey Astro 2020 did endorse the work on these probe-class missions but it did recommend that the cost cap should be increased by 1.5 times up to 1.5 billion dollars. The formal community announcement which was released on January the 11th included a schedule for the first probe competition with a draft announcement of opportunity or AO set to be released in June followed by the final AO in a year's time with the 90-day period following that being the last period of time where proposals can be submitted. Two or three proposals would then be selected in early 2024 with them being valued at about 5 million USD each before the final winner will be selected in 2025. The proposals are being limited however to just two concepts a far infrared imaging and spectroscopy space telescope or an X-ray mission that would complement ESA's yet to be launched X-ray telescope Athena. Sadly because of the current budget NASA is anticipating only being able to fly one of these types of missions per decade but Paul Hertz Astrophysics Division Director at NASA has said if the astrophysics budget grows fast enough to accommodate the recommendations of the Decadal Survey plus an increased probe cadence NASA would certainly be open to that. As you can probably tell there have been a few reports coming out about US government agencies and the Department of Defense is no different. The Office of Inspector Forced Department released a report on January 7th that found out that the Eastern Range at Cape Canaveral Space Force Station and the Western Range at Vandenberg Space Force Base are continuing to rely on outdated equipment to support launches. Sometimes it gets so bad that the service needs to go to online marketplaces such as eBay to find spare parts. 28% of systems such as radars, antennas and commands destruct systems lacked spare parts because they are obsolete either because they are no longer manufactured or because the companies that did make the components have actually gone out of business. According to the Space Force the average age of range items with a potential mission impact with no available spares is more than 30 years old. Luckily these issues have not been a major impact for launches out of either range in recent years. The report found that there were no problems between January 2016 and March 2021 excluding a wildfire at Vandenberg which damaged communications lines. The launch cadence out of both coasts is expected to rise rapidly over the next few years reaching a predicted 119 that's a lot in 2027 at the Cape so it is important that potential issues like this are ironed out. One approach to mitigate the risk is to install an autonomous flight safety system onto the launch vehicles themselves as Space Launch Delta 45 recently noted that a recent launch of a vehicle without an AFSS required 29 range items to support it however a vehicle with an AFSS required just six. The Space Force is working on range modernization to address the concerns in the report which is under a project called Range of the Future but Colonel James Horne the deputy director of launch and range operations for space systems at Patrick Space Force Base believes that the name is inadequate and it should be the range of the now as there is already so many things that they have done to enable the current surge in launches. Talking of launches it's time for space traffic. Starting off the space traffic this week we had another launch from SpaceX Transporter 3 on board was over 100 different small sites which lifted off from Space Launch Complex 40 at the Cape Canaveral Space Force Station in Florida and are currently heading to their Sun Synchronous Orbits. For the 10th time in its life Booster B1058 successfully touched down at LZ1 which marks the 28th consecutive landing of a Falcon 9 booster. This is also the first time that SpaceX launched both the first and second launch of the year which really goes to show that they have a launch cadence and a half for 2022. To put the icing on the cake Planet who had 44 Superdust satellites inside the ferry used one of their pre-existing satellites on orbit to get this awesome footage of the first return to launch site recovery of the year. If you look very closely you can see the Falcon Booster sitting on landing zone one. The second launch cover is above the clouds which was Virgin Orbit's first flight of the year and it went as planned following a one-day push from January 12th to January 13th. Cosmic Girl, the Boeing 747-400 carrier aircraft took off from runway 30 at the Mojave Air and Spaceport at 2139 Coordinated Universal Time with Launcher 1 being dropped just over an hour later at 2252 above the Pacific Ocean. The satellites on board from the United States Department of Defense, SAP Revolution and Spire Global are heading for a 500km 45 degree low-earth orbit. China's first launch of the year came in the form of Cheyenne 13 which was placed atop a Long March 2D. Gifting off from launch complex 9 at the Cheyenne satellite launch centre, as it is China, we know very little about what was actually inside of the payload ferry but it was declared for technological demonstration purposes. Coming up over the next seven days, we have Star and Group 4 Mission 6 on the Falcon Knight and USSF-8 on the Atlas V 511. And here is your space weather with Dr. Tamata Scove. Space weather this week is definitely getting a bit on the lively side. As we take a look at our Earth-facing disc, you can see all of the active regions and in fact one of them lights off WHAM right there back on the 14th.  We're going to get maybe a glancing blow in and around the 20th. It's kind of hard to tell. We're waiting for more coronagraph imagery and our prediction models to tell us for sure but you can see it's beginning to be a pretty active sun. In fact as we take a look at our far side this is stereo A and it's looking at the sun just a little bit from the side. You can see all of this activity still on the sun's far side including everything on the east limb. There's at least three more active regions on the east limb of stereo's view that have not rotated into earth view yet and some of these might be big flare players so it looks like we are going to continue to have an elevated m flare risk over the next couple days and that could cause radio blackouts which could affect radio propagation and radio comms for space traffic. For more details on this week's space weather including when and where you can see aurora how those solar storms might affect you and what does it mean to have big m flare players check out my channel we're seeing me at space weatherwoman.com. Just before we finish up this week's news thank you to all the citizens of tomorrow who support the show financially every month through youtube memberships. Every penny helps keep station 204 on orbit and if you want to unlock some cool perks let the escape velocity orbital and ground support citizens receive such as exclusive discord channels and access to the space news scripts then head over to youtube.com forward slash tmro forward slash join or just hit the join button below where you can support us for as little as $1 per month. If you enjoyed this episode and you are yet to subscribe we would very much appreciate it if you did as we are aiming for 100,000 subscribers by the end of the year. If you want to have a discussion about the world of spaceflight past present or future a discord server can be found at the link in the description down below as well as all the sources of the power of the stories in this episode so if you want to do some further reading like that massive pdf document i mentioned earlier or you just want to see where we get our data everything is down there. Thank you so much for watching we'll see you in the news next week goodbye.