Podcasts about ospf

In today's episode, we continue the discussion about routing and routing protocols by focusing on commonalities rather than differences among  protocols such as OSPF, RIP, EIGRP, or BGP. We explain how, in general, routing protocols discover each other, communicate, maintain relationships, and exchange routing information. Next, we explore the topics of selecting best paths in... Read more »

In today's episode, we continue the discussion about routing and routing protocols by focusing on commonalities rather than differences among  protocols such as OSPF, RIP, EIGRP, or BGP. We explain how, in general, routing protocols discover each other, communicate, maintain relationships, and exchange routing information. Next, we explore the topics of selecting best paths in... Read more »

Our ongoing IPv6 Basics series continues with an episode on v6 routing essentials. We start with a comparison of various routing protocols: RIP, OSPF, IS-IS, EGP, and BGP. We look at pros and cons of each, and discuss challenges such as dual stack IPv4 and IPv6 network implementation, memory and resource use with IPv6, and... Read more »

Our ongoing IPv6 Basics series continues with an episode on v6 routing essentials. We start with a comparison of various routing protocols: RIP, OSPF, IS-IS, EGP, and BGP. We look at pros and cons of each, and discuss challenges such as dual stack IPv4 and IPv6 network implementation, memory and resource use with IPv6, and... Read more »

Well, as if cybersecurity doesn't have enough acronyms. There's RIP, OSPF, TCP, IP, SSH, AES, and so many others. Now, there are three really important ones to remember: ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), ML-DSA (Module Lattice-Based Signature Standard) and SLH-DSA (Stateless Hash-based Digital Signature Standard). ML-KEM is defined in the FIPS 203 standard, ML-DSA as FIPS 204, and for SLH-DSA, we have FIPS 205. https://medium.com/@billatnapier/get-used-to-three-boring-acronyms-ml-kem-ml-dsa-and-slh-dsa-0156b6ab82c5 

September is Suicide Prevention Month.  Today, we're talking about Suicide Prevention Training and Resources with my guest, Austin Lucas, from the Ohio Suicide Prevention Foundation (OSPF).     During our interview, we talk about  How we met and what the Ohio Suicide Prevention Foundation is Suicide prevention training opportunities for Pharmacists  How pharmacists in direct patient care roles can spot warning signs and have effective conversations with patients at risk of suicide Pharmacist suicide rates compared to the general working population Coping strategies for stressed, burned-out pharmacists who may be considering suicide Resources, including the Voices for Suicide Prevention Podcast BONUS discussion at the very end of the interview (Hint: suicide terminology has changed over the years - Austin tells you what you need to know.)    We cover a lot in our 40-minute interview.   Thank you for listening to episode 295 of The Pharmacist's Voice ® Podcast.   To read the FULL show notes (including all links), visit https://www.thepharmacistsvoice.com/podcast.  Select episode 295.   Kindly share this episode with your fellow pharmacists and your state pharmacist association. Subscribe for all future episodes.  This podcast is on all major podcast players and YouTube.  Links to popular podcast players are below. ⬇️   Apple Podcasts   https://apple.co/42yqXOG  Spotify  https://spoti.fi/3qAk3uY  Amazon/Audible  https://adbl.co/43tM45P YouTube https://bit.ly/43Rnrjt   Bio - Austin Lucas (August 2024) Austin Lucas serves as the Program Director for the Ohio Suicide Prevention Foundation (OSPF). He manages suicide prevention programming, training, events, education, and resources for federal, state, and foundation grants. Additionally, Austin is the project lead for the Suicide Prevention Plan for Ohio Implementation Team, which ensures the goals and objectives in the Suicide Prevention Plan for Ohio are met and exceeded. Austin also serves as the project lead to build out Ohio's local and state suicide fatality review and psychological autopsy infrastructure. He is passionate about empowering communities to spread suicide prevention training, knowledge, and skills throughout their locality.   About the Ohio Suicide Prevention Foundation (OSPF) - August 2024 The Ohio Suicide Prevention Foundation is a non-profit organization that works tirelessly to prevent one of our most preventable causes of death: suicide. Our work includes reducing the stigma of suicide, promoting evidence-based prevention strategies, and raising awareness about suicide's relationship to mental illness and substance use disorders, and other factors that contribute to suicide. Our community-based programs and best-practice resources are specifically designed to improve mental health across the state. Thanks to a combination of education, training, and support, we're helping all of Ohio's communities reduce the risk of suicide and lessen its effects on family, friends, and neighbors.   Links from this episode  OSPF website: https://www.ohiospf.org/ OSPF Facebook: https://www.facebook.com/ohiospf OSPF Instagram: https://www.instagram.com/ohio_spf/ OSPF LinkedIn: https://www.linkedin.com/company/ohio-suicide-prevention-foundation/ Austin Lucas on LinkedIn https://www.linkedin.com/in/austinmlucas/  Voices for Suicide Prevention Podcast https://podcasts.apple.com/us/podcast/voices-for-suicide-prevention/id1615500158 (Apple Podcasts Link) The Ohio Pharmacists Association https://www.ohiopharmacists.org Kim's websites and social media links: ✅Business website https://www.thepharmacistsvoice.com ✅The Pharmacist's Voice ® Podcast https://www.thepharmacistsvoice.com/podcast ✅Pronounce Drug Names Like a Pro © Online Course https://www.kimnewlove.com  ✅A Behind-the-scenes look at The Pharmacist's Voice ® Podcast © Online Course https://www.kimnewlove.com  ✅LinkedIn https://www.linkedin.com/in/kimnewlove ✅Facebook https://www.facebook.com/kim.newlove.96 ✅Twitter https://twitter.com/KimNewloveVO ✅Instagram https://www.instagram.com/kimnewlovevo/ ✅YouTube https://www.youtube.com/channel/UCA3UyhNBi9CCqIMP8t1wRZQ ✅ACX (Audiobook Narrator Profile) https://www.acx.com/narrator?p=A10FSORRTANJ4Z ✅Start a podcast with the same coach who helped me get started (Dave Jackson from The School of Podcasting)! **Affiliate Link - NEW 9-8-23**      Thank you for listening to episode 295 of The Pharmacist's Voice ® Podcast.  If you know someone who would like this episode, please share it with them!

On today's episode we delve into OSPF filtering. That is, how to filter routes from a device's routing table in an OSPF environment. This is a tricky business, because OSPF requires an identical database on every device in an OSPF area. That means you can't stop announcing a route from one OSPF router because you... Read more »

On today's episode we delve into OSPF filtering. That is, how to filter routes from a device's routing table in an OSPF environment. This is a tricky business, because OSPF requires an identical database on every device in an OSPF area. That means you can't stop announcing a route from one OSPF router because you... Read more »

On today's episode we delve into OSPF filtering. That is, how to filter routes from a device's routing table in an OSPF environment. This is a tricky business, because OSPF requires an identical database on every device in an OSPF area. That means you can't stop announcing a route from one OSPF router because you... Read more »

We turn the nerd meter up to eleven on today's episode with longtime friend of the show, Russ White. First we dive into how an Ethernet adapter knows when a link is lost, where Russ teaches us all about loss of carrier and OAM. He also gives us a tutorial on how the rest of... Read more »

We turn the nerd meter up to eleven on today's episode with longtime friend of the show, Russ White. First we dive into how an Ethernet adapter knows when a link is lost, where Russ teaches us all about loss of carrier and OAM. He also gives us a tutorial on how the rest of... Read more »

We turn the nerd meter up to eleven on today's episode with longtime friend of the show, Russ White. First we dive into how an Ethernet adapter knows when a link is lost, where Russ teaches us all about loss of carrier and OAM. He also gives us a tutorial on how the rest of... Read more »

One dark day, Ivan Pepelnjak stopped labbing. He just couldn't make himself yet again go through assigning addresses, building links, putting devices in place, setting up OSPF, BGP, VXLAN, EVPN, etc. before even being able to start whatever simulation or test he wanted to do. But from that darkness arose netlab. Ivan created netlab to... Read more »

One dark day, Ivan Pepelnjak stopped labbing. He just couldn't make himself yet again go through assigning addresses, building links, putting devices in place, setting up OSPF, BGP, VXLAN, EVPN, etc. before even being able to start whatever simulation or test he wanted to do. But from that darkness arose netlab. Ivan created netlab to... Read more »

One dark day, Ivan Pepelnjak stopped labbing. He just couldn't make himself yet again go through assigning addresses, building links, putting devices in place, setting up OSPF, BGP, VXLAN, EVPN, etc. before even being able to start whatever simulation or test he wanted to do. But from that darkness arose netlab. Ivan created netlab to... Read more »

Blog: https://medium.com/asecuritysite-when-bob-met-alice/one-of-the-greatest-protocols-and-one-of-the-greatest-weaknesses-of-the-internet-meet-the-d8201a1e6e80 So the Internet isn't the large-scale distributed network that DARPA tried to create, and which could withstand a nuclear strike on any part of it. At its core is a centralised infrastructure of routing devices and of centralised Internet services. The protocols its uses are basically just the ones that were drafted when we connected to mainframe computers from dumb terminals. Overall, though, a single glitch in its core infrastructure can bring the whole thing crashing to the floor. And then if you can't get connected to the network, you often will struggle to fix it. A bit like trying to fix your car, when you have locked yourself out, and don't have the key to get in. As BGP still provides a good part of the core of the Internet, any problems with it can cause large scale outages. Recently Facebook took themselves off the Internet due to a BGP configuration errors, and there have been multiple times when Internet traffic has been “tricked” to take routes through countries which do not have a good track record for privacy. BGP does the core of routing on the Internet, works by defining autonomous systems (AS). The ASs are identified with an ASN (Autonomous System Number) and keep routing tables which allows the ASs to pass data packets between themselves, and thus route between them. Thus the Facebook AS can advertise to other AS's that it exists and that packets can be routed to them. When the Facebook outage happened, the Facebook AS failed to advertise its presence. Each AS then defines the network ranges that they can reach. Facebook's ASN is AS32935 and covers around 270,000 IP address ranges [here]. What is BGP? The two main interdomain routing protocols in recent history are EGP (Exterior Gateway Protocol) and BGP (Border Gateway Protocol). EGP suffers from several limitations, and its principal one is that it treats the Internet as a tree-like structure, as illustrated in Figure 1. This assumes that the structure of the Internet is made up of parents and children, with a single backbone. A more typical topology for the Internet is illustrated in Figure 2. BGP is now one of the most widely accepted exterior routing protocol, and has largely replaced EGP. Figure 1: Single backbone — Tree-like topology Figure 2: Multiple backbones BGP is an improvement on EGP (the fourth version of BGP is known as BGP-4), and is defined in RFC1772. Unfortunately it is more complex than EGP, but not as complex as OSPF. BGP assumes that the Internet is made up of an arbitrarily interconnected set of nodes. It then assumes the Internet connects to a number of AANs (autonomously attached networks), as illustrated in Figure 3, which create boundaries around organizations, Internet service providers, and so on. It then assumes that, once they are in the AAN, the packets will be properly routed. Figure 3: Autonomously attached networks Most routing algorithms try to find the quickest way through the network, whereas BGP tries to find any path through the network. Thus, the main goal is reachability instead of the number of hops to the destination. So finding a path which is nearly optimal is a good achievement. The AAN administrator selects at least one node to be a BGP speaker and also one or more border gateways. These gateways simply route the packet into and out of the AAN. The border gateways are the routers through which packets reach the AAN. The speaker on the AAN broadcasts its reachability information to all the networks within its AAN. This information states only whether a destination AAN can be reached; it does not describe any other metrics. An important point is that BGP is not a distance-vector or link state protocol because it transmits complete routing information instead of partial information. The BGP update packet also contains information on routes which cannot be reached (withdrawn routes), and the content of the BGP-4 update packet is: Unfeasible routes length (2 bytes). Withdrawn routes (variable length). Total path attribute length (2 bytes). Path attributes (variable length). Network layer reachability information (variable length). This can contain extra information, such as ‘use AAN 1 in preference to AAN 2'. Routers within AS's share similar routing policies, and thus operate as a single administrative unit. All the routers outside the AS treat the AS as a single unit. The AS identification number is assigned by the Internet Assigned Numbers Authority (IANA) in the range of 1 to 65,535, where 64,512 to 65,535 are reserved for private use. The private numbers are only used within private domain, and must be translated to registered numbers when leaving the domain. BGP and routing loops BGP uses TCP segments on port 179 to send routing information (whereas RIP uses port 520). BGP overcomes routing loops by constructing a graph of autonomous systems, based on the information provided by exchanging information between neighbors. It can thus build up a wider picture of the entire interconnected ASs. A keep-alive message is send between neighbours, which allows the graph to be kept up-to-date. Single-homed systems ASs which have only one exit point are defined as single-homed systems, and are often referred to as stub networks. These stubs can use a default route to handle all the network traffic destined for non-local networks. There are three methods that an AS can use so that the outside world can learn the addresses within the AS: Static configuration. For this, an Internet access provider could list the customer's networks as static entries within its own router. These would then be advertised to other routers connected to its Internet core. This approach could also be used with a CIDR approach which aggregates the routes. Use an Interior Gateway Protocol (IGP) on the link. For this, an Internet access provider could run a IGP on the single connection, this can then be used to advertise the connected networks. This method allows for a more dynamic approach, than static configuration. A typical IGP is OSPF. Use an Exterior Gateway Protocol (EGP) on the link. An EGP can be used to advertise the networks. If the connected AS does not have a registered AS, the Internet access provider can assign it from a private pool of AS numbers (64,512 to 65,535), and then strip off the numbers when advertising the AS to the core of the Internet. Multihomed system A multi-homed system has more than one exit point from the AS. As it has more than one exit point, it could support the routing of data across the exit points. A system which does not support the routing of traffic through the AS is named a non-transit AS. Non-transit ASs thus will only advertise its own routes to the Internet access providers, as it does not want any routing through it. One Internet provider could force traffic through the AS if it knows that routing through the AS is possible. To overcome this, the AS would setup filtering to stop any of this routed traffic. Multi-homed transit systems have more than one connection to an Internet access provider, and also allow traffic to be routed through it. It will route this traffic by running BGP internally so that multiple border routers in the same AS can share BGP information. Along with this, routers can forward BGP information from one border router to another. BGP running inside the AS is named Internet BGP (IBGP), while it is known as External BGP (EBGP) if it is running outside AS's. The routers which define the boundary between the AS and the Internet access provider is known as border routers, while routers running internal BGP are known as transit routers. BGP specification Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol (exterior routing protocol), which builds on EGP. The main function of a BGP-based system is to communicate network reachability information with other BGP systems. Initially two systems exchange messages to open and confirm the connection parameters, and then transmit the entire BGP routing table. After this, incremental updates are sent as the routing tables change. Each message has a fixed-size header and may or may not be followed a data portion. The fields are: Marker. Contains a value that the receiver of the message can predict. It can be used to detect a loss of synchronization between a pair of BGP peers, and to authenticate incoming BGP messages. 16 bytes. Length. Indicates the total length, in bytes, of the message, including the header. It must always be greater than 18 and no greater than 4096. 2 bytes. Type. Indicates the type of message, such as 1 — OPEN, 2 — UPDATE, 3 — NOTIFICATION and 4 — KEEPALIVE. OPEN message The OPEN message is the first message sent after a connection has been made. A KEEPALIVE message is sent back confirming the OPEN message. After this the UPDATE, KEEPALIVE, and NOTIFICATION messages can be exchanged. Figure 4 shows the extra information added to the fixed-size BGP header. It has the following fields: Version. Indicates the protocol version number of the message. Typical values are 2, 3 or 4. 1 byte. My Autonomous System. Identifies the sender's Autonomous System number. 2 bytes. Hold Time. Indicates the maximum number of seconds that can elapse between the receipt of successive KEEPALIVE and/or UPDATE and/or NOTIFICATION messages. 2 bytes. Authentication Code. Indicates the authentication mechanism being used. This should define the form and meaning of the Authentication Data and the algorithm for computing values of Marker fields. Authentication Data. The form and meaning of this field is a variable-length field which depends on the Authentication Code. Figure 4: BGP message header and BGP OPEN message data BGP configuration BGP configuration commands are similar to those used for RIP (Routing Internet Protocol). To configure the router to support BGP the following commands is used: RouterA # config tRouterA(config)# router bgp AS-number With IGP's, such as RIP, the network command defined the networks on which routing table update are sent. For BGP a different approach is used to define the relationship between networks. This is [here]: RouterA # config tRouterA(config) # router bgp AS-numberRouter(config-router)# network network-number [mask network-mask] where the network command defines where to advertise the locally learnt networks. These networks could have been learnt from other protocols, such as RIP. An optional mask can be used with the network command to specify individual subnets. With the BGP protocol neiphbors must establish a relationship, for this the following is used: RouterA # config tRouterA(config) #router bgp AS-numberRouter(config-router)#network network-number [mask network-mask]Router(config-router)# neighbor ip-address remote-as AS-number which defines the IP address of a connected BGP-based router, along with its AS number. Conclusions At its core, the Internet is not a decentralised infrastructure. It is fragile and open to human error and adversarial attacks. Too much of our time is spent on making our services work and very little on making them robust. We need to spend more time looking at scenarios and how to mitigate them. Previously it was Facebook taking themselves offline, the next time it could be a nation-state bring down a whole country … and that it is likely to have a devastating effect. Now … I have setup more Cisco challenges for BGP for you, so go and learn more about BGP configuration here: https://asecuritysite.com/cisco/bgp

You're a one-person wrecking crew. You rock your compute infrastructure, your hypervisor and virtual machine management system, and your storage subsystems, but you'll admit, you could use some help with the networking side every once in a while.  In fact, every now and again, something happens on the network and you never can quite get to the root of it; you rebooted a device and that ended up fixing it ninety nine times out of a hundred.  Let's not talk about that one-hundredth time - that was a doozy and turned out to be an obscure setting, or a malfunctioning printer or client system.  Either way, it sure would be nice to know, for certain, if you could make things better, permanently. Or… Maybe you're at a large organization; perhaps even in the networking and security arm of an I.T. group, but somebody new starts and as you look over the documentation, you realize it's terribly out of date.  It would be a great exercise to map everything out and update the records and create diagrams in addition to mentoring the new person, but there's just not enough hours in the day to do both.  Or…is there a way you could? Welcome back to another episode of your favorite I.T. podcast with a healthy dose of empathy, Data Center Therapy.  Your hosts, as always, include the gregarious and well-travelled Mr. Matt “Traffic Shaping the T1 with Napster” Yette as well as the multi-talented and tenured Mr. Matt “Hospitals don't have change control windows!” Cozzolino.  In this edition, the Matts welcome IVOXY Director of Consulting and O.G. of the Networking Practice, Mr. Mack “Channel Surfing” Nethkin as well as the newest IVOXY Senior Network Consultant, Mr. Robert “Pain is just Weakness leaving the Network” Clack. If terms like STP, HSRP, VRRP, BGP, OSPF, and Dynamic Routing get your motor running, great.  If it's all Greek to you, that's A-OK - in fact, you'll likely pick up a few new network terms while giving this one a listen. When listening to this latest episode, you, our grateful listeners will hear tales of: Mack's experiences at Alaska Airlines and how those experiences shaped the practices he advocates for (including good switch names) and things he looks for when delivering network assessments for customers. The various sections of a typical network assessment, and what are included in those sections (including infrastructure, availability, management, performance and security elements, all to paint a more complete picture!) How network assessments are performed (and yes, there are diagrams!), the red/yellow/green light methodologies, but also more importantly, the why of the assessment - and why those reasons matter to businesses. Please be sure to like, share and subscribe wherever you found this podcast and stay tuned to our show to learn about our upcoming training courses, including a second round of Matt Cozzolino's Advanced vSphere 8 class.  Catch you on the next jam-packed episode of Data Center Therapy - and stay safe, assess your stacks or get some help assessing them, and as always, stay informed, DCT friends!

In this episode we are going to look at Single-Area OSPFv2 Configuration.We are helping a network engineer test an OSPF set up by building the network in the lab where you work. We have interconnected the devices and configured the interfaces and have connectivity within the local LANs. Our job is to complete the OSPF configuration according to the requirements left by the engineer.Use the information provided and the list of requirements to configure the test network. When the task has been successfully completed, all hosts should be able to ping the internet server.We will be discussing Implement single-area OSPFv2 in both point-to-point and broadcast multiaccess networks.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Configuration Examples for Enterprise Networking, Security, and Automation v3 (ENSA)Single-Area OSPFv2 ConfigurationLab 2.7.1 - Single-Area OSPFv2 ConfigurationPodcast Number: 67Season: 1-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment 

In this episode we are going to look at Verify Single-Area OSPFv2.We are the network administrator for a branch office of a larger organization. Our branch is adding a new wireless network into an existing branch office LAN. The existing network is configured to exchange routes using OSPFv2 in a single-area configuration. Our task is to verify the operation of the existing OSPFv2 network, before adding in the new LAN. When we are sure that the current OSPFv2 LAN is operating correctly, we will connect the new LAN and verify that OSPF routes are being propagated for the new LAN. As branch office network administrator, we have full access to the IOS on routers R3 and R4. We only have read access to the enterprise LAN routers R1 and R2, using the username BranchAdmin, and the password Branch1234.We will be discussing the CLI commands to verify the operation of an existing OSPFv2 network. In Part 2, we will add a new LAN to the configuration and verify connectivity, identify and verify the status of OSPF neighbors, determine how the routes are being learned in the network, explain how the neighbor state is determined, examine the settings for the OSPF process ID, and finally add a new LAN into an existing OSPF network and verify connectivity.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Configuration Examples for Enterprise Networking, Security, and Automation v3 (ENSA)Single-Area OSPFv2 ConfigurationLab 2.6.6 - Verify Single-Area OSPFv2Podcast Number: 66Season: 1-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment 

In this episode we are going to look at Propagate a Default Route in OSPFv2.In this activity, we will configure an IPv4 default route to the Internet and propagate that default route to other OSPF routers. We will then verify the default route is in downstream routing tables and that hosts can now access a web server on the Internet.We will be discussing Propagating a Default Route and Verifying Connectivity.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Configuration Examples for Enterprise Networking, Security, and Automation v3 (ENSA)Single-Area OSPFv2 ConfigurationLab 2.5.3 - Propagate a Default Route in OSPFv2Podcast Number: 65Season: 1-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment 

In this episode we are going to look at configuring Modify Single-Area OSPFv2.In this activity, OSPF is already configured and all end devices currently have full connectivity. We will modify the default OSPF routing configurations by changing the hello and dead timers and adjusting the bandwidth of a link. Then we will verify that full connectivity is restored for all end devices. We will be Modifying OSPF Default Settings and Verifying Connectivity.Thank you so much for watching this episode of my series on Configuration Examples for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.comYouTube Channel: https://YouTube.com/KevTechify-------------------------------------------------------Cisco Certified Network Associate (CCNA)Configuration Examples for Enterprise Networking, Security, and Automation v3 (ENSA)Single-Area OSPFv2 ConfigurationLab 2.4.11 - Modify Single-Area OSPFv2Podcast Number: 64Season: 1-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment 

In this episode we are going to look at configuring Point-to-Point Single-Area OSPFv2 Configuration.In this activity, we will activate OSPF routing using network statements and wildcard masks, configuring OSPF routing on interfaces, and by using network statements quad-zero masks. In addition, we will configure explicit router IDs and passive interfaces. We will be Configuring Router IDs, Configuring Networks for OSPF Routing, Configuring Passive Interfaces, and Verifying OSPF configuration.Thank you so much for watching this episode of my series on Configuration Examples for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.comYouTube Channel: https://YouTube.com/KevTechify-------------------------------------------------------Cisco Certified Network Associate (CCNA)Configuration Examples for Enterprise Networking, Security, and Automation v3 (ENSA)Single-Area OSPFv2 ConfigurationLab 2.2.13 - Point-to-Point Single-Area OSPFv2 ConfigurationPodcast Number: 62Season: 1-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment 

CCNA v7: Practical Configuration ExamplesThe fourth series on the CCNA.Hi Everyone and welcome to my Tech Heads in the KevTechify Nation.Thanks to new technologies, networks are becoming more intelligent, programmable and software-driven. This series support this evolution and will expose you to new concepts and experiences. Best of all, this series is tied to CCNA certifications.In this series, Practical Configuration Examples, I'll demonstrate and explain many of the concepts of the CCNA. I'll use actual configuration to demonstrate these. I'll work through practical examples of how to use these technologies and concepts. I'll enter the commands and explain what and why I am doing the thing I am doing. We'll start with basic device configuration, then look at addressing, VLANs, Router-on-a-Stick, basic security, Wireless configuration, routing protocols like OSPF, Access Control Lists, Network Address Translation, network management, and finally network troubleshooting.Begin preparing for a networking career with this series on Practical Configuration Examples. This is my fourth series on the CCNA. It will introduce and demonstrate how to apply and use the concepts of the CCNA. Recommended preparation for this series is my other series on the CCNA.I'm Kevin. I am a seasoned and experienced IT professional with over 20 years of experience in network administration, IT consulting, and adult technical education. I have a primary focus on being a Solutions Architect. I enjoy the challenge of finding innovative and practical solutions for IT projects. I have been involved with extensive practical implementations in a variety of technical and operational capacities including research and development, business strategies, project management, and process analysis for clients requiring a wide variety of technology-based solutions.I also enjoy being a Technology Mentor. With a focus on certified technical training, I can be found either in a classroom environment instructing on network infrastructure and network services; or developing dynamic and engaging training materials. I hold several technology and instructor certifications from multiple vendors, including Microsoft, Cisco, Google, CompTIA, DELL Compellent Storage Area Networks, and Amazon Web Services.KevTechify is my approach to blend my knowledge and experiences with dynamic and engaging training materials. A new approach to learning technology to make you a better and a more in-demand IT professional.Once again, I'm Kevin here at KevTechify. Let's get this series and adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)                                                                    Configuration Examples for Introduction to Networks v1 (ITN)IntroLab 0 - IntroductionLab Number: 0Pod Number: 0-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment 

The FR Routing project is a fully featured open-source routing stack, including BGP, OSPF, and IS-Is (among others), supported by a community including NVDIA, Orange, VMWare, and many others. On today's episode of the Hedge, Tom Ammon and Russ White are joined by Donald Sharp, Alistair Woodman, and Quentin Young to update listeners on projects completed and underway in FR Routing.

In this episode we are going to look at Multiaccess OSPF Networks.We will be discussing OSPF Network Types, OSPF Designated Router, OSPF Multiaccess Reference Topology, Verify OSPF Router Roles, Verify DR/BDR Adjacencies, Default DR/BDR Election Process, DR Failure and Recovery, The ip ospf priority Command, and Configure OSPF Priority.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Enterprise Networking, Security, and Automation v3Episode 2 - Single-Area OSPFv2 ConfigurationPart C - Multiaccess OSPF NetworksPodcast Number: 6-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment  

In this episode we are going to look at Point-to-Point OSPF Networks.We will be discussing The network Command Syntax, The Wildcard Mask, Configure OSPF Using the network Command, Configure OSPF Using the ip ospf Command, Passive Interface, Configure Passive Interfaces, OSPF Point-to-Point Networks, and Loopbacks and Point-to-Point Networks.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Enterprise Networking, Security, and Automation v3Episode 2 - Single-Area OSPFv2 ConfigurationPart B - Point-to-Point OSPF NetworksPodcast Number: 5-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment  

In this episode we are going to look at OSPF Router ID.We will be discussing OSPF Reference Topology, Router Configuration Mode for OSPF, Router IDs, Router ID Order of Precedence, Configure a Loopback Interface as the Router ID, Explicitly Configure a Router ID, and Modify a Router ID.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Enterprise Networking, Security, and Automation v3Episode 2 - Single-Area OSPFv2 ConfigurationPart A - OSPF Router IDPodcast Number: 4-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment  

In this episode we are going to look at OSPF Operation.We will be discussing OSPF Operational States, Establish Neighbor Adjacencies, Synchronizing OSPF Databases, and The Need for a DR, LSA Flooding With a DR.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Enterprise Networking, Security, and Automation v3Episode 1 - Single-Area OSPFv2 ConceptsPart C - OSPF OperationPodcast Number: 3-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment  

In this episode we are going to look at OSPF Packets.We will be discussing Types of OSPF Packets, Link-State Updates, and Hello Packet.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Enterprise Networking, Security, and Automation v3Episode 1 - Single-Area OSPFv2 ConceptsPart B - OSPF PacketsPodcast Number: 2-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment  

In this episode we are going to look at OSPF Features and Characteristics.We will be discussing Introduction to OSPF, Components of OSPF, Link-State Operation, Single-Area and Multiarea OSPF, Multiarea OSPF, and OSPFv3.Thank you so much for listening to this episode of my series on Enterprise Networking, Security, and Automation for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.com-------------------------------------------------------Cisco Certified Network Associate (CCNA)Enterprise Networking, Security, and Automation v3Episode 1 - Single-Area OSPFv2 ConceptsPart A - OSPF Features and CharacteristicsPodcast Number: 1-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment  

About Serena Serena is a Network Engineer who specializes in Data Center Compute and Virtualization. She has degrees in Computer Information Systems with a concentration on networking and information security and is currently pursuing a master's in Data Center Systems Engineering. She is most known for her content on TikTok and Twitter as Shenetworks. Serena's content focuses on networking and security for beginners which has included popular videos on bug bounties, switch spoofing, VLAN hoping, and passing the Security+ certification in 24 hours.Links: TikTok: https://www.tiktok.com/@shenetworks Twitter: https://twitter.com/notshenetworks?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key, or a shared admin account, isn't going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And not, that is not me telling you to go away, it is: goteleport.com.Corey: This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database that is not the bind DNS server. If you're tired of managing open source Redis on your own, or you're using one of the vanilla cloud caching services, these folks have you covered with the go to manage Redis service for global caching and primary database capabilities; Redis Enterprise. To learn more and deploy not only a cache but a single operational data platform for one Redis experience, visit redis.com/hero. Thats r-e-d-i-s.com/hero. And my thanks to my friends at Redis for sponsoring my ridiculous non-sense.  Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Once upon a time, I was a grumpy Unix systems administrator—because it's not like there's a second kind of Unix systems administrator—then I decided it was time to get better at the networking piece, so I got a CCNA one year. Did this make me a competent network engineer? Absolutely not. But it made me a slightly better systems person.My guest today is coming from the other side of the world, specifically someone who is, in fact, good at the networking things. Serena—or @SheNetworks as you might know her from TikTok or @notshenetworks from the Twitters—thank you for joining me, I appreciate your time.Serena: Yeah, thanks for inviting me on.Corey: So, at a very high level, you are a network engineer, and you specialize in data center compute and virtualization, which is fun because I remember doing a lot of that once upon a time before I went basically all in on Cloud consulting, and then sort of forgot that data centers existed. That's still a thing that's still going well, and there are computers out there that don't belong to what are the three biggest tech companies in the world?Serena: Yeah. Shockingly, there's still a ton of data centers out there, still a lot of private hosting, and a lot of the environments that we see are mixed environment; they will have some cloud, some on-prem. But yes, data centers are still relevant. [laugh].Corey: On some level, it feels like once you get into the world of cloud, you don't have to really think about networking anymore. You know, until there's a big outage, and suddenly everyone had think about the networks. But it also feels like it is abstractions piled upon abstractions in the cloud infrastructure space. How much of what happens in data centers these days maps to what happens in these hyperscaler provider environments?Serena: That's a good question. I think—so I have two CCNAs; I'm very familiar with networking, I'm very familiar with virtualization, and I went and got my AWS certification because as we're talking about a lot of cloud things happening now, it's big, it's good to know about it. And underlying infrastructure under the cloud is all the data centers that I work with, all the networking things that I work with. So, it maps very well to me. I thought I had, like, a really easy time studying for my AWS certification because a lot of the concepts just had, like, a different fancy name for AWS versus just what you know, as, like, NAT, or, you know, DNS, different things like that.Corey: Of course, NAT used to be a thing that was—everyone would yell at you, “It's not security,” even though there are—I would argue there are security elements tied into it. But honestly, that feels like one of the best ways to pick fights with people who are way better at this than I am. Nowadays, of course, I just view NAT through a lens of, “Yeah, I totally want to pay an extra four-and-a-half cents per gigabyte passing through a managed NAT gateway,” which remains, of course, my nemesis. The intersection of security, networking, and billing leads to basically just being very angry all the time.Serena: Yeah. You come into the field, like, so ready to go, and then sometimes you do get beat down. But it's worth it, I think. I really like what I do.Corey: And what you do is something of an anomaly because most people who focus on this world of data center networking and the security aspects thereof, and the virtualization stuff, are all—how do I put it politely?—old, grumpy and unpleasant. I mean, I guess I'm not going to put it politely because I'm just going to be honest with it. Because I'm one of those people, let's be clear here. Instead, you are creating a whole bunch of content on Twitter and on TikTok, where I've got to say that the union set in the Venn diagram between TikTok and deep-dive networking and cybersecurity is basically you. How did you get there?Serena: That's a really good question. To your first point, the, you know, old grumpy, kind of, stereotype, those are honestly some of my favorite people, truly, because I don't know what it is, but I just vibe with them in a work environment so well. And it's funny, you know, when I got my first job out of college, I was definitely the youngest person on my team by far. And we would all go out to lunch, I would mess with all of them, we'd all play pranks on each other. Just integrating into the teams was always super easy for me, which I'm really lucky that—not everybody has that experience, especially in their first job; things are a little rough.But it's always great. Like, I love the diversity in tech. And to your second point, how did I end up here, right, with this kind of intersection from this networking world to TikTok? People are always confused. Like, how did that happen? How are you finding followers on TikTok that are interested in networking?And I'm just as shocked honestly. [laugh]. I started making this content this time last year, and… you know, at first I was like, nobody wants to learn about DNS on TikTok. This is where people dance and play pranks and all this stuff.Corey: And if there's dancing when it comes to DNS, at some point, something has gone other hilarious or terrifyingly. That again, I use it as a database, so who am I to talk?Serena: [laugh]. Yeah, but it's been fun. I am shocked. But there's such a wide variety of people now using TikTok and it's growing so quickly. Early on in my TikTok career, I had messages and emails from people who are vice presidents at major Fortune 100 companies asking me, you know, if I'd be interested in working there or, you know, something like that, and I was just—I was so shocked because there was a company that was a Fortune 100, and one of their VPs joined one of my Lives, and was asking me questions, just about, like, my background career, and then they sent me a follow up email [laugh] to be like, “Hey.”So, I was like, “Did I just get interviewed on my Live on TikTok?” And that they always, like, cracked me up. And at that point, I knew I was like, okay, this is something different; like, this is interesting. Because, you know, at the end of the day, you see the views and the numbers and the followers, but you don't have, really, faces to put to them or names, and you don't really know where a lot of these people are from, so you don't know who's seeing it. And a lot of times, I think I made the assumption that they are younger kids. Which is true, but there are also a lot of very seasoned professionals that have been in this field for a very long time that also follow me, and comment on my videos, and add great input and things like that.Corey: There's a giant misunderstanding, I think across the industry, that the executives at the big serious companies, you know, the ones whose mottos may as well be, “That's not funny,” have no personality themselves as people and that they live their entire lives in this corporate bubble where they talk to their kids primarily via I don't know, Microsoft Teams, or WebEx, or something else equally sad. And in practice, that just doesn't work that way. They're human beings, too. And granted, you have to present in certain ways in certain rooms, but the idea that, oh, you're only going to reach developers with attitude problems by having a personality of being on modern platforms. I mean, it's an easy mistake to make.I know this because I spent years making it myself with the nonsense that I do until suddenly people are reaching out and it's, “Huh. You sure did use a lot of high-level strategic terms for a developer.” And you start digging into it, and it's like, “Oh, you're your chief operating officer to giant company. I bet your code is terrible.” Is it? It's like, “Yeah. Turns out, maybe I'm not looking at that through the right lens.” Meeting people where they are with engaging content is important, and I think that a lot of folks completely miss that bus.Serena: Yeah, I agree. And this is a small field, right, so it gets kind of nerve wracking sometimes because sometimes you say things and it's so easy to be like, this is how I joke with my friends. But I'm still somewhat in a professional capacity because of me associating with my career, right? And then when my videos reach a million, half-a-million views, when we think about how many people are actually in this field that would be interested in viewing that content, you realize, oh, wow. Like, this is a huge mixed bag of people, which does include very high level executives, all the way to people that are in high school that are just interested in learning more. So, it's definitely been interesting to figure that out along the way. [laugh]. But yeah, they will have regular personalities. They all like TikTok too. If they don't, they're lying. [laugh].Corey: I used to be very down on the whole TikTok thing, but I started experimenting with it. And yeah, it turns out I have a face for radio and, you know, the social graces for Twitter. So, it's not really my cup of tea, but I enjoy watching it. I found that I'm not really a video person, but something about the TikTok format means I'm just going to start scrolling. And oh, dear, it's been six hours and my phone battery died. Thank God, or I'd still be there. There's something very captivating about it and I really like the format.The problem I always had with looking at a lot of the deeply technical content out there is so many companies are out there producing this and selling this. And that's fine. Like, money is not the end all, be all [of this 00:09:40]. I'm about to spend weeks of my life on something, the fact that it cost me 30 or 50 bucks or whatnot is really not economic thing I should be concerning myself with. But it all feels like it's classroom stuff. It's if you give people an option, are you going to go to a college lecture or are you going to go to a comedy show? Does the idea of, I want to be entertained. If you can teach me something while entertaining me, that feels like the winning combination, and you've absolutely nailed that.Serena: I think a lot of these companies that are producing content, hold themselves back a lot. And that is why they're not successful, right? Because there's so many stipulations, and there's teams of people, and boardrooms of approvals, and all these things, and me, all I'm doing—I record all my TikToks on my iPhone, and I just use in-app editing. I spend a lot of time kind of researching, right, maybe I will experiment with different formats, but the best format that's worked for me is just being authentic, kind of, not having that corporate vibe, right? And also not really expecting anything in return.So, a lot of times, corporations are putting out content because they obviously want to drive traffic to their websites, and different things like that, but the companies that do the best are the ones that are just putting out content for free, and really not necessarily expecting anything in return. And they also give themselves so much more leeway into the type of content that they create because they're not thinking about the numbers at the end of it, right? You just got to put stuff out there and people will see it. For me, I just put stuff out there, I don't need to wait for someone to approve my TikTok for me to push it out and have this content there. So, that is a big difference.And I've learned that through working with sponsors where they'll send you a giant list of talking points they want you to say and I'm like, “You guys know this is a 60-second video, right?” It needs to be really small. You need to, like, really learn how to get the really important stuff out there because the rest of the smaller stuff doesn't matter as much. Like, sell them on one big thing, and that really makes a difference.Corey: Oh, very much so. I see that sometimes with this show where people will reach out and ask about sponsoring, and they'll want to have a URL that I read into the microphone, and it's with UTM tracking parameters and the rest. And it's, like, “I appreciate where you're coming from and your intention here, however, that is not generally how this format works, so let's talk about this and the outcome.” And again, it's a brave new world out there. Yeah, if you're used to buying display ads in various places, that is exactly what you do.For some reason, there's this corporate mentality toward we're going to spend $25 million on a billboard saturation campaign, and not really give any thought about what we're actually going to say now that we have all of that visual real estate to get people's attention with. It's, there's not enough focus on the message itself, and I think that is a giant lost opportunity. Enterprise marketing doesn't have to be boring, it can be a lot of fun.Serena: I agree. And I think podcasting was the last, probably, big area that people budgeted for marketing, right? So, you have your traditional TV commercials and there was YouTube, and—you know, TV commercials, billboards, newspapers, then there's YouTube, and then podcasts, I would say, probably came a little bit later, as far as these companies look at for marketing potential. And now TikTok is so new and a lot of these marketing companies have no idea how to be successful on it because it's just so different. It's Gen Z, the humor is different.It's kind of like [laugh] the wild west on social media where things are just, like, crazy, and you have to fight the algorithm because on TikTok it's, if you don't like it, you just scroll within three seconds. The attention span is so short. So, you really have to capture people's attention within those first three seconds. Versus a podcast, you have the whole, let's say, first 20 minutes to get people, kind of, interested before you can be like, oh, hey, and here's my sponsor. So, it's very different versus TikTok, they'll just, like, oh, scroll. So, [laugh] you have to get creative and think differently.Corey: Many moons ago, when I was getting my CCNA, I worked at a company where we wound up getting a core switches for the data center, which was at the time, something like 65 grand. Great. And then we rented—because we had configured it in our office—and then a couple of us had to rent a commercial van, which I think ran something like $30,000 itself to transport this thing 20 miles to the data center, and I'm sitting there going, like, “Wow, the switch is worth way more than the van that's sitting within. Also were really shitty movers and that doesn't seem like the best idea for anything.” But I just think they remember that, and it left an impression on me.What I like about cloud with what I do is I can take a credit card and then spend less than $10 on AWS—or theoretically, Azure, or Google Cloud or, you know, $2 million on IBM because oops-a-doozy, but fine—and I wind up coming out the other side of that with having done some interesting disaster stuff. You are teaching people about how this stuff works, but in a data center world, it seems to me that the startup costs of, “Oh, I'm going to buy this random router or switch to wind up doing some demonstration stuff for,” it feels like the startup costs of getting hands on that equipment would be out of reach for an awful lot of people. Am I just completely out of touch with how that world works?Serena: No, you're right, you're one hundred percent, right. It is difficult. So, in college, my undergraduate degree is computer information systems, and they had a Cisco Networking Academy. And so we had old switches, old layer 3 switches, and then we had some routers, and this is all stuff that was EOL, donated equipment, right? And this is going to—Corey: It breaks down you're bidding against very faraway places with no budget on eBay for replacements. Oh, yes.Serena: Yeah, exactly. And it was a lot of IOS stuff, right? And so when I was in college, I had no idea that NX-OS existed, which is the data center Nexus version operating system for their switches and things. And so when I got to my first job and saw NX-OS, I was like, “Oh, crap, [laugh] like, what is this?” Right?Because I honestly didn't even know. I graduated and did not know that existed. And I didn't know a lot of the stuff that I was working on at my first shop existed. And I really had to rely on, kind of, the fundamentals. And they are transferable, right? That's why it's good to kind of get into—like, I know what these routing protocols are. I know, layer 2, I know this cabling, so let me just learn these command differences and things like that.And once you get into a production environment in general, out of a lab, it hits the fan. Like, everything you feel like you've learned is gone almost because there's so many layers and now all of a sudden, you have these firewalls, when before you were just trying to get, like, your routing neighborships to establish [laugh] and you weren't worried about rules on a firewall somewhere. And [crosstalk 00:16:39]—Corey: “Oh, and by the way, in this environment, that link that you're working on goes down, every minute it's down, here is the number of commas in the amount of money that we're losing, and yes, that's a plural.” It's, “Okay, so I guess I'm going to double-check everything I run first.” Yeah, it's that caution that gives people a bit of credence there. [unintelligible 00:16:58] do these things in a, more or less, cowboy style in these environments, at least not for very long. Because you can break individual servers; that's fine, but if you break the network suddenly, you may as well not have the computers.Serena: Yeah. It can be paralyzing, truly. It can be very overwhelming your first networking job. Especially for me, I was just dealing with outages constantly because I worked for a vendor, and I was [laugh] like, I was just scared, you know? Because I would get these cases and it would be a hospital outage.And I'm like, “I just graduated college. Like, what do you want from me?” You know, and back to your original point, it is difficult in a data center space because the equipment's so expensive. So, a lot of people ask, “Do you have a home lab?” And one—there's a couple of reasons I don't really have a significant home lab. One, I move so much.Corey: Oh, and in the spare room basically is always 90 degrees and sounds like a jet engine taking off.Serena: Yeah.Corey: Yeah, it's one of those, I should probably find a different place where I don't live, to have that equipment. Yeah.Serena: Yeah. And I have access, like, remotely to all the lab equipment that I really need. So, I don't personally have one, but a lot of things that I do work with are so expensive, that I'm like, I can't afford to put this data center equipment in my house. That doesn't make any sense.And there is luckily now a lot of virtual labs that you can do. There's some sandboxes by Cisco and other vendors, where you can kind of get a little bit of hands-on experience. A lot of it relates to their certifications. You can rent racks, but that gets pretty pricey, too. So, it is difficult, and sometimes that's why a lot of these jobs, I think I have a lot of people who are looking for entry-level work, and it's hard to get into a specifically a data center space.And aside from racking, stacking, working in a data center—maybe a NOC—if you want to get into the actual,s I'm configuring Nexus switches, I'm configuring, you know, Palo Alto firewalls, it can be difficult because it's hard to get to that point, there's not a clear path.Corey: What is the entry path these days? I entered tech by working on a help desk, and those aren't really the jobs that they once were, in a lot of different ways. So, I've stopped talking to entry-level folks with the position of, “Oh, yeah, this is what you should do because that's what I did.” It turns into, like, “Okay, Boomer. Great job. Tell me a little bit more, though, about what the Great War was like, first.” No, we aren't going to go down that path. It's just I don't know what the entry-level point is for someone who's legitimately interested in these things these days.Serena: Nobody does. It's crazy. And you're right at the, “Okay, Boomer,” thing. See, networking was one of those… things that just got pushed onto people in, just, a general IT department, right? So, that's when everything was like, “Okay, we need to get on the internet, so, you know, hey, you handle some of the computer stuff. It's your job now. Good luck. Figure it out.”And so, people started doing that and they kind of just got pushed into it, and then as the internet grew, as our capabilities grew, then the job became, like, a little bit more specialized. And now we have, you know, dedicated network engineers, we have people running data centers. But that's not necessarily a viable path now for people just because there's so much to it now. There's cloud, there's security risks, there's data center, wireless, pho—I mean, you can be an engineer just for phones, right? So, it's a little bit difficult for, especially, the younger people coming in, and the people that I talk to, and figuring out, well, how do I get to what you're doing?And the way that I did is I went and got a four-year degree and then joined a new college graduate program at a Fortune 100 company. Which is a great path, I highly recommend it to anybody that can do it, but it's also not available for everybody, right, because not everybody has the means to get a four-year education, nor do you necessarily need one to do what I do. So, everybody's kind of has this different path, and it's very confusing for people who are aspiring network engineers, or aspiring cloud engineers, even.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: The narrative the cloud companies have been pushing for a while—like, and I'm in that space deeply enough that I haven't really thought to go super deep into questioning this—is that well, the future is all cloud, the data center is basically this legacy thing that the tide is slowly eroding, in the fullness of time, because everything will one day be cloud. Do you think that's accurate?Serena: I don't. I really don't think that's accurate. Don't get me wrong, I think that the cloud is here to stay, and a lot of people are going to be using it. And it's going to be—and it currently is a huge part of our lives. Like, as we've seen recently with a few of the AWS outages, when it goes down and goes down hard because everything's so centralized.And people like to think, like, oh, you know, we have all this redundancy, yadda, yadda. That has not protected us so far, [laugh] like, from these major outages, right? And a lot of places that I see—especially when you're looking at public sector—is a hybrid, where you do have data center on-prem and you have cloud. And I think that, personally, is the best way to go. Unless, you know, maybe you're a fast growing startup and AWS or Azure makes a lot of sense to you.And it does. There's great use cases for that, right? But they're—not only aside from the whole cloud shift, there's another shift of, you know, making our data centers eco-friendly, too, and workload optimization. So, maybe the price point that you're looking for, what's going to save your business the most money, is doing that hybrid. So, I'm going to store a lot of my private documents on site, I'm going to have this as a backup disaster recovery, but we're also going to operate in the cloud. I don't think that the data centers as we know them are going to go extinct. [laugh]. I think they will be around.Corey: Well, AWS finally made their Outpost—the smaller ones; read as servers that run AWS services on in your facility—available a year after announcing them. And I looked at it like, oh, wow, these things are 600 bucks a month. Which is not nothing, but certainly something I could afford to wind up exploring and doing some content. But okay, first, it's a three-year commitment. So, that's 20 grand or so. Okay, not ideal, but fine.That would effectively almost double my AWS bill, but that's not the hardest part because, oh, and to get one of these, you have to have enterprise support. And when I pointed this out to some Amazonian friends, their response was, “Well, what's the problem on this?” Yeah, enterprise support starts at $15,000 a month minimum, and that means that people aren't going to pick these up to do proof of concept work. They're going to do it when they already have a significant infrastructure out there, and I think that's leaving an awful lot of money on the table by making people jump through sales hoops, and getting proof of concept credits, and doing all the other stuff for this. It's just ship me a box for a few weeks and let me kick the tires on in my environment and see if it works or doesn't work.Worst case, I'll ship it back to you. Worst, worst case, I lose the thing, and then you charge me whatever it costs to replace this. But it still feels like they are really doing the whole, “Oh, it's only big legacy companies that have on-premises stuff.” I don't like that narrative.Serena: I don't either. And I honestly think it's a bad idea, right, because if you do put all of your eggs in the AWS basket and they have all the power, that's not going to give us a lot of bargaining, right? That's not going to give people a lot of—because they'll know. They know how hard it is to get off of AWS at that point: They know it's costly, it takes manpower, it takes knowledge, right? And I think that it is in people's best interest to kind of have that mixed environment. Just for long-term, I'm just very wary of centralizing everything in one area. I think it's a bad idea. [laugh]. I think that we need to be prepared for ourselves, and that means also relying a little bit on ourselves. We can't just, in my opinion, put everything in the AWS basket. [laugh].Corey: Not very long anyway. It just doesn't seem to work.Serena: Right. And it's a great product.Corey: Oh, it absolutely is, but—Serena: There's so many positive things about using cloud. Because I'm not the type of person that likes to, kind of, talk crap about any vendor. I think everybody has their pros, cons, flaws, whatever. It's really about what works best for your environment, and that's part of being a network engineer or an architect is evaluating your environment and figuring out what is going to be the best for you, right? There's no one size fits all, unfortunately.Corey: Yeah. And AWS is uniformly excellent, let's be very clear. Okay, not—maybe not uniformly. Some services are significantly better than others, but I have an opinion piece in the information—paywalled, unfortunately, but I'm working on i—the general thesis that AWS has gotten too big to fail, in that when it's not—like, first, they are going to have better uptime than you or I will running our own data centers, across the board.They are very good at keeping things up, but when they do go down, it's not just your company or my company anymore having an outage, it is a significant portion of, you know, the global economy, and that is an awful lot of systemic concentrated risk. I'm not suggesting they did anything wrong, as far as how they sold these things—though, some people will want to argue with that—but it's the, “What does this mean?” Are we ready to reckon with that as a society that whenever us-east-1 has a bad day, so does the stock market? Is that something we're really prepared to accept or wrangle with? Or worse than that, there are life-critical services now. Does that mean that we're going to accept there is some number of people who will die when there's an outage of a data center? And that's new territory for me. I have not worked in environments where it was life or death consequential. At least not directly.Serena: Yeah, I have. So, I have definitely worked in those environments, right, and it's very scary, and especially when it's outside of your control. So, if you are relying, or just waiting on AWS to get back up, you don't have the control to get in there and start fixing things yourself, which is my instinct, right? Like, I immediately want to get hands-on. I put my troubleshooting hat on, like, let's figure this out, let me look through logs, let me do this.And you don't have that option with AWS when it's a significant outage that's impacting multiple people, it's not some configuration internally to you, right?And that's scary. It's a scary place to be. And I think that we need to really consider the cascading effects that will happen, which a lot of these outages that are kind of starting to show us, right? And luckily, there hasn't been anything major catastrophic, but we do need to really consider life when we're talking about, you know, hospitals, 911 systems, all of these critical infrastructures that are going to be cloud managed, and out of our control, and centralized.So, you know, you lose one 911 system, okay, well, you can do a backup, right? You may be able to route all your calls to the city over because their 911 systems are up and running. Well, what if there's are out now, too, because you're both hosted on AWS?Corey: Or you're, “Ah, we're going to diversify and we're going to have this other one on a different cloud provider.” That's great, but there's a critical third-party dependency that's right back to the thing you're trying to avoid. And there you go again.Serena: Yep. And that's dependency hell, right? [laugh].Corey: Oh, yeah. And I don't know how we get away from that.Serena: Yeah.Corey: Like, we don't want everyone writing all their own stuff from scratch, like starting with assembly, move up the stack. But here we are.Serena: Right. And it's funny because these AWS outages specifically effects—or cloud outages, right? I feel like I'm picking on them. I'm not trying to—sorry, AWS, but [laugh] don't come for me.But you know, explaining to my mom, why her Ring doorbell is not working and her Roomba stopped working when that outage happened, right, she's like, “Why is this not—it won't connect.” Like, “I don't understand.” She's like, “What's AWS?” And then to tell my mom that the company that she buys her socks from, like, that she goes online and, like, buys on Amazon is the company that also is hosting her Roomba, you know, services, her Ring services, it's so interesting to have those conversations. And a lot of people who aren't in our field don't understand that. They don't understand cloud, they don't understand on-prem versus, you know, hosted by a third-party. So, it's interesting to watch that kind of unfold now because it's very new. It's very new territory.Corey: And one last question before we wind up calling it an episode. It is remarkably clear in talking to you that you are in no way, shape, or form, junior. You are not a beginner. You know exactly how this stuff works in significant depth. Your content that you put out is aimed at beginners. I do something very similar. So, to be very clear, this is not a criticism in the slightest, but I am curious as to why that's the direction you went in.Serena: I think there's a few reasons. Well, I might have this knowledge, right? I still consider myself very junior in my career, very early in my career. There's so many things that I don't know and I recognize that. When you're first starting out, you might have this kind of inflated sense of knowledge where you're like—like, me, I was like, “Oh, yeah. I know all about OSPF and running on IOS and the command line,” until I figured out there was an NX-OS and I'm like, “Oh crap, what else do I not know about?” Right? [laugh].Corey: Oh, by the way, that never goes away. I feel exactly the same way 20 years into my career, now. I still have absolutely no idea what I'm doing. So smile, nod, and get used to it is the only insight I've got there. But please, go on.Serena: And even on Twitter sometimes, I'm reading people's stuff, and I'm like, “How did you get into these obscure protocols and all these things?” And, you know, I just kind of dive deeper into there. But I think the big reason that I create a lot of my content for beginners is because I remember so well how it was at the beginning, learning about subnetting, and that IOS—[laugh]—[unintelligible 00:30:52] learning about subnetting, and all of the different models that we have, right? And I was overwhelmed, and I was stressed out, and it just seems so… just, like, a giant mountain to climb. It seems so daunting in the beginning, for me it did because there's so much, right?And it felt like everybody was so far ahead of me. And I don't want other people to really feel like that. Like, I don't want people to be turned off from networking because they feel like the bar is too high, that we're not letting enough new people enter because we're discouraging them from the beginning by saying, “Oh, well, you're going to have to know all this. And let me throw this certification book at you.” And they're big. Like, my certification books—and these are massive. And this is for one half of the CCNA.Corey: For those who aren't, like, on the video call—it's not being recorded video-wise—she's holding a book that you could use to kill a mid-sized dog by accident if it falls off a table. It looks like a phonebook with a hardcover on it.Serena: Yeah. [laugh]. It's huge, right? And there are thousands of pages, and we just give this to somebody and say, like, “Here you go. Make sure you remember all this.” And this is all new information.Corey: And does it still cover things like EIGRP? Like Cisco's proprietary routing protocols that I've never once seen in the wild?Serena: Yeah. So, sometimes you will have to learn that, and they've changed it recently, too. They update their certification exam. So, you will learn about some legacy protocols because sometimes you do run into them.Corey: Oh, yes. That's when I have the good sense to pay professionals who know what they're doing.Serena: [laugh]. Yeah. Exactly. So yeah, you do run into those sometimes. But it feels so daunting for new people, and I totally recognize that. And by nature of TikTok I, especially when I first start making content, I assume that most of the people on there are going to be people who are younger, who are interested in this career.And as you know, in tech in general, especially networking, security, cloud, there's a massive shortage of people, and how are we solving that, right? And my contribution to helping solve that is by getting people interested. And now I have people that DM me and say, “I passed my [Network+ 00:33:01],” or, “I just took the CCNA,” or, “This has been helping me with my class so much.” And that is like, okay, this is great.Like, that's exactly what I want. I want to help the pipeline, I want to get more people interested and help a diverse group of people get interested in tech and say, “Hey, like, this is, you know, where I came from. And I did it; you can do it; let's do it together,” type situation.Corey: I really want to thank you for being so generous with your time. If people want to learn more, as they absolutely should, where can they find you?Serena: I am on TikTok as @SheNetworks. I am on Twitter as @notshenetworks because somebody else—Corey: That is very confusing.Serena: [laugh]. I know. Well, my initial thing was like, I didn't really use Twitter that much, and I would just like—I kind of used it as, like, a backchannel to my TikTok, right, where I would just, like, “Hey, I'm going to go live,” or do this. And then my Twitter, kind of, got a little out of control [laugh] and out of my hands. And so—Corey: It does that sometimes.Serena: Yeah. I had no idea there would be so much interest. And it surprises me every day. So, it's exciting though. I really love all the people that I've met, and I feel like I fit in, and I've met so many good friends that it's been great. But yeah, so @notshenetworks on Twitter because somebody had shenetworks and it was a joke. And [laugh] so if you want to find me there, you could also find me there.Corey: And we will, of course, put links to that in the [show notes 00:34:20]. Thank you so much for taking the time to speak with me today. I really do appreciate it.Serena: Thank you for having me. This has been great. [laugh].Corey: Serena, also known as @SheNetworks, networking content creator to the stars. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice and then a long, angry, rambling comment about how the network isn't that important that you're then not going to be able to submit because the network isn't working.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

