CCNP Switch Workbook 7.4 Dynamic ARP Inspection

Hi Guys,

Im following along with the Switch Workbook 7.4, in my home lab, which is "very close to" but not exactly the same as using an INE lab.

 

I was following along with exercise 7.4 fine.  The Malicious user was initiating the gratuitous arps etc, and I was getting traffic flipping between the legitimate owner of 24.24.24.22 and the malicious user.

Then as per the instructions I configured dynamic arp inspection.  I then had some strange behaviour.  I could no longer ping 1.1.2.1 (my address is slightly different to the INE one).  However I had trusted Gi0/10 from switch 2.

The strange part was, I could actually ping 24.24.24.22 which was the default gateway.

I noticed that my ARP table was still pointing to the malicious user:

R2#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  24.24.24.1              -   001b.d5be.6b8b  ARPA   FastEthernet0/1
Internet  24.24.24.22            28   001d.a29b.30d0  ARPA   FastEthernet0/1

I then removed dynamic arp inspection, and then added it back in again:

SW2(config)#no ip arp inspection vlan 24
SW2(config)#do sh ip arp inspection

Source Mac Validation      : Disabled
Destination Mac Validation : Disabled
IP Address Validation      : Disabled
No active or enabled vlans on switch.
SW2(config)#
Mar 30 02:11:36.913: %PLATFORM_ENV-1-FRU_PS_ACCESS: FRU Power Supply is not responding
SW2(config)#
Mar 30 02:13:39.076: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
SW2(config)#
Mar 30 02:13:40.074: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down
SW2(config)#
Mar 30 02:13:47.826: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
Mar 30 02:13:48.832: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
SW2(config)#ip arp inspection vlan 24

I then noticed that my arp table was correct:

R2#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  24.24.24.1              -   001b.d5be.6b8b  ARPA   FastEthernet0/1
Internet  24.24.24.22             0   442b.03bc.4ac5  ARPA   FastEthernet0/1

And I could ping with 100% accuracy:

R2#ping 1.1.2.1 repeat 2000

Type escape sequence to abort.
Sending 2000, 100-byte ICMP Echos to 1.1.2.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (2000/2000), round-trip min/avg/max = 1/1/28 ms

 

So my question is - Is there a small window when you configure dynamic arp inspection, where your arp table is still pointing to the malicious user, and when you configure DAI, your arp table could be pointing at the malicious user still?

 

 

Comments

  • Hello Ross(?)

     

    Let me summarize what you wrote so I'm clear on the problem:

    1. Without DAI enabled you saw, "traffic flipping between the legitimate owner of 24.24.24.22 and the malicious user."

    ----The "malicious user" in your lab has the MAC/IP address of 001d.a29b.30d0/24.24.24.22

     

    2. When you enabled DAI, you could no longer ping a remote IP address (1.1.2.1) even though you had trusted the uplink interface on your Access Switch (Switch-2)

    ----At the same time you mentioned that with DAI enabled, you WERE able to ping 24.24.24.22 (default-gateway)

    ----ARP table on your client (R2) still had MAC of Malicious User (001d.a29b.30d0) instead of legitimate default-gateway.

     

    3. You disabled DAI on the switch, re-enabled it, and this somehow influenced the ARP table of your Client (R2) to now reflect the correct MAC entry of the legitimate default-gateway.

     

    If everything I've summarized above is correct, here are my thoughts:

    Item# 1 above: To be expected since DAI was not enabled.

    Item# 2 above: Keep in mind that your Client (R2) has no visibility into whether-or-not his connected switch is running DAI.  Also, routers will keep their ARP entries for 4-hours (by default).  So if R2 had previously learned of 24.24.24.22 from the Malicious User and placed that (incorrect) MAC into its ARP table, that MAC would remain there even after you enabled DAI on the switch. R2 would have no reason to remove it.

    Considering that the Malicious User WAS responsive to that IP address (24.24.24.22) it does not surprise me that R2 was able to ping it. So when you say in this step, that R2 was able to ping the address of 24.24.24.22 I suspect that ping was actually going to the Malicious User and not the legitimate default-gateway. This is not the fault of DAI...but the fault lays with R2 retaining an (incorrect) ARP entry from before DAI was enabled on the switch.

    Item# 3 above: I noticed that between the time you disabled DAI and then re-enabled it, Gig0/1 on your switch bounced.  I'm not sure where this interface leads to, but it's possible that this interface flap somehow caused the Default-Gateway (Switch-1) to re-send a Gratuitous ARP which would then update R2's ARP table with the correct ARP entry. If this was not the cause (the Gig0/1 interface flap) then SOMETHING must have happened to cause R2 to either:

    ----Re-ARP for 24.24.24.22 (normally that would only happen if Fast0/1 on R2 bounced)

    ----Receive an ARP Response from Switch-2, which would be considered the most recent info, and would overwrite the existing ARP entry in R2's ARP table.

Sign In or Register to comment.