Config Lab: DAI 1

Wendell Odom
By Wendell Odom October 8, 2021 17:05

IP uses Address Resolution Protocol (ARP) to discover the MAC address used by other hosts in the same subnet. Unfortunately, cybersecurity attacks often use legitimate protocols in unintended ways to form an attack, and ARP is no exception.

To help prevent ARP-based attacks, engineers can enable the Dynamic ARP Inspection (DAI) feature of LAN switches. DAI in a switch monitors ARP messages flowing through the switch, filtering messages based on a set of rules. Notably, DAI compares ARP messages to tables of legitimate data about IP/MAC address pairs, with the DHCP Snooping feature gathering that data based on DHCP messages. In this lab, you configure both DAI and DHCP snooping on two different switches and examine the minor differences in configuration.

All about Config Labs

The blog has a series of lab exercises called “Config Labs.” Each lab presents a topology with the relevant initial configuration for each device. The lab also lists new requirements, after which you should create the additional configuration to meet those requirements. You can do the lab on paper, in a text editor, or use software tools like Cisco Packet Tracer or Cisco Modeling Labs.

Once you have created your answer, you can click various tabs at the bottom of this post to see the lab answers, comments about the lab, and other helpful information.

The Lab Exercise

The Lab Exercise

Many cybersecurity attacks use established protocols like DHCP and ARP to find a way to learn information and cause problems in a network. Two switch features, DHCP Snooping and Dynamic ARP Inspection (DAI), prevent attacks based on DHCP and ARP, respectively. Both use a similar configuration model to enable the feature in a VLAN and then either trust or not trust each switch port.

DAI relies on a list of valid IP/MAC address pairs. The list includes IP/MAC address pairs considered to be legitimate in the subnet. DAI then monitors incoming ARP messages on untrusted ports, comparing the ARP messages to the table of legitimate address pairs and filtering the messages that do not conform to the entries in the table.

DAI uses a table built by DHCP Snooping or by ARP ACLs. For this lab, configure DHCP Snooping correctly, which causes DHCP Snooping to create a table called the DHCP Snooping Binding Table. This table lists the IP/MAC address pairs for any host that successfully leased an IP address. Then also configure DAI so that it uses the DHCP Snooping Binding table to make its decisions.

 

For this lab, take these specific steps.

  1. Configure DHCP Snooping as follows:
    1. Enable DHCP Snooping in VLAN 10.
    2. Switch SW1 operates as a layer 2 switch, not a layer 3 switch, so disable the insertion of DHCP Option 82 headers.
    3. Configure (or use the default) so each switch port is either trusted or untrusted for DHCP Snooping.
  2. Configure DAI as follows:
    1. Enable DAI in VLAN 10.
    2. Analyze the devices attached to the switch and ask yourself: Which devices will have entries in the DHCP Snooping Binding table? Then, make a note of those devices and switch ports.
    3. Configure (or use the default) so each switch port is either trusted or untrusted for DAI Snooping.

 

Initial Configurations

The initial configuration on switch SW1 places all four of its ports into the same VLAN (VLAN 10). In addition, the router has an IP address configured on its LAN interface (G0/0) so that it can ping the DHCP server’s address on the LAN. The router should also be able to ping the client PCs once they lease an IP address.

Example 1: SW1 Config

 

Example 2: R1 Config

 

The PCs each act as a DHCP client, expecting to lease an IP address and learn the mask and default gateway settings from the DHCP server. You can assume the DHCP Server shown in the figure works. However, to be complete, Example 5 shows the IOS DHCP server configuration that you could use to support this lab. (The CPT and CML files supplied with this lab use this same configuration.)

Example 3: DHCP Server (IOS Router)

Answer Options - Click Tabs to Reveal

You can learn a lot and strengthen real learning of the topics by creating the configuration – even without a router or switch CLI. In fact, these labs were originally built to be used solely as a paper exercise!

To answer, just think about the lab. Refer to your primary learning material for CCNA, your notes, and create the configuration on paper or in a text editor. Then check your answer versus the answer post, which is linked at the bottom of the lab, just above the comments section.