About IvanIvan Pepelnjak, CCIE#1354 Emeritus, is an independent network architect, blogger, and webinar author at ipSpace.net. He's been designing and implementing large-scale service provider and enterprise networks as well as teaching and writing books about advanced internetworking technologies since 1990.https://www.ipspace.net/About_Ivan_PepelnjakLinks:ipSpace.net: https://ipspace.net TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by my friends at ThinkstCanary. Most companies find out way too late that they've been breached. ThinksCanary changes this and I love how they do it. Deploy canaries and canary tokens in minutes and then forget about them. What's great is the attackers tip their hand by touching them, giving you one alert, when it matters. I use it myself and I only remember this when I get the weekly update with a “we're still here, so you're aware” from them. It's glorious! There is zero admin overhead  to this, there are effectively no false positives unless I do something foolish. Canaries are deployed and loved on all seven continents. You can check out what people are saying at canary.love. And, their Kub config canary token is new and completely free as well. You can do an awful lot without paying them a dime, which is one of the things I love about them. It is useful stuff and not an, “ohh, I wish I had money.” It is speculator! Take a look; that's canary.love because it's genuinely rare to find a security product that people talk about in terms of love. It really is a unique thing to see. Canary.love. Thank you to ThinkstCanary for their support of my ridiculous, ridiculous non-sense.  Corey: Developers are responsible for more than ever these days. Not just the code they write, but also the containers and cloud infrastructure their apps run on. And a big part of that responsibility is app security — from code to cloud.That's where Snyk comes in. Snyk is a frictionless security platform that meets developers where they are, finding and fixing vulnerabilities right from the CLI, IDEs, repos, and pipelines. And Snyk integrates seamlessly with AWS offerings like CodePipeline, EKS, ECR, etc., etc., etc., you get the picture! Deploy on AWS. Secure with Snyk. Learn more at snyk.io/scream. That's S-N-Y-K-dot-I-O/scream. Because they have not yet purchased a vowel.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I have an interesting and storied career path. I dabbled in security engineering slash InfoSec for a while before I realized that being crappy to people in the community wasn't really my thing; I was a grumpy Unix systems administrator because it's not like there's a second kind of those out there; and I dabbled ever so briefly in the wide world of network administration slash network engineering slash plugging the computers in to make them talk to one another, ideally correctly. But I was always a dabbler. When it comes time to have deep conversations about networking, I immediately tag out and look to an expert. My guest today is one such person. Ivan Pepelnjak is oh so many things. He's a CCIE emeritus, and well, let's start there. Ivan, welcome to the show.Ivan: Thanks for having me. And oh, by the way, I have to tell people that I was a VAX/VMS administrator in those days.Corey: Oh, yes the VAX/VMS world was fascinating. I talked—Ivan: Yes.Corey: —to a company that was finally emulating them on physical cards because that was the only way to get them there. Do you refer to them as VAXen, or VAXes, or how did you wind up referring—Ivan: VAXes.Corey: VAXes. Okay, I was on the other side of that with the inappropriately pluralizing anything that ends with an X with an en—‘boxen' and the rest. And that's why I had no friends for many years.Ivan: You do know what the first VAX was, right?Corey: I do not.Ivan: It was a Swedish Hoover company.Corey: Ooh.Ivan: And they had a trademark dispute with Digital over the name, and then they settled that.Corey: You describe yourself in your bio as a CCIE Emeritus, and you give the number—which is low—number 1354. Now, I've talked about certifications on this show in the context of the modern era, and whether it makes sense to get cloud certifications or not. But this is from a different time. Understand that for many listeners, these stories might be older than you are in some cases, and that's okay. But Cisco at one point, believe it or not, was a shining beacon of the industry, the kind of place that people wanted to work at, and their certification path was no joke.I got my CCNA from them—Cisco Certified Network Administrator—and that was basically a byproduct of learning how networks worked. There are several more tiers beyond that, culminating in the CCIE, which stands for Cisco Certified Internetworking Expert, or am I misremembering?Ivan: No, no, that's it.Corey: Perfect. And that was known as the doctorate of networking in many circles for many years. Back in those days, if you had a CCIE, you are guaranteed to be making an awful lot of money at basically any company you wanted to because you knew how networking—Ivan: In the US.Corey: —worked. Well, in the US. True. There's always the interesting stories of working in places that are trying to go with the lowest bidder for networking gear, and you wind up spending weeks on end trying to figure out why things are breaking intermittently, and only to find out at the end that someone saved 20 bucks by buying cheap patch cables. I digress, and I still have the scars from those.But it was fascinating in those days because there was a lab component of getting those tests. There were constant rumors that in the middle of the night, during the two-day certification exam, they would come in and mess with the lab and things you'd set up—Ivan: That's totally true.Corey: —you'd have to fix it the following day. That is true?Ivan: Yeah. So, in the good old days, when the lab was still physical, they would even turn the connectors around so that they would look like they would be plugged in, but obviously there was no signal coming through. And they would mess up the jumpers on the line cards and all that stuff. So, when you got your broken lab, you really had to work hard, you know, from the physical layer, from the jumpers, and they would mess up your config and everything else. It was, you know, the real deal. The thing you would experience in real world with, uh, underqualified technicians putting stuff together. Let's put it this way.Corey: I don't wish to besmirch our brethren working in the data centers, but having worked with folks who did some hilariously awful things with cabling, and how having been one of those people myself from time to time, it's hard to have sympathy when you just spent hours chasing it down. But to be clear, the CCIE is one of those things where in a certain era, if you're trying to have an argument on the internet with someone about how networks work and their responses, “Well, I'm a CCIE.” Yeah, the conversation was over at that point. I'm not one to appeal to authority on stuff like that very often, but it's the equivalent of arguing about medicine with a practicing doctor. It's the same type of story; it is someone where if they're wrong, it's going to be in the very fringes or the nuances, back in this era. Today, I cannot speak to the quality of CCIEs. I'm not attempting to besmirch any of them. But I'm also not endorsing that certification the way I once did.Ivan: Yeah, well, I totally agree with you. When this became, you know, a mass certification, the reason it became a mass certification is because reseller discounts are tied to reseller status, which is tied to the number of CCIEs they have, it became, you know, this, well, still high-end, but commodity that you simply had to get to remain employed because your employer needed the extra two point discount.Corey: It used to be that the prerequisite for getting the certification was beyond other certifications was, you spent five or six years working on things.Ivan: Well, that was what gave you the experience you needed because in those days, there were no boot camps. Today, you have [crosstalk 00:06:06]—Corey: Now, there's boot camp [crosstalk 00:06:07] things where it's we're going to train you for four straight weeks of nothing but this, teach to the test, and okay.Ivan: Yeah. No, it's even worse, there were rumors that some of these boot camps in some parts of the world that shall remain unnamed, were actually teaching you how to type in the commands from the actual lab.Corey: Even better.Ivan: Yeah. You don't have to think. You don't have to remember. You just have to type in the commands you've learned. You're done.Corey: There's an arc to the value of a certification. It comes out; no one knows what the hell it is. And suddenly it's, great, you can use that to really identify what's great and what isn't. And then it goes at some point down into the point where it becomes commoditized and you need it for partner requirements and the rest. And at that point, it is no longer something that is a reliable signal of anything other than that someone spent some time and/or money.Ivan: Well, are you talking about bachelor degree now?Corey: What—no, I don't have one of those either. I have—Ivan: [laugh].Corey: —an eighth grade education because I'm about as good of an academic as it probably sounds like I am. But the thing that really differentiated in my world, the difference between what I was doing in the network engineering sense, and the things that folks like you who were actually, you know, professionals rather than enthusiastic amateurs took into account was that I was always working inside of the LAN—Local Area Network—inside of a data center. Cool, everything here inside the cage, I can make a talk to each other, I can screw up the switching fabric, et cetera, et cetera. I didn't deal with any of the WAN—Wide Area Network—think ‘internet' in some cases. And at that point, we're talking about things like BGP, or OSPF in some parts of the world, or RIP. Or RIPv2 if you make terrible life choices.But BGP is the routing protocol that more or less powers the internet. At the time of this recording, we're a couple weeks past a BGP… kerfuffle that took Facebook down for a number of hours, during which time the internet was terrific. I wish they could do that more often, in fact; it was almost like a holiday. It was fantastic. I took my elderly relatives out and got them vaccinated. It was glorious.Now, we're back to having Facebook and, terrific. The problem I have whenever something like this happens is there's a whole bunch of crappy explainers out there of, “What is BGP and how might it work?” And people have angry opinions about all of these things. So instead, I prefer to talk to you. Given that you are a networking trainer, you have taught people about these things, you have written books, you have operated large—scale environments—Ivan: I even developed a BGP course for Cisco.Corey: You taught it for Cisco, of all places—Ivan: Yeah. [laugh].Corey: —back when that was impressive, and awesome and not a has-been. It's honestly, I feel like I could go there and still wind up going back in time, and still, it's the same Cisco in some respects: ‘evolve or die dinosaur,' and they got frozen in amber. But let's start at the very beginning. What is BGP?Ivan: Well, you know, when the internet was young, they figured out that we aren't all friends on the internet anymore. And I want to control what I tell you, and you want to control what you tell me. And furthermore, I want to control what I believe from what you're telling me. So, we needed a protocol that would implement policy, where I could say, “I will only announce my customers to you, but not what I've heard from Verizon.” And you will do the same.And then I would say, “Well, but I don't want to hear about that customer of yours because he's also my customer.” So, we need some sort of policy. And so they invented a protocol where you will tell me what you have, I will tell you what I have and then we would both choose what we want to believe and follow those paths to forward traffic. And so BGP was born.Corey: On some level, it seems like it's this faraway thing to people like me because I have a residential internet connection and I am not generally allowed to make my own BGP announcements to the greater world. Even when I was working in data centers, very often the BGP was handled by our upstream provider, or very occasionally by a router they would drop in with the easiest maintenance instructions in the world for me of, “Step one, make sure it has power. Step two, never touch it. Step three, we'd prefer if you don't even look at it and remain at least 20 feet away to keep from bringing your aura near anything we care about.” And that's basically how you should do with me in the context of hardware. So, it was always this arcane magic thing.Ivan: Well, it's not. You know, it's like power transmission: when you know enough about it, it stops being magic. It's technology, it's a bit more complicated than some other stuff. It's way less complicated than some other stuff, like quantum physics, but still, it's so rarely used that it gets this aura of being mysterious. And then of course, everyone starts getting their opinion, particularly the graduates of the Facebook Academy.And yes, it is true that usually BGP would be used between service providers, so whenever, you know, we are big enough to need policy, if you just need one uplink, there is no policy there. You either use the uplink or you don't use the uplink. If you want to have two different links to two different points of presence or to two different service providers, then you're already in the policy land. Do I prefer one provider over the other? Do I want to announce some things to one provider but other things to the other? Do I want to take local customers from both providers because I want to, you know, have lower latency because they are local customers? Or do I want to use one solely as the backup link because I paid so little for that link that I know it's shitty.So, you need all that policy stuff, and to do that, you really need BGP. There is no other routing protocol in the world where you could implement that sort of policy because everything else is concerned mostly with, let's figure out as fast as possible, what is reachable and how to get there. And BGP is like, “Hey, slow down. There's policy.”Corey: Yeah. In the context of someone whose primary interaction with networks is their home internet, where there's a single cable coming in from the outside world, you plug it into a device, maybe yours, maybe ISPs, maybe we don't care. That's sort of the end of it. But think in terms of large interchanges, where there are multiple redundant networks to get from here to somewhere else; which one should traffic go down at any given point in time? Which networks are reachable on the other end of various distant links? That's the sort of problem that BGP is very good at addressing and what it was built for. If you're running BGP internally, in a small network, consider not doing exactly that.Ivan: Well, I've seen two use cases—well, three use cases for people running BGP internally.Corey: Okay, this I want to hear because I was always told, “No touch ‘em.” But you know, I'm about to learn something. That's why I'm talking to you.Ivan: The first one was multinationals who needed policy.Corey: Yes. Many multi-site environments, large-scale companies that have redundant links, they're trying to run full mesh in some cases, or partial mesh where—between a bunch of facilities.Ivan: In this case, it was multiple continents and really expensive transcontinental links. And it was, I don't want to go from Europe to Sydney over US; I want to go over Middle East. And to implement that type of policy, you have to split, you know, the whole network into regions, and then each region is what BGP calls an autonomous system, so that it gets its stack, its autonomous system number and then you can do policy on that saying, “Well, I will not announce Asian routes to Europe through US, or I will make them less preferred so that if the Middle East region goes down, I can still reach Asia through US but preferably, I will not go there.”The second one is yet again, large networks where they had too many prefixes for something like OSPF to carry, and so their OSPF was breaking down and the only way to solve that was to go to something that was designed to scale better, which was BGP.And third one is if you want to implement some of the stuff that was designed for service providers, initially, like, VPNs, layer two or layer three, then BGP becomes this kitchen sink protocol. You know, it's like using Route 53 as a database; we're using BGP to carry any information anyone ever wants to carry around. I'm just waiting for someone to design JSON in BGP RFC and then we are, you know… where we need to be.Corey: I feel on some level, like, BGP gets relatively unfair criticism because the only time it really intrudes on the general awareness is when something has happened and it breaks. This is sort of the quintessential network or systems—or, honestly, computer—type of issue. It's either invisible, or you're getting screamed at because something isn't working. It's almost like a utility. On some level. When you turn on a faucet, you don't wonder whether water is going to come out this time, but if it doesn't, there's hell to pay.Ivan: Unless it's brown.Corey: Well, there is that. Let's stay away from that particular direction; there's a beautiful metaphor, probably involving IBM, if we do. So, the challenge, too, when you look at it is that it's this weird, esoteric thing that isn't super well understood. And as soon as it breaks, everyone wants to know more about it. And then in full on charging to the wrong side of the Dunning-Kruger curve, it's, “Well, that doesn't sound hard. Why are they so bad at it? I would be able to run this better than they could.” I assure you, you can't. This stuff is complicated; it is nuanced; it's difficult. But the common question is, why is this so fragile and able to easily break? I'm going to turn that around. How is it that something that is this esoteric and touches so many different things works as well as it does?Ivan: Yeah, it's a miracle, particularly considering how crappy the things are configured around the world.Corey: There have been periodic outages of sites when some ISP sends out a bad BGP announcement and their upstream doesn't suppress it because hey, you misconfigured things, and suddenly half the internet believes oh, YouTube now lives in this tiny place halfway around the world rather than where it is currently being Anycasted from.Ivan: Called Pakistan, to be precise.Corey: Exact—there was an actual incident there; we are not dunking on Pakistan as an example of a faraway place. No, no, an Pakistani ISP wound up doing exactly this and taking YouTube down for an afternoon a while back. It's a common problem.Ivan: Yeah, the problem was that they tried to stop local users accessing YouTube. And they figured out that, you know, YouTube, is announcing this prefix and if they would announce to more specific prefixes, then you know, they would attract the traffic and the local users wouldn't be able to reach YouTube. Perfect. But that leaked.Corey: If you wind up saying that, all right, the entire internet is available on this interface, and a small network of 256 nodes available on the second interface, the most specific route always wins. That's why the default route or route of last resort is the entire internet. And if you don't know where to send it, throw it down this direction. That is usually, in most home environments, the gateway that then hands it up to your ISP, where they inspect it and do all kinds of fun things to sell ads to you, and then eventually get it to where it's going.This gets complicated at these higher levels. And I have sympathy for the technical aspects of what happened at Facebook; no sympathy whatsoever for the company itself because they basically do far more harm than they do good and I've been very upfront about that. But I want to talk to you as well about something that—people are going to be convinced I'm taking this in my database direction, but I assure you I'm not—DNS. What is the relationship between BGP and DNS? Which sounds like a strange question, sometimes.Ivan: There is none.Corey: Excellent.Ivan: It's just that different large-scale properties decided to implement the global load-balancing global optimal access to their servers in different ways. So, Cloudflare is a typical example of someone who is doing Anycast, they are announcing the same networks, the same prefixes, from hundreds locations around the world. So, BGP will take care that you always get to the close Cloudflare [unintelligible 00:18:46]. And that's it. That's how they work. No magic. Facebook didn't believe in the power of Anycast when they started designing their service. So, what they're doing is they have DNS servers around the world, and the DNS servers serve the local region, if you wish. And that DNS server then decides what facebook.com really stands for. So, if you query for facebook.com, you'll get a different answer in Europe than in US.Corey: Just a slight diversion on what Anycast is. If I ping Google's public resolver 8.8.8.8—easy to remember—from my computer right now, the packet gets there and back in about five milliseconds.Wherever you are listening to this, if you were to try that same thing you'd see something roughly similar. Now, one of two things is happening; either Google has found a way to break the laws of physics and get traffic to a central point faster than light for the 8.8.8.8 that I'm talking to and the one that you are talking to are not in fact the same computer.Ivan: Well, by the way, it's 13 milliseconds for me. And between you and me, it's 200 millisecond. So yes, they are cheating.Corey: Just a little bit. Or unless they tunneled through the earth rather than having to bounce it off of satellites and through cables.Ivan: No, even that wouldn't work.Corey: That's what the quantum computers are for. I always wondered. Now, we know.Ivan: Yeah. They're entangling the replies in advance, and that's how it works. Yeah, you're right.Corey: Please continue. I just wanted to clarify that point because I got that one hilariously wrong once upon a time and was extremely confused for about six months.Ivan: Yeah. It's something that no one ever thinks about unless, you know, you're really running large-scale DNS because honestly, root DNS servers were Anycasted for ages. You think they're like 12 different root DNS servers; in reality, there are, like, 300 instances hidden behind those 12 addresses.Corey: And fun trivia fact; the reason there are 12 addresses is because any more than that would no longer fit within the 512 byte limit of a UDP packet without truncating.Ivan: Thanks for that. I didn't know that.Corey: Of course. Now, EDNS extensions that you go out with a larger [unintelligible 00:21:03], but you can't guarantee that's going to hit. And what happens when you receive a UDP packet—when you receive a DNS result with a truncate flag set on the UDP packet? It is left to the client. It can either use the partial result, or it can try and re-establish over a TCP connection.That is one of those weird trivia questions they love to ask in sysadmin interviews, but it's yeah, fundamentally, if you're doing something that requires the root nameservers, you don't really want to start going down those arcane paths; you want it to just be something that fits in a single packet not require a whole bunch of computational overhead.Ivan: Yeah, and even within those 300 instances, there are multiple servers listening to the same IP address and… incoming packets are just sprayed across those servers, and whichever one gets the packet replies to it. And because it's UDP, it's one packet in one packet out. Problem solved. It all works. People thought that this doesn't work for TCP because, you know, you need a whole session, so you need to establish the session, you send the request, you get the reply, there are acknowledgements, all that stuff.Turns out that there is almost never two ways to get to a certain destination across the internet from you. So, people thought that, you know, this wouldn't work because half of your packets will end in San Francisco, and half of the packets will end in San Jose, for example. Doesn't work that way.Corey: Why not?Ivan: Well, because the global Internet is so diverse that you almost never get two equal cost paths to two different destinations because it would be San Francisco and San Jose announcing 8.8.8.8 and it would be a miracle if you would be sitting just in the middle so that the first packet would go to San Francisco, the second one would go to San Jose, and you know, back and forth. That never happens. That's why Cloudflare makes it work by analysing the same prefix throughout the world.Corey: So, I just learned something new about how routing announcements work, an aspect of BGP, and you a few minutes ago learned something about the UDP size limit and the root name servers. BGP and DNS are two of the oldest protocols in existence. You and I are also decades into our careers. If someone is starting out their career today, working in a cloud-y environment, there are very few network-centric roles because cloud providers handle a lot of this for us. Given these protocols are so foundational to what goes on and they're as old as they are, are we as an industry slash sector slash engineers losing the skills to effectively deploy and manage these things?Ivan: Yes. The same problem that you have in any other sufficiently developed technology area. How many people can build power lines? How many people can write a compiler? How many people can design a new CPU? How many people can design a new motherboard?I mean, when I was 18 years old, I was wire wrapping my own motherboard, with 8-bit processor. You can't do that today. You know, as the technology is evolving and maturing, it's no longer fun, it's no longer sexy, it stops being a hobby, and so it bifurcates into users and people who know about stuff. And it's really hard to bridge the gap from one to the other. So, in the end, you have, like, this 20 [graybeard 00:24:36] people who know everything about the technology, and the youngsters have no idea. And when these people die, don't ask me [laugh] how we'll get any further on.Corey: This episode is sponsored by our friends at CloudAcademy. That's right, they have a different lab challenge up for you called, “Code Red: Repair an AWS Environment with a Linux Bastion Host.” What does it do? Well, its going to assess your ability to troubleshoot AWS networking and security issues in a production like environment. Well, kind of, its not quite like production because some exec is not standing over your shoulder, wetting themselves while screaming. But..ya know, you can pretend in fact I'm reasonably certain you can retain someone specifically for that purpose should you so choose. If you are the first prize winner who completes all four challenges with the fastest time, you'll win a thousand bucks. If you haven't started yet you can still complete all four challenges between now and December 3rd to be eligible for the grand prize. There's only a few days left until the whole thing ends, so I would get on it now. Visit cloudacademy.com/corey. That's cloudacademy.com/C-O-R-E-Y, for god's sake don't drop the “E” that drives me nuts, and thank you again to Cloud Academy for not only promoting my ridiculous non sense but for continuing to help teach people how to work in this ridiculous environment.Corey: On some level, it feels like it's a bit of a down the stack analogy for what happened to me early in my career. My first systems administration job was running a large-scale email system. So, it was a hobby that I was interested in. I basically bluffed my way into working at a university for a year—thanks, Chapman; I appreciate that [laugh]—and it was great, but it was also pretty clear to me that with the rise of things like hosted email, Gmail, and whatnot, it was not going to be the future of what the present day at that point looked like, which was most large companies needed an email administrator. Those jobs were dwindling.Now, if you want to be an email systems administrator, there are maybe a dozen companies or so that can really use that skill set and everyone else just outsources that said, at those companies like Google and Microsoft, there are some incredibly gifted email administrators who are phenomenal at understanding every nuance of this. Do you think that is what we're going to see in the world of running BGP at large scale, where a few companies really need to know how this stuff works and everyone else just sort of smiles, nods and rolls with it?Ivan: Absolutely. We're already there. Because, you know, if I'm an end customer, and I need BGP because I have to uplinks to two ISPs, that's really easy. I mean, there are a few tricks you should follow and hopefully, some of the guardrails will be built into network operating systems so that you will really have to configure explicitly that you want to leak [unintelligible 00:26:15] between Verizon and AT&T, which is great fun if you have too low-speed links to both of them and now you're becoming transit between the two, which did happen to Verizon; that's why I'm mentioning them. Sorry, guys.Anyway, if you are a small guy and you just need two uplinks, and maybe do a bit of policy, that's easy and that's achievable, let's say with some Google and paste, and throwing spaghetti at the wall and seeing what sticks. On the other hand, what the large-scale providers—like for example Facebook because we were talking about them—are doing is, like, light years away. It's like comparing me turning on the light bulb and someone running, you know, nuclear reactor.Corey: Yeah, you kind of want the experts running some aspects on that. Honestly, in my case, you probably want someone more competent flipping the light switch, too. But that's why I have IoT devices here that power my lights, it on the one hand, keeps me from hurting myself on the other leads to a nice seasonal feel because my house is freaking haunted.Ivan: So, coming back to Facebook, they have these DNS servers all around the world and they don't want everyone else to freak out when one of these DNS servers goes away. So, that's why they're using the same IP address for all the DNS servers sitting anywhere in the world. So, the name server for facebook.com is the same worldwide. But it's different machines and they will give you different answers when you ask, “Where is facebook.com?”I will get a European answer, you will get a US answer, someone in Asia will get whatever. And so they're using BGP to advertise the DNS servers to the world so that everyone gets to the closest DNS server. And now it doesn't make sense, right, for the DNS server to say, “Hey, come to European Facebook,” if European Facebook tends to be down. So, if their DNS server discovers that it cannot reach the servers in the data center, it stops advertising itself with BGP.Why would BGP? Because that's the only thing it can do. That's the only protocol where I can tell you, “Hey, I know about this prefix. You really should send the traffic to me.” And that's what happened to Facebook.They bricked their backbone—whatever they did; they never told—and so their DNS server said, “Gee, I can't reach the data center. I better stop announcing that I'm a DNS server because obviously I am disconnected from the rest of Facebook.” And that happens to all DNS servers because, you know, the backbone was bricked. And so they just, you know, [unintelligible 00:29:03] from the internet, they've stopped advertising themselves, and so we thought that there was no DNS server for Facebook. Because no DNS server was able to reach their core, and so all DNS servers were like, “Gee, I better get off this because, you know, I have no clue what's going on.”So, everything was working fine. Everything was there. It's just that they didn't want to talk to us because they couldn't reach the backend servers. And of course, people blamed DNS first because the DNS servers weren't working. Of course they weren't. And then they blame the BGP because it must be BGP if it isn't DNS. But it's like, you know, you're blaming headache and muscle cramps and high fever, but in fact you have flu.Corey: For almost any other company that wasn't Facebook, this would have been a less severe outage just because most companies are interdependent on each other companies to run infrastructure. When Facebook itself has evolved the way that it has, everything that they use internally runs on the same systems, so they wound up almost with a bootstrapping problem. An example of this in more prosaic terms are okay, the data center had a power outage. Okay, now I need to power up all the systems again and the physical servers I'm trying to turn on need to talk to a DNS server to finish booting but the DNS server is a VM that lives on those physical servers. Uh-oh. Now, I'm in trouble. That is a overly simplified and real example of what Facebook encountered trying to get back into this, to my understanding.Ivan: Yes, so it was worse than that. It looks like, you know, even out-of-band management access didn't work, which to me would suggest that out-of-band management was using authentication servers that were down. People couldn't even log to Zoom because Zoom was using single-sign-on based on facebook.com, and facebook.com was down so they couldn't even make Zoom calls or open Google Docs or whatever. There were rumors that there was a certain hardware tool with a rotating blade that was used to get into a data center and unbrick a box. But those rumors were vehemently denied, so who knows?Corey: The idea of having someone trying to physically break into a data center in order to power things back up is hilarious, but it does lead to an interesting question, which is in this world of cloud computing, there are a lot of people in the physical data centers themselves, but they don't have access, in most cases to log into any of the boxes. One of the most naive things I see all the time is, “Oh well, the cloud provider can read all of your data.” No, they can't. These things are audited. And yeah, theoretically, if they're lying outright, and somehow have falsified all of the third-party audit stuff that has been reported and are willing to completely destroy their business when it gets out—and I assure you, it would—yeah, theoretically, that's there. There is an element of trust here. But I've had to answer a couple of journalists questions recently of, “Oh, is AWS going to start scanning all customer content?” No, they physically cannot do it because there are many ways you can configure things where they cannot see it. And that's exactly what we want.Ivan: Yeah, like a disk encryption.Corey: Exactly. Disk encryption, KMS on some level, using—rolling your own, et cetera, et cetera. They use a lot of the same systems we do. The point being, though, is that people in the data centers do not even have logging rights to any of these nodes for the physical machines, in some cases, let alone the customer tenants on top of those things. So, on some level, you wind up with people building these systems that run on top of these computers, and they've never set foot in one of the data centers.That seems ridiculous to me as someone who came up visiting data centers because I had to know where things were when they were working so I could put them back that way when they broke later. But that's not necessary anymore.Ivan: Yeah. And that's the problem that Facebook was facing with that outage because you start believing that certain systems will always work. And when those systems break down, you're totally cut off. And then—oh, there was an article in ACM Queue long while ago where they were discussing, you know, the results of simulated failures, not real ones, and there were hilarious things like phone directory was offline because it wasn't on UPS and so they didn't know whom to call. Or alerts couldn't be diverted to a different data center because the management station for alert configuration was offline because it wasn't on UPS.Or, you know the one, right, where in New York, they placed the gas pump in the basement, and the diesel generators were on the top floor, and the hurricane came in and they had to carry gas manually, all the way up to the top floor because the gas pump in the basement just stopped working. It was flooded. So, they did everything right, just the fuel wouldn't come to the diesel generators.Corey: It's always the stuff that is under the hood on these things that you can't make sense of. One of the biggest things I did when I was evaluating data center sites was I'd get a one-line diagram—which is an electrical layout of the entire facility—great. I talked to the folks running it. Now, let's take a walk and tour it. Hmmm, okay. You show four transformers on your one-line diagram. I see two transformers and two empty concrete pads. It's an aspirational one-line diagram. It's a joke that makes it a one-liner diagram and it's not very funny. So it's, okay if I can't trust you for those little things, that's a problem.Ivan: Yeah, well, I have another funny story like that. We had two power feeds coming into the house plus the diesel generator, and it was, you know, the properly tested every month diesel generator. And then they were doing some maintenance and they told us in advance that they will cut both power feeds at 2 a.m. on a Sunday morning.And guess what? The diesel generator didn't start. Half an hour later UPS was empty, we were totally dead in water with quadruple redundancy because you can't get someone it's 2 a.m. on a Sunday morning to press that button on the diesel generator. In half an hour.Corey: That is unfortunate.Ivan: Yeah, but that's how the world works. [laugh].Corey: So, it's been fantastic reminding myself of some of the things I've forgotten because let's be clear, in working with cloud, a lot of this stuff is completely abstracted away. I don't have to care about most of these things anymore. Now, there's a small team of people that AWS who very much has to care; if they don't, I will say mean things to them on Twitter, if I let my HugOps position slip up just a smidgen. But they do such a good job at this that we don't have problems like this, almost ever, to the point where when it does happen, it's noteworthy. It's been fun talking to you about this just because it's a trip down a memory lane that is a lot more aligned with the things that are there and we tend not to think about them. It's almost a How it's Made episode.Ivan: Yeah. And don't be so relaxed regarding the cloud networking because, you know, if you don't go full serverless with nothing on-premises, you know what protocol you're running between on-premises and the cloud on direct connect? It's called BGP.Corey: Ah. You know, I did not know that. I've done some ridiculous IPsec pairings over those things, and was extremely unhappy for a while afterwards, but I never got to the BGP piece of it. Makes sense.Ivan: Yeah, even over IPsec if you want to have any dynamic failover, or multiple sites, or anything, it's [BP 00:36:56].Corey: I really want to thank you for taking the time to go through all this with me. If people want to learn more about how you view these things, learn more things from you, as I'd strongly recommend they should if they're even slightly interested by the conversation we've had, where can they find you?Ivan: Well, just go to ipspace.net and start exploring. There's the blog with thousands of blog entries, some of them snarkier than others. Then there are, like, 200 webinars, short snippets of a few hours of—Corey: It's like a one man version of re:Invent. My God.Ivan: Yeah, sort of. But I've been working on this for ten years, and they do it every year, so I can't produce the content at their speed. And then there are three different full-blown courses. Some of them are just, you know, the materials from the webinars, plus guest speakers plus hands-on exercises, plus I personally review all the stuff people submit, and they cover data centers, and automation, and public clouds.Corey: Fantastic. And we will, of course, put links to that into the [show notes 00:38:01]. Thank you so much for being so generous with your time. I appreciate it.Ivan: Oh, it's been such a huge pleasure. It's always great talking with you. Thank you.Corey: It really is. Thank you once again. Ivan Pepelnjak network architect and oh so much more. CCIE #1354 Emeritus. And read the bio; it's well worth it. I am Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice and a comment formatted as a RIPv2 announcement.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Learn how to configure Aruba switches. In this video I'll show you how to configure multiple switches using the Aruba CLI. Big thanks to Aruba Networks for sponsoring this video! Menu: Welcome: 0:00 Physical network setup: 0:21 SPFs: 0:42 Fiber break out cables: 1:34 100Gbps DAC cable: 2:59 Server connections (100Gbps): 3:28 Client connection options: 4:31 Console connections: 6:10 Putty setup: 7:25 Login to switch console (8300): 8:25 Check switch interfaces: 9:50 Name core switches: 11:00 show lldp neighbors: 11:18 Routed interfaces and OSPF: 12:42 Split 100Gbps MPO interface: 14:02 Configure access switches (6300M): 16:22 Issue with non Aruba SPFs: 19:15 show lldp neighbors between all switches :20:25 Previous videos: https://davidbombal.wiki/arubanetworks ========================= Free Aruba courses on Udemy: ========================= Security: https://davidbombal.wiki/arubasecurity WiFi: https://davidbombal.wiki/arubamobility Networking: https://davidbombal.wiki/freearubacourse ================================== Free Aruba courses on davidbombal.com ================================== Security: https://davidbombal.wiki/dbarubasecurity WiFi: https://davidbombal.wiki/dbarubamobility Networking: https://davidbombal.wiki/dbarubanetwo... ====================== Aruba discounted courses: ====================== View Aruba CX Switching training options here: https://davidbombal.wiki/arubatraining To register with the 50% off discount enter “DaBomb50” in the discount field at checkout. The following terms & conditions apply: 50% off promo ends 10/31/21 Enter discount code at checkout, credit card payments only (PayPal) Cannot be combined with any other discount. Discount is for training with Aruba Education Services only and is not applicable with training partners. ================ Connect with me: ================ Discord: https://discord.com/invite/usKSyzb Twitter: https://www.twitter.com/davidbombal Instagram: https://www.instagram.com/davidbombal LinkedIn: https://www.linkedin.com/in/davidbombal Facebook: https://www.facebook.com/davidbombal.co TikTok: http://tiktok.com/@davidbombal YouTube: https://www.youtube.com/davidbombal aruba aruba-cx aruba cx aruba app aruba-cx app aruba iphone aruba android aruba 8360 aruba 6300 aruba networks aruba networking abc networking aruba 6300m aruba instant one hpe hp hpe networking aruba mobility aruba security training free aruba training clearpass clearpass training hpe training free aruba clearpass training aruba networking aruba networks abc networking Please note that links listed may be affiliate links and provide me with a small percentage/kickback should you use them to purchase any of the items listed or recommended. Thank you for supporting me and this channel! #arubanetworks #aruba #arubacx

