Packet Pushers - Priority Queue

On today Priority Queue podcast, sponsor Juniper walks us through use case for its Contrail Edge Cloud software. We also cover the deployment and operation of this software solution. Our guest is Nick Davey, Product Line Manager at Juniper.

In today’s sponsored show with Juniper Networks, we dive into the world of silicon and ASICs. Our guest is Chang-Hong Wu, a VP and Juniper Fellow.

The Packet Pushers start the conversation by breaking down the differences between ASICs, FPGAs, and NPUs.

We discuss how Juniper uses both custom and merchant silicon in its gear. We also examine how Juniper enables programmability in its Penta ASIC, and how that compares to its fixed-pipeline Express ASIC.

Chang-Hong dives into the programmability features and capabilities of the Penta, and explains how use cases determine which ASIC Juniper chooses to go in which devices.

He also discusses advanced silicon designs such as silicon photonics and liquid cooling.

This episode is a great opportunity to get up to speed on networking ASICs.

Show Links:

Networking Innovation Built to Contend with the Unknowns  – Juniper Blog

Trio Packet Processing – Overview – Juniper Blog

Whitebox network hardware paired with disaggregation has created a market for network operating systems.

One of the latest entrants to that market is Arrcus, which launched in 2018 with guns blazing, claiming that its ArcOS® NOS is so strong it should be mentioned in the same breath as operating systems from Cisco, Juniper, and Arista.

Today, Arrcus has sponsored the podcast, and we’re going to have a discussion about ArcOS®. Why another NOS? What’s special about ArcOS®? What use cases is it best suited for?

Joining us from Arrcus are Keyur Patel, CTO and Murali Gandluru, VP of Product Management.

We discuss how ArcOS® was designed from first principles to support routing and switching, and is built around a microservices, scale-out architecture.

We also examine how it meets emerging demands for 5G and distributed data center and edge architectures; the different chipsets it can run on; how it differentiates itself from network OSs from Cisco, Arista, and others; and look at key use cases.

Show Links:

ArcOS® Website – Arrcus

Arrcus Blog

Arrcus Videos

Arrcus News

Arrcus Whitepapers (ArcOS Security, ArcOS DPAL)

ArcOS® At-a-Glance (PDF)

Arrcus and Broadcom: Partnering to power smart network infrastructure (Webinar)

Arrcus on LinkedIn

Arrcus on Twitter

In Priority Queue 154, we chatted with PC Drew about the challenges of standing up a fully operational network in the middle of nowhere.

That’s standard operating procedure for the military as they fulfill their combat and humanitarian missions around the world.

In this episode, we’re going to go deeper on one facet of that conversation, satellite communications. PC Drew is back, and he brought along a colleague, Evander Cook, to educate us on SATCOM.

PC is Chief Technology Officer at SchoolBlocks, and Evander is Director of Network Operations at the United States Marine Corps.

We discuss basic concepts including frequency bands, TDMA vs. FDMA, satellite coverage areas, and the relationship between signal quality and signal power.

PC and Evander also explain how different satellite orbits affect network design, the different kinds of military and commercial services available, and how to account for moving vehicles in satellite communications.

Sponsor: Packet Pushers Virtual Design Clinic

Join the Packet Pushers for our next Virtual Design Clinic on December 19th, 2018. This live, free virtual event includes presentations on continuous integration and continuous testing for networking, and the impact of NVMe over Fabrics to network design. We’ll also have a panel of experts to partipate in“ask me anything” segments. Celebrate the holiday change freeze by registering at packetpushers.net/vdc.

Show Links:

PQ 154: Design Challenges In Military Networks – Packet Pushers

Orbital Altitudes of many significant satellites of earth – Wikipedia (jpg)

One problem with learning networking technology is all the work it takes to set up your lab. Creating a virtualization environment, fighting with images, tweaking performance, building out the connections, and so on.

What if there was a tool that handled the set up burden for you? A tool where you could jump right in and start learning?

Our guests today tell us about a new online tool that does just that. Called NRE Labs, this Web site provides education and training for network automation.

You can learn the basics of YAML, Git, and working with APIs, try out automation tools, walk through lessons, or simply experiment with virtual instances of real networking interfaces.

Developed and supported by Juniper Networks, NRE Labs is free and open source, and welcomes contributions to the project. You don’t have to register or even log in to use the site; just show up and jump in.

Matt Oswalt and Derick Winkworth, both Product Marketing Managers and Juniper, are two of NRE Labs’ creators. They join us on the podcast to walk us through the site.

Sponsor: Packet Pushers Virtual Design Clinic 3

Join the Packet Pushers and special guests on December 19th for a live, online Virtual Design Clinic. See presentations on network design for NVMe fabrics, CI/CD for networking, and get your networking questions answered by our panel of experts. Sign up now for this free event.

Show Links:

NRE Labs

Antidote (NRE Labs OSS) – GitHub

Antidote Docs

Juniper Engnet – Juniper Networks