You can also implement the lab using the Cisco Packet Tracer network simulator. With this option, you use Cisco’s free Packet Tracer simulator. You open a file that begins with the initial configuration already loaded. Then you implement your configuration and test to determine if it met the requirements of the lab.

(Use this link for more information about Cisco Packet Tracer.)

Use this workflow to do the labs in Cisco Packet Tracer:

  1. Download the .pkt file linked below.
  2. Open the .pkt file, creating a working lab with the same topology and interfaces as the lab exercise.
  3. Add your planned configuration to the lab.
  4. Test the configuration using some of the suggestions below.

Download this lab’s Packet Tracer File

You can also implement the lab using Cisco Modeling Labs – Personal (CML-P). CML-P (or simply CML) replaced Cisco Virtual Internet Routing Lab (VIRL) software in 2020, in effect serving as VIRL Version 2.

If you prefer to use CML, use a similar workflow as you would use if using Cisco Packet Tracer, as follows:

  1. Download the CML file (filetype .yaml) linked below.
  2. Import the lab’s CML file into CML and then start the lab.
  3. Compare the lab topology and interface IDs to this lab, as they may differ (more detail below).
  4. Add your planned configuration to the lab.
  5. Test the configuration using some of the suggestions below.

Download this lab’s CML file!

 

Network Device Info:

This table lists the interfaces listed in the lab exercise documentation versus those used in the sample CML file.

Device Lab Port  CML Port
SW1 G0/1 G0/0
SW1 F0/1 G0/1
SW1 F0/2 G0/2
SW1 F0/3 G0/3
R1 G0/2/0 G0/2

Lab Answers Below: Spoiler Alert

Lab Answers: Configuration (Click Tab to Reveal)

Example 1: SW1 Config

Commentary, Issues, and Verification Tips (Click Tabs to Reveal)

First, focus on the DHCP Snooping configuration independent of the DAI configuration. The first three lines of Answer Example 1 list the DHCP Snooping global configuration. The first two commands enable DHCP Snooping in VLAN 10 (both are required): ip dhcp snooping and ip dhcp snooping vlan 10. Then, the no ip dhcp information option global command reverses a default setting of ip dhcp information option, which is necessary because the default setting makes sense only when the switch acts as both a layer 3 switch and as a DHCP Relay Agent.

As for the DHCP Snooping trust settings, the two switch SW1 ports connected to the DHCP clients can use the default setting of untrusted. But those defaults matter quite a bit to DAI because of the last of the following logic switch logic steps:

  1. DHCP Client messages enter the DHCP Snooping untrusted ports.
  2. DHCP Snooping allows the messages because they follow protocol rules.
  3. DHCP Snooping adds IP/MAC address pairs to the SW1 DHCP Snooping Binding table.

As for the other switch ports, the switch must trust the ports connected to the DHCP server (ip dhcp snooping trust) so that SW1 will allow incoming DHCP messages from the DHCP server. Also, note that the switch need not trust its port G0/1 (connected to router R1) because there should be no messages from the DHCP server arriving in that port. However, were the DHCP Server somewhere in the network further to the right of router R1, then SW1 would need to trust port G0/1 for DHCP Snooping.

Now, consider the DAI configuration. To start, ask yourself: For which of switch SW1’s switch ports does it make sense to treat the port as trusted and untrusted for DAI? It turns out that you can choose which ports to trust with DAI based on two rules:

  1. Trust for DAI if trusted for DHCP Snooping.
  2. Trust for DAI if the attached device is not a DHCP Client (even if the port is untrusted for DHCP Snooping)

Applying those rules to configure this lab, you should:

  • Make switch ports F0/2 and F0/3, the ports connected to the PCs, untrusted for DAI (the default setting)
  • Make switch port F0/1, the port connected to the DHCP server, trusted for DAI (rule 1 above)
  • Make switch port G0/1, the port connected to the router, trusted for DAI (rule 2 above)

Beyond those settings, DAI requires a single global configuration command to both enable the feature and enable it in a specific VLAN: ip arp inspection vlan 10 in this case.

Known Issues in this Lab