我們藉由一個連接三個辦公室，三個網段的簡單拓樸，來說明連接辦公室網路，維護正確的路由表內容的時候，到底應該使用靜態路由，還是多多運用動態路由協定。網路拓樸中，三部路由器，分別代表一個獨立辦公室，背後各只有一個區域網路、LAN網段。圖中每一個區域網路，我只列出一部電腦，來代表網段內的使用者，或者是伺服器。為了聚焦在路由表本身，IP地址已經全部配發完成。電腦上面只有基本網路連接功能。我們的目標是，完全接通三個辦公室中，不同的區域網路，區域網路內的任何電腦、電腦之間，都必須完全連通。路由表的基本知識回顧我們先回顧路由表的基本知識。路由器在轉送每一個封包的時候，一律查詢路由表。封包的目的地地址，如果在路由表中存在定義，那就按照路由表的定義轉送。反過來看，封包的目的地地址，如果在路由表中找不到定義，這個封包就會被直接丟棄。回到三個辦公室的情況。任何從電腦出發的封包，要到達其他辦公室的電腦的話，看完網路拓樸，我們馬上知道，都必須穿越兩次不同的路由器。因此，第一站的路由器裡面的路由表，必須包含兩個遠端辦公室網段的資訊，封包才有機會，被往下一部路由器轉送。事實上，拓樸中的三部路由器，上面的路由表，都必須包含對面遠端兩個辦公室的網段資訊，否則，完全的接通，肯定無法實現。路由表的初始內容接下來，我們觀察路由器上面，路由表的初始內容。初始的路由表的內容，有一些資訊是自動產生的。例如，直接相連的網段。除此之外，全部都必須透過我們的設定，來將缺少的路由表加進來。這樣的初始內容，肯定是不夠的，因此網路連通性，還不存在。所以，我們開始加入缺少的路由表內容。要加入路由表，我們有兩個選擇。靜態路由動態路由協定我們兩者都試試看，先別急著下結論。最後我們再來比較，哪一個工具比較好。加入路由表方法一：使用靜態路由依照剛才分析的結果，我們需要在三部路由器上面，分別透過靜態路由工具，來加入各兩筆的靜態路由資訊。以R1為例子，需要在IP、IPv4分別加入這兩筆：[R1]ip route 10.2.1.0 255.255.255.0 10.0.12.2ip route 10.3.1.0 255.255.255.0 10.0.13.3ipv6 route fd10:2:1::/64 Ethernet1/0 FE80::200:FF:FE12:2ipv6 route fd10:3:1::/64 Ethernet1/1 FE80::200:FF:FE13:3完成之後，「完全接通」這個目標，我們達到了。我們可以透過任意兩部電腦、電腦之間的PING工具，來驗收這個目標。以上的例子，分析過程應該不難理解。只不過，如果只能使用靜態路由，真的很不方便。首先，輸入的時候，靜態路由命令很長，而且隔壁路由器的地址資訊，需要反覆檢查確認。非常容易出錯。我們再觀察下面的兩個狀況，我們會發現，採用靜態路由，來維護路由表，真的很不方便。案例一假設第三號辦公室，需要增加一個網段。請參考網路拓樸。分析的過程差不多，但是，每一部的路由器上面，就必須分別增加一筆第三號辦公室的新網段。我這裡用路由器一來說明。我們必須先檢查目前有的路由表，得知缺少的新網段，然後透過靜態路由命令，來加入這一筆。事實上，路由器二，也必須完成相同的檢查，和確認。如果這樣還不夠讓人感到苦惱，我再加入一個狀況：案例二二號辦公室，要改換網段地址。相同的分析之後，我們發現，我們必須修改，所有路由器上面，跟二號網段相關的所有路由表的內容。我同樣用路由器一來說明。我們必須先檢查目前有的路由表，得知變更了的網段路由表內容，然後透過靜態路由命令，來移除舊的，加入新的這一筆路由表。當然，路由器三也必須完成相同的路由表檢查跟編輯。因此，如果我們只能使用靜態路由這個工具，將會很不方便，沒有彈性，糟糕的是，路由表並不會自動隨著網段地址改變而自動調整。有沒有更好的解決方案？當然是有的。加入路由表方法二：使用動態路由協定我們就挑選OSPF協定，來展示動態路由協定的優勢。我們會發現，OSPF協定的啟動、設定命令，每一部路由器都完全一樣，我們不需要來回檢查確認其他路由器的地址。我們甚至可以用剪貼(copy paste)的方式，一口氣設定完全部的路由器。 router ospf 1 network 0.0.0.0 255.255.255.255 area 7ipv6 router ospf 1int e1/0 ipv6 ospf 1 area 7int e1/1 ipv6 ospf 1 area 7int e2/0 ipv6 ospf 1 area 7int lo0 ipv6 ospf 1 area 7 我們輸入完成之後，接下來，只需要等待協定的交談結果，讓路由器自動幫我們將正確的路由表內容準備好。數秒鐘後，目前的路由表內容，已經是完全正確的。透過動態路由協定，是不是簡單很多呢？同時，前面所提到的兩個案例，動態路由協定，甚至於會幫助我們，自動更新路由表的內容。案例一我們的確必須透過命令，告知路由器三R3，新增加這個網段。除此之外，其他設定，全部不需要改變。路由表自動更新完成。案例二我們甚至於不需要修改任何原有的設定。因此，前面的兩個場景，我們同樣使用OSPF的時候，我們幾乎不需要更動增加設定，路由表就會自動調整過來。結論動態路由協定，可以幫助我們自動找到正確的路由表內容，更棒的是，當網路拓樸改變，路由表的內容，也會自動更新。同時，動態路由協定的命令，通常行數、字數也會比較少。所以，我們必須花時間去學習，類似於OSPF這類型的、自動化的動態路由協定，來幫助我們，用最少的命令，讓路由器自動去探索拓樸，調整路由表的內容。One more thing…只需要透過少數幾行的命令，就可以讓路由器自動維護，完全正確的路由表內容，確保辦公室網路的連通性。是不是既省力，效果也很讓人滿意呢？如果喜歡以上的內容，請訂閱「Cisco學習資訊分享」YouTube頻道。事實上，我們還可以從其他的觀察角度出發，來增加我們網路服務的品質。例如「斷線自動修復」，和「網路遠端管理」，我還沒有討論到。我將放在未來的影片中。歡迎大家開啟畫面、左方的影片連結，裡面有更多「Cisco學習資訊分享」的影片喔！

