Avery Pennarun published a lovely rambling on magic, science, engineering and a pinch of AI. You might enjoy reading it1 with your Sunday morning coffee 😎.
Pim van Pelt built an x86/Linux-based using Vector Packet Processor that can forwarding IP traffic at 150 Mpps/180 Gbps forwarding rates on a 2-CPU Dell server with E5-2660 (8 core) CPU.
He described the whole thing in a 8-part series of blog posts and a conference talk. Enjoy!
Pim van Pelt built an x86/Linux-based using Vector Packet Processor that can forwarding IP traffic at 150 Mpps/180 Gbps forwarding rates on a 2-CPU Dell server with E5-2660 (8 core) CPU.
He described the whole thing in a 8-part series of blog posts and a conference talk. Enjoy!
Pradosh Mohapatra started the Typical SD-WAN Solution Architecture section of Software-Defined WAN (SD-WAN) Overview webinar with the backend architecture.
Next step: CPE architecture, the topic of today’s video.
Pradosh Mohapatra started the Typical SD-WAN Solution Architecture section of Software-Defined WAN (SD-WAN) Overview webinar with the backend architecture.
Next step: CPE architecture, the topic of today’s video.
Daniel left an interesting comment on my Studying EVPN to Prepare for a Job Interview blog post:
I also never build a VXLAN fabric with two vendors. So, is it possible now to build one large fabric consisting of multiple vendors?
TL&DR: Yes, but just because you could doesn’t mean that you should.
Daniel left an interesting comment on my Studying EVPN to Prepare for a Job Interview blog post:
I also never build a VXLAN fabric with two vendors. So, is it possible now to build one large fabric consisting of multiple vendors?
TL&DR: Yes, but just because you could doesn’t mean that you should.
While I was developing Network Automation Concepts webinar and the network automation online course, I wrote numerous blog posts on the Network Infrastructure as Code (NIaC) concepts, challenges, implementation details, tools, and sample solutions.
In March 2023 I collected these blog posts into a dedicated NIaC resources page that also includes links to webinars, sample network automation solutions, and relevant GitHub repositories.
While I was developing Network Automation Concepts webinar and the network automation online course, I wrote numerous blog posts on the Network Infrastructure as Code (NIaC) concepts, challenges, implementation details, tools, and sample solutions.
In March 2023 I collected these blog posts into a dedicated NIaC resources page that also includes links to webinars, sample network automation solutions, and relevant GitHub repositories.
One of my readers sent me this question:
In your observations on IPv6 assignments, what are common point-to-point IPv6 interfaces on routers? I know it always depends, but I’m hearing /64, /112, /126 and these opinions are causing some passionate debate.
(Checks the calendar) It’s 2023, IPv6 RFC has been published almost 25 years ago, and there are still people debating this stuff and confusing those who want to deploy IPv6? No wonder we’re not getting it deployed in enterprise networks ;)
One of my readers sent me this question:
In your observations on IPv6 assignments, what are common point-to-point IPv6 interfaces on routers? I know it always depends, but I’m hearing /64, /112, /126 and these opinions are causing some passionate debate.
(Checks the calendar) It’s 2023, IPv6 RFC has been published almost 25 years ago, and there are still people debating this stuff and confusing those who want to deploy IPv6? No wonder we’re not getting it deployed in enterprise networks ;)
I already mentioned the introduction of VRF- and VLAN access links in netlab release 1.5.1. Let’s see how they can simplify your lab topologies.
I always tried to make lab topologies as concise as I could, sometimes cheating using JSON-in-YAML syntax. For example, the topology describing three routers running OSPF could be as simple as this:
module: [ ospf ]
nodes: [ r1, r2, r3 ]
links: [ r1-r2, r2-r3, r3-r1 ]
Let’s unravel that:
I already mentioned the introduction of VRF- and VLAN access links in netlab release 1.5.1. Let’s see how they can simplify your lab topologies.
I always tried to make lab topologies as concise as I could, sometimes cheating using JSON-in-YAML syntax. For example, the topology describing three routers running OSPF could be as simple as this:
module: [ ospf ]
nodes: [ r1, r2, r3 ]
links: [ r1-r2, r2-r3, r3-r1 ]
Let’s unravel that:
People keep telling me how well large language models like ChatGPT work for them, so now and then, I give it another try, most often resulting in another disappointment1. It might be that I suck at writing prompts2, or it could be that I have a knack for looking in the wrong places3.
This time4 I tried to “figure out5” why we need iSCSI checksums if we have iSCSI running over Ethernet which already has checksums. Enjoy the (ChatGPT) circular arguments and hallucinations with plenty of platitudes and no clear answer.
People keep telling me how well large language models like ChatGPT work for them, so now and then, I give it another try, most often resulting in another disappointment1. It might be that I suck at writing prompts2, or it could be that I have a knack for looking in the wrong places3.
This time4 I tried to “figure out5” why we need iSCSI checksums if we have iSCSI running over Ethernet which already has checksums. Enjoy the (ChatGPT) circular arguments and hallucinations with plenty of platitudes and no clear answer.
Bruce Davie continues documenting the tradeoffs we had to make in networking, this time with Was MPLS Traffic Engineering Worthwhile? I found this bit particularly familiar:
It wasn’t hard to make a theoretical argument that MPLS-TE could improve network performance and average link utilization, by moving traffic from congested links to uncongested ones. The hard part was proving that it would actually do a better job in practice than the more traditional methods such as using link weights and multipath routing to achieve the same ends.
Bruce Davie continues documenting the tradeoffs we had to make in networking, this time with Was MPLS Traffic Engineering Worthwhile? I found this bit particularly familiar:
It wasn’t hard to make a theoretical argument that MPLS-TE could improve network performance and average link utilization, by moving traffic from congested links to uncongested ones. The hard part was proving that it would actually do a better job in practice than the more traditional methods such as using link weights and multipath routing to achieve the same ends.
After introducing netlab in the Network Automation Tools webinar, I spent a few minutes describing the structure of the netlab lab topology file.
As always, use the video only as a starting point. For more details, read the netlab documentation (overview, reference guide).
After introducing netlab in the Network Automation Tools webinar, I spent a few minutes describing the structure of the netlab lab topology file.
As always, use the video only as a starting point. For more details, read the netlab documentation (overview, reference guide).
I must be a good prompt engineer – every time I ask ChatGPT something really simple it spews out nonsense. This time I asked it to build a small network with four routers:
I have a network with four Cisco routers (A,B,C,D). They are connected as follow: A-B, B-C, A-D, D-C. Each router has a loopback interface. Create router configurations that will result in A being able to reach loopback interfaces of all other routers.
Here’s what I got back1:
Here’s an example configuration for the four routers that should allow Router A to reach the loopback interfaces of all other routers: