The last video in the 2-hour-long Network Addressing part of How Networks Really Work discusses Network Address Translation.
After watching it, you might want to spend some extra quality time (with a bit of soap opera vibe) enjoying the recent Dual ISP deployment operational issues and uncertainties thread on the v6ops mailing list with a “surprising” result: NPTv6 or NAT66 is the least horrible way to do it.
I keep hearing numerous variations of the following argument from people believing in the unlimited powers of multi-cloud1 (deploying your workloads in multiple public cloud providers):
We don’t install all our servers in the same DC. But would you trust one Cloud Server Provider with all your applications? That’s why you should use multi-cloud.
I’ve been hearing similar arguments for at least 30 years, including:
I keep hearing numerous variations of the following argument from people believing in the unlimited powers of multi-cloud1 (deploying your workloads in multiple public cloud providers):
We don’t install all our servers in the same DC. But would you trust one Cloud Server Provider with all your applications? That’s why you should use multi-cloud.
I’ve been hearing similar arguments for at least 30 years, including:
Early bridges implemented a single bridging domain across all ports. Within a few years, we got multiple bridging domains within a single device (including bridging implementation in Cisco IOS). The capability to have multiple bridging domains stretched across several devices was still missing… until the modern-day Pandora opened the VLAN box and forever swamped us in the complexities of large-scale bridging.
Early bridges implemented a single bridging domain across all ports. Within a few years, we got multiple bridging domains within a single device (including bridging implementation in Cisco IOS). The capability to have multiple bridging domains stretched across several devices was still missing… until the modern-day Pandora opened the VLAN box and forever swamped us in the complexities of large-scale bridging.
One of my readers preparing for public cloud deployment sent me an interesting observation:
I pushed to use infrastructure-as-code as we move to Azure, but I’m receiving a lot of pushback due to most of the involved parties not having any experience with code. Management is scared to use any kind of “homegrown” tools that only a few would understand. I feel like I’m stuck deploying and managing the environment manually.
It looks like a bad case of suboptimal terminology for this particular audience. For whatever reason, some infrastructure engineers prefer to stay as far away from programming as possible1, and infrastructure-as-code sounds like programming to them.
One of my readers preparing for public cloud deployment sent me an interesting observation:
I pushed to use infrastructure-as-code as we move to Azure, but I’m receiving a lot of pushback due to most of the involved parties not having any experience with code. Management is scared to use any kind of “homegrown” tools that only a few would understand. I feel like I’m stuck deploying and managing the environment manually.
It looks like a bad case of suboptimal terminology for this particular audience. For whatever reason, some infrastructure engineers prefer to stay as far away from programming as possible1, and infrastructure-as-code sounds like programming to them.
In the last blog post in the VLANs and VRFs in netlab series, I described how we can combine VLANs and VRFs and create a VRF Lite solution with stretched VLANs. Wonder how hard would it be to create a routed multi-hop VRF Lite topology? It’s trivial.
Routed VRF Lite lab topology
In the last blog post in the VLANs and VRFs in netlab series, I described how we can combine VLANs and VRFs and create a VRF Lite solution with stretched VLANs. Wonder how hard would it be to create a routed multi-hop VRF Lite topology? It’s trivial.
Routed VRF Lite lab topology
Andrea Dainese released an interesting tool that performs automated network discovery, pushes the discovered data into NetBox, and then uses netbox-topology-views plugin to create network topology diagrams.
Definitely worth exploring!
Andrea Dainese released an interesting tool that performs automated network discovery, pushes the discovered data into NetBox, and then uses netbox-topology-views plugin to create network topology diagrams.
Definitely worth exploring!
A recent blog post by Andrew Lerner asks whether Cisco ACI is dead. According to Betteridge’s law of headlines, the answer is NO (which is also Andrew’s conclusion), but I liked this gem:
However, Gartner assesses that Nexus Dashboard Fabric Controller is the optimal fabric management software for most Cisco data center environments.
An automation intent-based system provisioning a traditional routed network is considered a better solution than a black-box proprietary software-defined blob of complexity? Who would have thought…
A recent blog post by Andrew Lerner asks whether Cisco ACI is dead. According to Betteridge’s law of headlines, the answer is NO (which is also Andrew’s conclusion), but I liked this gem:
However, Gartner assesses that Nexus Dashboard Fabric Controller is the optimal fabric management software for most Cisco data center environments.
An automation intent-based system provisioning a traditional routed network is considered a better solution than a black-box proprietary software-defined blob of complexity? Who would have thought…
After discussing rogue IPv6 RA challenges and the million ways one can circumvent IPv6 RA guard with IPv6 extension headers, Christopher Werny focused on practical aspects of this thorny topic: how can we test IPv6 RA Guard implementations and how good are they?
After discussing rogue IPv6 RA challenges and the million ways one can circumvent IPv6 RA guard with IPv6 extension headers, Christopher Werny focused on practical aspects of this thorny topic: how can we test IPv6 RA Guard implementations and how good are they?
Long long time ago, Daniel Dib started an interesting Twitter discussion with this seemingly simple question:
How does a switch/router know from the bits it has received which layer each bit belongs to? Assume a switch received 01010101, how would it know which bits belong to the data link layer, which to the network layer and so on.
As is often the case, Peter Paluch provided an excellent answer in a Twitter thread, and allowed me to save it for posterity.
Long long time ago, Daniel Dib started an interesting Twitter discussion with this seemingly simple question:
How does a switch/router know from the bits it has received which layer each bit belongs to? Assume a switch received 01010101, how would it know which bits belong to the data link layer, which to the network layer and so on.
As is often the case, Peter Paluch provided an excellent answer in a Twitter thread, and allowed me to save it for posterity.
Network terminology was easy in the 1980s: bridges forwarded frames between Ethernet segments based on MAC addresses, and routers forwarded network layer packets between network segments. That nirvana couldn’t last long; eventually, a big-enough customer told Cisco: “I don’t want to buy another box if I already have your too-expensive router. I want your router to be a bridge.”
Turning a router into a bridge is easier than going the other way round1: add MAC table and dynamic MAC learning, and spend an evening implementing STP.
Network terminology was easy in the 1980s: bridges forwarded frames between Ethernet segments based on MAC addresses, and routers forwarded network layer packets between network segments. That nirvana couldn’t last long; eventually, a big-enough customer told Cisco: “I don’t want to buy another box if I already have your too-expensive router. I want your router to be a bridge.”
Turning a router into a bridge is easier than going the other way round1: add MAC table and dynamic MAC learning, and spend an evening implementing STP.
A few weeks ago, Daniel Dib tweeted a slide from Radia Perlman’s presentation in which she claimed IPv6 was the worst decision ever as we could have adopted CLNP in 1992. I had similar thoughts on the topic a few years ago, and over tons of discussions, blog posts, and creating the How Networks Really Work webinar slowly realized it wouldn’t have mattered.