Keeping It Classless – Matt Oswalt’s blog

On today’s Packet Pushers episode, we dive into the guts of Cisco’s IOS-XR. What does it mean for IOS-XR to be carrier-grade? What kinds of problems need to be solved by large service providers? How does the architecture of IOS-XR solve them?

Cisco is our sponsor for this deconstruction of the NOS. Our guests are Jag Tangirala, Principal Engineer; and Praveen Bhagwatula, Distinguished Engineer.

We start by examining the scalability, performance and reliability requirements that carries and service providers demand, and then drill into IOS-XR’s architecture.

We break out the control, data, management and infrastructure planes and look at the role of abstraction in a network OS.

Our guests delve into what state means in the context of a network OS. We look at how IOS-XR captures and communicates state to the processes that need it using tools such as SysDB and an event notification system.

The discussion also tracks what happens if a process crashes and how the system recovers, and we look at how IOS-XR gets updated.

Join us for a truly deep dive into this OS. And get more details on IOS-XR at @xrdocs.io.

On today's Priority Queue, wireless engineer Lee Badman shares a real-world detective tale about a troubleshooting problem that took him into dark places involving wires.

This Priority Queue was recorded live at the Future:Net conference at VMworld 2018. Guests Bruce Davie and Guido Appenzeller discuss service meshes, differences between hybrid and multicloud, intrinsic security, intent-based networking and more.

Imagine you’ve got to build a network that delivers data no matter what, because the mission is critical.

And not just “mission critical” in the business sense–sometimes actual lives are at stake.

However, the constraints are enormous. All you’ve got to work with are satellite links with high latency and low throughput, no terrestrial infrastructure unless you provide it yourself, the very highest imaginable security requirements, and a limited budget.

This scenario is normal for the military. Here to chat with us about networking in this highly specialized environment is PC Drew.

We discuss issues such as working with bandwidth constraints, hostile environments, training and skills development, and more.

Drew is a major in the Marine Corps Reserve and was on active duty for ten years. He’s currently CTO at SchoolBlocks, and has a background in network and software engineering.

There’s a lot of interesting points in this show, so we’ve pasted the entirety of our show notes below.

Show Notes:

* We did a show with Peter Wohlers on the future of networking, which was also a bit of a look back at some evolution…QoS, SDN, etc. Some of that conversation had you both agreeing and disagreeing with us. Explain.

* Snowflake networks

* Unique configurations vs unique requirements/constraints vs unique networks

* Often, a “snowflake network” is a sign that it is misconfigured (not always…there are some actual unique requirements!)

* “QoS is the devil’s work” and “just get a bigger pipe”.

* It is the devil’s work–it’s hard, but necessary

* Many people can’t “just get a bigger pipe”–need to understand how to maximize what you have

* Overlaying networks adds significant complexity to an already complex environment (avoid tunnels!)

* Although we need tunnels, they make our lives harder.  Sometimes they’re required and other times they’re an indicator of an architecture that was not designed appropriately.

* Path MTU issues that Peter described also happen on overlay networks, where <1500 byte frames are common.

* MSS and TCP Windowing also play a role here

* Commoditization of network skills.  Deep technical experience is hard to come by in public AND private sectors.  How do you run global operations with less experienced people?

* Military networks are rather specialized. Can you describe some of the common constraints?

* Running military communications is often like someone walking into a field in the middle of nowhere and telling you: “I want all the capabilities that I have in my office….right here…in a few hours.”

* We’re often given very little requirements and asked to just “build it.”  Sometimes with very little notice.

* In practice, everything is limited by survivability, logistics, and bandwidth.

* Survivability

* Elements such as sand, water, heat/cold, unstable power, etc

* Mobility challenges (a force on the move)

* A thinking enemy (kinetic and cyber attacks)

* Physical security (concertina wire, barriers, being able to inspect cables for tampering, etc)

* Cyber security (evaluating your own posture, understanding the enemy’s capabilities and limitations, having tools that detect and potentially respond to network anomalies)

* Logistics

* In many cases, you have to pack up everything you need and take it with you.

In today’s Priority Queue podcast I chat with Andrew Mortensen about Distributed Denial Of Service Open Threat Signaling, or DOTS, an active IETF working group.

DOTS enables disparate DDoS products and services to interact so they can request, coordinate, and terminate mitigation efforts.

We discuss the rationale for DOTS, examine use cases, and look at the architecture that enables communication and coordination. We also look at how DOTS relates to, and differs from, BGP Flowspec.

Andrew is Principal Architect at Arbor Networks, the security division of NetScout.

This episode was recorded live at the 102nd meeting of the Internet Engineering Task Force in Montreal.

Show Links:

DDoS Open Threat Signaling (dots) – IETF

Distributed Denial of Service (DDoS) Open Threat Signaling Requirements – IETF

Distributed Denial of Service (DDoS) Open Threat Signaling Architecture – IETF

PQ Show 78: BGP Flowspec For DoS Mitigation – Packet Pushers