• 04/23/2014
    9:30 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

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.


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?

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.

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.

Re: Where does security sit?

Thanks, Orhan. That helps.

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?

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


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.

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.



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.


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.

Re: Where does security sit?

Apart from commercial answers cost and redundancy, Why would one preffer MPLS over legacy network is it VRF or edge making it less complex,

Re: Where does security sit?

Is question why MPLS rather than pure IP network or ?


Re: Where does security sit?

@OrhanErgun, Yes you got me right, my question is Why MPLS rather than pure IP network/ legacy network apart from fact that we have QoS like services available there as well.

Re: Where does security sit?

Historical reason for the MPLS was performance. Since for IP destination IP hop by hop lookup it used to consume more CPU than label based forwarding. But this is not anymore concern and use case for MPLS. 

Now MPLS is sed for its applications capability. VPNs, Traffic Engineering can give us segmentation, virtualization, bandwidth optimization, SLA protection and fast reroute capability.

Recent enhancements of IP also can gives us some of them. For example IP FRR with LFA and Remote LFA gives us to ability fast reroute.VRF lite can give us similar segmentation wth the MPLS but it is limited scale.

GRE, DMVPN,Get VPN, L2TPv3 can give us VPN capability again with the limitations and restrictions. For bandwith optimization, on small scale networks still PBR, Static routing might be an option but MPLS Traffic Engineering's primary driver is this case.

So our reason for MPLS is not the QoS. Intserv and Diffserv QoS is used both in MPLS and IP world. Even with MPLS especially for Intserv several enhancment has been made for RSVP to support MPLS Traffic Engineering.


Hope to help.



Re: Where does security sit?

Sounds really impressive answer Thank You @OrhanErgun. But with same when i overview security challanges with MPLS, I cannot deny the fact that there is no guarantee to VPN users that packets do not get read or corrupted when in transit over the MPLS core.

Re: Where does security sit?

For your security concern you are right at some level IMO. CIA which stands for confidentiality, integrity and availability should be in place for any critical data which needs to be protect.

If we look these three major field for VPNs, obviously if you are not encrypting your data, at least at service provider can be read, can be eavesdropping. But this is not weakness of MPLS, almost all overlays ( except IPSEC enabled DMVPN, GETVPN so on) works like this. So for confidentiality, another overlay , generally GETVPN is suggested over MPLS VPN since it is best suitable over the private VAN.

For integrity, you are also correct. There is no built in authentication/hashing alghoritm for MPLS. But again this is not weakness of MPLS, whatever technology you use, unless you are not implementing authentication maybe with preshared key or with certificates, you can not make sure from the integrity of packets.( For the link level errors some overlays use CRC for basic integrity check)

For availability, MPLS may or may not give you additional benefit based on which application of MPLS you implement.For example you might be implemented MPLS Traffic Engineering for local or path protection and you can get 50ms convergence time which is more than enough for most of the application.

Conclusion : MPLS is not weak from the security point of view compare to pure IP network, even maybe can be seen as more secure if you accept abstraction/segmentation as security parameters.