Guest Mr Billy Ramirez of YoungCTO Rafi Quisumbing A goal-oriented IT professional with more than 7 years of experience, CCNA R&S and CCNP Switch v2.0 certified, deep understanding and knowledge about computer networking principles and data network operations. https://www.linkedin.com/in/iambillyr... Exposed to large and complex BPO network infrastructure, hands-on experience on multi-vendor and multi-client network environment, familiar with ITSM / ITIL process, can work on high pressure and fast-phase environment, a team player and can work with minimal supervision. SKILL SETS: •CCNP Switch V.2.0 certified •CCNA R&S certified •Knowledge and experience in BPO multi-vendor and multi-client network environment •Knowledge and understating of network principles (OSI model, TCP/IP and network connectivity) •Knowledge in LAN switching technologies (Cisco and HP Switches, VLANs, STP, VTP etc.) •Knowledge in high availability and redundancy (HSRP, VRRP etc.) •Knowledge in IP routing protocols (RIP, OSPF, EIGRP and BGP) •Hands-on experience in managing Cisco switches and routers, HP switches and F5 load balancers •Knowledge in IP addressing and IP services (IPv4 and IPv6, DHCP, NAT, subnetting, etc.) •Knowledge of WAN technologies (MPLS, VPN, T1/E1 etc.)

Learn Wireshark if you are serious. Get the full Wireshark course for $9: https://bit.ly/wireshark20 Need help? Join my Discord: https://discord.com/invite/usKSyzb Download pcapng file here: https://bit.ly/wiresharkospf Questions and Answers: https://bit.ly/2KVp64a Menu: Overview: 0:00 Questions: 0:24 Answers: 2:46 In this course I'm going to show you how to capture packets from a network, how to capture passwords, replay voice conversations, view routing protocol updates and many more options. Do you know network protocols? Want to learn wireshark and have some fun? This is the course for you: Learn Wireshark practically. Wireshark pcapng files provided so you can practice while you learn! There is so much to learn in this course: - Capture Telnet, FTP, TFTP, HTTP passwords. - Replay VoIP conversations. - Capture routing protocol (OSPF) authentication passwords. - Troubleshoot network issues. - Free software. - Free downloadable pcapng files. - Answer quiz questions. The course is very practical. You can practice while you learn! Learn how to analyze and interpret network protocols and leverage Wireshark for what it was originally intended: Deep Packet Inspection and network analysis. Protocols we capture and discuss in this course include: - Telnet - FTP - TFTP - HTTP - VoIP - OSPF - EIGRP - DNS - ICMP ====================== Special Offers: ====================== Cisco Press: Up to 50% discount Save every day on Cisco Press learning products! Use discount code BOMBAL during checkout to save 35% on print books (plus free shipping in the U.S.), 45% on eBooks, and 50% on video courses and simulator software. Offer expires December 31, 2020. Shop now. Link: bit.ly/ciscopress50 ITPro.TV: https://itpro.tv/davidbombal 30% discount off all plans Code: DAVIDBOMBAL Boson software: 15% discount Link: https://bit.ly/boson15 Code: DBAF15P GNS3 Academy: CCNA ($10): https://bit.ly/gns3ccna10 Wireshark ($10): https://bit.ly/gns3wireshark DavidBombal.com DavidBombal.com: CCNA ($10): http://bit.ly/yt999ccna Wireshark ($9): https://bit.ly/wireshark9 Who this course is for: Network Engineers Network Architects Networking Students ccna ccnp ccna 200-301 ccna wireshark ospf ospf wireshark Wireshark wireshark download wireshark tutorial 2020 wireshark tutorial for beginners wireshark 2020 packet sniffing Please note that links listed may be affiliate links and provide me with a small percentage/kickback should you use them to purchase any of the items listed or recommended. Thank you for supporting me and this channel!

I show you how to capture and replay VoIP calls between virtual and physical IP phones. Get the full Wireshark course for $9: https://bit.ly/wireshark9 Need help? Join my Discord: https://discord.com/invite/usKSyzb Menu: Overview: 0:00 Network Setup: 0:50 Skinny: 2:20 Start Wireshark and capture: 3:40 Filter for SCCP: 4:16 Capture virtual phone VoIP calls: 6:08 Physical phone VoIP capture: 16:20 Download pcapng file here: https://bit.ly/wiresharkvoip In this course I'm going to show you how to capture packets from a network, how to capture passwords, replay voice conversations, view routing protocol updates and many more options. Do you know network protocols? Want to learn wireshark and have some fun? This is the course for you: Learn Wireshark practically. Wireshark pcapng files provided so you can practice while you learn! There is so much to learn in this course: - Capture Telnet, FTP, TFTP, HTTP passwords. - Replay VoIP conversations. - Capture routing protocol (OSPF) authentication passwords. - Troubleshoot network issues. - Free software. - Free downloadable pcapng files. - Answer quiz questions. The course is very practical. You can practice while you learn! Learn how to analyze and interpret network protocols and leverage Wireshark for what it was originally intended: Deep Packet Inspection and network analysis. Protocols we capture and discuss in this course include: - Telnet - FTP - TFTP - HTTP - VoIP - OSPF - EIGRP - DNS - ICMP ====================== Special Offers: ====================== Cisco Press: Up to 50% discount Save every day on Cisco Press learning products! Use discount code BOMBAL during checkout to save 35% on print books (plus free shipping in the U.S.), 45% on eBooks, and 50% on video courses and simulator software. Offer expires December 31, 2020. Shop now. Link: bit.ly/ciscopress50 ITPro.TV: https://itpro.tv/davidbombal 30% discount off all plans Code: DAVIDBOMBAL Boson software: 15% discount Link: https://bit.ly/boson15 Code: DBAF15P GNS3 Academy: CCNA ($10): https://bit.ly/gns3ccna10 Wireshark ($10): https://bit.ly/gns3wireshark DavidBombal.com DavidBombal.com: CCNA ($10): http://bit.ly/yt999ccna Wireshark ($9): https://bit.ly/wireshark9 Who this course is for: Network Engineers Network Architects Networking Students Wireshark wireshark download wireshark tutorial 2020 wireshark tutorial for beginners wireshark 2020 packet sniffing Please note that links listed may be affiliate links and provide me with a small percentage/kickback should you use them to purchase any of the items listed or recommended. Thank you for supporting me and this channel!

Both TFTP and FTP are insecure protocols. Everything is sent in clear text - including all usernames and passwords. Don't use them. Get the full Wireshark course for $9: https://bit.ly/wireshark9 Need help? Join my Discord: https://discord.com/invite/usKSyzb Free Wireshark and Ethical Hacking Course: Video #7. Watch the entire series here: https://bit.ly/wiresharkhacking Menu Overview: 0:00 Start Capture: 0:48 Ping test: 1:00 Copy files using TFTP: 1:40 Filter for TFTP: 2:27 Follow UDP stream: 2:45 FTP intro: 3:53 Upload a file using FTP: 4:16 Filter for FTP: 4:35 Follow TCP stream: 4:47 Download TFTP pcapng file here: https://bit.ly/311IjXc Download FTP pcapng file here: https://bit.ly/3iUlz1A Don't use TFTP or FTP! It sends everything in clear text. That means that someone can capture everything you send on the network - including usernames and passwords. In this course I'm going to show you how to capture packets from a network, how to capture passwords, replay voice conversations, view routing protocol updates and many more options. Do you know network protocols? Do you know how to hack? Want to learn wireshark and have some fun with Ethical hacking? This is the course for you: Learn Wireshark practically. Wireshark pcapng files provided so you can practice while you learn! There is so much to learn in this course: - Capture Telnet, FTP, TFTP, HTTP passwords. - Replay VoIP conversations. - Capture routing protocol (OSPF) authentication passwords. - Troubleshoot network issues. - Free software. - Free downloadable pcapng files. - Answer quiz questions. The course is very practical. You can practice while you learn! Learn how to analyze and interpret network protocols and leverage Wireshark for what it was originally intended: Deep Packet Inspection and network analysis. Protocols we capture and discuss in this course include: - Telnet - FTP - TFTP - HTTP - VoIP - OSPF - EIGRP - DNS - ICMP ====================== Special Offers: ====================== Cisco Press: Up to 50% discount Save every day on Cisco Press learning products! Use discount code BOMBAL during checkout to save 35% on print books (plus free shipping in the U.S.), 45% on eBooks, and 50% on video courses and simulator software. Offer expires December 31, 2020. Shop now. Link: bit.ly/ciscopress50 ITPro.TV: https://itpro.tv/davidbombal 30% discount off all plans Code: DAVIDBOMBAL Boson software: 15% discount Link: https://bit.ly/boson15 Code: DBAF15P GNS3 Academy: CCNA ($10): https://bit.ly/gns3ccna10 Wireshark ($10): https://bit.ly/gns3wireshark DavidBombal.com CCNA ($10): https://bit.ly/ccnafor10 Wireshark ($9): https://bit.ly/wireshark9 Who this course is for: Network Engineers Network Architects Ethical hackers Networking Students Wireshark wireshark download wireshark tutorial 2020 wireshark tutorial for beginners wireshark 2020 packet sniffing ethical hacking hacking Please note that links listed may be affiliate links and provide me with a small percentage/kickback should you use them to purchase any of the items listed or recommended. Thank you for supporting me and this channel!

Telnet is one of those really insecure protocols. Everything is sent in clear text - including all usernames and passwords. Don't use telnet. Get the full Wireshark course for $9: https://bit.ly/wireshark9 Need help? Join my Discord: https://discord.com/invite/usKSyzb Free Wireshark and Ethical Hacking Course: Video #6. Watch the entire series here: https://bit.ly/wiresharkhacking Download pcapng file here: https://bit.ly/2GSsNGg Don't use Telnet! It sends everything in clear text. That means that someone can capture everything you send on the network - including usernames and passwords. In this course I'm going to show you how to capture packets from a network, how to capture passwords, replay voice conversations, view routing protocol updates and many more options. Do you know network protocols? Do you know how to hack? Want to learn wireshark and have some fun with Ethical hacking? This is the course for you: Learn Wireshark practically. Wireshark pcapng files provided so you can practice while you learn! There is so much to learn in this course: - Capture Telnet, FTP, TFTP, HTTP passwords. - Replay VoIP conversations. - Capture routing protocol (OSPF) authentication passwords. - Troubleshoot network issues. - Free software. - Free downloadable pcapng files. - Answer quiz questions. The course is very practical. You can practice while you learn! Learn how to analyze and interpret network protocols and leverage Wireshark for what it was originally intended: Deep Packet Inspection and network analysis. Protocols we capture and discuss in this course include: - Telnet - FTP - TFTP - HTTP - VoIP - OSPF - EIGRP - DNS - ICMP Menu: Overview: 0:00 Network: 0:30 Start Capture :2:06 Filter for Telnet: 4:02 Follow TCP stream: 5:35 ====================== Special Offers: ====================== Cisco Press: Up to 50% discount Save every day on Cisco Press learning products! Use discount code BOMBAL during checkout to save 35% on print books (plus free shipping in the U.S.), 45% on eBooks, and 50% on video courses and simulator software. Offer expires December 31, 2020. Shop now. Link: bit.ly/ciscopress50 ITPro.TV: https://itpro.tv/davidbombal 30% discount off all plans Code: DAVIDBOMBAL Boson software: 15% discount Link: https://bit.ly/boson15 Code: DBAF15P GNS3 Academy: CCNA ($10): https://bit.ly/gns3ccna10 Wireshark ($10): https://bit.ly/gns3wireshark DavidBombal.com CCNA ($10): https://bit.ly/ccnafor10 Wireshark ($9): https://bit.ly/wireshark9 Who this course is for: Network Engineers Network Architects Ethical hackers Networking Students Wireshark wireshark download wireshark tutorial 2020 wireshark tutorial for beginners wireshark 2020 packet sniffing ethical hacking hacking Please note that links listed may be affiliate links and provide me with a small percentage/kickback should you use them to purchase any of the items listed or recommended. Thank you for supporting me and this channel!

Wireshark overload?! Use a filter! Get the full Wireshark course for $9: https://bit.ly/wireshark9 Join my Discord here: http://discord.davidbombal.com

When using Wireshark, you're going to want to use Display Filters to filter what you see. In this video I show you how to use them. Get the full Wireshark course for $9: https://bit.ly/wireshark9

You need to span or mirror Ethernet ports on switches to be able to capture packets. Otherwise unicast frames sent to know MAC addresses in your network will not be sent to your Wireshark monitoring station. Get the full Wireshark course for $9: https://bit.ly/wireshark9

This is a complete Wireshark and Ethical hacking course. Get the full Wireshark course for $9: https://bit.ly/wireshark9

This is a complete Wireshark and Ethical hacking course. Get the full Wireshark course for $9: https://bit.ly/wireshark9

This is a complete Wireshark and Ethical hacking course. DavidBombal.com: Wireshark ($9): https://bit.ly/wireshark9

This is Part 2 of my VIRL series showing you how to download, install and configure Cisco VIRL 2 using VMware Player and Windows 10. The new version of Cisco VIRL allows you to create virtual Cisco networks using just your Web browser. You don't have to use a thick client or any other software - everything is included and everything is easy to use. The new version of Cisco VIRL 2 is one of your best options for CCNA, CCNP and CCIE Labs. VIRL 2 has multiple advantages over other platforms such as GNS3 or EVE-NG. VIRL 2 supports an HTML5 web client and contains all the Cisco IOS images. You don't have to use a thick client like you do with GNS3. You don't have to follow a convoluted process to get Cisco images working like you do with EVE-NG. You don't have to try to find images as they are all included as part of your VIRL subscription and by simply mapping an ISO drive to your virtual machine you can immediately start using all Cisco IOS images in your topologies. Both EVE-NG and GNS3 require that you provide your own IOS images - typically they recommend that you buy a VIRL subscription anyway. That means that you are already paying for VIRL. VIRL2 is also an official Cisco product - that means that you don't have to worry about any gray legal issues with regards to running Cisco IOS images on your laptop. This is an official Cisco product that is supported by Cisco. By paying your yearly subscription fee of $199, you can use Cisco IOS images such as IOSv, IOSvL2, ASAv, NX-OSv and others without any worries. VIRL 2 has everything you need to get started. Disadvantages include the requirement to license your installation. That however has been simplified dramatically from previous releases. There is also a 20 node limited in topologies. However, for most of us that is fine for a lot of labs. Is VIRL better than GNS3 or EVE-NG? In many ways it is. But, all platforms have advantages and disadvantages. If you are studying for your ccie, you many prefer gns3 or eve-ng as they don't limit the number of devices in a topology like virl does. VIRL-PE limits you to 20 devices - so your topologies cannot be massive like they could with gns3 or eve ng. However, if you are studying for your ccna or ccnp, VIRL may be more than enough. Cisco have made massive changes to their certification programs and it is fantastic to see the new version of VIRL in action. Menu: Overview: 0:01 License VIRL server: 0:54 Start VIRL topology: 2:06 Interface overview: 2:42 Open Device Console: 4:20 Configure Cisco Network: 5:30 Rename Nodes in VIRL: 7:20 Create loopbacks and enable OSPF: 7:57 Do I recommend VIRL? 11:00 Videos mentioned: VIR2 Part 1: https://youtu.be/sW5-jHLygFg VIRL 2 Cisco Live: https://youtu.be/5xUvqDMxH3g VIRL 1 installation: https://youtu.be/Ie5GwqtUVc8 VIRL VIRL 2 CML Cisco Modeling Labs EVE-NG GNS3 Packet Tracer CCNA Cisco Devnet Associate CCNP Enterprise CCNP Security CCNP Data Center CCNP Service Provider CCNP Collaboration Cisco Certified Devnet Professional Cisco Certified Network Professional LPIC 1 LPIC 2 Linux Professional Institute LX0-103 LX0-104 XK0-004 Please note that links listed may be affiliate links and provide me with a small percentage/kickback should you use them to purchase any of the items listed or recommended. Thank you for supporting me and this channel! #virl #ccna #virl2

