Control and Data Plane

Control and Data Planes

Last Updated: [last-modified] (UTC)


Routers and switches use a conceptual model called ‘planes’. Planes describe how packets travel to, from, and through a device.

The control and data planes do not describe data itself. Rather, these planes describe how the device handles the data. For example, does the device process a packet itself, or does it forward it to another device?

To make matters more tricky, each device may see the traffic ins a different way. One device may classify traffic as data plane traffic. Another may classify the same traffic as part of the control plane.

The lines between the control and data plane can get blurry sometimes. The following sections will attempt to separate the two.



Control Plane

The control plane is generally considered to be where a router or switch makes its decisions. This is software based, and uses the CPU rather than specialised hardware, such as an ASIC.

For this reason, many people call the control plane the ‘slow path’.

Remember how the planes refer to how a device handles traffic? Well, traffic sent to a device or generated on a device is control plane traffic. An example of this is when a router forms neighbour relationships in OSPF or EIGRP. Or, when switches share BPDU’s for spanning-tree.


Control Plane traffic is sent to a device, or generated on a device



Another function of the control plane is to assign resources to the data plane. An example of this is using the data from the RIB to populate the FIB.

A logical subset of the control plane is the Management Plane. Any management traffic for the local device (such as SSH) is part of the management plane. This is because the destination of the management traffic is the local device.


Data Plane

The data plane (or forwarding plane) is the high speed path through the router/switch. Packets that pass through the device use the data plane, as opposed to packets directed to the device. For this reason, the data plane is also called the forwarding plane.


Data Plane traffic is forwarded through a device


The data plane need to provide a high speed and low latency path. To achieve this, a lot of data plane implementation is in hardware. This includes performing CEF lookups/caching, and using special ASICs. The FIB and LFIB are part of the data plane.


Want to see how ASIC’s work?

[maxbutton id=”1″]



Virtual switches are a little bit different. They don’t generally have specialised hardware to create a high-speed data path. This does not mean that they don’t have a data plane. Software techniques, such as special data structures and optimised kernels, provide the forwarding path.

But what about management traffic? What if it passes through a switch or router, destined for another device? This traffic is being forwarded, so for this device, it uses the forwarding plane (or data plane).



A few quick examples;

  • SSH to a router; Control Plane
  • Passing SSH traffic through to another device; Data Plane
  • BGP neighbour relationship; Control Plane
  • Forwarding BGP traffic; Data Plane
  • OSPF neighbourships and building the LSDB; Control Plane


A special case would be when the control and data planes span across a ‘fabric’. An example of this is a spine/leaf topology in a data centre. In this case, BGP EVPN provides a distributed control plane. But that’s a topic worthy of its own article.




3 thoughts on “Control and Data Plane”

  1. Migrated Comment:

    Christian (unverified) 2018-07-12 15:57
    This is a great write-up that cleared up some confusion i was experiencing. I like how you clarified that the mgmt plane is a subset of the control plane because i have been under the assumption that there are 3 planes, but when i do research the topic, i see mostly Data & Control planes.

Leave a Reply