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.

Easy Way to Generate Packets using Scapy

SCAPY STEPS:

1. Now, capture a packet on the port where we want to send our packet from and store it into filename.pcap. Send the file to your desktop using scp

#bash

$tcpdump -i et1_4 -w /mnt/flash/originalpacket.pcap

2. Now, open wireshark and select a packet and go to File > Export selected packet > Give a modifiedpacket.pcap

3. Copy the modifiedpacket.pcap to the switch from where we want to send the packet.

3. In switch (from which we want to send the packet), go to bash and install scapy on the switch from where we want to send

#bash

        $sudo wget scapy.zip

2. Now, run scapy by typing $sudo scapy //now we will get >>>Welcome to scapy

3. If we want to send the packet directly, use

 >>>sendp(rdpcap(“/mnt/flash/modifiedpacket.pcap”),iface=”et1_4”) //this sends the packet on interface et ¼.

Note: The above command can be used to send even many packets. It will send those packets one by one on the given interface. So, essentially, we couldv’e also used

>>>sendp(rdpcap(“/mnt/flash/originalpacket.pcap”),iface=”et1_4”)

(OR)

If we want to modify any fields:

>>>somename=rdpcap(“/mnt/flash/modifiedpacket.pcap”)

>>>somename \\show all the packets in the pcap file

>>>somename[0] \\we choose only the first packet. If we press enter, we will see all the layers in that packet

>>>somename[0][STP] \\we will filter in that packet for only the STP protocol

>>>somename[0][STP].portid = 12345\\we see which fields are there and use that name and then give the value we want. Here, for eg, we want to change the portid field and give it a value of 0X809a

>>>sendp(somename[0],iface=”et1_2”) //sends the selected packet (here, packet 0) on the interface et ½ . We will get a message saying that it has been sent

ARP and types of ARP

INTRODUCTION TO ARP:
* ARP is used to find the MAC address of the device for which we already know the IP address.
* The address resolution protocol (arp) is a protocol used by the IP, specifically IPv4, to map IP network addresses to the hardware addresses used by a data link protocol.
* The protocol operates on the Datalink layer (L2) but carries L3 information (IP addresses)
* There are four types of arp messages that may be sent by the arp protocol. These are identified by four values in the "operation" field of an arp message. The types of message are:
1. ARP request
2. ARP reply
3. RARP request
4. RARP reply
* The format of an arp message is shown below:
*

ARP Cache: * To reduce the number of address resolution requests, a client normally caches resolved addresses for a (short) period of time.
* The arp cache is of a finite size, and would become full of incomplete and obsolete entries for computers that are not in use if it was allowed to grow without check.
* The arp cache is therefore periodically flushed of all entries.
* This deletes unused entries and frees space in the cache.
* It also removes any unsuccessful attempts to contact computers which are not currently running.
* The arp request message ("who is X.X.X.X tell Y.Y.Y.Y", where X.X.X.X and Y.Y.Y.Y are IP addresses) is sent using the Ethernet broadcast address, and an Ethernet protocol type of value 0x806. Since it is broadcast, it is received by all systems in the same collision domain (LAN). This is ensures that is the target of the query is connected to the network, it will receive a copy of the query. Only this system responds. The other systems discard the packet silently.

GRATUITOUS ARP:
* Gratuitous ARP is used when a node (end system) has selected an IP address and then wishes to defend its chosen address on the local area network (i.e. to check no other node is using the same IP address). It can also be used to force a common view of the node's IP address (e.g. after the IP address has changed).
* Use of this is common when an interface is first configured, as the node attempts to clear out any stale caches that might be present on other hosts. The node simply sends an arp request for itself.


STATIC ARP:
* We can manually map an Ip address to a specific IP address.
* In switch (conf)#arp <ip address> <mac address> ARPA
* Then, we can see in ARP table using #show arp
* Note: if we don’t see the mapping, it is because the switch thinks the Ip address is in different subnet. So, we can use #ip address <ip address>/24 and then try the above show command

PROXY ARP:
http://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation-resolution/13718-5.html
* Proxy ARP is the technique in which one host, usually a router, answers ARP requests intended for another machine.
* Proxy ARP is the name given when a node responds to an arp request on behalf of another node. This is commonly used to redirect traffic sent to one IP address to another system.
* Proxy ARP works when the hosts are not configured with a default gateway.
* Thus, if A has to send packet to another Ip address on a different network (or different subnet also)

REVERSE ARP:
* Reverse ARP (RARP) as defined by RFC 903 works the same way as the Address Resolution Protocol (ARP), except that the RARP request packet requests an IP address instead of a media access control (MAC) address.
* RARP often is used by diskless workstations because this type of device has no way to store IP addresses to use when they boot. The only address that is known is the MAC address because it is burned in to the hardware.
* RARP requires a RARP server on the same network segment as the device interface. The figure below illustrates how RARP works.

* Because of the limitations with RARP, most businesses use Dynamic Host Configuration Protocol (DHCP) to assign IP addresses dynamically. DHCP is cost-effective and requires less maintenance than RARP. The most important limitations with RARP are as follows:
* Because RARP uses hardware addresses, if the internetwork is large with many physical networks, a RARP server must be on every segment with an additional server for redundancy. Maintaining two servers for every segment is costly.
* Each server must be configured with a table of static mappings between the hardware addresses and the IP addresses. Maintenance of the IP addresses is difficult.
* RARP only provides IP addresses of the hosts but not subnet masks or default gateways.