This section of each Config Lab Answers post hopes to help with those issues by listing any known issues with Packet Tracer related to this lab. In this case, the issues are:

Number Summary Detail
1 Core feature config only CPT supports the configuration of core DAI features, including all mentioned in this lab. However, the configuration support is limited.
2 DAI does not work as intended. CPT does not filter ARP messages with DAI enabled. Therefore, when you enable DAI and follow testing steps to simulate an attack, DAI does not filter the messages.
3 Incorrect show ip dhcp snooping binding output On real gear, this command displays the DHCP Snooping Binding Table. CPT sporadically displays correct table entries.
4 Sparse show ip dhcp snooping output Real gear displays more detailed output as compared to CPT.
5 Incorrect show ip arp inspection output Once configured, real gear shows the feature with a state of “active” in a VLAN. CPT shows “inactive.”
6 CPT feature platform differences In CPT, the 2960 and 3650 switch models provide some DHCP Snooping support. However, the support levels differ, with some differences in show commands. In our testing, the feature could be configured on both models but only worked when using 2960s.

 

Why Would Cisco Packet Tracer Have Issues?

(Note: The below text is the same in every Config Lab.)

Cisco Packet Tracer (CPT) simulates Cisco routers and switches. However, CPT does not run the same software that runs in real Cisco routers and switches. Instead, developers wrote CPT to predict the output a real router or switch would display given the same topology and configuration – but without performing all the same tasks, an actual device has to do. On a positive note, CPT requires far less CPU and RAM than a lab full of devices so that you can run CPT on your computer as an app. In addition, simulators like CPT help you learn about the Cisco router/switch user interface – the Command Line Interface (CLI) – without having to own real devices.

CPT can have issues compared to real devices because CPT does not run the same software as Cisco devices. CPT does not support all commands or parameters of a command. CPT may supply output from a command that differs in some ways from what an actual device would give. Those differences can be a problem for anyone learning networking technology because you may not have experience with that technology on real gear – so you may not notice the differences. So this section lists differences and issues that we have seen when using CPT to do this lab.

Beyond comparing your answers to this lab’s Answers post, you can test in Cisco Packet Tracer (CPT) or Cisco Modeling Labs (CML). In fact, you can and should explore the lab once configured. However, note that in CPT Version 8.0, which we used when creating this lab in 2021, CPT did not implement DAI verification commands very well. If using a later CPT version in later years, you may get better results. Regardless, you can try the various show commands in the list below:

  1. Display all DHCP Snooping settings and per-interface non-default settings: show ip dhcp snooping
  2. Display the DHCP Snooping Binding Table: show ip dhcp snooping binding
  3. Display subsets of information about DAI:
    1. show ip arp inspection
    2. show ip arp inspection interfaces
    3. show ip arp inspection statistics

More Labs with Related Content!

Config Lab: DHCP Snooping 2
Config Lab: CDP/LLDP 1
Wendell Odom
By Wendell Odom October 8, 2021 17:05
Write a comment

