 Oh, 15. 10, 9, 8, 7, 6, 5, 4, import episode 42. It's 21st January 2017, streaming directly from Singapore. It's Rebuild Live. All right, this time on Rebuild Live, we'll be chatting about computer network infrastructure with Rahul. Yay. Hi, Rahul. Welcome to episode 42 of Rebuild Live. I'm your host, Sayani. And on the sunboard is Chinme. Uh-oh. It's episode 42. 42, yeah. You know, like this is the episode that answers. This is the episode which is the answer of all things in life. Literally everything. All right. And Rahul is going to try to answer that. Yes. So Rahul is going to give us the answer to life and universe and everything. What a guest to have. All right. All right. Welcome to this episode 42, Rahul. And how do we meet Rahul Chinme? We met him in NUS Hackers National University of Singapore. They have a hacker student group. And at that time, he was a student there and we met him there. And from there on, Rahul has gone on to double a lot with network and infrastructure and security. And that's why we decided to bring him on board and discuss all this. That's true. So Rahul, why don't you introduce yourself? Um, okay. I'm Rahul. I do random, uh, pretty much everything that needs doing in some weird way or another at overseas family school. I do a bunch of network stuff. I build a bunch of prototype apps for this school. I do a whole bunch of automation things. And I dabble a little bit in helping people develop curriculum. All right. So, uh, we will get more into what Rahul does, but in the meantime, Chinme, you have a gift for Rahul. Yep. Yep. I do. Um, so as is tradition at the beginning of the show, we, we welcome our guests with a so-called malformed query. Uh, and Rahul, your malformed query for today is what kind of network does a hobbit have? What kind of network does a hobbit have? I don't know. A Tolkien ring network. Get it? Tolkien ring, Tolkien. Oh my God. Do you are a Tolkien? The guy who, yeah, yeah, I know the author of Lord of the Rings. Yes. And token ring. Oh my gosh. Oh, and like BNC connectors and awesomeness. Yes. All right. So there goes the morning, Saturday morning. I hope you're all awake and welcome to the audience in the live chat as well. So if you are listening to us and you, if you have questions for Rahul, we will answer them live during the show. It's a Gitter.im slash we build as G slash live, or you can just hit the website at live.webuild.sg and start chatting with the audience there. Start trolling Rahul. I mean, start asking questions. Hey, we should, I should actually encourage trolling. Okay, fine. We should not be nice people. Yes, we are nice. All right. So let's get on to the topic of the day, which is computer network infrastructure. So Rahul, you have set up a lot of infrastructure for offices, network infrastructure. So if you're put in charge of setting up one, what are some of the first few steps you will take? Well, the absolute first step is figuring out that this is slightly not so politically correct thing to say, but you need to figure out how much political. Hey, Rahul, before you start, sorry, could you bring your microphone closer? You, you seem to be modulating in and out or maybe add a couple of DVs of gain or something. I will add a little bit of gain. All right, bring your mouth close. Oh, yeah, just come closer to the microphone because you seem to be getting in and out of the microphone zone. Right. How about now? Yes. Yes, sounds better. Okay, brilliant. So first thing you need to find out is how much political capital you have because it's a very common thing. When someone goes, I'm going to set up the most awesome network here and the entire office just goes, why? We just want the internet to work, but then they don't realize that you need to spend money to get the internet to work. Right. So, you know, you're going to have to do the whole chat with management thing, but as you mean, you've managed to do all that. Very first thing you need to do is figure out your requirements. How many users are you going to have both wired and wireless? I mean, it's very rare for people to plug in their computers these days because no one really uses desktops quite as much. But you definitely are going to have things like printers, blah, blah, blah. And take it from me. The more wired devices you have, the better your life is going to be. Wireless is just, you know, you'd figure that by 2017 and what was it? Four revisions of Wi-Fi standards, people would have figured out some way to have better debugging. Wi-Fi just has absolutely terrible metrics in terms of a lot of things. So stick whatever you can on the internet. And then you're going to have a bunch of users on Wi-Fi. At which point you need to do a bunch of things. One, plan out based on your area that you need to cover. Should you be perhaps getting a bunch of small access points if you have people in a bunch of small rooms? Or should you get something like a Xeris array that has eight radios, 10 radios, all the way up to 20 radios. So what are these are like really big access points that have dedicated radios for every user? It's not so much dedicated radio per user, but you have a bunch of radios. And what they do is each radio, typically if you're running five gigahertz might run on a different channel. Sometimes it's per channel, different radios kind of stuff. Yeah, and the idea is that if you have too many people associating with one channel, these days you have fancy things you can do and hand them off to the other radio. OK, so you basically can serve a few thousand people from just what looks like one single access point in reality. It's a cluster of them that works better if you have like single large areas, if you have a whole bunch of small areas, it's a lot better to just get smaller, cheaper access points and put a lot of them around. Right. OK. So that's requirements wise, you need to know how many users you're going to have, where your users are going to be. That's also very important, how spread out they are, how close to you need to know about the physical location. You need to know the physical layout. You need to know the layout of the location of the people within your physical layout, as we all know with Wi-Fi walls are bad. Right. But walls are also amazing if you're using 8 or 211 AC on five gigahertz, because then you can reasonably say on this access point serves this room. Right. That's it. OK, so you want accidentally because it's it's all the both ways, right? If you if you are getting an access point too far out, then we're supposed to get it's actually a problem. Yeah, something that a lot of people do is they buy an access point and they go, hey, I can control the power of this. I'm going to set everything to maximum. No bad. Don't do this. OK. What you want to do is design your cell size such that people are on the closest access point with as you want some overlap because you don't want a dead zone, but you don't want too much of an overlap. Right. Ideally, if you can engineer overlap to be through a wall, that would be perfect because then you get a lovely little drop off over there. Right. OK. And then with AC, I guess, because of the channel width, why are walls? Oh, it's mostly because you can do beamforming if you have a whole bunch of reflection, which is nice. OK. I'm looking forward to 8 or 211 AD with 60 gigahertz won't even go through a piece of paper thing. That'll be hard. That'll be fun. Great. So let's say you have already set up the infrastructure and everything is done and the team is running and well. Are there some common things you monitor on a daily basis? Yeah. There's two general categories, I see. Well, actually three. The most important is can your users actually connect and get whatever they need to do done. Connect. OK. That's, you know, that's just a general metric of, like, are people yelling at you that something's broken? Usually shouldn't be the case in any office, any properly set up office that work. But the two general categories of things that you want to monitor, I guess, would be performance stats and security. OK. And it's something where some people like to say, oh, performance is, you know, good enough, nobody really cares anymore. But then some people go, security is the most important thing. Performance is the most important thing. This is an entire argument all over the internet perpetually. And there's also user access, you know, UX versus security is another big thing. But when it comes to things like Wi-Fi, one nice way of doing it is to have, like, a trusted network and an untrusted network. I mean, a lot of people are starting to do these even at home these days, which is kind of nice. You have, like, an untrusted network, your guests connect to, and then you have your network. So with performance stats, things you want to know in a big network generally would include what is the peak traffic on a port. Because if you have a gigabit backbone and one of your ports is hitting that full gigabit, you might want to consider adding a second port and aggregating it. OK. And then the other thing you want to track is things like port errors. Because in the case of my office, when we built out the new campus, there was something like 6,000 or 8,000 Ethernet links. Whoa. Wow, that's a lot. Was it 6,000 or 8,000? Basically, it's a lot of Ethernet links. We're talking, like, a few 148 port switches, almost 200 of them, I think. Wow. That's a lot of switches to make. It's a lot of switches. It's a lot of ports. And the one thing is when you put that many cables in, it doesn't matter how much, you know, how good your contract is. You will still have port errors. That's a normal thing. Yeah. So you want to track these errors, and then 90% of the time, it's going to be a bad cable. So you just make a log of these and you fix it. I'm guessing if you have that many ports, you have at least that many cables or even more. So, you know, having one bad cable among multitudes of thousands is probably kind of regular. Yeah, I mean, even if you have, like, the most awesome setup, you will have bad cabling. You just need to go back and fix it at some point. Yeah. The other thing is talking about performance metrics. It's very easy to get performance metrics on managed switches because they just give you everything over SNMP. Okay. Wi-Fi is a simple network management protocol. Simple little management protocol. Technically, it can be used for management as well, but most people don't really do that. They use it as a read-only stats thing. Okay. Wi-Fi, on the other hand, even if you're using Enterprise Gear, you don't really get that much visibility into what's going on. But, you know, you just, like, the one thing is definitely get Enterprise Gear. If you're on a budget, get Ubiquiti or something like that. It's like $200 in APP. Yeah. It's pretty affordable. I mean, you can even get, like, $100 ones if you don't need to cover a large area. Okay. And these will give you some kind of metrics, some kind of feedback. They'll tell you fairly useful things. Like, if you have one person eating up your entire Wi-Fi bandwidth in a room, you know who it is and whether they should or should not be doing it. Like, if they're torrenting something in at work, they shouldn't be doing things like that. The other thing about performance is your edge is very important because, generally, you don't really have much of a throughput problem within your building or your campus or your network. You will have problems at the edge because, I mean, Internet's not exactly that cheap on a business line. Right. For, like, 300 megabits, you're going to be paying a decent amount already. So you want to have some sort of QoS. It's pretty much mandatory. The QoS is quality of service. Yeah. And the nice, the more modern quality of service mechanisms, there's DSCP, which I can't remember the full form for, but I'm sure you can. What was it? DSCP. DSCP, okay. That basically tags. It's like a new version of the IP QoS that we had 10, 20 years ago. So it's a different... Which basically says, for example, VoIP traffic like we have right now and Mumble would be classified as early forward, which is this is a very small bandwidth connection, but send these packets through as quick as you can, please. Right. And then you have bulk transfers. So this is based on protocols? Yeah, this is based on the IP layer. Okay. And whatever sends it will have to tag it. Okay. So in this case, for example, my computer has to tag it or how does it work? Mumble would be tagging it. Okay. In general, Mumble might actually be automatically tagging it. I haven't actually tested. Okay. But if you're using asterisk or any big VoIP systems for like phones, they definitely tag it for you. Right. Right. So they'll tag it and then your switches will basically... Your switches will... Your switches will not because your switches are later too. Okay. They only see Ethernet frames. Right. There's Ethernet QoS as well, which you can use. Okay. But they wouldn't be seeing the DSCP or the IP QoS tags. That would be up to your routers. Okay. So your routers will see that and then forward that. Yeah. So in the other category of things you look through, the security one, you just want to have like monitor, monitor, monitor, monitor everything. But how do you make sense of the data? Because I mean, for like a large installation, you have, I don't know, thousands of thousands of net connections at any given time. So a lot of things that I like to do is basically have one place that hoovers up all your logs across your entire network. Okay. And then you have a white listing or gray listing system. So like these are lines that I expect to see all the time. It's perfectly normal. You can drop them. I don't even want to see them. Okay. And then you have things like these are lines where, if it happens say with like this many times in this many minutes, I don't want to see it. But if it goes above that threshold, now that's a problem. I don't want to see it. Yeah. Are these things that are like, are these well-known systems or well-known? It's unique to every campus. Okay. It's unique to every campus because everyone's traffic patterns are different. They're something that you have to learn as you sort of work. Yeah. You'll basically have to roll it out, get bombarded with logs for a day or two. And that will let you figure out what's going on. Okay. But it's pretty easy to like very quickly remove all the use the boom, boom, boom. I know these are supposed to be their things. Like a software engineering firm guaranteed you're going to have a whole bunch of SSH connections out to AWS. Right. And you generally know what sort of connections these are going to be. And you can just be like, yeah, this is expected. It's perfectly fine. If you see a bunch of open VPN, you're like, hmm, should I be having this? Maybe. Or should I not be having this? Right. Okay. Cool. So I think at this point of time, I think it's a perfect time to ask what are some of the tools you use to get the job done, whether it's setting up the infrastructure or even monitoring. So a lot of things that I use is very old school. Old school. Cool. Yeah. Very old school. Cool. Very old school. So for like network intelligence is a whole bunch of things. We use a bunch of open source projects. I'm a big fan of Icinga at work. We use Nagios, which is a, it's a monitoring solution that's very good at telling you is something up, is it down? Is it in a flapping state like that? Are my disks filling? The other thing we use a lot of is cacti, which gives you cute little graphs for everything from CPU usage, network utilization to number of clients connected to this web service right now. Right. Okay. And there's a whole bunch of bespoke things that are built with the logs and the SNMP information coming in from switches. What about like the SNMP stuff? Do you, do you, do you crawl that yourself or do you have tools to do that? It depends on what we're pulling. So both Nagios and cacti pull SNMP data. They do different things with it. Okay. Cacti, for example, we're pulling things like the traffic on every port. Okay. So if something maxes out, we can see that it's maxed out. Right. But there are things that we crawl ourselves using either the logs coming in from the switches or SNMP, things like, I now have a database. If you give me an IP address or a MAC address, I can tell you exactly where on campus that is right now. Right. Okay. That's very handy because. Yeah. And for Wi-Fi it's like down to a room level. Oh, nice. Because I guess. Because I guess with that kind of a size, you know, just figuring out where something physically something is coming from is really hard. Yeah. And, you know, sometimes you get a loop in your network. I mean, STP spanning three protocol will prevent any craziness from happening, but you still have a loop on your network and you still want to get rid of it. Right. In this case, you know, you can just be like, oh, right. I know it's between these two ports on this one switch over in that room somewhere, then someone to fix it. Do you do like, or do you use tools or do you like manually draw out network architecture diagrams? You know, what's going to get to what and, you know, how it's supposed to flow? Because I can imagine this like even before you deploy, like that kind of planning could be extremely critical. Yeah. And we spent almost an entire year planning out our network. The one thing I would recommend pretty much everyone does these days is to not do a traditional network that's like layer to everywhere. Okay. Back in the old days, you just put a bunch of switches, hook them up to a giant Cisco box, you know, in the basement. You spend like $300,000 or something on one of these. And sure, that was one way of doing it, but now you've got a lot of Ethernet running down there. The approach that I strongly prefer is something where you aggregate early and aggregate often. Okay. So in our case, we have a square building which makes it trivial because we just call it four wings. Right. The wings aggregate and the wings aggregate at the floor. Okay. And that's about the extent of the layer two network. Okay. Every floor is a separate layer two network. Right. So there's basically one router at every floor and every one. Yeah. And then all of them. There's one router at every floor. The wings are just switches. Okay. Right. And what this lets us do is between this and I think the four months that Ivana and I sat down coming up with ways to name every network thing on campus. Right. Now given a name, I can tell you exactly where something. Right. So it's everything's encoded in the DNS name because DNS is inherently hierarchical. Right. Okay. So you're using DNS internally as well. So you can directly talk to things using DNS instead of having to remember IP addresses of all sorts of things. Yeah. So there are a few thousand DNS entries that are just local and internal only. Yeah. Makes sense. I mean, if you think about it, that's exactly why DNS was invented. Right. But more for a global scale. But you know, once you start looking at infrastructures that are that big, you want to start using these kind of tools. And this is so basic. There's something that, you know, even your browsers and, you know, every single tool in the world kind of knows how to use. So. Yeah. Rahul, in terms of tools, do you script up there's a lot of scripts? Yeah. So it depends on a bunch of things. If we need to build something that is going to run long term and collect data, do something with it, process it, shove it somewhere. These days we've started using Go for it. Go. Just because Go gives you, you know, a single static binary, you stick it somewhere, you run it. You know, it's not going to go insane generally. Interesting. So you just use a compiler and just use the binary. Okay. Now, if it's something that isn't running all the time, it's a cron job or it's a one off or something like that or something that runs very rarely. That tends to be written in Python most of the time. Okay. Hello. So let's see. Can you hear us? Can you hear us, guys? There's a network, it seems. Hello. Oh, no. Network. Hello. How do you work? Really? Seems fine now. Okay. Strange. For a second. I hadn't brought issues. Hello. Can you guys hear us? Okay. Mine can hear us. Well. Jones having network problems because the little packets are traveling halfway around the world. I guess the packets that were traveling were really unhappy about us talking about more packets. Yes. They're jealous. problems. All right. Okay, so that's cool. Let's talk about graphing and graphing these logs. Like, do you use any graphing library or graphing framework? Pretty much everything that is graphed in this case, usually at in for like the office case for me, everything goes into cacti, which uses rd tool internally to do all the graphing. Sorry, what was that again? Your voice drop cacti. Okay, cacti is rd tool underneath. Oh, I know this thing. Our details another very old school. Yeah, it's super old. I remember back in the day, but during the hazes, there was this guy somewhere in Pungal or whatever who was like monitoring his own haze stuff and using rd tool to graph it. Super old school. But like my own info, I have a bit of Grafana going around. I used to use influx db as my data store. But influx db started getting a bit unreliable isn't is not the right word for it. It didn't eat my data. But it's not a very easy thing to maintain just because most distros don't ship it by default. Influx DB. That's interesting. It's a time series database. It's really good for things where you just you have a massive flow of events and you want based on timestamps. Yeah. Yeah, I have just started exploring it due to IoT stuff because there's also like sensor data coming up. Okay. Okay. Right. So let's talk about challenges then. Like what are those challenges that you deal with network infrastructure on a daily basis? Challenges generally involve one of the two categories of things that I mentioned earlier for monitoring is pretty much a two categories of challenges. Sometimes you get strange things like why why are people from this I random IP address I don't recognize trying to SSH into my switches. So that's like it's a you always get these weird drive by attacks, especially in the case where you have available guest networks available to people who, you know, visit and stuff. So when you mean by drive by attacks, that means people try to get in, try to do something naughty and go out. No, no, I'm saying that people walking around devices that they don't realize are doing these attacks. Oh, okay. So you just, you know, you'll just like a malware or people like probably malware of some sort. Because reliably, I found that whenever such a thing happens, it tends to attack its gateway. Instead of trying to attack like anything else. Right. But then the fun thing is it tries this and then it gets an SSH version mismatch or something like that. Right. And then it fails and it shows up in logs. Okay, I mean, it's if it succeeded, it would still show up in my logs with sure. Sure. So I guess logging all these things is or setting up logs for all of these things is also turning them on in fact, at all of these levels. On a big on even on a small network, but definitely on a big network, your only tool is intelligence. You want intelligence, you want visibility. So do you guys have like a network room? What is it called? No, right? Network operations? Yes. Do you have that? But if you think about any room where there's one person sitting down, who does networking things is a knock by definition with a few LCD screens and charts. No, I'm not a big fan of pull based stats or pull based alerts. I don't want a screen to go red when something goes wrong. I want to get a push alert when something goes wrong. All right. So if you if you just have like screens up there, you just get used to them at some point. Yeah, you get a little like he says nice to it because you know, you just have like, Yeah, but that one cell is always red. Who cares about it? Right? That's what I said. That's true. That's true. Yeah, I've read this mindset in design theory as well. They say that you have to be very careful of what notifications you send to users. Otherwise, they'll get desensitized. It's it's a lot like how in in Python, I think they have the whole explicit is better than implicit. The same way I always go, right? No, no, that's not what I was thinking. In Python, you have this thing where exceptions are supposed to be exceptional. Don't use them for flow control. Right? Okay. Right. Ignore the flow control because it's not really applicable here. But exceptions in real life and in networks and in anything have to be exceptional. Right. You can't just have like, here's a screen that was always green and it slightly turns right. That is like, nobody cares about that. What I want is like a ping, an alert, something on my phone, something on my watch. These days, since we're smartwatches, that's an amazing way of getting right. And that's only when something is really in trouble, not because you know, oh, I am at 50% capacity. Yeah, exactly. You don't want things like, Hey, I'm at like 48% battery, you don't want notifications on that. You don't want notifications on things like, Hey, so your colleague just SSH to this machine that he already had access to. Yeah. But if you all if you have like, you know, a bunch of failed SSH is again, you don't actually want notifications of that unless that it goes about some threshold. Right? Because if you have these drive by attacks like I was talking about earlier, you don't want to get pinged for everyone. Then you get desensitized again. That's not an emergency. An emergency is when you have, say, some guy trying to send 35,000 spam messages from your mail service, right? You want notifications. Okay. So then do you do you have to customize all these notifications scripts or whatever you use to send yourself? Yeah, absolutely. Because the thresholds are a very, very, very organization. Yeah, I would send 300 emails a day, sending even 500 might be like a minor case of what's going on. Yeah. But it's kind of similar for us where a single account usually doesn't send out more than, you know, a couple hundred males a day. Right? So if it hits 1000, we get an alert on that. And actually, if you hit 1000, it also kills that and stops you from sending more mail. But that means that when you send emails to you do send bulk emails to like parents or something, you have to like, take these down for a while for that one account. So it's very event based and organization specific. Yeah, it is. There is no way you can have a one stops. This was everything. People are going to be all like, Hey, you know, we can use machine learning and like do this and that. And as someone, I can tell you one thing. There is a reason ops people are traditionally very, very conservative with this stuff. It's because as a dev you can patch and fix something. When you're running ops, patching and fixing things usually involves spending. Yeah. And that's usually something that, you know, I mean, software patches are really very cheap hardware patches usually very expensive. Yeah, it's also like, if there have been vulnerabilities in switches before and upgrading switch firmware means downtime for that switch, right, which means downtime for every switch that has that switch as an upstream. Yeah. So there is no way to have like a zero downtime upgrade unless you have massively over specced your switches. Right. So do you have backup switches for these kind of things or we run spare inventory? Yes. For when things die, but for things like upgrades, I just pick a weekend and go, these two floors are going down. Right. Okay. So you I mean, because you're running in an organization where weekends are off, I guess you have that that capability of sticking. Yeah. In most organizations, if you're running things like for client devices, you can generally pull off something like this. Right. But if you have a data center, I can tell you like data center switches, you shed your like one day a year when you can upgrade it. Right. If you miss that, if you miss that window, that's it. Next year. You have to wait another year. Yeah. And especially this is really interesting with the light of all the random stuff that's happening these days where people are finding all sorts of vulnerabilities in switches online. And there's a whole thing about upgrades and not being able to upgrade. And I think that's really interesting that you know, if they do once a year, that's really scary. Yeah. You know how they say right that most secure code is code that's not written. Yeah. But these days, everyone's shoving more and more and more smarts into devices. And that just means more and more vulnerabilities. Yeah. I wouldn't be surprised if someone can do as my watch. I'm pretty sure that's going to happen at some point. Cue someone writing that app right now. Yeah. All right. So we have just one more question for Rahul, but before that live audience, if you have questions or thoughts for Rahul, please put them in getter.im slash rebuild sg slash live and we will ask Rahul after this segment. So Rahul, for the last bit of things, how do you keep learning new things about network infrastructure? So considering most people listening are more on the dev side and less on the dev ops or even the operations side, the easiest way for you to get more info initially is going to be hacking news. Every time there's something new and exciting, it turns up on hacking news. There's also r slash sysadmin and r slash net sec. Okay, net sec. Okay. These are very handy. r slash sysadmin unfortunately is not something that you'd want to follow. It's something you want to pull. Wait, this is Reddit, is it? Yeah. Reddit slash r slash. Because the problem with r slash sysadmin is it's 90% windows people talking about like domain controllers and honestly, that doesn't really factor into our world. Okay. The other very useful source for things is Nanog. Nanog. The North American Network Operators Group. They have a mailing list, you know, you just subscribe to that mailing list. You do get some noise in there every now and then, but then it's not that bad. Okay. You get, that's where you go for like, you know, for example, oh hey, this ISP just started advertising YouTube to the rest of the world. You might want to block them and you get like advance notice or things like this. It doesn't really affect you because, you know, the average person has two or three ISPs that, you know, are in the chain between tier one and them, so you don't really have to deal with that very often, but just in case. Anyway, Nanog is one source. The other one is just read, read, read, read, because a lot of it is just, hey, I didn't know this RFC existed, for example. RFC, yes. What about books, Rahul? I have not found a good networking book. Yeah. I was recommended, or rather, so I've been trying to learn about networking and I have like two books. One is Interconnections by Radio Perlman. I think it's really old, but I was told that this is kind of the fundamentals. And the second one is by Andrew S. Tannenbaum. Right, yes. Tannenbaum's books. Yes. He wrote Operating Systems and I also found a book by him about networking. So if you want to get into the fundamentals, maybe these two books, really, really fundamental stuff. And when he said old book, that's one very important thing. Too often people discount something just because it's old, especially protocols, and they come up with a new fangled way of doing things. I mean, here's an example. We had this thing in the 1980s called Resource Location Protocol, I think. Okay. The idea was you connect yourself to a network and you auto discover printers and SSH things. Does this sound familiar? Yes. For sure. So this RLP was reinvented as SLP with some changes. Right. And then SLP was an Apple-pushed thing that they used up until 10.2, I think, when they introduced Rendezvous, which was renamed Bonjour. Yeah, that's Autoconf, right? It's all the general idea of Zeroconf, as they call it. Autoconf implies that you did some config and that automatically hit something. Right. Zeroconf implies you don't touch anything. Everything discovers itself. Yeah. But it's amazing how it's very frequent. The more you look into history of not just networks, but also a lot of things to do with software engineering, people are just spending all their time reinventing the wheel, except in the case of software engineering, there's a lot of reinventing the wheel within the wheel, within the wheel in a platform effect, as they call it. Yes. It's insane that you now have Linux running inside a browser, running on top of some framework, running on top of your kernel, which is also Linux, and then you go, hmm. Right. Abstractions of abstractions. It's not really abstractions. It's more like we're building an OS within an OS within an OS. And at some point, you just start wondering if that's all worth it, or maybe we should just go back to it. So don't discount old books and RFCs. Yeah. Read the fundamentals and know why such a protocol was built. Great. So, Chitmay, shall we go on to the audience questions? We have a few, right? Yeah. Let's go on. If not, just keep posting, you know, as long as Chitmay's asking Rahul, we will take up your questions. So keep them coming. Let's go on to IAPOling. All right. The first question is from Michael. He asks for recommendations for home routers. Now, see, the problem is that the home router that I used to recommend to most people that didn't want to spend time on their network has been discontinued. Now, it used to be the Apple Airport. Apple Airport. Oh, they discontinued it. Yeah. It's been discontinued very, very, very unfortunately in Apple's new, as I would describe it, misguided approach of let's cut everything that isn't iOS. Right. Okay. So do you have an alternative? I've yet to find one that is like great for people that don't want to spend too much time. But if you're willing to spend like, you know, a couple of hours, if that every quarter, then it's a pretty good idea to get something like a router board or a micro-teak or actually, if you just want a router without Wi-Fi, I can recommend the Ubiquiti Edge Router Lite that has a web UI. It's like, you go in, you set it up 10 minutes, you're pretty much done. Right. Okay. That's pretty good for like, I mean, it's not something you can hand off to your parents and have them configure, but it's something you can configure for them once. It's for the geeky ones. Okay. It's not for the geeky ones. For the geeky ones, you'll be doing the router board or the micro-teak, you know, things with the CLI to control it. Or in my case, I'm using a PC Engine's board. PC Engine's, yeah. Yeah, because it was like $120. It's cheap. It's really good. It's x86. It runs Linux. I can do whatever I want on it. Wi-Fi wise, I strongly recommend, even for home use these days, I strongly recommend Ubiquiti. And if you get the... They're cheap, right? They used to be really expensive. They used to be really expensive. Now, you can get them like at a bed below 100. Yeah. The nice thing about them is these days, you can get... I think it's called the Unified Cloud Key if you don't want to run the controller yourself. Oh, really? The thing is, the controller, honestly, it doesn't need to always be running. Okay. You fire up the controller on your laptop. You configure your AP and that's it. It's done. Okay. And the controller is basically just your client to talk to the AP and set it up. Yeah. Okay. Awesome. Yeah, I actually run a micro-teak myself. So it's... I will agree that it's super fun. It's very... You can customize a lot of things, but it also means that you have to be able to do a lot of these things if you want to get it. Yeah. You want to set aside like one or two days initially when you configure it. Agreed. Exactly. Because it's surprising how much stuff like what you're recommending earlier with Apple actually has pre-configured for you. Yeah. And then when you start doing it yourself, you're like, what the hell is a hairpin net? And why the hell do I need it? And then you're like, yes, of course. That makes sense. I mean, there's also like the QoS stuff. Apple does it automatically for you. They use something that's not actually FQ CodeL, but very similar to FQ CodeL. Yeah. FQ CodeL is fair queuing with control delay. Yep. Okay. Probably one of the best QoS algorithms out there right now. Okay. Can you get that kind of stuff set up on other orders? Yeah, you can. It's just... If you... The other option to get something that runs DEWRT. Right. Okay. In which case, you just fire up the web GUI and it asks you which QoS thing you want enabled. Okay. All right. Cool. All right. The next question is from Bjorn and he asks a security question. He says, So I've been hearing about this ping of death and how MIRC or US can nuke your computer. How can I protect myself? Oh, sorry. That was wrong. I was going for this. You need to label your soundboard. My soundboard is so... Some stickers or something like that. Yeah, that soundboard definitely is. It's very amazing when you get the badum dish when... Come on. Once again, Chinme. Yeah. So security questions. I've been hearing about this ping of death and how I RC warriors can nuke your computer. How can I protect myself? Uh-oh. Pings of death are just another name for denial of service attacks. You can't really protect yourself that well from it other than reject the packets and hope upstream doesn't hate you anymore. Yeah. I mean, the problem with denial of service attacks is you really can't do anything except whoever has provided you internet service could possibly reject packets that are naughty. But generally, if you're a consumer, what happens is when you get DDoS, your ISP temporarily kills your internet for a bit. Yep. And then you have nothing else to do. Just sit, twiddle your fingers, and I don't know, maybe get like 3G or something. Yeah, use your LTE connection instead. All right. Next question from Seb. What are your thoughts on running a CDN from a gigabit internet connection in Singapore? Any ISP limits? You shouldn't have any problems except if you're running on a residential connection. You're going to not have lots of fun in the evenings. Right. Because obviously the ISP also applies quality of service type things and they try and make it as fair as they can because they only have so much international bandwidth. Right. And even local bandwidth, because of the way our open net stuff works, it is not much fun. Okay. So it can be done. Just don't expect to be able to use a full gigabit pipe. Right. Okay. Also, in general, is the net like outbound connections from Singapore that good in general? No. Okay. In general, you want to avoid, I mean, if you're covering Southeast Asia, Singapore is amazing. Okay. But it's amazing on a relative scale. Right. I have seen 150 millisecond latency to Indonesia. Okay. In which time I can hit the US? But then are the big network centers like Amazon or whatever on a different cable? Well, because they seem, I mean, there's a bunch of service. Okay. So they probably get higher. Yeah, they've just really paid more. That's it. Okay. All right. Fair enough. Next question from Kai. What do you think about IPv6? I think IPv4 needs to go die in a fire. Okay. Oh, that's hard. I'm not a fan of IPv4 at all. NAT is something that NAT is horrible these days. That's the network address. So you have like translation. Yes. Yeah. And these days you have to carry a great NAT as well, which now you're behind two NATs. Yes. And it just gets very annoying. CG NAT is especially, I don't know. Do any of telcos do it? I know. I know. Yes, MyRepublic. Oh, really? MyRepublic, I'm now going to call you out publicly on the internet. Can you stop issuing 10 slash 8 addresses? I know the mobile phone 3G networks do that. Yeah. But the mobile phone networks use proper CG NAT bands. There is a 100.64, I think, that has been reserved for CG NAT. And instead, dear friends over in MyRepublic go, hey, why don't we use an RFC 1918 set? And all I can think of is maybe you should hire a network engine. Yeah, because you shouldn't be giving out 10.2 non-internal networks, right? Yeah. Interesting. That breaks a lot of best practices. All right. Cool. And the last question we have is, do you have a hardware list for engineers? Wait, what was it? Network engineers. Like, what are your tools of the trade? Like, we're here. Tools of the trade. You want a laptop as light as you can get? Because you want to run around? Because you will be walking around. And this laptop has to be Linux? It can be either Linux or OS X. It doesn't really matter. Linux or OS X, OK. Not Windows 98. I mean, you can use Windows. It's perfectly fine. Just make sure you have a Linux VM in it. OK. You also want a USB serial dongle? OK. You want to make sure that... A lot of stuff. Finally, if everything dies, talk serial. Literally everything talks serial. Even at home, I have like two switches and a router. All of them use serial. I mean, I can access each of them, but if it breaks, then serial's the only way to get to them. And also, Ethernet dongle, if your laptop, which because it's light, should not actually have Ethernet built-in. Macbooks, yeah. Well, no. Literally everything you buy these days that's light doesn't have built-in Ethernet. Because, and some more you said, as light as possible. Yeah, it's generally good to hear. Because honestly, like, 90% of your job is just going to be a keyboard, a terminal, and a web browser. You don't really need power, so it's OK. Interesting. Cool. Cool. So those are the tools of the trade. OK, good. That's all the questions we have for now. Let's move on to the next round, which is called Rapid Fire. I got my sound effects right for the one. Yes, finally. I know. All right. It's going to be really good at shooting bullets. Yes. So Rapid Fire, as you know. Quick questions. You don't have to politically correct. I don't think you're ever politically correct. So I don't know either. Politics, what is that? So first question, V.I. or E.Max? E.Max is a similar to him. OK. So E.Max, lovers can go eat it. Anyway, bite. Yes. Favorite website for getting your geek news fix? Reddit and hack and use. Reddit and hack and use. Cool. Current favorite video game or board game? I know you like both. Yeah. Current favorite board game is going to be code names. Code names. Yes. Look it up. It's fun. Current favorite video game at the moment is Factorio. If you're a programmer or if you're a network engineer or anything to do with technology, you will love that game. Factorio. Factorio. OK. I know Rahul loves to play this indie game. So it must be really cool. All right. The next geek toy or gadget you're looking forward to buy? Next geek toy or gadget? Anything you are really eyeing? No, not at the moment. OK. Wow. Rahul's content with what he has. Yeah. What's the next tool, language or framework you want to learn or pick up? I'm still working on picking up Rust. Rust. OK. You got to make sure you don't get rusty with it. Yeah. I mean like, let's put it this way. The language name is very appropriate. You spend like a year doing it and you're still like, wow, I'm still learning new things every day. I'm still rusty. Wow. This is so rusty. Anyway, what's your favorite sci-fi book or movie? I like Starship Troopers only if you don't take it in the way the author meant it, but you take it ironically. OK. Ironix Starship Troopers. Current favorite meetup group in Singapore? There are lots of. Because we love. Oh, because that's where I get a lot of exposure to things that I normally wouldn't bother reading. That's true. It's like the lazy meetup, right? People read out papers to you. Yeah. And it's also like for most meetups, you know, you turn up for the Python meetup because you do Python. You turn up for the Go meetup because you do Go. You turn up for JavaScript meetup because you do JavaScript. But when you turn up for this, you have no idea. Yeah, that's true. I mean, it always blows your mind. Yeah. I mean, I'm still waiting for a chicken paper, but still. You could do it. You should do it. Sure. Or we could get Meng to do it. I think it would be more funny. Anyway, the last question is there. Oh, actually, I would ask you this one. What's your favorite programming language? Rust. Rust. Okay. Cool. All right. Thank you very much for answering our rapid fire out. And now we'll move on to the next section that's PIX. The way PIX works is we go on a table. We'll give you some time, Rahul, to think about your PIX. We'll start with Sani and me and Rahul. And the idea is to pick two or two, three interesting things. Blogs, books, apps, foods, meetups, whatever that you want our audience to try out. So do you want to start with the PIX, Sani? Yes. This year, I started wearing a wearable. Finally. That is so hipster. She starts wearing wearables. I got a me band, a Xiaomi band, and I started pairing it with my iPhone and I started tracking the sleep. I'm really excited about the sleep function because it vibrates on my wrist and wakes me up. It actually can count how long I sleep, how long I deep sleep. Maybe it's not so accurate because it doesn't really do my retina eye motion tracking. But yeah, it's pretty interesting. And I can get calls on my me band. So if somebody's calling on my. Well, you just get notifications. Yes. But if you get calls, that would be really weird because you're like holding your watch to your ear like, hello, I can't hear you. Hello. Hey, I do that sometimes when your hands are all like really busy. The best you can do is poke a button on your watch and go, can I call you back in five minutes? Oh, so you wear, Rahul, you wear I watch or? I wear an Apple watch. Yes. Okay. Okay. Apple watch. So there you go. So yeah, try out some kind of wearable and pair it with your hand phone and see what you can do. Yeah. Cool. Is that the only pick you have? Yes, I do. All right. Good. I have two picks. The first is Kycat. I think I've picked this before. Kycat is a tool for making schematics and PCB layouts. It's open source and recently its main competitor, Eagle. So this is for electronics, by the way. Just went from a freeware slash paid for premium kind of model to a paid subscription kind of model. So Kycat has basically become now the de facto standard of anybody sort of, you know, doing a small little hobbyist project. Check it out. It's super awesome. There's a lot of tutorials now. The forum called Kycat.info that does a lot of, you know, tutorials and questions and stuff. It's really matured well now. And my second pick is this interesting IC from the manufacturer Sylapse. It's called the EFM32. It's a Cortex M0 based IC. It's a small little microcontroller. It's basically nothing special about the microcontroller except it's really small. It's a 24 pin package. And the best part is it has a USB physical layer built in. So you can actually do USB stuff. You can do serial ports like a console USB thing, you know, like how you plug in Arduino and you can get console to it. Something similar with it. It's super cheap, super easy. It has a lot of the stuff built in so you don't really need any components. In fact, just with like five or six passives around it, you can have a USB setup very, very easily. So if you wanted to get USB connected to your electronics, the EFM32 Happy Gecko is called. It's super awesome from Sylapse. So those are my two picks. Rahul. My pick is going to be a book that I've just started reading. Great. It's called Hackers Delight by something Warren, Henry Warren, I think. Okay. It's it's Hank Warren. Right. Okay. It's some Warren. So it's called, it's called Hackers Delight. You can get it on Amazon. You can get it in a Kindle, whatever. It's a book that basically covers, it's almost like CodeGolf in a book. So he starts talking about algorithms to do certain tasks. And then it's sort of like, how, what's the minimum number of operations or how fast can we make this go? I don't know. So it's about algorithms and what is it? It's about algorithms in a way that most people don't usually think of unless they're working in the embedded space, I guess, because, you know, size is important, their speed is important. Interesting. Hey, that's going to be my next book. Thanks, Rahul. Yeah. What else? I think that's about it. All right. Cool. Thanks for doing picks and let's move on to the next segment, which is. Event Loom. This is where we tell all our listeners and audience that, hey, apart from online reading and podcasting, go and meet people in events. So the next up we have on First Feb, which is the Hackware Internet of Things special. It's going to be at Google APAC headquarters in Singapore. So if you are in Singapore on First Feb evening, come down and join us. The next event is Fawcetia. Yeah, Fawcetia is happening again. It's going to happen in Singapore again. Yep. It's at the 17th to 19th of March at the Science Center. And they are looking for speakers. So if you have a project that's really interesting, it doesn't have to be software. In fact, they're specifically looking for hardware projects and biohacking projects. So if you have interesting projects that you think would be relevant to the open source, open community, open source ideologies, do submit talks. They are absolutely looking for speakers. They always have issues having enough local speakers. But in general, otherwise, do attend a conference. It's really fun. You get people from all over the region coming down and sharing some really cool stuff that they're working on. Yay, so go ahead and attend events. Make some friends. Here's something that you have never known before. And the last segment is called Electric Plug. So this is where Rahul will tell us how to connect with him. Rahul, how can people connect with you? You can find me on Twitter. That's twitter.com. Rahul, which is my backup username that I use because someone has taken twitter.com. On GitHub, you can find me at twitter. GitHub.com. There's a bunch of really weird projects there. Some maybe to your interests, some may not. I am working on something kind of fun that I might be releasing later this week. Does it involve an IoT wrap? It does not involve an IoT wrap, but it does involve networks. Networks. Okay, good. Sounds fun. Cool. Actually, Rahul has a lot of interesting projects that you should check out. One of the ones that I use a lot is a Chrome plugin. I think we probably have it for Firefox as well, which strips off all the random crap at the end of a URL. Yeah, it's called The Origin. For advertising stuff. Yeah, you know, like if you click on a link and have all this crap at the end that tells them where you came from and just annoys the heck out of me. It's okay when it's in your browser, but when you copy paste it in the link to someone in Facebook chat or something and you find the link is like 35 megabytes by itself. So yeah, it's there for both Firefox and Chrome. Yes, so there's a lot of small little gadgets that Rahul makes that I use here and there. Small little scripts gadget. There's also something that Claudio who's in the chat and I built called Wee. It's W-H-E-E, I think. Okay, and what does that do? If you have a browser tab that's playing audio and you close it, it plays the classic cartoon rewind thingy. Okay. It's yeah, just install it, try it out. It's fun. Okay, we will definitely include the links to the show notes for all of this. Yes, we will have all of this in the show notes. Hey, Claudio, you got a mention. Oh right, one thing, one last thing. I like this look. If you run VMs on OS 10 a lot. There was this lovely little project. Called X-Hive a while ago that I think I've talked about before. So this is the stuff that you use the hypervisor framework? It uses the native hypervisor framework built into the OS and these days it's been... A lightweight OSX virtualization solution. It's been superseded by Docker's hyperkit these days. Okay, okay. So the X-Hive upstream is basically that hyperkit's where all the fun stuff is. But I do have a cute little tool that I used to run my VMs called X-Hive, which is also on my GitHub page. You basically have a little iini file and one command, boom, VM, the CPU usage is absolutely minimal compared to things like virtual walks. Cool. Yeah, this is something that I really enjoyed with Docker, but I guess I should try this out as well. Yeah, it's like if you just want VMs to run stuff. Yeah. So on all my laptops, I have one VM called my dev environment that runs Arch Linux, which I do everything in. The macOS bit for me is more a browser and a UI than it is a core. Cool. I should check that out. That sounds really interesting. Yay. So thank you Rahul for joining us for this episode 42 of UI. Thanks for having me. Yes, we really enjoyed it. Thanks to the live audience as well for joining us today. They were very team. They didn't troll too much. I'm actually quite surprised. We learned a lot about computer network infrastructure, a lot to play with as well with a lot of things that Rahul mentioned. So that's it for this week's episode 42 of We Will Live. We will come together again online on another Saturday morning with another cool guest. Until then, return zero.