Hi Brian-

A fellow CCIE candidate and I were recently discussing reflexive access lists and he brought up that in INE Vol 2, Lab 5, Section 6.1, the breakdown for reflexive access lists notes that traffic originated by the router is not reflected. He thought this may be because the traffic originating from the router is always control plane which I disagreed with, holding that the categorization is not strictly dependent on origin.

We consulted the Wendell Odom CCIE book and found this text, which further blurred the lines:

… But routers and switches must handle a variety of traffic, including BPDUs, routing updates, HSRP, CDP, CEF, process-switched packets, ARP, and management traffic such as SSH, SNMP, RADIUS. All of these are processed by the router or switch’s control plane…

Odom states that even SSH traffic can be considered control plane which seems contradicting to us.

We were hoping you could assist in drawing the line between the control plane and data plane. Is it determined by the source/destination of the packets, the use or intent of the packets, or is it more of a general abstract concept?

Thanks so much for the help!


Hi Joseph,

It’s kind of a gray area. The control plane in general is anything that’s needed in order to get routing working on that device; in other words, it is the “signalling” of the network. Control plane packets are destined to or locally originated by the router itself. This is really what separates the concept of the control and data plane.

What Odom is saying is that a routing update, let’s say OSPF, going to the router is process switched, which means that the general purpose CPU has to handle it. Management protocols, like Telnet, SSH, SNMP, etc. could be considered part of the control plane, but are more properly considered part of the Management Plane, which is a specific subset of the control plane. This may give you an idea of what I mean.

As for the data plane, sometimes called the Forwarding Plane, this is basically anything that goes *through* the router, and not *to* the router. The protocol or application itself doesn’t really determine whether the traffic is control, management, or data plane, but more importantly how the router processes it.

For example suppose we have a simple 3 router topology that is R1–R2–R3, and R1 and R3 are running BGP with each other. From R1 and R3′s perspective, these packets are part of the control plane, because they are locally originated/destined, and need to be process switched in order to look into the packet details and actually build the BGP table. However from R2′s perspective, these packets would be in its data plane, because the traffic is neither originated from or destined to it. If R2 was a distributed platform, say 7600, it would be able to CEF switch these BGP packets at the line card without having to consult the general Route Processor (RP). However regardless what architecture R1 and R3 used, this traffic would be process switched because it is their local control plane traffic.

The same would be true of Telnet in this case. If R1 Telnets to R3, on both of these routers the packets need to be handled by the control/management plane. However from R2′s perspective this is just data plane traffic that is transiting between its links.

As for the reflexive access list, it’s unrelated to this. The issue is that an outbound access-list does not affect locally generated traffic on the router. It’s an issue with the internal order of operations of the router’s processes.  Check this video for more information on the reflexive access list issue.

About Brian McGahan, CCIE #8593, CCDE #2013::13:

Brian McGahan was one of the youngest engineers in the world to obtain the CCIE, having achieved his first CCIE in Routing & Switching at the age of 20 in 2002. Brian has been teaching and developing CCIE training courses for over 10 years, and has assisted thousands of engineers in obtaining their CCIE certification. When not teaching or developing new products Brian consults with large ISPs and enterprise customers in the midwest region of the United States.

Find all posts by Brian McGahan, CCIE #8593, CCDE #2013::13 | Visit Website

You can leave a response, or trackback from your own site.

