Previous posts in this series covered numerous intricacies of DHCP relaying:
Now for the final bit of the puzzle: what if we want to do inter-VRF DHCP relaying with redundant DHCP servers?
Sebastian described an interesting Cisco ACI quirk they had the privilege of chasing around:
We’ve encountered VM connectivity issues after VM movements from one vPC leaf pair to a different vPC leaf pair with ACI. The issue did not occur immediately (due to ACI’s bounce entries) and only sometimes, which made it very difficult to reproduce synthetically, but due to DRS and a large number of VMs it occurred frequently enough, that it was a serious problem for us.
Here’s what they figured out:
Sebastian described an interesting Cisco ACI quirk they had the privilege of chasing around:
We’ve encountered VM connectivity issues after VM movements from one vPC leaf pair to a different vPC leaf pair with ACI. The issue did not occur immediately (due to ACI’s bounce entries) and only sometimes, which made it very difficult to reproduce synthetically, but due to DRS and a large number of VMs it occurred frequently enough, that it was a serious problem for us.
Here’s what they figured out:
Last month I described how you can simplify your VLAN- or VRF lab topologies with VRF- and VLAN links, automatically setting vlan.access or vrf attribute on a set of links. Link groups allow you to do the same for any set of link attributes.
Imagine you have a small network with three PE-routers connected to a central P-router:
Last month I described how you can simplify your VLAN- or VRF lab topologies with VRF- and VLAN links, automatically setting vlan.access or vrf attribute on a set of links. Link groups allow you to do the same for any set of link attributes.
Imagine you have a small network with three PE-routers connected to a central P-router:
Michele Chubirka published a must-read article on technology fallacies including this gem:
Technologists often assume that all problems can be beaten into submission with a technology hammer.
As I’ve been saying for ages (not that anyone would listen): all the technology in the world won’t save you unless you change the mentality and rearchitect broken processes.
Michele Chubirka published a must-read article on technology fallacies including this gem:
Technologists often assume that all problems can be beaten into submission with a technology hammer.
As I’ve been saying for ages (not that anyone would listen): all the technology in the world won’t save you unless you change the mentality and rearchitect broken processes.
I mentioned IP source address validation (SAV) as one of the MANRS-recommended actions in the Internet Routing Security webinar but did not go into any details (as the webinar deals with routing security, not data-plane security)… but I stumbled upon a wonderful companion article published by RIPE Labs: Why Is Source Address Validation Still a Problem?.
The article goes through the basics of SAV, best practices, and (most interesting) using free testing tools to detect non-compliant networks. Definitely worth reading!
I mentioned IP source address validation (SAV) as one of the MANRS-recommended actions in the Internet Routing Security webinar but did not go into any details (as the webinar deals with routing security, not data-plane security)… but I stumbled upon a wonderful companion article published by RIPE Labs: Why Is Source Address Validation Still a Problem?.
The article goes through the basics of SAV, best practices, and (most interesting) using free testing tools to detect non-compliant networks. Definitely worth reading!
Pete Lumbis concluded his ASICs for Networking Engineers presentation with a brief overview of types of switching ASICs and a wrap-up.
You can watch his entire 90-minute presentation (sliced into shorter videos) with Free ipSpace.net Subscription.
Pete Lumbis concluded his ASICs for Networking Engineers presentation with a brief overview of types of switching ASICs and a wrap-up.
You can watch his entire 90-minute presentation (sliced into shorter videos) with Free ipSpace.net Subscription.
Tom Ammon sent me his thoughts on choosing the right level of abstraction in your network automation solution as a response to my What Is Intent-Based Networking blog post, and allowed me to publish them on ipspace.net.
I totally agree with your what vs how example with OSPF. I work on a NOS team where if we wanted, we could say, instead of “run OSPF on these links”, do this:
Tom Ammon sent me his thoughts on choosing the right level of abstraction in your network automation solution as a response to my What Is Intent-Based Networking blog post, and allowed me to publish them on ipspace.net.
I totally agree with your what vs how example with OSPF. I work on a NOS team where if we wanted, we could say, instead of “run OSPF on these links”, do this:
I wrote dozens of blog posts debunking disaster recovery fairy tales (mostly of the long-distance vMotion and stretched clusters variety) over the years. They are collected and sorted (and polished a bit) in the new Disaster Recovery Resources page. Hope you’ll find them useful.
I wrote dozens of blog posts debunking disaster recovery fairy tales (mostly of the long-distance vMotion and stretched clusters variety) over the years. They are collected and sorted (and polished a bit) in the new Disaster Recovery Resources page. Hope you’ll find them useful.
I attended ITNOG 7 last week, and thoroughly enjoyed a full day of interesting presentations, including how do you run Internet services in a war zone by Elena Lutsenko and Milko Ilari.
The morning was focused primarily on BGP:
I attended ITNOG 7 last week, and thoroughly enjoyed a full day of interesting presentations, including how do you run Internet services in a war zone by Elena Lutsenko and Milko Ilari.
The morning was focused primarily on BGP:
containerlab release 0.41.0 that came out a few days ago changed a few topology attributes with no backward compatibility, breaking netlab for anyone doing a new installation. The only way out of that conundrum was to push out a new netlab release that uses the new attributes and requires containerlab release 0.41.0 (more about that in a minute).
On a more positive note, netlab release 1.5.3 brings a few interesting features, including:
containerlab release 0.41.0 that came out a few days ago changed a few topology attributes with no backward compatibility, breaking netlab for anyone doing a new installation. The only way out of that conundrum was to push out a new netlab release that uses the new attributes and requires containerlab release 0.41.0 (more about that in a minute).
On a more positive note, netlab release 1.5.3 brings a few interesting features, including:
Roman Dodin wrote an article describing Nokia’s Ansible collection for SR Linux. Although I don’t use SR Linux (even though it was the first container supported by netlab ;), it was still very interesting to read about the design tradeoffs they had to make: