VNets and VPN/ExpressRoute connections are associated with vHub’s Default Route Table, which allows both VNet-to-VNet and VNet-to-Remote Site IP connectivity. This chapter explains how we can isolate vnet-swe3 from vnet-swe1 and vnet-swe2 using VNet-specific vHub Route Tables (RT), still allowing VNet-to-VPN Site connection. As a first step, we create a Route Table rt-swe12 to which we associate VNets vnet-swe1 and vnet-swe2. Next, we deploy a Route Table rt-swe3 for vnet-swe3. Then we propagate routes from these RTs to Default RT but not from rt-swe12 to rt-swe3 and vice versa. Our VPN Gateway is associated with the Default RT, and the route to remote site subnet 10.11.11.0/24 is installed into the Default RT. To achieve bi-directional IP connectivity, we also propagate routes from the Default RT to rt-swe-12 and rt-swe3. As the last step, we verify both Control Plane operation and Data Plane connections.
Figure 12-1: Virtual Network Segmentation.
Today's podcast episode revisits the subject of IPv6 address allocation along with how changes in network planning and Regional Internet Registry (RIR) policy are influencing allocation size requests. We also look at how network trends around IoT, cloud, and SD-WAN might affect allocation size and how to overcome "IPv4 thinking."
The post IPv6 Buzz 120: Revisiting IPv6 Address Allocation – What’s The Right Size For Your Organization? appeared first on Packet Pushers.
One of my readers sent me a question along these lines:
How do we determine the number of spines needed in a leaf-and-spine fabric? It’s easy to calculate the number of leaf nodes from the required number of server ports, and two spines give you the redundancy. Does it make sense to have more spines if two are good enough from the capacity perspective?
There are at least two factors to consider:
One of my readers sent me a question along these lines:
How do we determine the number of spines needed in a leaf-and-spine fabric? It’s easy to calculate the number of leaf nodes from the required number of server ports, and two spines give you the redundancy. Does it make sense to have more spines if two are good enough from the capacity perspective?
There are at least two factors to consider:
For last week’s show, we had Christopher Wood on to talk about oDoH. This week, Chris joins us again to talk about Multiplexed Application Substrate over QUIC Encryption, or masque, which is a more generalized privacy proxy. You can find more about masque at the IETF WG page.
With the release of ChatGPT as a product, Microsoft brought Machine Learning (ML) and Artificial Intelligence (AI) back into focus for millions of users—including network operators, coders, and other folks in information technology. People are once against asking if this technology will make them redundant or how it might change their day-to-day jobs. As always, […]
The post Chatbot Attack Vectors And Failure Modes In Networking And IT appeared first on Packet Pushers.
This video looks at the fundamentals of Data Processing Units (DPUs) and what they can do with an eye toward helping network engineers and infrastructure professionals. Greg Ferro from the Packet Pushers and Joseph White, a Fellow at Dell Technologies, discuss how DPUs are different from GPUs and CPUs; using DPUs to offload workloads from […]
The post Understanding DPUs For Network Engineers – Packet Pushers Livestream With Dell Technologies – Video appeared first on Packet Pushers.
WebAssembly (Wasm) is an up-and-coming technology that's probably going to fall into the lap of operations folks. WebAssembly is basically a specification on how to compile things to a bytecode format and how to execute that bytecode. On today's Day Two Cloud we start to peel the onion on what WebAssembly, what it's used for, and why you might want to get your hands on it.
The post Day Two Cloud 183: How Did We Get To WebAssembly And What Is It For? appeared first on Packet Pushers.