Data Plane (or) Forwarding Plane

DATA PLANE:

• 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 data plane is the workhorse of the switching elements in our networks.
• It has the responsibility of parsing packet headers (or cells, SONET) in high speed search ASICs. It manages QOS, filtering, encapsulations, Queuing, Policing all of the reasons we had and still do in many cases purpose built silicon or custom ASIC designs.
• The data/forwarding plane must do those operations in the “Fast Path” to keep up with performance needs in data centers and core networks.  (https://en.wikipedia.org/wiki/Fast_path)
• A case here could be Arista’s 7124FX switch that have low latency as well FPGA for programming the data plane
• The functions of data plane are:

• Also known as Forwarding Plane
• Forwards traffic to the next hop along the path to the selected destination network according to control plane logic
• Data plane packets go through the router
• The routers/switches use what the control plane built to dispose of incoming and outgoing frames and packets

• Forwarding data planes typically come either centralized or distributed. This means the forwarding engine is either centrally located across the ethernet fabric/crossbar or pushed all the way to the edge. The more performance required the more that distributed forwarding is pushed to the edge.
• For example - when a LAN switch receives a frame in an interface in VLAN 3, the switch makes a forwarding decision based on the VLAN 3 entries in the MAC address table, and forwards the packet. All this logic focuses on forwarding the user's data, so it is part of a switch's data plane processing.

Control Plane

CONTROL PLANE:

• Control plane packets are destined to or locally originated by the router itself.
• 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.
• The Routing Information (data)Base (RIB) and Label Information Base (LIB) are processed in software and used to populate FIB(forwarding information base) and the LFIB.
• The Control plane feeds the forwarding/data plane with what it needs to create its forwarding tables and updates topology changes as they occur. The number of control packets is very very small even in a very large network. This is the reason the control plane can often be thought of as the “slow path” in legacy route once-switch-many-packet switching architectures.
• In distributed architecture platforms, routing protocols, and most other protocols, always run on the core CPU. But, there are other control plane protocols such as ARP, BFD, and ICMP that in some distributed architecture platforms have now been offloaded to the line card CPU.
• A list of functions performed in control plane are:

• Makes decisions about where traffic is sent
• Control plane packets are destined to or locally originated by the router itself
• The control plane functions include the system configuration, management, and exchange of routing table information
• The route controller exchanges the topology information with other routers and constructs a routing table based on a routing protocol, for example, RIP, OSPF or BGP
• Control plane packets are processed by the router to update the routing table information.
• It is the Signalling of the network
• Since the control functions are not performed on each arriving individual packet, they do not have a strict speed constraint and are less time-critical

• For example: STP and any IP routing protocol are examples.......

Control Plane and Data Plane- Highlights

• We have 2 planes- Data and Control Plane
• ASICs are there in data plane and CPU is there in Control Plane
• Data Plane is a forwarding plane. It checks only the destination MAC address.
• if it doesn’t match its own addresses, it just forwards based on its forwarding tables.

• If it matches, it sends it up to CPU (Control Plane)

• We also have a trap mechanism where it filters for specific MAC address. For eg, in STP, even though the MAC address is not addressed to us, a trap is created which forces to send the STP BPDUs to the Control Plane.
• Another case where trap occurs can be seen when the MAC address is addressed to us but the IP address is different (eg, using static ARP), then, since we won’t have the address in our forwarding tables even though we are on same SVI VLAN, it traps to the Control Plane in order to sends back a “Destination Unreachable” message.

DATA PLANE and CONTROL PLANE:

• Responsible to forward the transit traffic (either user or production traffic).
• The actual forwarding happens in the data plane.

• Control Plane is responsible for decision making (like whether to prefer BGP route or OSPF route and chooses BGP route) and then forwards it to data plane.
• Even the rules for data plane has to be programmed through Control Plane. For eg, we program the data plane to forward the packets or to send to the CPU via control plane
• We can see the data plane forwarding rules via #show ip route hosts //we will see that for these IP address, send to the CPU
• #show platform trident l3 hardware routes

//this command can be used to see the hardware programming for L3 .ie. IP addresses. For L2, it is programmed in TCAM. Now, in the above command, if MAC address is 00:00:00:00:00:00 for any IP, then, it is forwarded to the CPU. If any IP to other MAC address is there, it had been learnt through ARP. (note: we can verify by seeing that all the entries of ARP will also be there in table, other than the ones on management interface, since management is not connected to ASIC)

• #show process top //can be used to see the live running process on EOS.

        If we ping a switch using very large size and repeat, then, we can see that the CPU usage is very high.

• #bash

        $netstat -s

        //This command can be used to see the CPU drops

• Now, during troubleshooting, if we have to see even transit traffic, we cannot do so using tcpdump. For that, we use port mirroring.

#monitor session <anysessionname> source <interface> <direction>

Here, <anysessioname> = anand

interface = et 23

direction= both (looks at both ingress and egress ports)

#monitor session <anysessionname> destination et 21 //Now, if we connect a host to et21 and run wireshark, we can see all the traffic (both transit and CPU oriented ) on the interface et 23

---

• 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 OSPF 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 OSPF database. However from R2′s perspective, these packets would be in its data plane, because the traffic is neither originated from or destined to it.