18 Comments

  1. Henri June 3, 13:40

    Hello i think that SW1 config answer in line 3 should be:
    no ip dhcp snooping information option

    Reply to this comment
  2. Edmond H. January 7, 18:35

    Hello,

    Since we are talking about security I have two questions:

    1) Some operating systems allow us to change the mac address, and if I well understood, DAI can detect that as explained in the Cert Guide Vol. 2 pg 159-160.
    That means if we modify the host’s mac address, the mac address in the ethernet header or arp header (I don’t know which one will be changed) won’t match the hardware mac address and DAI will discard the frame.

    Is what I am telling true or not?

    2)If the answer of the question 1 is true:

    If the DAI is not enable, all “switchport port-security” functionalities become deciduous for hackers.Because an attacker could use an allowed mac address to bypass the security rules.

    True or not?

    Thanks in advance.

    Reply to this comment
    • Wendell Odom Author January 12, 11:14

      Hi Edmund,
      Taking your questions by number:
      1: I haven’t tested that specific scenario. Let’s say in that scenario the user is legit. If they change the MAC and reboot, causing the switch port to go down, I believe then DHCP Snooping will remove its snooping binding table entry, when the PC comes up and DHCP leases the switch makes a new DHCP snooping binding entry. So DAI has a legit entry to use.
      DAI is more about an attacker on a second port when stable on the first port, which isn’t the scenario you described. But taking your scenario literally, if changing the MAC on the PC left the switch port up, without testing it, I would guess DAI would stop the traffic sent by the PC with the new MAC address. HAven’t tested it, though.

      2) I’d say no to that one. First, the attacker is unlikely to know your port security config. But if they did, the sequence would be to get access to a port in an office or cubicle. Then somehow discern which switch port it’s attached to. Only then could it take advantage of knowing the port security config (which is again unlikely). But yes, knowing the switch config, and connecting to a wall plate, knowing the switch port, you could connect with port security allowing the connection.

      Then… not discussed in CCNA are other security measures. I’d suggest checking out 802.1X/EAP, which would then require authentication before the user could send any traffic past the switch. Or Software Defined Access (SDA), with the DNA Center Controller and ISE, which also requires authentication before the user can use the LAN and also dynamically assigns the user to a VLAN based on their login credentials.

      Good questions, made me think!

      Reply to this comment
      • Edmond H. January 16, 18:41

        By re-reading my questions, I noticed I did not explain very well the scenario, sorry…

        Here is a more consistent scenario :

        (legit user) Allowed PC1 with mac address AAAA:BBBB:0001 connected to a switch (F0/1) with
        port-security activated for only this mac: AAAA:BBBB:0001

        (hacker) Not allowed LAPTOP with mac address CAFE:CCCC:9999

        If the hacker know the PC1’s mac address, he could :

        1)Replace his own mac address (LAPTOP) with PC1’s mac address
        In example with the following command in linux : “ifconfig ethX hw ether AAAA:BBBB:0001”

        Now the hacker’s laptop has the mac address AAAA:BBBB:0001 and the switch cannot make the difference between PC1 and the LAPTOP because the only way to do that is by looking at the mac address.

        2)The hacker sitting at the desk with the PC1 on it, UNPLUG the PC1’s RJ-45 connector and PUT it directly in his laptop.
        It does not matter if the maximum allowed port is 1, because the allowed pc has been unplugged
        and there is still only one device connected on the port (The LAPTOP with the allowed m/c).

        The hacker don’t need to know the switch’s port-security configuration, because he is already
        allowed to connect using the PC1’s mac address.

        I have an option on my modem-router that allows to restrict the Internet access by filtering mac addresses. So I tested the scenario;

        I change my PC’s mac address, ping my router and finally analyzed what’s happen with wireshark:
        The src mac address has been change in the frame sent (ethernet II layer 2) and (ARP layer 3) , I was able to bypass my router’s security.

        To come to the conclusion,I just wanted to know if a cisco switch port-security option is able to detect this trivial attack because maybe it looks directly at the real hardware mac address and if it’s not the case, can ARP Inspection tools or something else help to avoid this problem?

        I know the question is out the scope of CCNA, but if we are sure that port-security could be easily bypassed, we have to be aware of that.

        P.S. Concerning SDA – DNA, I just finished the book and I never listen about that so far, I think it’s a very interesting concept that make a lot of what we learn old-fashioned.

        Thank you for your availability.

        Reply to this comment
        • Wendell Odom Author January 17, 12:56

          Hi Edmund,
          Thanks, much clearer now.
          On your #1, the attacker learns the MAC of the legitimate PC via some other means than knowing the switch config. Got it. So the short answer is yes, port security cannot help in that case. If the attacker uses that same MAC address and that same Ethernet port it appears to be the same device to port security. port security checks only the source MAC address of incoming frames.
          To me, that means the attacker has access to the PC. There’s a whole other world of tools to protect access to the OS, to prevent someone with access to the OS from connecting to the network to use it, and so on. But Port Security isn’t the solution here.
          I don’t think DHCP Snooping or DAI help in this case, either. Your starting point is an attacker on the same port as a legit PC using the same MAC as the legit PC. So they have physical access to the space and keyboard access to the OS so they can look around and learn things. So I still think your approach to the problem (ignoring CCNA scope) is about protecting access to the legit PC.

          Hope this helps,
          Wendell
          PS SDA is cool. So is SD-WAN, ACI, all the software-defined options from Cisco. But you have to know the CCNA stuff to understand the more advanced things. EG, with SDA, there’s a underlay campus that, when installed by DNA-C, functions as a routed access layer. That alone requires half of what you learn in CCNA! Kudos to you for digging in and learning well.

          Reply to this comment
          • Edmond H. January 20, 17:27

            Thanks for the answer, now it’s clear for me, port-security is a useful functionality but we have to pay attention for the case we mention earlier.

            I used the word “hacker” for a general purpose, but sometime users can create security holes unintentionally, for example, a young employee that want to play games on Internet or something else using his own laptop because usually companies don’t allow users to install programs on the company’s pc or the pc is not enough powerful to make the job, etc …

            Most of cases analyzed in the book are scenarios around a switch, meaning that the hacker is located inside the company.So we can’t exclude the fact, with a very low probability, that the hacker could be a big rat working for the company knowing his allowed mac address, but as you say : “There’s a whole other world of tools”.

            I think we talk about security enough and I better focus on the CCNA exam, thanks for the blog, I really appreciate it and the books too.

            Thank you Wendell, you are our superstar!

    • Wendell Odom Author January 21, 08:06

      You’re quite welcome, Edmond!

      Reply to this comment
  3. Azza January 29, 21:44

    Hi Mr. Odom,
    Referencing OCG Vol 2, page 161, Example 8-5.

    On DAI, you wrote, “If you were to configure a switch only with commands shown in Example 8-5, the switch would filter all ARPs entering all untrusted ports in VLAN 11.”

    The commands in Example 8-5 are as follows:
    #ip arp inspection vlan 11
    #interface GigabitEthernet1/0/2
    #ip arp inspection trust

    So, my question (my thought) is that without DHCP snooping and ARP ACLs, and when only the commands (stated above) are used, what would the switch compare the filtered ARPs to?

    Azza

    Reply to this comment
    • Wendell Odom Author February 3, 16:20

      Hi Azza,
      Thanks for the note.
      I had to go back and read to get the context. And I see what’s probably confusing there.
      So, what I mean is this:
      Configure like Example 8-5 only, with no ARP ACL and no DHCP Snooping, and DAI filters all incoming ARPs on untrusted ports. The reason: There’s no table with which to find permissible entries, as you suggest in your question. So, DAI alone creates deny-all-ARP logic for untrusted ports.
      Then, that sentence you quoted was meant to be a lead-in to suggest that you must also configure ARP ACLs or DHCP snooping, and here’s how to also config DHCP snooping in the scenario in the book, as per Example 8-6.

      Hope this helps! Feel free to follow up.
      Wendell

      Reply to this comment
  4. Azza February 4, 19:11

    Hi Mr. Odom,
    Referencing OCG Vol 1, page 566, Line 15.

    You write, “The show ipv6 route command lists the link-local address of the neighboring router, rather than the global unicast or unique local unicast address.”

    I tested the ‘show ipv6 route’ command in all it variations and it does not list the link-local address of the neighboring router.
    However, my lab is in packet tracer and that might have something to do about it.
    I have checked the errata file on the OCG Vol 1 “CCNA-200-301-Vol1-Errata-2023-02-01” and I could not find anything about this.

    So, is the statement still correct that the ‘show ipv6 route’ command lists the link-local address of the neighboring router?

    The following are the examples from my lab:
    Router(config)#int g0/0/0
    Router(config-if)#ipv6 add 2001:db8:1111:2::1/64

    Router(config-if)#do sho ipv6 int bri
    GigabitEthernet0/0/0 [up/up]
    FE80::260:5CFF:FEB6:501
    2001:DB8:1111:2::1
    GigabitEthernet0/0/1 [administratively down/down]
    unassigned

    Router(config-if)#do sho ipv6 route
    IPv6 Routing Table – 3 entries
    ! Legend omitted for brevity
    C 2001:DB8:1111:2::/64 [0/0]
    via GigabitEthernet0/0/0, directly connected
    L 2001:DB8:1111:2::1/128 [0/0]
    via GigabitEthernet0/0/0, receive
    L FF00::/8 [0/0]
    via Null0, receive

    Router(config-if)#do sho ipv6 nei
    IPv6 Address Age Link-layer Addr State Interface
    2001:DB8:1111:2::2 7 00D0.BCA4.5A01 REACH Gig0/0/0

    Router#sho ipv6 rou summar
    IPv6 routing table name is default(0) global scope – 3 entries
    IPv6 routing table default maximum-paths is 16
    Route Source Networks Overhead Memory (bytes)
    connected 1 88 124
    local 2 176 248
    Total 3 264 372

    Number of prefixes:
    /8: 1, /64: 1, /128: 1

    Reply to this comment
    • Wendell Odom Author February 7, 14:04

      Hi Azza,
      Welcome to the site. I appreciate the Mr. Odom, but feel free to call me by my first name.
      I think you’re missing some context, but FYI, the book is correct as is, and I think Packet Tracer works correctly as well on this point.
      As for your question, I refer you back to the page, to the entire paragraph just above Figure 24-8 from which the sentence you quoted comes from. Couple of key facts from that:
      – It mentions the next-hop address will be a link-local address (LLA).
      – It mentions the show ipv6 route command.
      – The one show ipv6 route command you listed in your post does not list a route that has a next-hop address field in it.

      What routes have a next-hop address? Those that require the local router to forward packets to the neighboring router. For example, if your Packet Tracer topology had two routers in it (like the topology in Figure 24-8), and you enabled OSPFv3, R1 would learn a route for “Subnet 2” per the figure. that route would list R2’s LLA as the next hop address.

      EG, add this to the routers:
      ipv6 router ospf 1
      router-id 1.1.1.1 (or 2.2.2.2, or 3.3.3.3, make them unique)

      on each interface, add:
      ipv6 ospf 1 area 0

      Assuming you had already enabled IPv6 unicast routing, and had already configured correct global unicast addresses on the interfaces, then that additional configuration should make OSPF work. Then the routes learned by OSPF (which have a next-hop address value) will list the LLA of the neighboring router.

      Hope this helps,
      Wendell

      Reply to this comment
  5. John rambo February 27, 17:24

    Hello Wendell,

    Thank you so much for your efforts in making this lab.

    I just wanted to point out that the lab and the picture for it is slightly off. The lab has additional devices.

    Thank you

    Reply to this comment
  6. Vicente Torres March 23, 15:13

    Hi Wendell,

    A quick doubt. If we use fixed IPs in our LAN devices instead of DHCP, we cannot use DAI feature, right? (Because DAI depends on DHCP snooping binding table).

    Reply to this comment
    • Wendell Odom Author March 31, 15:51

      Vicente,
      DAI can can also use something called an ARP ACL, which provides matching logic for ARP messages independent of the DHCP process.

      Reply to this comment
  7. Bill April 4, 09:07

    Hi Wendell – this is a general question. I’m getting stuck on the logic of DAI trust vs. not trusted settings on ports. Specifically, why do we want all non-DHCP clients to be trusted for DAI?

    Reply to this comment
    • Wendell Odom Author April 4, 17:31

      Hey Bill,
      DAI is tricky. And discussing DAI while keeping it basic is challenging, too. So, to do that, the chapter discusses DAI with the DHCP Snooping Binding Table, but with only a bare mention of ARP ACLs. In short – and this is the key – for an untrusted port, the only way DAI approves of an ARP is if that host successfully used DHCP. With no DHCP Snooping table entry, no passing the DAI check. So any port connected to devices with static IP addresses, or to anything not a DHCP client, you need to trust.
      In real life, this can be reasonably applied in most cases, particularly if the site follows a consistent plan for which ports connect to user devices and which don’t, rather than arbitrary choices for switch ports.

      Hope this helps.
      Wendell

      Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email

Search

Categories