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.

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

At the age of 20, Brian McGahan earned his first CCIE in Routing & Switching, and became known as the “youngest engineer in the world.” He continued on to earn CCIE certifications in Security, Service Provider, and Data Center. Brian has developed and taught for INE since 2002, setting the bar for CCIE training and helping thousands of engineers obtain their own certifications--we’re proud to have such an accomplished and driven instructor on the INE team. When he is not developing new products for INE, he consults with large ISPs and enterprise customers. You may contact Brian McGahan at bmcgahan@ine.com, follow him on Twitter, or find him helping others in INE’s IEOC Community Forum.

Subscribe to INE Blog Updates

New Blog Posts!