There are two words that get the blame more often than not when a problem cannot be rooted: the network! Today, along with special guest, Scott Lowe, we try to dig into what the network actually means. We discover, through our discussion that the network is, in fact, a distributed system. This means that each component of the network has a degree of independence and the complexity of them makes it difficult to understand the true state of the network. We also look at some of the fascinating parallels between networks and other systems, such as the configuration patterns for distributed systems. A large portion of the show deals with infrastructure and networks, but we also look at how developers understand networks. In a changing space, despite self-service becoming more common, there is still generally a poor understanding of networks from the developers’ vantage point. We also cover other network-related topics, such as the future of the network engineer’s role, transferability of their skills and other similarities between network problem-solving and development problem-solving. Tune in today! Follow us: https://twitter.com/thepodlets Website: https://thepodlets.io Feeback: info@thepodlets.io https://github.com/vmware-tanzu/thepodlets/issues Hosts: Duffie Cooley Nicholas Lane Josh Rosso Key Points From This Episode: • The network is often confused with the server or other elements when there is a problem.• People forget that the network is a distributed system, which has independent routers.• The distributed pieces that make up a network could be standalone computers.• The parallels between routing protocols and configuration patterns for distributed systems.• There is not a model for eventually achieving consistent networks, particularly if they are old.• Most routing patterns have a time-sensitive mechanism where traffic can be re-dispersed.• Understanding a network is a distributed system gives insights into other ones, like Kubernetes.• Even from a developers’ perspective, there is a limited understanding of the network.• There are many overlaps between developers and infrastructural thinking about systems.• How can network engineers apply their skills across different systems?• As the future changes, understanding the systems and theories is crucial for network engineers.• There is a chasm between networking and development.• The same ‘primitive’ tools are still being used for software application layers.• An explanation of CSMACD, collisions and their applicability. • Examples of cloud native applications where the network does not work at all.• How Spanning Tree works and the problems that it solves.• The relationship between software-defined networking and the adoption of cloud native technologies.• Software-defined networking increases the ability to self-service.• With self-service on-prem solutions, there is still not a great deal of self-service. Quotes: “In reality, what we have are 10 or hundreds of devices with the state of the network as a system, distributed in little bitty pieces across all of these devices.” — @scott_lowe [0:03:11] “If you understand how a network is a distributed system and how these theories apply to a network, then you can extrapolate those concepts and apply them to something like Kubernetes or other distributed systems.” — @scott_lowe [0:14:05] “A lot of these software defined networking concepts are still seeing use in the modern clouds these days” — @scott_lowe [0:44:38] “The problems that we are trying to solve in networking are not different than the problems that you are trying to solve in applications.” — @mauilion [0:51:55] Links Mentioned in Today’s Episode: Scott Lowe on LinkedIn — https://www.linkedin.com/in/scottslowe/ Scott Lowe’s blog — https://blog.scottlowe.org/ Kafka — https://kafka.apache.org/ Redis — https://redis.io/ Raft — https://raft.github.io/ Packet Pushers — https://packetpushers.net/ AWS — https://aws.amazon.com/ Azure — https://azure.microsoft.com/en-us/ Martin Casado — http://yuba.stanford.edu/~casado/ Transcript: EPISODE 15 [INTRODUCTION] [0:00:08.7] ANNOUNCER: Welcome to The Podlets Podcast, a weekly show that explores Cloud Native one buzzword at a time. Each week, experts in the field will discuss and contrast distributed systems concepts, practices, tradeoffs and lessons learned to help you on your cloud native journey. This space moves fast and we shouldn’t reinvent the wheel. If you’re an engineer, operator or technically minded decision maker, this podcast is for you. [EPISODE] [0:00:41.4] DC: Good afternoon everybody. In this episode, we’re going to talk about the network. My name is Duffie Cooley and I’ll be the lead of this episode and with me, I have Nick. [0:00:49.0] NL: Hey, what’s up everyone. [0:00:51.5] DC: And Josh. [0:00:52.5] JS: Hi. [0:00:53.6] DC: And Mr. Scott Lowe joining us as a guest speaker. [0:00:56.2] SL: Hey everyone. [0:00:57.6] DC: Welcome, Scott. [0:00:58.6] SL: Thank you. [0:01:00.5] DC: In this discussion, we’re going to try and stay away, like we do always, we’re going to try and stay away from particular products or solutions that are related to the problem. The goal of it is to really kind of dig in to like what the network means when we refer to it as it relates to like cloud native applications or just application design in general. One of the things that I’ve noticed over time and I’m curious, what you all think but like, one of the things I’ve done over time is that people are kind of the mind that if it can’t root cause a particular issue that they run into, they’re like, “That was the network.” Have you all seen that kind of stuff out there? [0:01:31.4] NL: Yes, absolutely. In my previous life, before being a Kubernetes architect, I actually used my networking and engineering degree to be a network administrator for the Boeing Company, under the Boeing Corporation. Time and time again, someone would come to me and say, “This isn’t working. The network is down.” And I’m like, “Is the network down or is the server down?” Because those are different things. Turns out it was usually the server. [0:01:58.5] SL: I used to tell my kids that they would come to me and they would say, the Internet is down and I would say, “Well, you know. I don’t think the entire Internet is down, I think it’s just our connection to the Internet.” [0:02:10.1] DC: Exactly. [0:02:11.7] JS: Dad, the entire global economy is just taking a total hit. [0:02:15.8] SL: Exactly, right. [0:02:17.2] DC: I frequently tell people that my first distributed system that I ever had a real understanding of was the network, you know? It’s interesting because it kind of like, relies on the premises that I think a good distributed system should in that there is some autonomy to each of the systems, right? They are dependent on each other or even are inter communicate with each other but fundamentally, like when you look at routers and things like that, they are autonomous in their own way. There’s work that they do exclusive to the work that others do and exclusive to their dependencies which I think is very interesting. [0:02:50.6] SL: I think the fact that the network is a distributed system and I’m glad you said that Duffie, I think the fact the network is a distributed system is what most people overlook when they start sort of blaming the network, right? Let’s face it, in the diagrams, right, the network’s always just this blob, right? Here’s the network, right? It’s this thing, this one singular thing. When in reality, what we have are like 10 or hundreds of devices with the state of the network as a system, distributed in little bitty pieces across all of these devices. And no way, aside from logging in to each one of these devices are we able to assemble what the overall state is, right? Even routing protocols mean, their entire purpose is to assemble some sort of common understanding of what the state of the network is. Melding together, not just IP addresses which are these abstract concept but physical addresses and physical connections. And trying to reason to make decisions about them, how we center across and it’s far more complex and a lot of people understand, I think that’s why it’s just like the network is down, right? When reality, it’s probably something else entirely. [0:03:58.1] DC: Yeah, absolutely. Another good point to bring up is that each of these distributed pieces of this distributed system are in themselves like basically like just a computer. A lot of times, I’ve talked to people and they were like, “Well, the router is something special.” And I’m like, “Not really. Technically, a Linux box could just be a router if you have enough ports that you plug into it. Or it could be a switch if you needed to, just plug in ports.” [0:04:24.4] NL: Another good interesting parallel there is like when we talk about like routing protocols which are a way of – a way that allow configuration changes to particular components within that distributed system to be known about by other components within that distributed system. I think there’s an interesting parallel here between the way that works and the way that configuration patterns that we have for distributed systems work, right? If you wanted to make a configuration only change to a set of applications that make up some distributed system, you might go about like leveraging Ansible or one of the many other configuration models for this. I think it’s interesting because it represents sort of an evolution of that same idea in that you’re making it so that each of the components is responsible for informing the other components of the change, rather than taking the outside approach of my job is to actually push a change that should be known about by all of these concepts, down to them. Really, it’s an interesting parallel. What do you all think of that? [0:05:22.2] SL: I don’t know, I’m not sure. I’d have to process that for a bit. But I mean, are you saying like the interesting thought here is that in contrast to typical systems management where we push configuration out to something, using a tool like an Ansible, whatever, these things are talking amongst themselves to determine state? [0:05:41.4] DC: Yeah, it’s like, there are patterns for this like inside of distributed systems today, things like Kafka and you know, Kafka and Gossip protocol, stuff like this actually allows all of the components of a particular distributed system to understand the common state or things that would be shared across them and if you think about them, they’re not all that different from a routing protocol, right? Like the goal being that you give the systems the ability to inform the other systems in some distributed system of the changes that they may have to react to. Another good example of this one, which I think is interesting is like, what they call – when you have a feature behind a flag, right? You might have some distributed configuration model, like a Redis cache or database somewhere that you’ve actually – that you’ve held the running configuration of this distributed system. And when you want to turn on this particular feature flag, you want all of the components that are associated with that feature flag to enable that new capability. Some of the patterns for that are pretty darn close to the way that routing protocol models work. [0:06:44.6] SL: Yeah, I see what you're saying. Actually, that’ makes a lot of sense. I mean, if we think about things like Gossip protocols or even consensus protocols like Raft, right? They are similar to routing protocols in that they are responsible for distributing state and then coming to an agreement on what that state is across the entire system. And we even apply terms like convergence to both environments like we talk about how long it takes routing protocol to converge. And we might also talk about how long it takes for and ETCD cluster to converge after changing the number of members in the cluster of that nature. The point at which everybody in that distributed system, whether it be the network ETCD or some other system comes to the same understanding of what that shared state is. [0:07:33.1] DC: Yeah, I think that’s a perfect breakdown, honestly. Pretty much every routing technology that’s out there. You know, if you’re taking that – the computer of the network, you know, it takes a while but eventually, everyone will reconcile the fact that, “Yeah, that node is gone now.” [0:07:47.5] NL: I think one thing that’s interesting and I don’t know how much of a parallel there is in this one but like as we consider these systems like with modern systems that we’re building at scale, frequently we can make use of things like eventual consistency in which it’s not required per se for a transaction to be persisted across all of the components that it would affect immediately. Just that they eventually converge, right? Whereas with the network, not so much, right? The network needs to be right now and every time and there’s not really a model for eventually consistent networks, right? [0:08:19.9] SL: I don’t know. I would contend that there is a model for eventually consistent networks, right? Certainly not on you know, most organizations, relatively simple, local area networks, right? But even if we were to take it and look at something like a Clos fabric, right, where we have top of rack switches and this is getting too deep for none networking blokes that we know, right? Where you take top of rack switches that are talking layer to the servers below them or the end point below them. And they’re talking layer three across a multi-link piece up to the top, right? To the spine switches, so you have leaf switches, talking up spine switches, they’re going to have multiple uplinks. If one of those uplinks goes down, it doesn’t really matter if the rest off that fabric knows that that link is down because we have the SQL cost multi pathing going across that one, right? In a situation like that, that fabric is eventually consistent in that it’s okay if you know, knee dropping link number one of leaf A up to spine A is down and the rest of the system doesn’t know about that yet. But, on the other hand, if you are looking at network designs where convergence is being handled on active standby links or something of that nature or there aren’t enough paths to get from point A to point B until convergence happens then yes, you’re right. I think it kind of comes down to network design and the underlying architecture and there are so many factors that affect that and so many designs over the years that it’s hard to – I would agree and from the perspective of like if you have an older network and it’s been around for some period of time, right? You probably have one that is not going to be tolerant, a link being down like it will cause problems. [0:09:58.4] NL: Adds another really great parallel in software development, I think. Another great example of that, right? If we consider for a minute like the circuit breaking pattern or even like you know, most load balancer patterns, right? In which you have some way of understanding a list of healthy end points behind the load balancer and were able to react when certain end points are no longer available. I don’t consider that a pattern that I would relate to specifically if they consent to eventual consistency. I feel like that still has to be immediate, right? We have to be able to not send the new transaction to the dead thing. That has to stop immediately, right? It does in most routing patterns that are described by multi path, there is a very time sensitive mechanism that allows for the re-dispersal of that traffic across known paths that are still good. And the work, the amazing amount of work that protocol architects and network engineers go through to understand just exactly how the behavior of those systems will work. Such that we don’t see traffic. Black hole in the network for a period of time, right? If we don’t send traffic to the trash when we know or we have for a period of time, while things converge is really has a lot going for it. [0:11:07.0] SL: Yeah, I would agree. I think the interesting thing about discussing eventual consistency with regards to the networking is that even if we take a relatively simple model like the DOD model where we only have four layers to contend with, right? We don’t have to go all the way to this seven-layer OSI model. But even if we take a simple layer like the DOD four-layer model, we could be talking about the rapid response of a device connected at layer two but the less than rapid response of something operating at layer three or layer four, right? In the case of a network where we have these discreet layers that are intentionally loosely coupled which is another topic, we could talk about from a distribution perspective, right? We have these layers that are intentionally loosely coupled, we might even see consistency and the application of the cap theorem, behave differently at different layers of their model. [0:12:04.4] DC: That’s right. I think it’s fascinating like how much parallel there is here. As you get into like you know, deep architectures around software, you’re thinking of these things as it relates to like these distributed systems, especially as you’re moving toward more cloud native systems in which you start employing things like control theory and thinking about the behaviours of those systems both in aggregate like you know, some component of my application, can I scale this particular component horizontally or can I not, how am I handling state. So many of those things have parallels to the network that I feel like it kind of highlights I’m sure what everybody has heard a million times, you know, that there’s nothing new under the sun. There’s million things that we could learn from things that we’ve done in the past. [0:12:47.0] NL: Yeah, totally agree. I recently have been getting more and more development practice and something that I do sometimes is like draw out like how all of my functions and my methods, and take that in rack with each other across a consisting code base and lo and behold when I draw everything out, it sure does look a lot like a network diagram. All these things have to flow together in a very specific way and you expect the kind of returns that you’re looking for. It looks exactly the same, it’s kind of the – you know, how an atom kind of looks like a galaxy from our diagram? All these things are extrapolated across like – [0:13:23.4] SL: Yeah, totally. [0:13:24.3] NL: Different models. Or an atom looks like a solar system which looks like a galaxy. [0:13:28.8] SL: Nicholas, you said your network administrator at Boeing? [0:13:30.9] NL: I was, I was a network engineer at Boeing. [0:13:34.0] SL: You know, as you were sitting there talking, Duffie, so, I thought back to you Nick, I think all the times, I have a personal passion for helping people continue to grow and evolve in their career and not being stuck. I talk to a lot of networking folks, probably dating because of my involvement, back in the NSX team, right? But folks being like, “I’m just a network engineer, there’s so much for me to learn if I have to go learn Kubernetes, I wouldn’t even know where to start.” This discussion to me underscores the fact that if you understand how a network is a distributed system and how these theories apply to a network, then you can extrapolate those concepts and apply them to something like Kubernetes or other distributed systems, right? Immediately begin to understand, okay. Well, you know, this is how these pieces talk to each other, this is how they come, the consensus, this is where the state is stored, this is how they understand and exchange date, I got this. [0:14:33.9] NL: if you want to go down that that path, the controlled plane of your cluster is just like your central routing back bone and then the kublets themselves are just your edge switches going to each of your individual smaller network and then the pods themselves have been nodes inside of the network, right? You can easily – look at that, holy crap, it looks exactly the same. [0:14:54.5] SL: Yeah, that’s a good point. [0:14:55.1] DC: I mean, another interesting part, when you think about how we characterize systems, like where we learn that, where that skillset comes from. You raise a very good point. I think it’s an easier – maybe slightly easier thing to learn inside of networking, how to characterize that particular distributed system because of the way the components themselves are laid out and in such a common way. Where when we start looking at different applications, we find a myriad of different patterns with particular components that may behave slightly differently depending, right? Like there are different patterns within software like almost on per application bases whereas like with networks, they’re pretty consistently applied, right? Every once in a while, they’ll be kind of like a new pattern that emerges, that it just changes the behavior a little bit, right? Or changes the behavior like a lot but at the same time, consistently across all of those things that we call data center networks or what have you. To learn to troubleshoot though, I think the key part of this is to be able to spend the time and the effort to actually understand that system and you know, whether you light that fire with networking or whether you light that fire with like just understanding how to operationalize applications or even just developing and architecting them, all of those things come into play I think. [0:16:08.2] NL: I agree. I’m actually kind of curious, the three of us have been talking quite a bit about networking from the perspective that we have which is more infrastructure focused. But Josh, you have more of a developer focused background, what’s your interaction and understanding of the network and how it plays? [0:16:24.1] JS: Yeah, I’ve always been a consumer of the network. It’s something that is sat behind an API and some library, right? I call out to something that makes a TCP connection or an http interaction and then things just happen. I think what’s really interesting hearing talk and especially the point about network engineers getting into thee distributed system space is that I really think that as we started to put infrastructure behind API’s and made it more and more accessible to people like myself, app developers and programmers, we started – by we, you know, I’m obviously generalizing here. But we started owning more and more of the infrastructure. When I go into teams that are doing big Kubernetes deployments, it’s pretty rare, that’s the conventional infrastructure and networking teams that are standing up distributed systems, Kubernetes or not, right? It's a lot of times, a bunch of app developers who have maybe what we call dev-ops, whatever that means but they have an application development background, they understand how they interact with API’s, how to write code that respects or interacts with their infrastructure and they’re standing up these systems and I think one of the gaps of that really creates is a lot of people including myself just hearing you all talk, we don’t understand networking at that level. When stuff falls over and it’s either truly the network or it’s getting blamed on the network, it’s often times, just because we truly don’t understand a lot of these things, right? Encapsulation, meshes, whatever it might be, we just don’t understand these concepts at a deep level and I think if we had a lot more people with network engineering backgrounds, shifting into the distributed system space. It would alleviate a bit of that, right? Bringing more understanding into the space that we work in nowadays. [0:18:05.4] DC: I wonder if maybe it also would be a benefit to have like more cross discussions like this one between developers and infrastructure kind of focused people, because we’re starting to see like as we’re crossing boundaries, we see that the same things that we’re doing on the infrastructure side, you’re also doing in the developer side. Like cap theorem as Scott mention which is the idea that you can have two out of three of consistency, availability and partitioning. That also applies to networking in a lot of ways. You can only have a network that is either like consistent or available but it can’t handle partitioning. It can be a consistent to handle partitioning but it’s not always going to be available, that sort of thing. These things that apply in from the software perspective also apply to us but we think about them as being so completely different. [0:18:52.5] JS: Yeah, I totally agree. I really think like on the app side, a couple of years ago, you know, I really just didn’t care anything outside of the JVM like my stuff on the JVM and if it got out to the network layer of the host like just didn’t care, know, need to know about that at all. But ever since cloud computing and distributed systems and everything became more prevalent, the overlap has become extremely obvious, right? In all these different concepts and it’s been really interesting to try to ramp up on that. [0:19:19.6]:19.3] NNL: Yeah, I think you know Scott and I both do this. I think as I imagine, actually, this is true of all four of us to be honest. But I think that it’s really interesting when you are out there talking to people who do feel like they’re stuck in some particular role like they’re specialists in some particular area and we end up having the same discussion with them over and over again. You know, like, “Look, that may pay the bills right now but it’s not going to pay the bills in the future.” And so you know, the question becomes, how can you, as a network engineer take your skills forward and not feel as though you’re just going to have to like learn everything all over again. I think that one of the things that network engineers are pretty decent at is characterizing those systems and being able to troubleshoot them and being able to do it right now and being able to like firefight those capabilities and those skills are incredibly valuable in the software development and in operationalizing applications and in SRE models. I mean, all of those skills transfer, you know? If you’re out there and you’re listening and you feel like I will always be a network engineer, consider that you could actually take those skills forward into some other role if you chose to. [0:20:25.1] JS: Yeah, totally agree. I mean, look at me, the lofty career that I’ve been come to. [0:20:31.4] SL: You know, I would also say that the fascinating thing to me and one of the reasons I launched, I don’t say this to like try and plug it but just as a way of talking about the reason I launched my own podcast which is now part of packet pushers, was exploring this very space and that is like we’ve got folks like Josh who comes from the application development spacing is now being, you know, in a way, forced to own and understand more infrastructure and we’ve got the infrastructure folks who now in a way, whether it be through the rise of cloud computing and abstractions away from visible items are being forced kind of up the stack and so they’re coming together and this idea of what does the future of the folks that are kind of like in our space, what does that look like? How much longer does a network engineer really need to be deeply versed in all the different layers? Because everything’s been abstracted away by some other type of thing whether it’s VPC’s or Azure V Nets or whatever the case is, right? I mean, you’ve got companies bringing the VPC model to on premises networks, right? As API’s become more prevalent, as everything gets sort of abstracted away, what does the future look like, what are the most important skills and it seems to me that it’s these concepts that we’re talking about, right? This idea of distributed systems and how distributed systems behave and how the components react to one another and understanding things like the cap theorem that are going to be most applicable rather than the details of trouble shooting VGP or understanding AWS VPC’s or whatever the case may be. [0:22:08.5] NL: I think there is always going to be a place for the people who know how things are running under the hood from like a physical layer perspective, that sort of thing, there’s always going to be the need for the grave beards, right? Even in software development, we still have the people who are slinging kernel code in C. And you know, they’re the best, we salute you but that is not something that I’m interested in it for sure. We always need someone there to pick up the pieces as it were. I think that yeah, having just being like, I’m a Cisco guy, I’m a Juniper guy, you know? I know how to pawn that or RSH into the switch and execute these commands and suddenly I’ve got this port is now you know, trunk to this V neck crap, I was like, Nick, remember your training, you know? How to issue those commands, I wonder, I think that that isn’t necessarily going away but it will be less in demand in the future. [0:22:08.5] SL: I’m curious to hear Josh’s perspective as like having to own more and more of the infrastructure underneath like what seems to be the right path forward for those folks? [0:23:08.7] JS: Yeah, I mean, unfortunately, I feel like a lot of times, it just ends up being trial by fire and it probably shouldn’t be that. But the amount of times that I have seen a deployment of some technology fall over because we overlapped the site range or something like that is crazy. Because we just didn’t think about it or really understand it that well. You know, like using one protocol, you just described BGP. I never ever dreamt of what BGP was until I started using attributed systems, right? Started using BGP as a way to communicate routes and the amount off times that I’ve messed up that connection because I don’t have a background in how to set that up appropriately, it’s been rough. I guess my perspective is that the technology has gotten better overall and I’m mostly obviously in the Kubernetes space, speaking to the technologies around a lot of the container networking solutions but I’m sure this is true overall. It seems like a lot of the sharp edges have been buffed out quite a bit and I have less of an opportunity to do things terribly wrong. I’ve also noticed for what it’s worth, a lot of folks that have my kind of background or going out to like the AWS is the Azure’s of the world. They’re using all these like, abstracted networking technologies that allow t hem to do really cool stuff without really having to understand how it works and they’re often times going back to their networking team on prem when they have on prem requirements and being like it should be this easy or XY and Z and they’re almost like pushing the networking team to modernize that and make things simpler. Based on experiences they’re having with these cloud providers. [0:24:44.2] DC: Yeah, what do you mean I can’t create a load balancer that crosses between these two disparate data centers as it easily is. Just issuing a single command. Doesn’t this just exist from a networking standpoint? Even just the idea that you can issue an API command and get a load balancer, just that idea alone, the thousands of times I have heard that request in my career. [0:25:08.8] JS: And like the actual work under the hood to get that to work properly is it’s a lot, there’s a lot of stuff going on. [0:25:16.5] SL: Absolutely, yeah, [0:25:17.5] DC: Especially when you’re into plumbing, you know? If you’re going to create a load balancer with API, well then, what API does the load balancer use to understand where to send that traffic when it’s being balanced. How do you handle discovery, how do you hit like – obviously, yeah, there’s no shortage on the amount of work there. [0:25:36.0] JS: Yeah. [0:25:36.3] DC: That’s a really good point, I mean, I think sometimes it’s easy for me to think about some of these API driven networking models and the cost that come with them, the hidden cost that come with them. An example of this is, if you’re in AWS and you have a connectivity between wo availability, actually could be any cloud, it doesn’t have to be an AWS, right? If you have connectivity between two different availability zones and you’re relying on that to be reliable and consistent and definitely not to experience, what tools do you have at your disposal, what guarantees do you have that that network has even operating in a way that is responsive, right? And in a way, this is kind of taking us towards the observability conversation that I think we’ve talked a little bit about the past. Because I think it highlights the same set of problems again, right? You have to understand, you have to be able to provide the consumers of any service, whether that service is plumbing, whether it’s networking, whether it’s your application that you’ve developed that represents a set of micro service. You have to provide everybody a way or you know, have to provide the people who are going to answer the phone at two in the morning. Or even the robots that are going to answer the phone at two in the morning. I have to provide them some mechanism by which to observe those systems as they are in use. [0:26:51.7] JS: I’m not convinced that very many of the cloud providers do that terribly well today, you know? I feel like I’ve been burned in the past without actually having an understanding of the state that we’re in and so it is interesting maybe the software development team can actually start pushing that down toward the networking vendors out there out in the world. [0:27:09.9] NL: Yeah that would be great. I mean I have been recently using a managed Kubernetes service. I have been kicking the tires on it a little bit. And yeah there has been a couple of times where I had just been got by networking issues. I am not going to get into what I have seen in a container network interface or any of the technologies around that. We are going to talk about that another time. But the CNI that I am using in this managed service was just so wonky and weird. And it was failing from a network standpoint. The actual network was failing in a sense because the IP addresses for the nodes themselves or the pods wasn’t being released properly and because of our bag. And so, the rules associated with my account could not remove IP addresses from a node in the network because it wasn’t allowed to and so from a network, I ran out of IP addresses in my very small site there. [0:28:02.1] SL: And this could happen in database, right? This could happen in a cache of information, this could happen in pretty much the same pattern that you are describing is absolutely relevant in both of these fields, right? And that is a fascinating thing about this is that you know we talk about the network generally in these nebulous terms and that it is like a black box and I don’t want them to know anything about it. I want to learn about it, I don’t want to understand it. I just want to be able to consume it via an API and I want to have the expectation that everything will work the way it is supposed to. I think it is fascinating that on the other side of that API are people maybe just like you who are doing their level best to provide, to chase the cap theorum into it’s happy end and figure out how to actually give you what you need out of that service, you know? So, empathy I think is important. [0:28:50.4] NL: Absolutely, to bring that to an interesting thought that I just had where on both sides of this chasm or whatever it is between networking and develop, the same principles exists like we have been saying but just to elicited on it a little bit more, it’s like on one side you have like I need to make sure that these ETCD nodes communicate with each other and that the data is consistent across the other ones. So, we use a protocol called RAFT, right? And so that’s eventually existent tool then that information is sent onto a network, which is probably using OSPF, which is “open shortest path first” routing protocol to become eventually consistent on the data getting from one point to the other by opening the shortest path possible. And so these two things are very similar. They are both these communication protocols, which is I mean that is what protocol means, right? The center for communication but they’re just so many different layers. Obviously of the OSI model but people don’t put them together but they really are and we keep coming back to that where it is all the same thing but we think about it so differently. And I am actually really appreciating this conversation because now I am having a galaxy brain moment like boo. [0:30:01.1] SL: Another really interesting one like another galaxy moment, I think that is interesting is if you think about – so let us break them down like TCP and UTP. These are interesting patterns that actually do totally relate again just in software patterns, right? In TCP the guarantee is that every data gram, if you didn’t get the entire data gram you will understand that you are missing data and you will request a new version of that same packet. And so, you can provide consistency in the form of retries or repeats if things don’t work, right? Not dissimilar from the ability to understand like that whether you chuck some in data across the network or like in a particular data base, if you make a query for a bunch of information you have to have some way of understanding that you got the most recent version of it, right? Or ETCD supports us by using the revision by understanding what revision you received last or whether that is the most recent one. And other software patterns kind of follow the same model and I think that is also kind of interesting. Like we are still using the same primitive tools to solve the same problems whether we are doing it at a software application layer or whether we are doing it down in the plumbing at the network there, these tools are still very similar. Another example is like UTP where it is basically there are no repeats. You either got the packet or you didn’t, which sounds a lot like an event stream to me in some ways, right? Like it is very interesting, you just figured out like I put in on the line, you didn’t get it? It is okay, I will put another line here in a minute you can react to that one, right? It is an interesting overlap. [0:31:30.6] NL: Yeah, totally. [0:31:32.9] JS: Yeah, the comparison to event streams or message queues, right? There is an interesting one that I hadn’t considered before but yeah, there are certainly parallels between saying, “Okay I am going to put this on the message queue,” and wait for the acknowledgement that somebody has taken it and taken ownership of it as oppose to an event stream where it is like this happened. I admit this event. If you get it and you do something with it, great. If you don’t get it then you don’t do something with it, great because another event is going to come along soon. So, there you go. [0:32:02.1] DC: Yep, I am going to go down a weird topic associated with what we are just talking about. But I am going to get a little bit more into the weeds of networking and this is actually directed into us in a way. So, talking about the kind of parallels between networking and development, in networking at least with TCP and networking, there is something called CSMACD, which is “carry your sense multi,” oh I can’t remember what the A stands for and the CD. [0:32:29.2] SL: Access. [0:32:29.8] DC: Multi access and then CD is collision detection and so basically what that means is whenever you sent out a packet on the network, the network device itself is listening on the network for any collisions and if it detects a collision it will refuse to send a packet until a certain period of time and they will do a retry to make sure that these packets are getting sent as efficiently as possible. There is an alternative to that called CMSCA, which was used by Mac before they switched over to using a Linux based operating system. And then putting a fancy UI in front of it, which collision avoidance would listen and try and – I can’t remember exactly, it would time it differently so that it would totally just avoid any chance that there could be collision. It would make sure that no packets were being sent right then and then send it back up. And so I was wondering if something like that exists in the realm between the communication path between applications. [0:33:22.5] JS: Is it collision two of the same packets being sent or what exactly is that? [0:33:26.9] DC: With the packets so basically any data going back and forth. [0:33:29.7] JS: What makes it a collision? [0:33:32.0] SL: It is the idea that you can only transmit one message at a time because if they both populate the same media it is trash, both of them are trash. [0:33:39.2] JS: And how do you qualify that. Do you receive an ac from the system or? [0:33:42.8] NL: No there is just nothing returned essentially so it is like literally like the electrical signals going down the wire. They physically collide with each other and then the signal breaks. [0:33:56.9] JS: Oh, I see, yeah, I am not sure. I think there is some parallels to that maybe with like queuing technologies and things like that but can’t think of anything on like direct app dev side. [0:34:08.6] DC: Okay, anyway sorry for that tangent. I just wanted to go down that little rabbit-hole a little bit. It was like while we are talking about networking, I was like, “Oh yeah, I wanted to see how deep down we can make this parallel going?” so that was the direction I went. [0:34:20.5] SL: Like where is that that CSMACD, a piece is like seriously old school, right? Because it only applied to half duplex Ethernet and as soon as we went to full duplex Ethernet it didn’t matter anymore. [0:34:33.7] DC: That is true. I totally forgot about that. [0:34:33.8] JS: It applied the satellite with all of these as well. [0:34:35.9] DC: Yeah, I totally forgot about that. Yeah and with full duplex, we totally just space on that. This is – damn Scott, way to make me feel old. [0:34:45.9] SL: Well I mean satellite stuff, too, right? I mean it is actually any shared media upon which you have to – where if this stuff goes and overlap there, you are not going to be able to make it work right? And so, I mean it is interesting. It is actually an interesting PNL. I am struggling to think of an example of this as well. I mean my brain is going towards circuit breaking but I don’t think that that is quite the same thing. It is sort the same thing that in a circuit breaking pattern, the application that is making the request has the ability obviously because it is the thing making the request to understand that the target it is trying to connect to is not working correctly. And so, it is able to make an almost instantaneous decision or at least a very shortly, a very timely decision about what to do when it detects that state. And so that’s a little similar and that you can and from the requester side you can do things if you see things going awry. And really and in reality, in the circuit breaking pattern we are making the assumption that only the application making the request will ever get that information fast enough to react to it. [0:35:51.8] JS: Yeah where my head was kind of going with it but I think it is pretty off is like on a low level piece of code like it is maybe something you write in C where you implement your own queue in that area and then multiple threads are firing off the same time and there is no block system or mechanism if two threads contend to put something in the same memory space that that queue represents. That is really going down the rabbit hole. I can’t even speak to what degree that is possible in modern programming but that is where my head was. [0:36:20.3] NL: Yeah that is a good point. [0:36:21.4] SL: Yeah, I think that is actually a pretty good analogy because the key commonality here is some sort of shared access, right? Multiple threads accessing the same stack or memory buffer. The other thing that came to mind to me was like some sort of session multiplexing, right? Where you are running multiple application layer sessions inside a single sort of network connection and those network sessions getting comingled in some fashion. Whether through identifiers or sequence number or something else of that nature and therefore, you know garbling the ultimate communication that is trying to be sent. [0:36:59.2] DC: Yeah, locks are exactly the right direction, I think. [0:37:03.6] NL: That is a very good point. [0:37:05.2] DC: Yeah, I think that makes perfect sense. Good, all right. Yes, we nailed it. [0:37:09.7] SL: Good job. [0:37:10.8] DC: Can anybody here think of a software pattern that maybe doesn’t come across that way? When you are thinking about some of the patterns that you see today in cloud native applications, is there a counter example, something that the network does not do at all? [0:37:24.1] NL: That is interesting. I am trying to think where event streams. No, that is just straight up packets. [0:37:30.7] JS: I feel like we should open up one of those old school Java books of like 9,000 design patterns you need to know and we should go one by one and be like, “What about this” you know? There is probably something I can’t think of it off the top of my head. [0:37:43.6] DC: Yeah me neither. I was trying to think of it. I mean like I can think of a myriad of things that do cross over even the idea of only locally relevant state, right? That is like a cam table on a switch that is only locally relevant because once you get outside of that switching domain it doesn’t matter anymore and it is like there is a ton of those things that totally do relate, you know? But I am really struggling to come up with one that doesn’t – One thing that is actually interesting is I was going to bring up – we mentioned the cap theorem and it is an interesting one that you can only pick like two and three of consistency availability and partition tolerance. And I think you know, when I think about the way that networks solve or try to address this problem, they do it in some pretty interesting way. It’s like if you were to consider like Spanning Tree, right? The idea that there can really only be one path through a series of broadcast domains. Because we have multiple paths then obviously we are going to get duplicity and the things are going to get bad because they are going to have packets that are addressed the same things across and you are going to have all kinds of bad behaviors, switching loops and broadcast storms and all kinds of stuff like that and so Spanning Tree came along and Spanning Tree was invented by an amazing woman engineer who created it to basically ensure that there was only one path through a set of broadcast domains. And in a way, this solved that camp through them because you are getting to the point where you said like since I understand that for availability purpose, I only need one path through the whole thing and so to ensure consistency, I am going to turn off the other paths and to allow for partition tolerance, I am going to enable the system to learn when one of those paths is no longer viable so that it can re-enable one of the other paths. Now the challenge of course is there is a transition period in which we lose traffic because we haven’t been able to open one of those other paths fast enough, right? And so, it is interesting to think about how the network is trying to solve with the part that same set of problems that is described by the cap theorem that we see people trying to solve with software routine. [0:39:44.9] SL: No man I totally agree. In a case like Spanning Tree, you are sacrificing availability essentially for consistency and partition tolerance when the network achieves consistency then availability will be restored and there is other ways to doing that. So as we move into systems like I mentioned clos fabrics earlier, you know a cost fabric is a different way of establishing a solution to that and that is saying I’d later too. I will have multiple connections. I will wait those connections using the higher-level protocol and I will sacrifice consistency in terms of how the routes are exchanged to get across that fabric in exchange for availability and partition columns. So, it is a different way of solving the same problem and using a different set of tools to do that, right? [0:40:34.7] DC: I personally find it funny that in the cap theorem there is at no point do we mention complexity, right? We are just trying to get all three and we don’t care if it’s complex. But at the same time, as a consumer of all of these systems, you care a lot about the complexity. I hear it all the time. Whether that complexity is in a way that the API itself works or whether even in this episode we are talking about like I maybe don’t want to learn how to make the network work. I am busy trying to figure out how to make my application work, right? Like cognitive load is a thing. I can only really focus on so many things at a time where am I going to spend my time? Am I going to spend it learning how to do plumbing or am I going to spend it actually trying the right application that solves my business problem, right? It is an interesting thing. [0:41:17.7] NL: So, with the rise of software defined networking, how did that play into the adoption of cloud native technologies? [0:41:27.9] DC: I think it is actually one of the more interesting overlaps in the space because I think to Josh’s point again. his is where we were taking I mean I work for a company called [inaudible 0:41:37], in which we were virtualizing the network and this is fascinating because effectively we are looking at this as a software service that we had to bring up and build and build reliably and scalable. Reliably and consistently and scalable. We want to create this all while we are solving problems. But we need it to do within an API. It is like we couldn’t make the assumption with the way that networks were being defined today like going to each component and configuring them or using protocols was actually going to work in this new model of software confined networking. And so, we had an incredible amount of engineers who were really focused from a computer science perspective on how to effectively reinvent network as a software solution. And I do think that there is a huge amount of cross over here like this is actually where I think the waters meet between the way the developers think about the problems and the way that network engineers think about the problem but it has been a rough road I will say. I will say that STN I think is actually has definitely thrown a lot of network engineers under their heels because they’re like, “Wait, wait but that is not a network,” you know? Because I can’t actually look at it and characterize it in the way that I am accustomed to looking at characterizing the other networks that I play with. And then from the software side, you’re like, “Well maybe that is okay” right? Maybe that is enough, it is really interesting. [0:42:57.5] SL: You know I don’t know enough about the details of how AWS or Azure or Google are actually doing their networking like and I don’t even know and maybe you guys all do know – but I don’t even know that aside from a few tidbits here and there that AWS is going to even divulge the details of how things work under the covers for VPC’s right? But I can’t imagine that any modern cloud networking solution whether it would be VBPC’s or VNET’s or whatever doesn’t have a significant software to find aspect to it. You know, we don’t need to get into the definitions of what STN is or isn’t. That was a big discussion Duffie and I had six years ago, right? But there has to be some part of it that is taking and using the concepts that are common in STN right? And applying that. Just as the same way as the cloud vendors are using the concepts from compute virtualization to enable what they are doing. I mean like the reality is that you know the work that was done by the Cambridge folks on Zen was a massive enabler trade for AWS, right? The word done on KVM also a massive enabler for lots of people. I think GCP is KBM based and V Sphere where VM Ware data as well. I mean all of this stuff was a massive enablers for what we do with compute virtualization in the cloud. I have to think that whether it is – even if it wasn’t necessarily directly stemming out of Martin Casado’s open flow work at Stanford, right? That a lot of these software define networking concepts are still seeing use in the modern clouds these days and that is what enables us to do things like issue an API call and have an isolated network space with its own address space and its own routing and satiated in some way and managed. [0:44:56.4] JS: Yeah and on that latter point, you know as a consumer of this new software defined nature of networking, it is amazing the amount of I don’t know, I started using like a blanket marketing term here but agility that it is added, right? Because it has turned all of these constructs that I used to file a ticket and follow up with people into self-service things that when I need to poke holes in the network, hopefully the rights are locked down, so I just can’t open it all up. Assuming I know what I am doing and the rights are correct it is totally self-service for me. I go into AWS, I change the security group roll and boom, the ports have changed and it never looked like that prior to this full takeover of what I believe is STN almost end to end in the case of AWS and so on. So, it is really just not only has it made people like myself have to understand more about networking but it has allowed us to self-service a lot of the things. That I would imagine most network engineers were probably tired of doing anyways, right? How many times do you want to go to that firewall and open up that port? Are you really that excited about that? I would imagine not so. [0:45:57.1] NL: Well I can only speak from experience and I think a lot of network engineers kind of get into that field because it really love control. And so, they want to know what these ports are that are opening and it is scary to be like this person has opened up these ports, “Wait what?” Like without them even totally knowing. I mean I was generalizing, I was more so speaking to myself as being self-deprecating. It doesn’t apply to you listener. [0:46:22.9] JS: I mean it is a really interesting point though. I mean do you think it makes the networking people or network engineers maybe a little bit more into the realm of observability and like knowing when to trigger when something has gone wrong? Does it make them more reactive in their role I guess. Or maybe self-service is not as common as I think it is. It is just from my point of view, it seems like with STN’s the ability to modify the network more power has been put into the developers’ hands is how I look at it, you know? [0:46:50.7] DC: I definitely agree with that. It is interesting like if we go back a few years there was a time when all of us in the room here I think are employed by VMware. So, there was a time where VMware’s thing was like the real value or one of the key values that VMware brought to the table was the idea that a developer come and say “Give me 10 servers.” And you could just call an API or make it or you could quickly provision those 10 servers on behalf of that developer and hand them right back. You wouldn’t have to go out and get 10 new machines and put them into a rack, power them and provision them and go through that whole process that you could actually just stamp those things out, right? And that is absolutely parallel to the network piece as well. I mean if there is nothing else that SPN did bring to the fore is that, right? That you can get that same capability of just stamping up virtual machines but with networks that the API is important in almost everything we do. Whether it is a service that you were developing, whether it is a network itself, whether it is the firewall that we need to do these things programmatically. [0:47:53.7] SL: I agree with you Duffie. Although I would contend that the one area that and I will call it on premises STN shall we say right? Which is the people putting on STN solutions. I’d say the one area at least in my observation that they haven’t done well is that self-service model. Like in the cloud, self-service is paramount to Josh’s point. They can go out there, they can create their own BPC’s, create their own sub nets, create their own NAT gateways, Internet gateways to run security groups. Load balancers, blah-blah, all of that right? But it still seems to me that even though we are probably 90, 95% of the way there, maybe farther in terms of on premise STN solutions right that you still typically don’t see self-service being pushed out in the same way you would in the public cloud, right? That is almost the final piece that is needed to bring that cloud experience to the on-premises environment. [0:48:52.6] DC: That is an interesting point. I think from an infrastructure as a service perspective, it falls into that realm. It is a problem to solve in that space, right? So when you look at things like OpenStack and things like AWS and things like JKE or not JKE but GCE and areas like that, it is a requirement that if you are going to provide infrastructure as a service that you provide some capability around networking but at the same time, if we look at some of the platforms that are used for things like cloud native applications. Things like Kubernetes, what is fascinating about that is that we have agreed on a least come – we agreed on abstraction of networking that is maybe I don’t know, maybe a little more precooked you know what I mean? In the assumption within like most of the platforms as a service that I have seen, the assumption is that when I deploy a container or I deploy a pod or I deploy some function as a service or any of these things that the networking is going to be handled for me. I shouldn’t have to think about whether it is being routed to the Internet or not or routed back and forth between these domains. I should if anything only have to actually give you intent, be able to describe to you the intent of what could be connected to this and what ports I am actually going to be exposing and that the platform actually hides all of the complexity of that network away from me, which is an interesting round to strike. [0:50:16.3] SL: So, this is one of my favorite things, one of my favorite distinctions to make, right? And that is this is the two worlds that we have been talking about, applications and infrastructure and the perfect example of these different perspectives and you even said it or you talked there Duffie like from an IS perspective it is considered a given that you have to be able to say I want a network, right? But when you come at this from the application perspective, you don’t care about a network. You just want network connectivity, right? And so, when you look at the abstractions that IS vendors and solutions or products have created then they are IS centric but when you look at the abstractions that have been created in the cloud data space like within Kubernetes, they are application centric, right? And so, we are talking about infrastructure artifacts versus application artifacts and they end up meeting but they are coming at this from two different very different perspectives. [0:51:18.5] DC: Yeah. [0:51:19.4] NL: Yeah, I agree. [0:51:21.2] DC: All right, well that was a great discussion. I imagine that we are probably get into – at least I have a couple of different networking discussions that I wanted to dig into and this conversation I hope that we’ve helped draw some parallels back and forth between the way – I mean there is both some empathy to spend here, right? I mean the people who are providing the service of networking to you in your cloud environments and your data centers are solving almost exactly the same sorts of availability problems and capabilities that you are trying to solve with your own software. And I think in itself is a really interesting takeaway. Another one is that again there is nothing new under the sun. The problems that we are trying to solve in networking are not different than the problems that you are trying to solve in applications. We have far fewer tools and we generally network engineers are focused on specific changes that happen in the industry rather than looking at a breathe of industries like I mean as Josh pointed out, you could break open a Java book. And see 8,000 patterns for how to do Java and this is true, every programming language that I am aware of I mean if you look at Go and see a bunch of different patterns there and we have talked about different patterns for just developing cloud native aware applications as well, right? I mean there is so many options in the software versus what we can do and what are available to us within networks. And so I think I am rambling a little bit but I think that is the takeaway from this session. Is that there is a lot of overlap and there is a lot of really great stuff out there. So, this is Duffie, thank you for tuning in and I look forward to the next episode. [0:52:49.9] NL: Yep and I think we can all agree that Token Ring should have won. [0:52:53.4] DC: Thank you Josh and thank you Scott. [0:52:55.8] JS: Thanks. [0:52:57.0] SL: Thanks guys, this was a blast. [END OF EPISODE] [0:52:59.4] ANNOUNCER: Thank you for listening to The Podlets Cloud Native Podcast. Find us on Twitter at https://twitter.com/ThePodlets and on the http://thepodlets.io/ website, where you'll find transcripts and show notes. We'll be back next week. Stay tuned by subscribing. [END]See omnystudio.com/listener for privacy information.