UNICAST ARP REQUEST:
* As per RFC 1122: Unicast Poll -- Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls. Again, the timeout should be on the order of a minute, and typically N is 2.
* This is one of four mechanism to timeout the stale ARP entries.

DHCP Snooping

• DHCP snooping is a security feature that acts like a firewall between untrusted hosts and trusted DHCP servers. The DHCP snooping feature performs the following activities:
  

•Validates DHCP messages received from untrusted sources and filters out invalid messages.

•Rate-limits DHCP traffic from trusted and untrusted sources.

•Builds and maintains the DHCP snooping binding database, which contains information about untrusted hosts with leased IP addresses.

•Utilizes the DHCP snooping binding database to validate subsequent requests from untrusted hosts.

• DHCP snooping is enabled on a per-VLAN basis. By default, the feature is inactive on all VLANs. You can enable the feature on a single VLAN or a range of VLANs.
  

• Packet Validation:
  
• The switch validates DHCP packets received on the untrusted interfaces of VLANs with DHCP snooping enabled. The switch forwards the DHCP packet unless any of the following conditions occur (in which case the packet is dropped):
  
• The switch receives a packet (such as a DHCPOFFER, DHCPACK, DHCPNAK, or DHCPLEASEQUERY packet) from a DHCP server outside the network or firewall.
  
• The switch receives a packet on an untrusted interface, and the source MAC address and the DHCP client hardware address do not match. This check is performed only if the DHCP snooping MAC address verification option is turned on.
  
• The switch receives a DHCPRELEASE or DHCPDECLINE message from an untrusted host with an entry in the DHCP snooping binding table, and the interface information in the binding table does not match the interface on which the message was received.
  
• The switch receives a DHCP packet that includes a relay agent IP address that is not 0.0.0.0.
  

• The default trust state of all interfaces is untrusted. You must configure DHCP server interfaces as trusted. You can also configure other interfaces as trusted if they connect to devices (such as switches or routers) inside your network. You usually do not configure host port interfaces as trusted.
  

More info:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/snoodhcp.html

Configuring DHCP Server on Arista EOS

We know that Arista's EOS operating system runs on top of Linux. So, in order to configure DHCP Server on Arista's EOS, the way is to install the DHCP package on linux. The steps are shown below:

Configuring DHCP Server and Relay:

Switch1 (server) (et30)-----(et30) DHCPRelay (int vlan 1, switchport access-vlan 1)------Client

On Switch 1 (DHCP Server)

• #int et 30  \\we use et30 because both the switches are connected via et30 on both sides
  

#no switchport

#ip address 10.0.0.1/30

• #ip route 192.168.1.0/24 10.0.0.2  \\giving a static route to the destination n/w (192.X.X.X) and also we specify the next hop which is the Relay (10.0.0.2)
  

• #show version ||to check the fedora version. Eg) fc14 or fc18. If FC18, downgrade to FC14 using #Dir \\check for the image of older version and then #bootfrom <image> • Download the correct RPM from the following URL: http://dl.fedoraproject.org/pub/archive/fedora/linux/updates/, choose i386 architecture and send the file to switch using #copy scp:admin@macbook-pro/Users/Desktop/dhcp.rpm extension: • #extension dhcp.i686.rpm \\To install the dhcp extension • #bash • $sudo vi /etc/dhcp/dhcpd.conf • # DHCP Server Configuration file. #   see /usr/share/doc/dhcp*/dhcpd.conf.sample #   see dhcpd.conf(5) man page ddns-update-style interim; subnet 192.168.1.0 netmask 255.255.255.0 {         option routers                  192.168.1.254;         option subnet-mask              255.255.255.0;         option domain-search              "example.com";         option domain-name-servers       192.168.1.1;         option time-offset              -18000;     # Eastern Standard Time         range 192.168.1.10 192.168.3.99; } subnet 10.0.0.0 netmask 255.255.255.252 { range 10.0.0.1 10.0.0.2; }  (OR) subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.254; //the IP address of SVI is the default gateway option subnet-mask 255.255.255.0; range 192.168.1.20 192.168.1.30; } subnet 10.0.0.0 netmask 255.255.255.252 { range 10.0.0.1 10.0.0.2; } • $service dhcpd start \\to start the dhcp service • $service dhcpd status \\to check whether the dhcp service is running • $sudo dhcpd et 30 • $sudo dhcpd vlan1 \\to assign DHCP IP address to devices on vlan1

On Switch 2 (relay),

• Configuring the interface connected to client side:

#conf

#int vlan1

#ip address 192.168.1.254/24 //Making a router and network for the hosts since hosts are connected to relay router

#ip helper 10.0.0.1 \\Configuring this router to act as relay, so use the IP address of the switch 1 interface. It should be assigned for the vlan network

• Configuring the interface connected to server:

(conf)#int et 30  \\connecting it to switch 1

#no switchport

#ip address 10.0.0.2/30 

FOR TROUBLESHOOTING:

#show ip dhcp relay counters