Another interesting take on ChatGPT in networking, this time by Tom Hollingsworth in The Dangers of Knowing Everything:
In a way, ChatGPT is like a salesperson. No matter what you ask it the answer is always yes, even if it has to make something up to answer the question.
To paraphrase an old joke: It’s not that ChatGPT is lying. It’s just that what it knows isn’t necessarily true. See also: the difference between bullshit and lies.
Did you know that most chassis switches look like leaf-and-spine fabrics1 from the inside? If you didn’t, you might want to watch the short Chassis Architectures video by Pete Lumbis (author of ASICs for Networking Engineers part of the Data Center Fabric Architectures webinar).
Did you know most chassis switches look like leaf-and-spine fabrics1 from the inside? If you didn’t, you might want to watch the short Chassis Architectures video by Pete Lumbis (author of ASICs for Networking Engineers part of the Data Center Fabric Architectures webinar).
TL&DR: No. You can move on.
NANOG87 summary by John Kristoff prompted me to look at NANOG87 presentations, and one of them discussed ChatGPT and Network Engineering (video). I couldn’t resist the clickbait ;)
Like most using ChatGPT for something articles we’re seeing these days, the presentation is a bit too positive for my taste. After all, it’s all fine and dandy to claim ChatGPT generates working router configurations and related Jinja2 templates if you know what the correct configurations should look like and can confidently say “and this is where it made a mistake” afterwards.
TL&DR: No. You can move on.
NANOG87 summary by John Kristoff prompted me to look at NANOG87 presentations, and one of them discussed ChatGPT and Network Engineering (video). I couldn’t resist the clickbait ;)
Like most using ChatGPT for something articles we’re seeing these days, the presentation is a bit too positive for my taste. After all, it’s all fine and dandy to claim ChatGPT generates working router configurations and related Jinja2 templates if you know what the correct configurations should look like and can confidently say “and this is where it made a mistake” afterwards.
Over the years I wrote a dozen blog posts describing various aspects of using CI/CD in network automation. These blog posts are now collected in the new CI/CD in Networking page that also includes links to related podcasts, webinars, and sample network automation solutions.
Over the years I wrote a dozen blog posts describing various aspects of using CI/CD in network automation. These blog posts are now collected in the new CI/CD in Networking page that also includes links to related podcasts, webinars, and sample network automation solutions.
A networking engineer attending the Building Next-Generation Data Center online course asked this question:
What is the best practice to connect DC fabric to outside world assuming there are 2 spine switches in the fabric and EVPN VXLAN is used as overlay? Is it a good idea to introduce edge (border) switches, or it is better to connect outside world directly to the spine?
As always, the answer is “it depends,” this time based on:
A networking engineer attending the Building Next-Generation Data Center online course asked this question:
What is the best practice to connect DC fabric to outside world assuming there are 2 spine switches in the fabric and EVPN VXLAN is used as overlay? Is it a good idea to introduce edge (border) switches, or it is better to connect outside world directly to the spine?
As always, the answer is “it depends,” this time based on:
After figuring out how DHCP relaying works and testing it in a simple lab, I went a step further and tested VRF-aware DHCP relaying.
I had to make just a few changes to the DHCP relaying lab topology:
After figuring out how DHCP relaying works and testing it in a simple lab, I went a step further and tested VRF-aware DHCP relaying.
I had to make just a few changes to the DHCP relaying lab topology:
Just in case you wondered why we have eight bits per byte: after Julia Evans investigated this mystery, Steven Bellovin published an excellent overview of the early years of bytes and words.
Just in case you wondered why we have eight bits per byte: after Julia Evans investigated this mystery, Steven Bellovin published an excellent overview of the early years of bytes and words.
Vadim Semenov created an interesting solution out of open-source tools (and some glue): a system that tracks, logs, and displays OSPF changes in your network.
It might not be exactly what you’re looking for (and purists would argue it should use BGP-LS), but that’s the beauty of open-source solutions: go and adapt it to your needs, generalizes your fixes, and submit a pull request.
Vadim Semenov created an interesting solution out of open-source tools (and some glue): a system that tracks, logs, and displays OSPF changes in your network.
It might not be exactly what you’re looking for (and purists would argue it should use BGP-LS), but that’s the beauty of open-source solutions: go and adapt it to your needs, generalizes your fixes, and submit a pull request.
After implementing MLAG functionality with EVPN and having a VXLAN-like fabric transport path between MLAG members, it becomes possible to get rid of the MLAG peer link.
Not surprisingly, most implementations of virtual MLAG peer link remain proprietary. Lukas Krattiger described the details of Cisco’s vPC Fabric Peering implementation in the EVPN Deep Dive webinar.
After implementing MLAG functionality with EVPN and having a VXLAN-like fabric transport path between MLAG members, it becomes possible to get rid of the MLAG peer link.
Not surprisingly, most implementations of virtual MLAG peer link remain proprietary. Lukas Krattiger described the details of Cisco’s vPC Fabric Peering implementation in the EVPN Deep Dive webinar.
A few weeks ago I described why EBGP TCP packets have TTL set to one (unless you configured EBGP multihop). Although some people claim that (like NAT) it could be a security feature, it’s not a good one. Generalized TTL Security Mechanism (GTSM, described in RFC 5082) is much better.
Most BGP implementations set TTL field in outgoing EBGP packets to one. That prevents a remote intruder that manages to hijack a host route to an adjacent EBGP peer from forming a BGP session as the TCP replies get lost the moment they hit the first router in the path.
A few weeks ago I described why EBGP TCP packets have TTL set to one (unless you configured EBGP multihop). Although some people claim that (like NAT) it could be a security feature, it’s not a good one. Generalized TTL Security Mechanism (GTSM, described in RFC 5082) is much better.
Most BGP implementations set TTL field in outgoing EBGP packets to one. That prevents a remote intruder that manages to hijack a host route to an adjacent EBGP peer from forming a BGP session as the TCP replies get lost the moment they hit the first router in the path.
Even though IPv6 could buy its own beer (in US, let alone rest of the world), networking engineers still struggle with its deployment – one of the first questions I got in the ipSpace.net Design Clinic was:
We have been tasked to start IPv6 planning. Can we discuss (for enterprises like us who all of the sudden want IPv6) which design paths to take?
I did my best to answer this question and describe the basics of creating an IPv6 addressing plan. For even more details, watch the IPv6 webinars (most of them at least a few years old, but nothing changed in the IPv6 world in the meantime apart from the SRv6 madness).