Get the course for $10 on Udemy: http://bit.ly/2IXZnn8 or GNS3 Academy: http://bit.ly/2J4PzIb This is a tshark and Termshark tutorial: It is now possible to capture and view Wireshark captures directly in a console window. No need for a graphical user interface (GUI) - you can do all of this directly within a Linux terminal or console. tshark and Termshark installation: ============================== tshark: apt-get install tshark Termshark: wget https://github.com/gcla/termshark/releases/download/v1.0.0/termshark_1.0.0_linux_x64.tar.gz tar -xf termshark_1.0.0_linux_x64.tar.gz cd termshark_1.0.0_linux_x64 install termshark /usr/local/bin How to use: tshark -w tshark1.pcap termshark -r tshark1.pcap Help: termshark UserGuide: https://github.com/gcla/termshark/blob/master/docs/UserGuide.md Course overview: Do you know network protocols? Do you know how to hack? Want to learn wireshark and have some fun with Ethical hacking? This is the course for you: Learn Wireshark practically. Wireshark pcapng files provided so you can practice while you learn! There is so much to learn in this course: - Capture Telnet, FTP, TFTP, HTTP passwords. - Replay VoIP conversations. - Capture routing protocol (OSPF) authentication passwords. - Troubleshoot network issues. - Free software. - Free downloadable pcapng files. - Answer quiz questions. The course is very practical. You can practice while you learn! Learn how to analyze and interpret network protocols and leverage Wireshark for what it was originally intended: Deep Packet Inspection and network analysis. Protocols we capture and discuss in this course include: - Telnet - FTP - TFTP - HTTP - VoIP - OSPF - EIGRP - DNS - ICMP Who this course is for: Network Engineers Network Architects Ethical hackers Networking Students #wireshark #termshark #tshark

Get the course for $10 here: http://bit.ly/2IXZnn8 Do you know network protocols? Do you know how to hack? Want to learn wireshark and have some fun with Ethical hacking? This is the course for you: Learn Wireshark practically. Wireshark pcapng files provided so you can practice while you learn! There is so much to learn in this course: - Capture Telnet, FTP, TFTP, HTTP passwords. - Replay VoIP conversations. - Capture routing protocol (OSPF) authentication passwords. - Troubleshoot network issues. - Free software. - Free downloadable pcapng files. - Answer quiz questions. The course is very practical. You can practice while you learn! Learn how to analyze and interpret network protocols and leverage Wireshark for what it was originally intended: Deep Packet Inspection and network analysis. Protocols we capture and discuss in this course include: - Telnet - FTP - TFTP - HTTP - VoIP - OSPF - EIGRP - DNS - ICMP Who this course is for: Network Engineers Network Architects Ethical hackers Networking Students #CCNA #Wireshark #Hacking

