 I'm going to take an answer to the speaker exemption. Sorry about that. Thanks. Thank you, guys, for thanks, everyone, for coming. My name is Thomas Smith. I suppose the intro, I'm not a dev, so I have to warn you. I am the maintainer for the NSH port in OpenBSD. And I assist the author and founder of the NSH projects, Chris Compusho. And it is very much he's Batman. And I'm Robin's baby brother's cousin, something like that. So I don't speak for the OpenBSD projects. I'm a user. And I probably trampling today, I'd be trampling over the shoulders of giants, such as Chris Compusho, Stuart Henderson, Kurt Moseychuk, who helped me with the getting into ports. And I really appreciate his help and guidance. And of course, I'd have to say Chris Compusho has been more than generous in accepting some terrible patches from me and making minor tweaks to actually make the patches fix the compiler's without making the program explode. So a shout out to Chris for his generosity and just not actually screaming at me, go, what were you doing? But earlier, moving swiftly on. I suppose for me, OpenBSD and indeed FreeBSD in the areas I use it, probably the BSD projects have made my working life easier. So it's really do appreciate all the generosity of time and effort you put into the code. And I suppose I'd like to just say, if you're using some obscure project or a project that it is nice just to say hi to the developer, buy him a beer if they like that point or whatever their poison is. And also just even just send them emails with good positive feedback. So I'm an engineer and a business owner. I really like the road less traveled. And I like to try and get some sort of deep understanding of the issues at hand. And I suppose I've always found myself in IT always been, as my friend said, do you know that thing in front of you, Tom, it's called the curve. So I've always just tried to catch up and try and catch that curve. But it's a moving target, you know yourself. Chris Capuccio is surprisingly similar profile. He has an ISP in the United States in Oregon. And he's the author of NSH. And he's also the author of Flash RD, which was to help run open BSD on flash drives when flash drives were much more unreliable than they are today and in areas where you don't have a data center type power and cooling environment. And so where you can't effectively rely on it. And I suppose this is the main reason why you see on so many network appliances that you generally don't write to the config. The actual OS is pretty much static. Or you don't write to the disk, the config is static. I'm going to skip a couple of slides just for the base. But basically, I've been in IT since 2000. And I've dabbled in different being introduced to Linux first, then going on to the free BSD through my friends in Red Brick in DC and a shout out to them. Although they gave out to me that I didn't spend too much time on the terminal. So apologies. I'm trying to make up for it now. Just from our side of it, being an ISP, we use open BSD wherever we can. And it's a case of if we can, we think we should at least try. So we use the recursive DNS, authoritative and recursive DNS servers using, obviously, the NSH from the NLNet project, which is in base, which is brilliant. Open NPD for timekeeping, which anyone who's used OSPF or any timer-based network and protocol is absolutely critical to have synchronized time. It also helps with incident management and understanding what happens on an incident on your network, be it security or an actual fault, fault diagnostics and resolution. We use relad for some load balancing and SSL termination or TLS termination. I think it's the more fashionable term for it nowadays. Although I'll probably be correct afterwards. It's not a fashion statement, but I'm sure there's something more technical related to it. And thanks, Theo, for his talk on TLS earlier on in the conference. Obviously, we use the PF firewall, and we use the network termination units or climb-premises equipment. So why open BSD? Well, I just think design the invitation to syntax of the PF BGPD. The network configuration interface is brief, but very profound. You can really do some lovely stuff. So why am I talking about NSH? Well, NSH is a CLI intended for open BSD network appliances. There is some interest in free BSD, and I think we probably... And I think depending on how well we get the configuration language done, and any of you, those who are linguistic experts, and I would like to have a chat with you about that. Because initially, NSH was about, oh, let's make it look like Cisco, or a well-known operating system that rhymes with San Francisco or something like that. And of course, a lot of network vendors then, in order to try and take some market share, made their equipment behave and look like a Cisco command line interface. And so from that point of view, so with that in mind, that's what Chris's initial aim was, was to actually make it just behave like a Cisco device. I'd make it easier for someone who's trained on Cisco to use open BSD, and that's a kind of a really cool thing, you know? So I just want to talk about a very simple example. If you have a switch and you have a VLAN 101, so VLAN is just carving up a switch into virtual, local area networks. And we're just going to call it 101. And we want to make one of the ports an access port and one of the ports a trunk port, okay, on the switch. So it's very simple config. And we want a disabled spanning tree because spanning tree is terrible. That's said, if any of you design spanning tree, thanks, because it does suck less than the loops it prevents. But if it's misconfigured, so it's more maybe it's the engineer sucks to be fair, but I think we've all been stung with a spanning tree incident at one stage or another and disabled any other discovery protocols. So what I'm going to do is just kind of go through what I just a couple of configs that you would see on a typical network device that you would see and you kind of go, what's going on here, okay? So here's a Brockage, it's an old Brockage VDX6720. So you've host name, just set the name of the switch. So it kind of appears on the prompt, so that at least you know what device you're on. You've got an interface VLAN that declares that you want to VLAN, you call us, give it some description, which is fine. And then obviously you need to apply that VLAN to a particular interface. So in this case, we're just going to cover the trunk port because it's a bit more involved, but it's kind of simple. You've got interface 10 gigabit ethernet, chassis number one, blade number zero, port number 10. So on most switches, it would look like that because most people just have a single one-U switch. Anyway, so you've got, you set the MTU to the maximum that the chipset would allow so that we don't run into any issues with storage area networks where people might want to run jumbo frames or large. Frames that exceed 15, 14 bytes plus the VLAN header plus the CRC 1518 or 1522, depending on which document you read. One includes the CRC checksum that you never seen in Wireshark because the card has already stripped it. But anyway, I've digressed it a little bit. But so we've got switch port. So we say we want this set as a switch port because some switches are sophisticated and they might be actually a router as well. So you have to say I want to use this as a switch port. I want to use it in mode trunk, which means I want to use it as a VLAN like I want to use tight VLANs out of it. And then we say switch or trunk allowed VLAN add 101. So we've added that. We do BPU drop enable, which is handy if you're facing customers and you don't trust them. So you don't want them to inject spanning tree events into your network, which is just a pro tip there. But anyway, and we say we don't want to use spanning tree on this port at all. So we're not trying to communicate or send anything themselves. And we disable LLDP and we just say no shutdown, which is the nice way of saying it. So I'm going into detail with this, but I promise you it's, and you can also see at the top, we've set the NTP servers. So just through our two NTP servers on our network. Now if we look at an Orista, you start to see there's kind of a pattern. They're not exactly the same, but they're kind of close enough that if you type NTP in double tab, it'll say, oh, do you want to specify the server? You know, you'll see that there's a declaration of the VLAN again, VLAN 101. And then you have the interface, and instead of 10 gigabit ethernet, they just ethernet nine slash two because it's a 40 gig switch. So the nine is the ninth port, 40 gig port, two is the second 10 gig interface of the four 10 gig interfaces on that 40 gig port. And we see we have an MTU, we can do a nice description as well, which is nice. And we've got switch port trunk, allow VLAN 101, switch port mode trunk, switch port. And then we're doing all these, disabling the protocols again. Again, two different vendors, but very similar config. Must be a conspiracy somewhere. Anyway, so then we go and look at a Cisco 2960S, nothing special, it's kind of a low end switch. But again, you see here, oh, we've set the host name, NTP peer, this time instead of NTP server. But again, it's kind of, the syntax is kind of usable, and it's close enough that you will find your way around it. You know, you'll find a way of configuring NTP if you're asked to do it. It's not close enough that it'll still annoy you a little bit, but at least, you know, you can't just copy from an Arista to a Brocade to a Cisco, you have to do some tweaks and work out what's going on. And it keeps people like me in a job where we kind of say, well, it's not so easy to migrate. So we go VLAN 101, we've a description, we can put a description into it. And then obviously then we set it on an interface which happens to be chassis one, LED zero, and port six, and gigabit ethernet. Switch port mode trunk, so it's all the same. So we're seeing TP-Link, again, another low cost switch, probably using a Broadcom or a Marvel reference implementation, again, using very similar config strategy. Got your host name, got your declaration of your VLAN, and how to apply the VLAN to the port. We look at Ubiquiti, this is where it kind of gets a little bit further away from the standards. And so my advice is if you ever get a switch from a new vendor and you think you know how to configure the command line, what I would do is save yourself a lot of hassle, open the web configuration interface, configure it visually in the web configuration interface, and then do a show run. And Ubiquiti will surprise you with a very unusual configuration, just slightly with this VLAN participation, exclude and include. But again, the principle is the same, you declare your VLAN and you have all these types of, you have all these types of configuration. You'll see there's just one item here, I've got switch port protected, and that's just a nice support isolation issue, which is a really handy way of limiting broadcast domains, but also eliminating layer two threats on untrusted networks, access networks, so campus networks like these fine places are hotel networks where you provide LAN ports. So what a protective port generally does, if you put them all in the same group, they're all isolated from each other. So if someone runs a rogue DHCP server, or backends the run type of TP-Link Wi-Fi router into the campus network to try and take it down with a DHCP server, well, this would actually prevent that. So it's just a really nice tool, a port isolation, and it cuts out an enormous amount of crappy stuff that someone trying to hijack poison arc and stuff like that is not possible with that. Did anyone notice a pattern-ish emerging there? Yeah, cool. At least one person's awake here. So if we were to do this in OpenBSD, using the standard OpenBSD tools, we might edit with my favorite editor, plugging MG here, you'd edit it, and we might say we call it a VLAN agnode or something like that. It's just been a little bit nerdy there. Then we go MG slash ETC, hostname.ixero, because that particular system happens to have an Intel, 10 gigabit network card, so OpenBSD labels the interface based on the driver and then the port number, according to some magic. We then just set the MTU to 9216, and we set the interface to up. That's all we're doing. We do the same to the second physical interface. But you'll notice also just to be clarified, on the previous slide, I only showed you the trunk port config, because the access port configurations is just like saying, access VLAN 101, it's simple. But just when you're trying to do it on an OpenBSD box, if you're coming from a switch background, it's just a slightly different mindset. So of course, then what we have to do is we have to create a VLAN 101, like a tagged interface on one of the interfaces. So we put it on, we say to its parents, we say we want VLAN 101 to be a sub-interface of IX1, okay, so the Intel. And we want to set the MTU, we set the VNet ID, which is the VLAN tag, and we just set it to up. And we look at the bridge configuration, we would use my favorite editor again, post named up bridge 101. We set the max address to a particular number that matches your network. I think allegedly I would imagine if you use more max addresses, it would use slightly more RAM, allegedly. I think that's probably true. And then the timeouts 300, a tip for any of your network lads is, try and align your ARP timeouts to your bridge timeouts and certainly don't ever have your ARP timeout longer than your bridge timeout, or you'll have lice, unicast, floods, which is, you'll know about them when you get them, but they're not particularly pleasant, particularly if someone has 100 meg UDP stream and then it's replicated across every port in your layer two domain, it can be quite nasty. And if they are wireless in there, you're going to really have suffering and pain. But then you have, so we have max address, we set it to up, and then what we're doing is we're adding the ports in. So we, in a switch when you declare a VLAN, you're just saying, hey, I just want a VLAN 101. In OBST, what you're saying is, well, I need a forwarding domain, a layer two forwarding domain, so it's a bridge. And we need to add it in. So we add in IX0, the physical interface IX0. So that's going to be like an access port. Sorry. So then we add VLAN 101, and we say it's protected and we join it as a bridge. And we say it's protected and we join it and we say it's VLAN 101 and it's in protected group one. So just, that was the feature that MPI plus the OBST project implemented, which I contributed in a very small way too, but like really, really small. As in I asked for it, and then they delivered it. It's actually, it's the ideal model for open source development actually. And so then, and we also just minus STP, but certainly it did really help a lot. So basically any device that's in a protected group, that's in the same protected group is isolated from everyone else in that protected group. And that's really nice, so because what you want is you may want to have your untrusted customers who are connecting to your hotel network not to be allowed to see each other, but they need to be able to see the local gateway. So you put the gateway or a printer or some service, maybe a file server that they want to access or a web, you know, intranet website in a different protected port group and they can all see each, they can see the people in the different protected groups, but not the ones in the same one, which is really nice. And you can also cascade it, you can make the members of multiple protected groups, which was a feature, oh, there we go. It's a feature I didn't ask for, but I got free of charge because of open source peer review and someone said, well, we can actually go one step further, doesn't create any complexity and actually delivers a better result. And it's an example of why many eyes in open source works. And I really do thank the developers and MPI for the, I suppose, the collaboration in the backend and looking at it, so I really appreciate it. And of course, it was useful for VMMs so that you could isolate VMMs from each other. Or I'm using the wrong terminology there, but just let it slide, just let it slide briefly. So then obviously, I just continue on with the OVC, the standard config, you then might want to change your NTPD configuration to have, you know, you'd have to edit NTPD.conf, you'd have to restart it and then you'd have to restart the network to apply the changes. And that's assuming that there wasn't any conflicting configuration on the devices beforehand, okay? So that's typically what would happen on your previous one. We could do it as an interactive on rc.local script and that kind of does it, as far as I know. I'm pretty certain it does. And effectively, we're just using the config tools that are already there. And that is quite readable, like I was looking at it last night and going, yeah, you could kind of work with that, no problem. And you just have to restart the NTPD.conf because of course, if config changes take effect immediately. So why would I use NSH again? I know I'm asking that question again, but I suppose the part of the reason is if you're not familiar with OpenBSD and you're asked to support us, which happens when you're asking junior guys to solve problems for you on the network, they're faced with a turbo with a flashing cursor, either like which file do I go and read? How do I understand the configuration of the server? And it does take a little bit of time to actually work out what's going on. It's perfectly possible. And if you use this, I do have a controversial opinion about the capital T for change in routing domain, but that's just because it just don't like the user's shift on, but maybe we can put a patch in to make OpenBSD case insensitive on the command line. That might help. There's comments later. Welcome, please. So then, so where's the problem? Okay, we can step one, you can do the if config, you can look through it, look for everything start.conf. Nice pro tip will be to check RCCTL LS status so you can actually see what's actually running on the system, particularly if your customers say this is not working or something's not working. And usually, because if it's a non-technical user, they'll just go, I can't work, something's wrong, nothing's working for me. And you kind of go, well, this is the server that serves them, so what is the daemon? And at least then they can kind of go through it. You can look for it. And after reviewing all that, we can resolve the customer issue. So NSH, if it was fully functional and implemented, everything that OpenBSD could implement, theoretically, we could just do show running configuration. And so if we were to do show running configuration, and by the way, show running configuration is kind of like the configuration syntax as well. So we can kind of establish that, okay, we have an ag node, we've made that. It has two physical interfaces, IX0, IX1. They're not shut down, so someone probably wants to use them. We have an interface of the VLAN 101. We've abridged VLAN 101, so chances are we're using the layer too forward in domain. And we've configured. And you can see here, there's one subtle difference there that there's no mention of the protective ports. And that's because the protective ports feature, it's not fully implemented in NSH. So this is where we have the departure from where it is and where we want it to be. And so what we have here, what's really nice about NTPD and what's also saved us a lot, I think saved Chris a lot of sanity because he has shouldered a lot more to burden, held a lot more infinitely more, is that we've got what NSH has been smart enough not to try and keep up with all the config changes and all the feature implementations of each daemon. And so it wraps around the control commands and it wraps around, and effectively that NTP rules, you can almost say slash ETC NTPD.com. And that's literally like, and it's just pushing that into the daemon. And then just NTP enable. And so that, so that, so if you're new to NSH, you can also use it to read or just run in config and just see what's on the kernel. It's also useful, I would ask for people to run it just to see how the thing, how it differs from what they're expecting. So for instance, if you use a protective ports, you get a nasty surprise, you go, well, there's no, I configure protective ports to the kernel and you haven't implemented it in NSH. So what's going on there? And so I would welcome any feedback where you say, hey, this doesn't work. Or, and so, and also if you're trying to dabble in it a safe way, or I think a safe way of using it, it's just to go show running config, don't do any changes in that and keep using your traditional tools so that you could actually assess what config changes are not being picked up by NSH. If they're not being picked up by NSH, chances are we can't configure with NSH that's something that needs to be remedied. Like the idea, particularly for me in terms of trying, my journey of trying to understand the code and my understanding is limited, I'll fully admit, is to actually do a gap analysis, like for instance on SysCTLs or SysControls for like, you know, there's ones there for controlling IP forwarding. Do you want to turn on IP forwarding or not? Do you want to make it a router or not? Or do you want to make it a firewall? Or do you want to put that port forward? And in that case, you know, there's a SysCTL for that, but the last one for changing ARP timeouts or ARP, you know, the timeout before retrying an ARP request. So there's always that. So we do welcome gap analysis and feedback on this. So recent improvements, they've added WireGuard support and you know, he has like the VEB support for VEB, interface, two-port MAC relay, which is nice as well, and support for interface monitoring mode. Public service obligation at BI, where's the exit sign? This is just, I'll just slag it a little bit, but the graveyard of many a configuration file, just my desperate attempt to get out of the config file. The improvement is coming soon and waiting on an OK. So we've improved the manual page. So we ported the man page from text to mandoc or mdoc, sorry, Ingo. I really appreciate the help and stewardship of Ingo who gave me very generous feedback on trying to improve the quality of it. I would say that mdoc is tough as a writer, but when you see the results as a reader and being able to search stuff, it is a phenomenal, it is just really a phenomenal project. So I really do appreciate the work that Ingo and the D. Chris taps initially on us, just to shout out to them. What we've also done is a new integration script because it's, you know, the integration script is dangerous. So you have to back up the original config, all the daemons, all the network configs, and then import basic configurations. So there's still a gap in what we can import and what we can't. And so it's really targeted at someone saying, oh, I'd like to try OpenBSD as a router or a firewall or a layer 2 switch of some sort, like as a software switch. And it's targeted for maybe a newly installed box where it's not like your life's configuration work about to be trashed by a defaulting NSH config. And we've implemented all the nest.init-sys controls that have evolved over the last, I suppose, 10 years in OpenBSD thanks to Florian and all the other people who work on OpenBSD. A shout out to two of my fellow DCU colleagues who joined us for the summer as part of a work placement program from my local university. And I really appreciate their efforts because they had limited exposure to OpenBSD and then they were being asked to contribute to this. And they really had a baptism of fire and they did some really good work in it. Just so I want to say hi to Alan McGrath and Scott McDonnell. They said, is there going to be a video? And I said, yes, and I will give you a shout out. So shout out, thank you very much. And I wish you all the best in your careers. And they're just really good guys and I wish them the best for their filer. So NSH installed, well, it's simple. You just go package at NSH. You can choose an aesthetic or dynamically linked flavor. And in this state, you can just read us and read the current kernel configuration. You won't see all the daemon configurations. That's just the way it is. But what you do guess is you could actually, my father used to always use to make things more get-outable. So to make it more accessible. So I just want to say hi to dad as well. Just on that one. But to use the NSH as a primary configuration interface, well, you have to back up the configs first because you're about to lose them all. And the second thing is you need to also, then try to move into a location where they might be imported, okay? So we do import the likes of bgpd.cov, ospf.cov, edgpd.cov that we are trying to narrow that gap of what we import. Again, what we're doing just to be clear, whatever the configuration syntax of pf or relad or open bgpd or ospfd, we're just taking that and we're wrapping around this. We're just pushing it into a running config under either bgpd rules for bgp stuff or ospf rules for ospf stuff and obviously for relad for your low balancer configs, okay? And simply what you do with KSH, like let's say if you had a bgp router you wanted to import it, you would do a cp, you copy the bgpd into var run bgpd.com.zero you move the file then to a backup. And the reason why you move it is you don't want to have two, a man or a woman can have only one master. So it's like, which one are you using to configure the system? And then by running bgp enable, it'll look for that part of that config, look at that file location, go right, that's your starting configuration. So you can also obviously do it with the copying examples if you're new. And what's really nice I have to say is when you run bgpd enable, it will actually check the config file and say hang on, there's errors, it'll do what you do with bgpd, would normally do anyway with bgpctl and stuff like that with the reload command. Or bgp control, sorry. I just have a habit of just being literal because it's not actually controllable. But I know what you mean, sorry. So the next thing then we've got, you can also run in NSH interactively, so you just type NSH in the command line. You can update the config so we can go, you can update the config like as a script to just say whatever's in this file I want you to execute as a script. And it might be enabling 100 interfaces, setting up OSPF and bgpd on them. So you can have whatever script, so you can do a script offline as a text and then just import it. And then obviously there's the initialize the config which you do kind of a startup, that's how you start the payment. Question, where should one, this is more if you can come up to me afterwards or in the bar later, or if you'd like to grab the mic later on. Like where would you put the integration scripts? Like for that, like what's good location? I don't think it goes in package read me. I'm thinking maybe var nsh in scripts or integration scripts or something like that. Because when I say integration scripts, it's like taking over, it's doing more than what you would, you would expect a package ad to do because you certainly don't want package ad, blow your config away and take over your machine. I think it'd be frowned upon to say at least. To do on the high priority side of things, what do we want to do? We'd like to import support from newer and renamed daemons like the Resolve D to the daemon to control the contents of the resolve.conf. Slack D, obviously the stateless auto configuration for IPv6, we want to be able to control the neighbor discovery protocol in IPv6, newer bridge features such as protect ports and then maybe let's say less commonly used devices such as 4G modems and stuff like that or 5G modems. And then implement, let's say, improved support for the actual DAC clients as well. So there's been improvements all the time. Primarily, I think for people who are on laptops and they're moving from network to network, but we need to take account of that in NSH to be fully functional. It's useful also for us, so for 10 minutes, thank you very much for that. Peter Hanstein, author of PF and a great educator. Thank you. Sorry for putting the spotlight out here. So then just like what we find with, sorry, I just asked for a train of thought there. If you have an ISP and you're trying to run like client units and you want to be able to update them and push config using the DSP, the integration of these is crucial. Like it seems trivial if you've static configs, but if you are trying to do devices on mass, the integration of these and I have to pay tribute to Florian and Pamela and the guys and all the people who've been helping us by improving the support for the problem of having multiple different network cards with multiple different sources of configuration and prioritizing that. So it is pretty nice with the work they've been doing. To do, there's a long to do list, so volunteers, welcome. But if you consider how to support additional packages that we would use commonly like open VPN, PMACCT, great. If you haven't used this, it's a great flow aggregator and disaggregator and starter for network flows by Paolo Lucchinde and he worked for an ISP when he was a young lad and he actually wrote it and it was a super approachable guy. And just anyway, it's really cool projects actually. So just if you haven't used it and you work with flows, I think you might want to use it. And then PFTOP, if top, even just use PFTOP is great one for analyzing where's your traffic being used on your firewall. If top is great, when you're trying to work out what are my interface, it's just kind of a graphical on the command line view of it's actually going through each individual interface. Fast and Mon, if you're an ISP and you have gamers on your network, you know Fast and Mon or if you don't, you will want to know it because it's a brilliant piece of software if I have it lost enough. I'm probably butchering his last name, but then review, I think place where we can really learn from is BGP CTL. And when you use this BGP or BGP control, thanks Claudio and Job and Theo and Theo for all that work that they've done on it. But because of the amount of data that you're processing like if you're searching for internet routes and looking up items on that, it really does help. To know that these guys know how to process that data and maybe we need to learn from how BGP CTL won't manage the BGP config. And then also how to, how it reports back the status of the system. And also the proof set model that it uses as well. We also want to review the syntax to ensure there's a synced and understandable. It's something that probably OpenBSD does pretty well in terms of naming things and the attention to detail, having people like Ingo around making sure that what we're saying is aligned with what we're doing. And I think for me as a network administrator, having a device that tells you what it's doing truthfully and accurately and succinctly is really important. And when there's a deviation between what's actually been said it's doing and what it's actually doing it really makes your life that's already complicated, more complicated. To do, there's a to-do list on Chris's yellow man GitHub account and it's on that URL there. So he wants to squash folks. It's improving automation and regression testing. So one of the things that was nice for me is I was only using maybe OpenBSD, OSPFD, BGPD, PF, couple assist CTLs and that was my kind of config. And it was only when I started exploring the different other daemons that NSH could control that you actually find other bugs. And it was in the process of updating the manual pages we were managed to squash more bugs. So we probably want to improve in the import capability from other daemons as well. Where am I? Other software that I think is worth checking out and learning from. Again, I'm booting OpenBGPD there and OpenBGPD CTL, because I do think it's five minutes. Thank you. And we've got the BSD router project which is nice, you know, it's BSD and there's definitely things to be learned from how they do stuff and how we can, I suppose, learn from their strengths. The FRR, the free range routing project. Again, that has a similar Cisco command line interface. It uses Zebra as the BGPD daemon, which, you know, for me, from my experience of using Zebra and other platforms, it was challenging. I know it's been extensively rewritten as well, but to be fair, I suppose it's just PTSD or something like that associated with running it before, but not on free range routing. It was actually on a Linux bus and it was a commercial project, actually. And then FreeRouter is a really interesting one. It's based in Java, so it's kind of like, whoa, okay. But if you look at the actual configuration syntax and it's done by, I think, a Hungarian guy and like, his regression testing scripts and his continuous integration, it's remarkably efficient in terms of how he's documented that and he has replicated quite a significant portion of Cisco's functionality. And it's just something that I think we can learn from in terms of certainly the way he has all these sample configs that can be tested that every time he does a new build, it's there, it's testing and improves the quality and the reliability of the final product for the user community. And it's just, it is something that while, and it does run on FreeBSD and it does run on Linux and he does have two images. I've had mixed results with it, but from a user interface point of view, it's phenomenal and it has pretty decent performance, surprisingly. So it's trying to, I suppose, just learn from what other people have done and take, I suppose, Rob Alder, good ideas. And just, I suppose, you know, I suppose those who strive for perfection soon find it's a moving target. I'm happy to take questions and do, and so, okay. Any questions? Thank you, very interesting speech. And I would like to ask you, you know, based on my experience, medium and large ISP, I'm trying to get away from a command line as much as they can, right? They're trying to automate configuration and there are some, let's say, emerging technologies to do this, like, for example, young models and netcom. Yeah. What's your experience with OpenBSD and with that? I've been honest, I relied on the command line but my version of automation is a lot of scripts that SSH into a box run a command line and do it that way. And I suppose we probably are trying to keep our configs as simple as possible because of that. So we try to, as in, that it's replicatable and it's not that, oh, if it's this type of interface, we do it this way. We try to use the same type of interface everywhere and even if at the risk of some suboptimal configuration, we'll do that just to keep it standard. One of the things that I had mentioned on the slides is on the to-do list, Chris wants to do a kind of a web-based. So what I think the way we'll approach this and Chris is the leader of the project really, so I think what we need to do is make sure that we dial in the command line, that the command line behaves itself, as you would expect like an OpenBSD configuration to. And then after that is to tackle maybe some sort of a privseft web server where you can do maybe REST commands and stuff like that, like what some of the major vendors have been doing for the last past few years. But for me, like on the automation side of things, like we've literally been just using Ansible or actually just shell scripts and Ansible with runbooks, and that's kind of how we've been using it. Also, I don't think like in terms of NSH, what I like about it at the moment is we're just using, we're kind of using the SSH as the kind of the network-facing interface, so that's locked down anyway. And then we're just relying on it locally as just a root user. We're looking at a privseft model for that, but it's kind of hard because for now, what we want to do is just be able to configure stuff. And generally, if you're changing any network configuration in the kernel, you're running as root anyway, so it's kind of, but if you then start having users with less like a help desk staff or junior staff where you don't want them making changes, then we do need to have that type of a privseft model. And it's appropriate, we need to be looking towards there. And certainly, if you had a multi-tenanted solution, yeah, that'd be much more complicated. But one thing I will say is NSH is rooting to main aware, so that is pretty nice. But it's rooting to main aware, but you're just the one user interfacing with all the rooting domains, so it's not like we can just say, oh, here's your client configuration as client X, and you can edit it yourself if you want. So it's not there yet on that front. But yeah, so on the automation front, like we're just using shell scripts in, and really the focus is to get, to align NSH's capability with all the developments, the extensive improvements in the network stack in OpenBSD and the rooting domains for the past 10 years. And we have a bit of catch up to do there. You know, automation is one part of the whole aspect, right? There's also data validation, which is really important, and somehow young is taking care of this part, this is what I was asking. And then I don't know if we have time, just like a second question. Instead of SNMP and like a sort of pushing strategy to do monitoring, is there anything else that we can use like similar to, sorry, instead of pulling strategy, is there anything else we can use to push strategy? You have SysLog, so we, you know, and so SysLog is a pushing strategy, you know, as long as you have the connectivity, obviously if you, you know, like so if you lose your uplink and there was a whole stream of information that you would like for that the uplink is used to take that SysLog traffic, you're gonna lose it. But so SysLog is there, there is SNMPD, I don't know, does that do traps, does it? It's getting there. It's getting there, but certainly SysLog at least has it. So whatever you would see in slash FireLog, messages FireLog, Damon, it's there and you can adjust that. And that's what we've used in our experience. But I would say in some ways, like RISP is quite small, you know, we're around 3000 users. So the number of devices, it's almost like we're, you know, each router is one of our pets and you know, they all have their personalities and we know them all individually, you know. So we probably need to get a bit more, but it is certainly on like the radar because if you want to grow and scale, you need to do that. Thanks for much for the questions. Thank you. Appreciate it. Thank you. I have a question. Yeah. Who's the artist? That's my daughter Sophie. So she painted them. So I tried to give her some pocket money to do it, but so she gave me one for my birthday to be fair. So that was, so that was my daughter Sophie. So shameless plug for Sophie's artist. I'm also into doing child labor. So if you want to, if you want to get some art, I could certainly, you know, I can get a work in every day, every day after school and we can push it. Any other questions? Thanks. Just to follow up on your network modeling question, there was a net confyang project to drive Alpine Linux at one point. COVID kind of dried up the funding for that. But if you're Blake, can you speak up? Sorry. Sorry, mask. There was a net confyang project to, to drive Alpine Linux at one point with, with net confyang and, you know, all this is controls and network config and stuff. COVID caused the funding for that project to dry up. But if you're interested, come talk to me. Thanks, Blake. Anyone else? I don't bite. Swear. Any VI users who want to defend? I think we're pretty much out of time. So, as I said, there's a traditional guest from, from the organizers and one special... Thanks very much. Appreciate it. And let's thank our speaker. Thank you, guys.