Edge Devices Are The Brains Of The Network
In the LAN, WAN, or datacenter network, edge devices do most of the work. The network edge has more features and performs more functions than other layers of the network topology.
As we move from the edge to the core, we expect more throughput but fewer features, because core devices should involve little except packet forwarding. Fewer protocols and features should be deployed, requiring less configuration and keeping control plane states at a minimum.
Datacenter networks, POPs, LANs, the branch, and the core can be thought of as different segments of networks. The features of these networks and their implementation might be different for enterprises, service providers, mobile operators, and for telcos, but the general theory remains the same. If we look at each segment separately, we can see why edge devices have to do more intelligent jobs, and why choosing the correct edge devices may be more critical than devices at other layers.
In the LAN, for example, we enable first-hop security on the access layer switches -- which make up the edge devices of the LAN. As a best practice, we also start to enable QoS as close as possible to the source. So implementing QoS policy at the edge of the network is important.
QoS might be implemented in different network segments for different reasons, but the place where you do it does not change. In the LAN, QoS might be implemented to protect voice traffic at the network edge. In the datacenter, you might use it at the virtualization layer to protect Fibre Channel traffic -- which is also at an edge of the network. In addition, we enable multicast features, such as IGMP and IGMP snooping, at the edge of the network. These are CPU-intensive processes if not handled by ASICs at the edge.
Access layer devices can supply power over Ethernet (PoE) to IP phones, wireless access points, and other devices in the LAN, so power negotiation is done at the edge of the network. If access lists, distribution lists, or filtering mechanisms need to be implemented, the best place again is the access layer. With the increased popularity of TrustSec and ISE deployments for user and device identification, this type of downloadable access list is a good example. Enforcement is done at the access layer, based on the policy on the ISE.
Service provider edge
When it comes to service providers, such as those supplying VPN services, provider edge (PE) devices always offer more in the way of configuration, policy, and control plane state. For MPLS VPN service, MP-BGP is necessary to distribute the VPN labels and neighborship between PE devices at the edge. The core of the network does not keep state, cannot be configured for BGP, and doesn't keep customer prefixes in its memory.
If a service provider offers multicast MPLS L3VPN service, let's say with Rosen GRE implementation, almost all the configuration is done at the PE devices.
We want core devices to be simple from a configuration point of view. When configuration increases, it's more likely that operational mistakes will increase as well. A higher mean time between mistakes increases your rate of high availability, so the KISS (Keep It Simple Stupid) principle should be kept in mind.
In the datacenter network, the edge may not be defined clearly, especially after virtualization. However, the edge can be thought of as the virtual access switch -- for example, a VMware distribution switch or Cisco Nexus 1000V. The general theory is the same for both.
Virtual PortChannel, FabricPath, or TRILL can be implemented at the aggregation layer and core of the network. But for all of these technologies, the aggregation layer must handle more processes and keep more states in the control and data plane, when compared to the core. For example, while the FabricPath leaf layer is implemented at the aggregation layer, the spine might be at the core. While the spine only knows how to route at Layer 2 to the leaf switches, the leaf nodes can learn the addresses from both the classical Ethernet side and from the FabricPath core.
Do you have questions about this topic? Ask me in the comments.
Recommended For You
In honor of St. Patrick’s Day, there’s no better time to reflect on those instants when life threw us a curveball, but we were able to hit a home run.
The success of modern enterprises, especially those utilizing real-time communications solutions, is highly reliant on IT infrastructure availability.
To understand the critical role of HTTP/2 in streamlining operations, we must look back at the technologies and implementation gaps that got us where we are today.
A video overview and best practices on how to reduce broadcasts and find other things to tune.
This is a great example of the perfect storm of variables coming together to cause performance issues. Watch the video to see how the problem was found.
Providers should be making infrastructure work for everyone in 2019, improving efficiency and opening up networks for all apps on their infrastructure.