routing protocol for IP networks
POPULARITY
41 episodes with ospf
14 episodes with ospf
4 episodes with ospf
4 episodes with ospf
6 episodes with ospf
3 episodes with ospf
2 episodes with ospf
3 episodes with ospf
2 episodes with ospf
Ethan and Holly continue their OSPF journey this week with OSPF Network Types. They discuss the two main OSPF network types used today: the broadcast and point to point networks. They also explain designated routers, backup designated routers, and when those are used and why. Lastly they discuss some soft skills – knowing your vendor... Read more »
Ethan and Holly continue their OSPF journey this week with OSPF Network Types. They discuss the two main OSPF network types used today: the broadcast and point to point networks. They also explain designated routers, backup designated routers, and when those are used and why. Lastly they discuss some soft skills – knowing your vendor... Read more »
Our OSPF series continues with a look at OSPF neighbor formation and related timers. We talk about the five major packet types that carry information among OSPF routers, how OSPF routers become neighbors, how they negotiate link-state database exchanges, keep-alive messages, and how they negotiate designated and backup routers when multiple devices are on the... Read more »
Our OSPF series continues with a look at OSPF neighbor formation and related timers. We talk about the five major packet types that carry information among OSPF routers, how OSPF routers become neighbors, how they negotiate link-state database exchanges, keep-alive messages, and how they negotiate designated and backup routers when multiple devices are on the... Read more »
By popular request (and now that we have some other background topics covered) we start our series on the Open Shortest Path First (OSPF) routing protocol. We kick off the series with OSPF basics including Link State Advertisements, Link State Database, and other related essentials. We’ll explore additional OSPF topics over subsequent episodes. This week’s... Read more »
By popular request (and now that we have some other background topics covered) we start our series on the Open Shortest Path First (OSPF) routing protocol. We kick off the series with OSPF basics including Link State Advertisements, Link State Database, and other related essentials. We’ll explore additional OSPF topics over subsequent episodes. This week’s... 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 »
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!
Configuration Examples with KevTechify for the Cisco Certified Network Associate (CCNA)
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
Configuration Examples with KevTechify for the Cisco Certified Network Associate (CCNA)
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
Configuration Examples with KevTechify for the Cisco Certified Network Associate (CCNA)
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
Configuration Examples with KevTechify for the Cisco Certified Network Associate (CCNA)
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
Configuration Examples with KevTechify for the Cisco Certified Network Associate (CCNA)
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
Configuration Examples with KevTechify for the Cisco Certified Network Associate (CCNA)
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
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
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) ***
© 2020-2025 Ivy Podcast Discovery LLC