We recap EuroBSDcon in Paris, tell the story behind a pf PR, and show you how to do screencasting with OpenBSD. This episode was brought to you by Headlines Recap of EuroBSDcon 2017 in Paris, France (https://2017.eurobsdcon.org) EuroBSDcon was held in Paris, France this year, which drew record numbers this year. With over 300 attendees, it was the largest BSD event I have ever attended, and I was encouraged by the higher than expected number of first time attendees. The FreeBSD Foundation held a board meeting on Wednesday afternoon with the members who were in Paris. Topics included future conferences (including a conference kit we can mail to people who want to represent FreeBSD) and planning for next year. The FreeBSD Devsummit started on Thursday at the beautiful Mozilla Office in Paris. After registering and picking up our conference bag, everyone gathered for a morning coffee with lots of handshaking and greeting. We then gathered in the next room which had a podium with microphone, screens as well as tables and chairs. After developers sat down, Benedict opened the devsummit with a small quiz about France for developers to win a Mogics Power Bagel (https://www.mogics.com/?page_id=3824). 45 developers participated and DES won the item in the end. After introductions and collecting topics of interest from everyone, we started with the Work in Progress (WIP) session. The WIP session had different people present a topic they are working on in 7 minute timeslots. Topics ranged from FreeBSD Forwarding Performance, fast booting options, and a GELI patch under review to attach multiple providers. See their slides on the FreeBSD wiki (https://wiki.freebsd.org/DevSummit/201709). After lunch, the FreeBSD Foundation gave a general update on staff and funding, as well as a more focused presentation about our partnership with Intel. People were interested to hear what was done so far and asked a few questions to the Intel representative Glenn Weinberg. After lunch, developers worked quietly on their own projects. The mic remained open and occasionally, people would step forward and gave a short talk without slides or motivated a discussion of common interest. The day concluded with a dinner at a nice restaurant in Paris, which allowed to continue the discussions of the day. The second day of the devsummit began with a talk about the CAM-based SDIO stack by Ilya Bakulin. His work would allow access to wifi cards/modules on embedded boards like the Raspberry Pi Zero W and similar devices as many of these are using SDIO for data transfers. Next up was a discussion and Q&A session with the FreeBSD core team members who were there (missing only Benno Rice, Kris Moore, John Baldwin, and Baptiste Daroussin, the latter being busy with conference preparations). The new FCP (FreeBSD community proposals) were introduced for those who were not at BSDCan this year and the hows and whys about it. Allan and I were asked to describe our experiences as new members of core and we encouraged people to run for core when the next election happens. After a short break, Scott Long gave an overview of the work that's been started on NUMA (Non-Uniform Memory Architecture), what the goals of the project are and who is working on it. Before lunch, Christian Schwarz presented his work on zrepl, a new ZFS replication solution he developed using Go. This sparked interest in developers, a port was started (https://reviews.freebsd.org/D12462) and people suggested to Christian that he should submit his talk to AsiaBSDcon and BSDCan next year. Benedict had to leave before lunch was done to teach his Ansible tutorial (which was well attended) at the conference venue. There were organized dinners, for those two nights, quite a feat of organization to fit over 100 people into a restaurant and serve them quickly. On Saturday, there was a social event, a river cruise down the Seine. This took the form of a ‘standing' dinner, with a wide selection of appetizer type dishes, designed to get people to walk around and converse with many different people, rather than sit at a table with the same 6-8 people. I talked to a much larger group of people than I had managed to at the other dinners. I like having both dinner formats. We would also like to thank all of the BSDNow viewers who attended the conference and made the point of introducing themselves to us. It was nice to meet you all. The recordings of the live video stream from the conference are available immediately, so you can watch the raw versions of the talks now: Auditorium Keynote 1: Software Development in the Age of Heroes (https://youtu.be/4iR8g9-39LM?t=179) by Thomas Pornin (https://twitter.com/BearSSLnews) Tuning FreeBSD for routing and firewalling (https://youtu.be/4iR8g9-39LM?t=1660) by Olivier Cochard-Labbé (https://twitter.com/ocochardlabbe) My BSD sucks less than yours, Act I (https://youtu.be/4iR8g9-39LM?t=7040) by Antoine Jacoutot (https://twitter.com/ajacoutot) and Baptiste Daroussin (https://twitter.com/_bapt_) My BSD sucks less than yours, Act II (https://youtu.be/4iR8g9-39LM?t=14254) by Antoine Jacoutot (https://twitter.com/ajacoutot) and Baptiste Daroussin (https://twitter.com/_bapt_) Reproducible builds on NetBSD (https://youtu.be/4iR8g9-39LM?t=23351) by Christos Zoulas Your scheduler is not the problem (https://youtu.be/4iR8g9-39LM?t=26845) by Martin Pieuchot Keynote 2: A French story on cybercrime (https://youtu.be/4iR8g9-39LM?t=30540) by Éric Freyssinet (https://twitter.com/ericfreyss) Case studies of sandboxing base system with Capsicum (https://youtu.be/jqdHYEH_BQY?t=731) by Mariusz Zaborski (https://twitter.com/oshogbovx) OpenBSD's small steps towards DTrace (a tale about DDB and CTF) (https://youtu.be/jqdHYEH_BQY?t=6030) by Jasper Lievisse Adriaanse The Realities of DTrace on FreeBSD (https://youtu.be/jqdHYEH_BQY?t=13096) by George Neville-Neil (https://twitter.com/gvnn3) OpenSMTPD, current state of affairs (https://youtu.be/jqdHYEH_BQY?t=16818) by Gilles Chehade (https://twitter.com/PoolpOrg) Hoisting: lessons learned integrating pledge into 500 programs (https://youtu.be/jqdHYEH_BQY?t=21764) by Theo de Raadt Keynote 3: System Performance Analysis Methodologies (https://youtu.be/jqdHYEH_BQY?t=25463) by Brendan Gregg (https://twitter.com/brendangregg) Closing Session (https://youtu.be/jqdHYEH_BQY?t=29355) Karnak “Is it done yet ?” The never ending story of pkg tools (https://youtu.be/1hjzleqGRYk?t=71) by Marc Espie (https://twitter.com/espie_openbsd) A Tale of six motherboards, three BSDs and coreboot (https://youtu.be/1hjzleqGRYk?t=7498) by Piotr Kubaj and Katarzyna Kubaj State of the DragonFly's graphics stack (https://youtu.be/1hjzleqGRYk?t=11475) by François Tigeot From NanoBSD to ZFS and Jails – FreeBSD as a Hosting Platform, Revisited (https://youtu.be/1hjzleqGRYk?t=16227) by Patrick M. Hausen Bacula – nobody ever regretted making a backup (https://youtu.be/1hjzleqGRYk?t=20069) by Dan Langille (https://twitter.com/DLangille) Never Lose a Syslog Message (https://youtu.be/qX0BS4P65cQ?t=325) by Alexander Bluhm Running CloudABI applications on a FreeBSD-based Kubernetes cluster (https://youtu.be/qX0BS4P65cQ?t=5647) by Ed Schouten (https://twitter.com/EdSchouten) The OpenBSD web stack (https://youtu.be/qX0BS4P65cQ?t=13255) by Michael W. Lucas (https://twitter.com/mwlauthor) The LLDB Debugger on NetBSD (https://youtu.be/qX0BS4P65cQ?t=16835) by Kamil Rytarowski What's in store for NetBSD 8.0? (https://youtu.be/qX0BS4P65cQ?t=21583) by Alistair Crooks Louxor A Modern Replacement for BSD spell(1) (https://youtu.be/6Nen6a1Xl7I?t=156) by Abhinav Upadhyay (https://twitter.com/abhi9u) Portable Hotplugging: NetBSD's uvm_hotplug(9) API development (https://youtu.be/6Nen6a1Xl7I?t=5874) by Cherry G. Mathew Hardening pkgsrc (https://youtu.be/6Nen6a1Xl7I?t=9343) by Pierre Pronchery (https://twitter.com/khorben) Discovering OpenBSD on AWS (https://youtu.be/6Nen6a1Xl7I?t=14874) by Laurent Bernaille (https://twitter.com/lbernail) OpenBSD Testing Infrastructure Behind bluhm.genua.de (https://youtu.be/6Nen6a1Xl7I?t=18639) by Jan Klemkow The school of hard knocks – PT1 (https://youtu.be/8wuW8lfsVGc?t=276) by Sevan Janiyan (https://twitter.com/sevanjaniyan) 7 years of maintaining firefox, and still looking ahead (https://youtu.be/8wuW8lfsVGc?t=5321) by Landry Breuil Branch VPN solution based on OpenBSD, OSPF, RDomains and Ansible (https://youtu.be/8wuW8lfsVGc?t=12385) by Remi Locherer Running BSD on AWS (https://youtu.be/8wuW8lfsVGc?t=15983) by Julien Simon and Nicolas David Getting started with OpenBSD device driver development (https://youtu.be/8wuW8lfsVGc?t=21491) by Stefan Sperling A huge thanks to the organizers, program committee, and sponsors of EuroBSDCon. Next year, EuroBSDcon will be in Bucharest, Romania. *** The story of PR 219251 (https://www.sigsegv.be//blog/freebsd/PR219251) The actual story I wanted Kristof to tell, the pf bug he fixed at the Essen Hackathon earlier this summer. As I threatened to do in my previous post, I'm going to talk about PR 219251 for a bit. The bug report dates from only a few months ago, but the first report (that I can remeber) actually came from Shawn Webb on Twitter, of all places Despite there being a stacktrace it took quite a while (nearly 6 months in fact) before I figured this one out. It took Reshad Patuck managing to distill the problem down to a small-ish test script to make real progress on this. His testcase meant that I could get core dumps and experiment. It also provided valuable clues because it could be tweaked to see what elements were required to trigger the panic. This test script starts a (vnet) jail, adds an epair interface to it, sets up pf in the jail, and then reloads the pf rules on the host. Interestingly the panic does not seem to occur if that last step is not included. Obviously not the desired behaviour, but it seems strange. The instances of pf in the jails are supposed to be separate. We try to fetch a counter value here, but instead we dereference a bad pointer. There's two here, so already we need more information. Inspection of the core dump reveals that the state pointer is valid, and contains sane information. The rule pointer (rule.ptr) points to a sensible location, but the data is mostly 0xdeadc0de. This is the memory allocator being helpful (in debug mode) and writing garbage over freed memory, to make use-after-free bugs like this one easier to find. In other words: the rule has been free()d while there was still a state pointing to it. Somehow we have a state (describing a connection pf knows about) which points to a rule which no longer exists. The core dump also shows that the problem always occurs with states and rules in the default vnet (i.e. the host pf instance), not one of the pf instances in one of the vnet jails. That matches with the observation that the test script does not trigger the panic unless we also reload the rules on the host. Great, we know what's wrong, but now we need to work out how we can get into this state. At this point we're going to have to learn something about how rules and states get cleaned up in pf. Don't worry if you had no idea, because before this bug I didn't either. The states keep a pointer to the rule they match, so when rules are changed (or removed) we can't just delete them. States get cleaned up when connections are closed or they time out. This means we have to keep old rules around until the states that use them expire. When rules are removed pfunlinkrule() adds then to the Vpfunlinkedrules list (more on that funny V prefix later). From time to time the pf purge thread will run over all states and mark the rules that are used by a state. Once that's done for all states we know that all rules that are not marked as in-use can be removed (because none of the states use it). That can be a lot of work if we've got a lot of states, so pfpurgethread() breaks that up into smaller chuncks, iterating only part of the state table on every run. We iterate over all of our virtual pf instances (VNETFOREACH()), check if it's active (for FreeBSD-EN-17.08, where we've seen this code before) and then check the expired states with pfpurgeexpiredstates(). We start at state 'idx' and only process a certain number (determined by the PFTMINTERVAL setting) states. The pfpurgeexpiredstates() function returns a new idx value to tell us how far we got. So, remember when I mentioned the odd V_ prefix? Those are per-vnet variables. They work a bit like thread-local variables. Each vnet (virtual network stack) keeps its state separate from the others, and the V_ variables use a pointer that's changed whenever we change the currently active vnet (say with CURVNETSET() or CURVNETRESTORE()). That's tracked in the 'curvnet' variable. In other words: there are as many Vpfvnetactive variables as there are vnets: number of vnet jails plus one (for the host system). Why is that relevant here? Note that idx is not a per-vnet variable, but we handle multiple pf instances here. We run through all of them in fact. That means that we end up checking the first X states in the first vnet, then check the second X states in the second vnet, the third X states in the third and so on and so on. That of course means that we think we've run through all of the states in a vnet while we really only checked some of them. So when pfpurgeunlinkedrules() runs it can end up free()ing rules that actually are still in use because pfpurgethread() skipped over the state(s) that actually used the rule. The problem only happened if we reloaded rules in the host, because the active ruleset is never free()d, even if there are no states pointing to the rule. That explains the panic, and the fix is actually quite straightforward: idx needs to be a per-vnet variable, Vpfpurge_idx, and then the problem is gone. As is often the case, the solution to a fairly hard problem turns out to be really simple. As you might expect, finding the problem takes a lot more work that fixing it Thanks to Kristof for writing up this detailed post explaining how the problem was found, and what caused it. *** vBSDcon 2017: BSD at Work (https://www.ixsystems.com/blog/vbsdcon-2017-dexter/) The third biennial vBSDcon hosted by Verisign took place September 7th through 9th with the FreeBSD Developer Summit taking place the first day. vBSDcon and iXsystems' MeetBSD event have been alternating between the East and West coasts of the U.S.A. and these two events play vital roles in reaching Washington, DC-area and Bay Area/Silicon Valley audiences. Where MeetBSD serves many BSD Vendors, vBSDcon attracts a unique government and security industry demographic that isn't found anywhere else. Conference time and travel budgets are always limited and bringing these events to their attendees is a much-appreciated service provided by their hosts. The vBSDcon FreeBSD DevSummit had a strong focus on OpenZFS, the build system and networking with the FreeBSD 12 wish list of features in mind. How to best incorporate the steady flow of new OpenZFS features into FreeBSD such as dataset-level encryption was of particular interest. This feature from a GNU/Linux-based storage vendor is tribute to the growth of the OpenZFS community which is vital in light of the recent “Death of Solaris and ZFS” at Oracle. There has never been more demand for OpenZFS on FreeBSD and the Oracle news further confirms our collective responsibility to meet that demand. The official conference opened with my talk on “Isolated BSD Build Environments” in which I explained how the bhyve hypervisor can be used to effortlessly tour FreeBSD 5.0-onward and build specific source releases on demand to trace regressions to their offending commit. I was followed by a FreeNAS user who made the good point that FreeNAS is an exemplary “entry vector” into Unix and Enterprise Storage fundamentals, given that many of the vectors our generation had are gone. Where many of us discovered Unix and the Internet via console terminals at school or work, smart phones are only delivering the Internet without the Unix. With some irony, both iOS and Android are Unix-based yet offer few opportunities for their users to learn and leverage their Unix environments. The next two talks were The History and Future of Core Dumps in FreeBSD by Sam Gwydir and Using pkgsrc for multi-platform deployments in heterogeneous environments by G. Clifford Williams. I strongly recommend that anyone wanting to speak at AsiaBSDCon read Sam's accompanying paper on core dumps because I consider it the perfect AsiaBSDCon topic and his execution is excellent. Core dumps are one of those things you rarely think about until they are a DROP EVERYTHING! priority. G. Clifford's talk was about what I consider a near-perfect BSD project: pkgsrc, the portable BSD package manager. I put it up there with OpenSSH and mandoc as projects that have provided significant value to other Open Source operating systems. G. Clifford's real-world experiences are perfectly inline with vBSDcon's goal to be more production-oriented than other BSDCons. Of the other talks, any and all Dtrace talks are always appreciated and George Neville-Neil's did not disappoint. He based it on his experiences with the Teach BSD project which is bringing FreeBSD-based computer science education to schools around the world. The security-related talks by John-Mark Gurney, Dean Freeman and Michael Shirk also represented vBSDcon's consideration of the local community and made a convincing point that the BSDs should make concerted efforts to qualify for Common Criteria, FIPS, and other Government security requirements. While some security experts will scoff at these, they are critical to the adoption of BSD-based products by government agencies. BSD Now hosts Allan Jude and Benedict Reuschling hosted an OpenZFS BoF and Ansible talk respectively and I hosted a bhyve hypervisor BoF. The Hallway Track and food at vBSDcon were excellent and both culminated with an after-dinner dramatic reading of Michael W. Lucas' latest book that raised money for the FreeBSD Foundation. A great time was had by all and it was wonderful to see everyone! News Roundup FreeBSD 10.4-RC2 Available (https://lists.freebsd.org/pipermail/freebsd-stable/2017-September/087848.html) FreeBSD 10.4 will be released soon, this is the last chance to find bugs before the official release is cut. Noteworthy Changes Since 10.4-RC1: Given that the amd64 disc1 image was overflowing, more of the base components installed into the disc1 (live) file systems had to be disabled. Most notably, this removed the compiler toolchain from the disc1 images. All disabled tools are still available with the dvd1 images, though. The aesni(4) driver now no longer shares a single FPU context across multiple sessions in multiple threads, addressing problems seen when employing aesni(4) for ipsec(4). Support for netmap(4) by the ixgbe(4) driver has been brought into line with the netmap(4) API present in stable/10. Also, ixgbe(4) now correctly handles VFs in its netmap(4) support again instead of treating these as PFs. During the creation of amd64 and i386 VM images, etcupdate(8) and mergemaster(8) databases now are bootstrapped, akin to what happens along the extraction of base.txz as part of a new installation via bsdinstall(8). This change allows for both of these tools to work out-of-box on the VM images and avoids errors seen when upgrading these images via freebsd-update(8). If you are still on the stable/10 branch, you should test upgrading to 10.4, and make sure there are no problems with your workload Additional testing specifically of the features that have changed since 10.4-BETA1 would also be most helpful This will be the last release from the stable/10 branch *** OpenBSD changes of note 628 (https://www.tedunangst.com/flak/post/openbsd-changes-of-note-628) EuroBSDCon in two weeks. Be sure to attend early and often. Many and various documentation improvements for libcrypto. New man pages, rewrites, expanded bugs sections, and more. Only allow upward migration in vmd. There's a README for the syspatch build system if you want to run your own. Move the kernel relinking code from /etc/rc into a seperate script usable by syspatch. Kernel patches can now be reduced to just the necessary files. Make the callers of sogetopt() responsible for allocating memory. Now allocation and free occur in the same place. Use waitpid() instead of wait() in most programs to avoid accidentally collecting the wrong child. Have cu call isatty() before making assumptions. Switch mandoc rendering of mathematical symbols and greek letters from trying to imitate the characters' graphical shapes, which resulted in unintelligible renderings in many cases, to transliterations conveying the characters' meanings. Update libexpat to 2.2.4. Fix copying partial UTF-8 characters. Sigh, here we go again. Work around bug in F5's handling of the supported elliptic curves extension. RFC 4492 only defines elliptic_curves for ClientHello. However, F5 is sending it in ServerHello. We need to skip over it since our TLS extension parsing code is now more strict. After a first install, run syspatch -c to check for patches. If SMAP is present, clear PSL_AC on kernel entry and interrupt so that only the code in copy{in,out}* that need it run with it set. Panic if it's set on entry to trap() or syscall(). Prompted by Maxime Villard's NetBSD work. Errata. New drivers for arm: rktemp, mvpinctrl, mvmpic, mvneta, mvmdio, mvpxa, rkiic, rkpmic. No need to exec rm from within mandoc. We know there's exactly one file and directory to remove. Similarly with running cmp. Revert to Mesa 13.0.6 to hopefully address rendering issues a handful of people have reported with xpdf/fvwm on ivy bridge with modesetting driver. Rewrite ALPN extension using CBB/CBS and the new extension framework. Rewrite SRTP extension using CBB/CBS and the new extension framework. Revisit 2q queue sizes. Limit the hot queue to 1/20th the cache size up to a max of 4096 pages. Limit the warm and cold queues to half the cache. This allows us to more effectively notice re-interest in buffers instead of losing it in a large hot queue. Add glass console support for arm64. Probably not yet for your machine, though. Replace heaps of hand-written syscall stubs in ld.so with a simpler framework. 65535 is a valid port to listen on. When xinit starts an X server that listens only on UNIX socket, prefer DISPLAY=unix:0 rather than DISPLAY=:0. This will prevent applications from ever falling back to TCP if the UNIX socket connection fails (such as when the X server crashes). Reverted. Add -z and -Z options to apmd to auto suspend or hibernate when low on battery. Remove the original (pre-IETF) chacha20-poly1305 cipher suites. Add urng(4) which supports various USB RNG devices. Instead of adding one driver per device, start bundling them into a single driver. Remove old deactivated pledge path code. A replacement mechanism is being brewed. Fix a bug from the extension parsing rewrite. Always parse ALPN even if no callback has been installed to prevent leaving unprocessed data which leads to a decode error. Clarify what is meant by syslog priorities being ordered, since the numbers and priorities are backwards. Remove a stray setlocale() from ksh, eliminating a lot of extra statically linked code. Unremove some NPN symbols from libssl because ports software thinks they should be there for reasons. Fix saved stack location after resume. Somehow clang changed it. Resume works again on i386. Improve error messages in vmd and vmctl to be more informative. Stop building the miniroot installer for OMAP3 Beagleboards. It hasn't worked in over a year and nobody noticed. Have the callers of sosetopt() free the mbuf for symmetry. On octeon, let the kernel use the hardware FPU even if emulation is compiled in. It's faster. Fix support for 486DX CPUs by not calling cpuid. I used to own a 486. Now I don't. Merge some drm fixes from linux. Defer probing of floppy drives, eliminating delays during boot. Better handling of probes and beacons and timeouts and scans in wifi stack to avoid disconnects. Move mutex, condvar, and thread-specific data routes, pthreadonce, and pthreadexit from libpthread to libc, along with low-level bits to support them. Let's thread aware (but not actually threaded) code work with just libc. New POSIX xlocale implementation. Complete as long as you only use ASCII and UTF-8, as you should. Round and round it goes; when 6.2 stops, nobody knows. A peak at the future? *** Screencasting with OpenBSD (http://eradman.com/posts/screencasting.html) USB Audio Any USB microphone should appear as a new audio device. Here is the dmesg for my mic by ART: uaudio0 at uhub0 port 2 configuration 1 interface 0 "M-One USB" rev 1.10/0.01 addr 2 uaudio0: audio rev 1.00, 8 mixer controls audio1 at uaudio0 audioctl can read off all of the specific characterisitcs of this device $ audioctl -f /dev/audio1 | grep record mode=play,record record.rate=48000 record.channels=1 record.precision=16 record.bps=2 record.msb=1 record.encoding=slinear_le record.pause=0 record.active=0 record.block_size=1960 record.bytes=0 record.errors=0 Now test the recording from the second audio device using aucat(1) aucat -f rsnd/1 -o file.wav If the device also has a headset audio can be played through the same device. aucat -f rsnd/1 -i file.wav Screen Capture using Xvfb The rate at which a framebuffer for your video card is a feature of the hardware and software your using, and it's often very slow. x11vnc will print an estimate of the banwidth for the system your running. x11vnc ... 09/05/2012 22:23:45 fb read rate: 7 MB/sec This is about 4fps. We can do much better by using a virtual framebuffer. Here I'm setting up a new screen, setting the background color, starting cwm and an instance of xterm Xvfb :1 -screen 0 720x540x16 & DISPLAY=:1 xsetroot -solid steelblue & DISPLAY=:1 cwm & DISPLAY=:1 xterm +sb -fa Hermit -fs 14 & Much better! Now we're up around 20fps. x11vnc -display :1 & ... 11/05/2012 18:04:07 fb read rate: 168 MB/sec Make a connection to this virtual screen using raw encoding to eliminate time wasted on compression. vncviewer localhost -encodings raw A test recording with sound then looks like this ffmpeg -f sndio -i snd/1 -y -f x11grab -r 12 -s 800x600 -i :1.0 -vcodec ffv1 ~/out.avi Note: always stop the recording and playback using q, not Ctrl-C so that audio inputs are shut down properly. Screen Capture using Xephyr Xephyr is perhaps the easiest way to run X with a shadow framebuffer. This solution also avoids reading from the video card's RAM, so it's reasonably fast. Xephyr -ac -br -noreset -screen 800x600 :1 & DISPLAY=:1 xsetroot -solid steelblue & DISPLAY=:1 cwm & DISPLAY=:1 xrdb -load ~/.Xdefaults & DISPLAY=:1 xterm +sb -fa "Hermit" -fs 14 & Capture works in exactally the same way. This command tries to maintain 12fps. ffmpeg -f sndio -i snd/1 -y -f x11grab -r 12 -s 800x600 -i :1.0 -vcodec ffv1 -acodec copy ~/out.avi To capture keyboard and mouse input press Ctrl then Shift. This is very handy for using navigating a window manager in the nested X session. Arranging Windows I have sometimes found it helpful to launch applications and arrange them in a specific way. This will open up a web browser listing the current directory and position windows using xdotool DISPLAY=:1 midori "file:///pwd" & sleep 2 DISPLAY=:1 xdotool search --name "xterm" windowmove 0 0 DISPLAY=:1 xdotool search --class "midori" windowmove 400 0 DISPLAY=:1 xdotool search --class "midori" windowsize 400 576 This will position the window precisely so that it appears to be in a tmux window on the right. Audio/Video Sync If you find that the audio is way out of sync with the video, you can ajust the start using the -ss before the audio input to specify the number of seconds to delay. My final recording command line, that delays the audio by 0.5 seconds, writing 12fps ffmpeg -ss 0.5 -f sndio -i snd/1 -y -f x11grab -r 12 -s 800x600 -i :1.0 -vcodec ffv1 -acodec copy ~/out.avi Sharing a Terminal with tmux If you're trying to record a terminal session, tmux is able to share a session. In this way a recording of an X framebuffer can be taken without even using the screen. Start by creating the session. tmux -2 -S /tmp/tmux0 Then on the remote side connect on the same socket tmux -2 -S /tmp/tmux0 attach Taking Screenshots Grabbing a screenshots on Xvfb server is easily accomplished with ImageMagick's import command DISPLAY=:1 import -window root screenshot.png Audio Processing and Video Transcoding The first step is to ensure that the clip begins and ends where you'd like it to. The following will make a copy of the recording starting at time 00:00 and ending at 09:45 ffmpeg -i interactive-sql.avi -vcodec copy -acodec copy -ss 00:00:00 -t 00:09:45 interactive-sql-trimmed.avi mv interactive-sql-trimmed.avi interactive-sql.avi Setting the gain correctly is very important with an analog mixer, but if you're using a USB mic there may not be a gain option; simply record using it's built-in settings and then adjust the levels afterwards using a utility such as normalize. First extact the audio as a raw PCM file and then run normalize ffmpeg -i interactive-sql.avi -c:a copy -vn audio.wav normalize audio.wav Next merge the audio back in again ffmpeg -i interactive-sql.avi -i audio.wav -map 0:0 -map 1:0 -c copy interactive-sql-normalized.avi The final step is to compress the screencast for distribution. Encoding to VP8/Vorbis is easy: ffmpeg -i interactive-sql-normalized.avi -c:v libvpx -b:v 1M -c:a libvorbis -q:a 6 interactive-sql.webm H.264/AAC is tricky. For most video players the color space needs to be set to yuv420p. The -movflags puts the index data at the beginning of the file to enable streaming/partial content requests over HTTP: ffmpeg -y -i interactive-sql-normalized.avi -c:v libx264 -preset slow -crf 14 -pix_fmt yuv420p -movflags +faststart -c:a aac -q:a 6 interactive-sql.mp4 TrueOS @ Ohio Linuxfest '17! (https://www.trueos.org/blog/trueos-ohio-linuxfest-17/) Dru Lavigne and Ken Moore are both giving presentations on Saturday the 30th. Sit in and hear about new developments for the Lumina and FreeNAS projects. Ken is offering Lumina Rising: Challenging Desktop Orthodoxy at 10:15 am in Franklin A. Hear his thoughts about the ideas propelling desktop environment development and how Lumina, especially Lumina 2, is seeking to offer a new model of desktop architecture. Elements discussed include session security, application dependencies, message handling, and operating system integration. Dru is talking about What's New in FreeNAS 11 at 2:00 pm in Franklin D. She'll be providing an overview of some of the new features added in FreeNAS 11.0, including: Alert Services Starting specific services at boot time AD Monitoring to ensure the AD service restarts if disconnected A preview of the new user interface support for S3-compatible storage and the bhyve hypervisor She's also giving a sneak peek of FreeNAS 11.1, which has some neat features: A complete rewrite of the Jails/Plugins system as FreeNAS moves from warden to iocage Writing new plugins with just a few lines of code A brand new asynchronous middleware API Who's going? Attending this year are: Dru Lavigne (dlavigne): Dru leads the technical documentation team at iX, and contributes heavily to open source documentation projects like FreeBSD, FreeNAS, and TrueOS. Ken Moore (beanpole134): Ken is the lead developer of Lumina and a core contributor to TrueOS. He also works on a number of other Qt5 projects for iXsystems. J.T. Pennington (q5sys): Some of you may be familiar with his work on BSDNow, but J.T. also contributes to the TrueOS, Lumina, and SysAdm projects, helping out with development and general bug squashing. *** Beastie Bits Lumina Development Preview: Theme Engine (https://www.trueos.org/blog/lumina-development-preview-theme-engine/) It's happening! Official retro Thinkpad lappy spotted in the wild (https://www.theregister.co.uk/2017/09/04/retro_thinkpad_spotted_in_the_wild/) LLVM libFuzzer and SafeStack ported to NetBSD (https://blog.netbsd.org/tnf/entry/llvm_libfuzzer_and_safestack_ported) Remaining 2017 FreeBSD Events (https://www.freebsdfoundation.org/news-and-events/event-calendar/2017-openzfs-developer-summit/) *** Feedback/Questions Andrew - BSD Teaching Material (http://dpaste.com/0YTT0VP) Seth - Switching to Tarsnap after Crashplan becomes no more (http://dpaste.com/1SK92ZX#wrap) Thomas - Native encryption in ZFS (http://dpaste.com/02KD5FX#wrap) Coding Cowboy - Coding Cowboy - Passwords and clipboards (http://dpaste.com/31K0E40#wrap) ***