A long-time subscriber with a knack for telling me precisely why something I’m doing sucks big time sent me his opinion on netlab1 installation instructions:
I do not want to say it is impossible to follow your instruction but I wonder why the process is not clearly defined for someone not deeply involved in such tasks with full understanding of why to install from github, etc..
Many guys do not know if they want to use libvirt. They want to use the tool simple way without studying upfront what the libvirt is - but they see libvirt WARNING - should we install libvirt then or skip the installation?. But stop, this step of libvirt installation is obligatory in the 2nd Ubuntu section. So why the libvirt warning earlier?
I believe we should start really quickly to enjoy the tool before we reject it for “complexity”. Time To Play matters. Otherwise you are tired trying to understand the process before you check if this tool is right for you.
He was absolutely right – it was time to overhaul the “organically grown” installation instructions and make them goal-focused and structured. For those of you who want to see the big Continue reading
One of my readers sent me an intriguing challenge based on the following design:
The following picture shows the simplified network diagram:
One of my readers sent me an intriguing challenge based on the following design:
The following picture shows the simplified network diagram:
Some webinars on ipSpace.net are ancient (= more than a decade old). I’m refreshing some of them (the overhaul of Introduction to Virtualized Networking was completed earlier this month); others will stay as they are because the technology hasn’t changed in a long while, and it’s always nice to hear someone still finds them useful. This is a recent feedback I got on the DMVPN webinars:
As with any other webinar I have viewed on ipspace.net, this one provides the background as to why you may or may not want to do certain things and what impact that may have (positive or negative) on your network. Then it digs into the how of actually doing something. Brilliant content as always.
IPSpace.net is my go-to for deep dives on existing and emerging technologies in the networking industry. No unnecessary preamble. Gets straight to the point of why you are looking at a specific technology and explains the what and the why before getting into the how.
Some webinars on ipSpace.net are ancient (= more than a decade old). I’m refreshing some of them (the overhaul of Introduction to Virtualized Networking was completed earlier this month); others will stay as they are because the technology hasn’t changed in a long while, and it’s always nice to hear someone still finds them useful. This is a recent feedback I got on the DMVPN webinars:
As with any other webinar I have viewed on ipspace.net, this one provides the background as to why you may or may not want to do certain things and what impact that may have (positive or negative) on your network. Then it digs into the how of actually doing something. Brilliant content as always.
IPSpace.net is my go-to for deep dives on existing and emerging technologies in the networking industry. No unnecessary preamble. Gets straight to the point of why you are looking at a specific technology and explains the what and the why before getting into the how.
Julio Perez wrote a wonderful blog post describing how he combined netsim-tools and containerlab to build Arista cEOS labs.
Hint: when you’re done with that blog post, keep reading and add his blog to your RSS feed – he wrote some great stuff in the past.
Julio Perez wrote a wonderful blog post describing how he combined netlab and containerlab1 to build Arista cEOS labs.
Hint: when you’re done with that blog post, keep reading and add his blog to your RSS feed – he wrote some great stuff in the past.
netlab was known as netsim-tools at the time he wrote the blog post ↩︎
For whatever reason, most IT vendors attach “you cannot use this for performance testing and/or publish any results” caveat to their licensing agreements, so it’s really hard to get any independent test results that are not vendor-sponsored and thus suitably biased.
Justin Pietsch managed to get a permission to publish test results of Junos container implementation (cRPD) – no surprise there, Junos outperformed all open-source implementations Justin tested in the past.
What about other commercial BGP stacks? Justin did the best he could: he published Testing Commercial BGP Stacks instructions, so you can do the measurements on your own.
For whatever reason, most IT vendors attach “you cannot use this for performance testing and/or publish any results” caveat to their licensing agreements, so it’s really hard to get any independent test results that are not vendor-sponsored and thus suitably biased.
Justin Pietsch managed to get a permission to publish test results of Junos container implementation (cRPD) – no surprise there, Junos outperformed all open-source implementations Justin tested in the past.
What about other commercial BGP stacks? Justin did the best he could: he published Testing Commercial BGP Stacks instructions, so you can do the measurements on your own.
A few weeks ago, Nick Buraglio and Chris Cummings invited me for an hour-long chat about netsim-tools on the Modem Podcast.
We talked about why one might want to use netsim-tools instead of another lab orchestration solution and the high-level functionality offered by the tool. Nick particularly loved its IPAM features which got so extensive in the meantime that I had to write a full-blown addressing tutorial. But there’s so much more: you can also get a fully configured OSPFv2, OSPFv3, EIGRP, IS-IS, SRv6, or BGP lab built from more than a dozen different devices. In short (as Nick and Chris said): you can use netsim-tools to make labbing less miserable.
A few weeks ago, Nick Buraglio and Chris Cummings invited me for an hour-long chat about netlab on the Modem Podcast1.
We talked about why one might want to use netlab instead of another lab orchestration solution and the high-level functionality offered by the tool. Nick particularly loved its IPAM features which got so extensive in the meantime that I had to write a full-blown addressing tutorial. But there’s so much more: you can also get a fully configured OSPFv2, OSPFv3, EIGRP, IS-IS, SRv6, or BGP lab built from more than a dozen different devices. In short (as Nick and Chris said): you can use netlab to make labbing less miserable.
netlab was known as netsim-tools when we were recording that podcast. ↩︎
Sander Steffann sent me an intriguing question a long while ago:
I was wondering if there are any downsides to setting “system mtu jumbo 9198” by default on every switch? I mean, if all connected devices have MTU 1500 they won’t notice that the switch could support longer frames, right?
That’s absolutely correct, and unless the end hosts get into UDP fights things will always work out (aka TCP MSS saves the day)… but there must be a reason switching vendors don’t use maximum frame sizes larger than 1514 by default (Cumulus Linux seems to be an exception, and according to Sébastien Keller Arista’s default maximum frame size is between 9214 and 10178 depending on the platform).
Sander Steffann sent me an intriguing question a long while ago:
I was wondering if there are any downsides to setting “system mtu jumbo 9198” by default on every switch? I mean, if all connected devices have MTU 1500 they won’t notice that the switch could support longer frames, right?
That’s absolutely correct, and unless the end hosts get into UDP fights things will always work out (aka TCP MSS saves the day)… but there must be a reason switching vendors don’t use maximum frame sizes larger than 1514 by default (Cumulus Linux seems to be an exception, and according to Sébastien Keller Arista’s default maximum frame size is between 9214 and 10178 depending on the platform).
Got this question from one of my readers:
When adopting the BGP on the VM model (say, a Kubernetes worker node on top of vSphere or KVM or Openstack), how do you deal with VM migration to another host (same data center, of course) for maintenance purposes? Do you keep peering with the old ToR even after the migration, or do you use some BGP trickery to allow the VM to peer with whatever ToR it’s closest to?
Short answer: you don’t.
Kubernetes was designed in a way that made worker nodes expendable. The Kubernetes cluster (and all properly designed applications) should recover automatically after a worker node restart. From the purely academic perspective, there’s no reason to migrate VMs running Kubernetes.
Got this question from one of my readers:
When adopting the BGP on the VM model (say, a Kubernetes worker node on top of vSphere or KVM or Openstack), how do you deal with VM migration to another host (same data center, of course) for maintenance purposes? Do you keep peering with the old ToR even after the migration, or do you use some BGP trickery to allow the VM to peer with whatever ToR it’s closest to?
Short answer: you don’t.
Kubernetes was designed in a way that made worker nodes expendable. The Kubernetes cluster (and all properly designed applications) should recover automatically after a worker node restart. From the purely academic perspective, there’s no reason to migrate VMs running Kubernetes.
Antonio Boj enjoyed the Cisco ACI webinars by Mario Rosi and sent me this feedback:
I just wanted to pass you my feedback about the documentation and content of the above webinars. Excellent content, very well organized.
My expectation is always high about your content because I’ve become used to it with other webinars you published. I always look for non-marketing content to understand the technology.
I don’t want to criticize vendors based on assumptions or personal agendas from interested people but evaluate whether or not it is the right path forward for the problem I want to solve, knowing the pros and cons. So again, both webinars about Cisco ACI have given me excellent visibility of the solution. Thank you very much!
Antonio Boj enjoyed the Cisco ACI webinars by Mario Rosi and sent me this feedback:
I just wanted to pass you my feedback about the documentation and content of the above webinars. Excellent content, very well organized.
My expectation is always high about your content because I’ve become used to it with other webinars you published. I always look for non-marketing content to understand the technology.
I don’t want to criticize vendors based on assumptions or personal agendas from interested people but evaluate whether or not it is the right path forward for the problem I want to solve, knowing the pros and cons. So again, both webinars about Cisco ACI have given me excellent visibility of the solution. Thank you very much!
Whenever someone asks me about LISP, I answer, “it’s a nice idea, but cache-based forwarding never worked well.” Oldtimers familiar with the spectacular failures of fast switching and various incarnations of flow switching usually need no further explanation. Unfortunately, that lore is quickly dying out, so let’s start with the fundamentals: how does packet forwarding work?
Packet forwarding used by bridges and routers (or Layer-2/3 switches if you believe in marketing terminology) is just a particular case of statistical multiplexing – a mechanism where many communication streams share the network resources by slicing the data into packets that are sent across the network. The packets are usually forwarded independently; every one of them must contain enough information to be propagated by each intermediate device it encounters on its way across the network.
Whenever someone asks me about LISP, I answer, “it’s a nice idea, but cache-based forwarding never worked well.” Oldtimers familiar with the spectacular failures of fast switching and various incarnations of flow switching usually need no further explanation. Unfortunately, that lore is quickly dying out, so let’s start with the fundamentals: how does packet forwarding work?
Packet forwarding used by bridges and routers (or Layer-2/3 switches if you believe in marketing terminology) is just a particular case of statistical multiplexing – a mechanism where many communication streams share the network resources by slicing the data into packets that are sent across the network. The packets are usually forwarded independently; every one of them must contain enough information to be propagated by each intermediate device it encounters on its way across the network.
Found a pointer to another you cannot beat the laws of physics or networking result: you cannot avoid latency spikes with end-to-end congestion control regardless of the amount of unicorn dust or hype you’re throwing at the problem (original paper).