Networking

09:30 AM
Orhan Ergun
Orhan Ergun
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Edge Devices Are The Brains Of The Network

In any type of network, the edge is where all the action takes place. Think of the edge as the brains of the network, while the core is just the dumb muscle.

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.

LAN edge
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.

Datacenter edge
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.

Orhan Ergun, CCIE, CCDE, is a network architect mostly focused on service providers, data centers, virtualization and security. He has more than 10 years in IT, and has worked on many network design and deployment projects. View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Page 1 / 2   >   >>
Jamescon
100%
0%
Jamescon,
User Rank: Apprentice
4/23/2014 | 5:26:18 PM
Where does security sit?
Orhan. I agree that the edge is where things happen (including some pretty important things like access control). However, I'm curious what you think of VMware pitch to make the hypervisor sort of a key to security, working on the assumption that bad guys will get through the edge security anyway. Thoughts?
OrhanErgun
50%
50%
OrhanErgun,
User Rank: Moderator
4/24/2014 | 1:35:26 AM
Re: Where does security sit?
IMO Whatever security prevention vendor takes at the host level, still you implement your control plane and data plane protection on your network. Control plane protection can be implemented to every layer and still you implement data plane protection at the edges as infrasturcture filtering. Also defense in depth may require protection at many layers. Hope to help.
aditshar1
50%
50%
aditshar1,
User Rank: Ninja
4/24/2014 | 3:35:51 AM
Re: Where does security sit?
I agree with author completely on Edge Devices Are The Brains Of The Network, every edge keeps relevance as PE is between one network service provider area and areas by other network providers.
Jamescon
50%
50%
Jamescon,
User Rank: Apprentice
4/24/2014 | 9:23:22 AM
Re: Where does security sit?
Thanks, Orhan. That helps.
Susan Fogarty
50%
50%
Susan Fogarty,
User Rank: Strategist
4/24/2014 | 9:55:08 AM
Re: Where does security sit?
Jamescon, that's a very big question. As Orhan notes, security is often multi-layered, and that may be the way it continues to be. But what VMware is talking about is really interesting. We have a video of Martin Casado explaining how all functionality should move to the applications or edge. They want to expand that to security as well, which they say would make data essentially "invisible" on the network and invulnerable to attack. I'm not sure if just moving your attack point to a different location solves that much, but the advantage is that you have more control, at that point right?
OrhanErgun
100%
0%
OrhanErgun,
User Rank: Moderator
4/24/2014 | 10:47:49 AM
Re: Where does security sit?
We often do this mistake while we are designing a network as well. Shifting complexity from one place of the network to another instead of trying to find simplest one.
CCDE06
50%
50%
CCDE06,
User Rank: Apprentice
4/25/2014 | 4:49:41 AM
Re: Where does security sit?
Nice Article Orhan,

I think the brain should have full visibility and knowledge of every angle and leaf within a system and this is what you can see from the Network core point of view while the edge is specialized to do certain functions on limited area within the network without full knowledge of what is happening on the entire network

 
OrhanErgun
50%
50%
OrhanErgun,
User Rank: Moderator
4/25/2014 | 9:51:56 AM
Re: Where does security sit?
Brain should have visibility of course but summarization always should be put in place. Thus floding domain boundary for layer 2 and layer3 control plane should be kept at minimum. As an example you dont want to extend spanning tree to multiple domains also you dont want to extend your IGP as flat to everywhere if scaling is concern.

You separate complexity from complexity so if your edge is hub and spoke topology, you want to isolate that module complexity from your core which maybe partial/full mesh or ring.


So, I agree with some part of your comment but every PIN actually requires careful attention. If we accept brain should have visibility and then if we say core should have full visibility then both would be wrong. Brain should have different capabilities as well in addition to visibility but not full visibility since this is distributed architecture. For SDN, SDDC talk we could maybe say that.


If we also say core should have full visibility IMO this would be also wrong since you want most of the time hide the topology and summarize the reachability if suboptimality and/or blackhole is not a big concern than scaling and convergence.


Thanks,

Orhan
jgherbert
50%
50%
jgherbert,
User Rank: Ninja
4/26/2014 | 7:43:02 PM
Re: Where does security sit?
The door opens and in walks Software Defined Networking.

Perhaps the ideal world would be a mixture of the two:

- Topology awareness /somewhere/. This doesn't have to be in the egde or the core; it could well sit in a controller device that doesn't reside in the network architecture per se.

- Brains at the edge. Or, at least, the ability to enforce policies. Where the egde obtains those policies is another question. Perhaps they are self-sufficient, or perhaps they rely on another source to program them. 

As to moving security to the hypervisor, sure, have at it. Double up in he network? For sure too. Now figure out how to sync those two so that there's a consistent policy in place without doubling up on the administration required to maintain it. Part of VMWare's argument for hypervisor security, as I recall, is that you get to implement policy prior to encapsulation in VXLAN. I seem to recall that part of Cisco's ACI pitch is that the ACI chip can look inside VXLAN are wire speed and process policies against it. If so, that particular argument for VMWare begins to falter, especially if you have more than just VMWare in your network (I know I do). VMWare position the 'edge' as being the hypervisor (with the brains), and then the rest of the network (access AND core) are relegated to 'dumb'. I maintain that unless you're in the lucky position (YMMV) to run nothing but VMWare overlays, you'd absolutely better have that defence in layers that we mentioned.

Definitely an interesting post - thank you.

 
OrhanErgun
50%
50%
OrhanErgun,
User Rank: Moderator
4/27/2014 | 12:49:29 AM
SDN - Controller based approach
Thanks jgherbert for your comment. Maybe I should have change the article name to Today's distributed architecture holds it's intelligence at the edge. For controller based approach, I would argue that it will be again at the edge if controller is placed as virtual. But at least hardware (switches, routers) will not keep same amount of state, will not have to be topology aware, running complex alghoritms so on.

Also which PIN  the controller will be managing is important IMO. If you deployed it in the DC, still your WAN module might have two or three layer boundaries, so everything for the distributed architecture would be true.
Page 1 / 2   >   >>
Cartoon
Slideshows
Audio Interviews
Archived Audio Interviews
Jeremy Schulman, founder of Schprockits, a network automation startup operating in stealth mode, joins us to explore whether networking professionals all need to learn programming in order to remain employed.
White Papers
Register for Network Computing Newsletters
Current Issue
2014 Private Cloud Survey
2014 Private Cloud Survey
Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.
Video
Twitter Feed