22 Responses to “Control Plane vs. Data Plane”

  1. xda.kok says:

    Just a quick question regarding the data and transport plane.
    Watching MPLS vod 3 I understand that the MPLS VPN label aids the PE into which CE to send a packet. On the other hand the route-target tells the PE into which vrf table certain prefixes have to be imported. It looks redundant, so the route-target happens at the control plane and the mpls vpn label at the data plane…
    Still it not clear to me how this second (MPLS VPN) label is generated and how it get exactly exchanged and how it relates to the route-target. I would appreciate if you can elaborate more on this.


    • Correct, the route-target is used in the control plane of VPNv4 BGP to control which VPN (VRF) a route belongs to. The control plane also generates the MPLS labels. Specifically there are two labels that are significant in MPLS L3VPN, the Transport Label and the VPN Label. The Transport Label is normally generated by LDP, and tells the MPLS core which PE the traffic should be routed to. The VPN Label is generated by VPNv4 BGP, and tells the PE which CE the traffic should be routed to. The actual routing of the packets happens in the Forwarding (Data) Plane, but the labels are derived via the Control Plane.

      Check these videos for more detailed explanations and examples:
      MPLS Layer 3 VPNs and VPNv4 BGP
      MPLS Layer 3 VPN Verification & Troubleshooting

  2. John says:

    Nice explanation. I think (correct me if I am wron) that key point is that the transport happens in global so a vpn label is needed so that the PE knows to which vrf to switch and continue forwarding the vpn4 address to the CE device. This is indeed an example to show the difference between the data and control plane since for this to work the routes in the vrf table alone is not enough.

    • Correct. When the packet is received on the PE router from the P routers (MPLS cloud), it comes in on an interface in the global routing table. Since you can have the same IP prefix in multiple VRF tables, the PE router would not know which VRF table to do the routing lookup in without the VPN label.

  3. John says:


    Thank you for the clarification !

  4. Anna says:

    Hi Brian

    I built a topology with routers

    R1 connected ( serial) to R2 connected (serial ) to R3

    I used Ripv2 ( No auto summary ) for establishing connectivity.

    Now I started telnet session from R1 to R3 and ran debug ip packet

    Then what I see in R1 and R3 is

    From R1 the packet consults FIB and the return traffic is routed through RIB

    In R3 also the traffic destined to R3 is routed through RIB and
    the return traffic is Forwarded using FIB

    Now my question whether traffic orignated from the router uses FIB or CEF always?

    Or can we say that the traffic orignated and which passes through the router is CEF switched and traffic destined to the router is process switched or uses RIB?


  5. michal says:

    Brian , thanks for the post and I was wondering about what would be the good interpretation of the control plane protocols such as BFD that are supposed to be hardware supported on some high-end platforms ? We probably can not consider them at the exactly same level with other c-plane protocols in terms of the processing ? or maybe it’s just hardware for hello/keepalive only .

  6. ccieanna says:

    Hi Brian

    I have some doubts.

    If the debug output is process switched then there is a command
    debug ip cef then how will CEF switched traffic will be process switched.

    Sorry I am little bit confused here.

    When I Telnet and issue a debug command the output says that
    the traffic is using FIB.The process switched traffic should use RIB

    Only when I switch CEF off the traffic uses RIB.

    Why this anomaly?

    Could you please explain this?


  7. ccieanna says:

    Hi Brian

    Got it.

    I have some doubts . I will post in forum.

    Thanks for replying.


  8. miodragpro says:

    Simply and clear.
    Thanks Brian.

  9. [...] Lí thuyết về control plane và data plane đã xuất hiện trong các sách của CCNA nhưng mình còn nắm rất mơ hồ. Thậm chí bây giờ vẫn còn cảm thấy khó hiểu. Hôm nay mình tìm hiểu 1 vài tài liệu trên net, cũng vỡ ra được đôi chút. Mình lược dịch lại một bài viết trên blog INE để giúp các bạn dễ hiểu hơn. Các bạn có thể đọc bản gốc tại ĐÂY. [...]

  10. Rajan says:

    Please correct me if i am wrong:
    Control plane and Data plane are equivalent to Routing Engine & Packet Forwarding Engine in Juniper right?

  11. Bogdan says:

    Hi Brian,

    Is there any difference for the broadcast traffic? In theory, the traffic should be handled by data plane, like any other traffic, but if the device (let’s say it’s a switch) has an SVI in that VLAN, then the broadcast is destined for the switch as well. Is there any way for the data plane to “know” if the broadcast should be process switched?


    • Broadcasts are switched but not routed, unlike unicast or multicast which can be both switched and routed. This is why a VLAN is considered your “broadcast domain” because a broadcast can not leave the local VLAN. If the router/switch is running layer 3, and has an IP address on the subnet that the broadcast is received on, then yes it is process switched. In terms of CEF switching this is called a “receive adjacency”, which is for any packets destined to the router itself.

  12. bach says:

    Great read. Straight and to the point with the examples.

  13. Sachet Bansal says:


    I want to know that if we consider a general scenario in which until our management plane is not active then we cannot configure protocols on the control plane means the control plane does not get active, so we can say that control plane is dependent on management plane and vice versa if we are able to reach the device as there are no protocols active in the control plane which can carry our telnet or ssh packet to the device. If we consider the above points then we can see that the management plane is dependent on control plane and vice versa. But does this apply for data plane also, i mean until the control plane isn’t active the data will not flow through the network so the data plane is dependent on control plane. Does any of the plane has its dependency on the data plane?
    I want to know the inter-relationship between these three planes and the authenticity level of my statement.
    Kindly clarify it out to me.

    • Hi Sachet,

      This is a very good question, and yes, both the management and control planes are dependent on each other. Take for example a regular x86 server. Suppose that remote access to the server is lost, e.g. Apache stops responding to TCP port 80, and the web server is down. If the problem is due to the underlying control plane, for example routing in the network is broken, then all data plane and “in-band” management plane traffic is dropped. I.e. you won’t be able to SSH to the server to manage it. In these type of situations, “in-band” management vs. “out-of-band” management (OOB) is what ultimately determines whether you can still manage the box or not. In our simple server crash example, the “out-of-band” management of the server recovery would to directly plug into it with a keyboard, video, and mouse (KVM), and see if there’s any local output.

      In the case of current networking devices, there is generally both an out-of-band serial (console) port that you can locally connect to the OS from, plus a dedicated out-of-band Ethernet management port that you can connect to the OS from. Normally the OOB Ethernet management port has a separate CPU controlling it, which means that if the normal control/data plane CPU crashes, it’s failure is isolated from the management plane CPU.

      The end result is that management and control planes *aren’t* always dependent on each other anymore (originally they were), but data-plane is still always dependent on control-plane. Note that there are certain cases where data-plane and control-plane are hardware separated, and data-plane can forward through a control-plane failure, e.g. Non-Stop Forwarding (NSF). Even in these cases however an initial control-plane is always first required to initialize the data plane.


Leave a Reply


CCIE Bloggers