ARP Inspection Question

[John Blakley]

All,

I don't have a way of labbing this up at the moment, so I have a question to see what everyone else has seen in the past. Consider the following topology (attached).

DHCP Snooping and DAI are enabled across all switches. The dhcp snooping binding table has host A listed on the switch that host A connects to, and there is a dhcp snooping database on the dhcp server. Host A is in an office, but this person needs to go to a conference room that connects to switch C. Switch C doesn't know anything about the dhcp snooping entry from switch B. Will host A be able to pass traffic, or will DAI stop the traffic from being passed until an arp acl is configured on switch c or the port is trusted that host A connects to? If it's able to pass traffic, how is switch C learning it? Does it request the mac address/ip pair from the dhcp server and then enter it into it's own binding table? This is what I'm thinking because otherwise dai is going to be hard for me to manage.

Also, I couldn't find a way of doing this, but is there a way of sharing a database across switches? It seemed like it was creating a new file even though the same name was given, so I ended up naming them by switch - switcha.dhcpBinding, etc.

Thanks!
John

[Rolf Fischer]

John,

now I understand why you needed an external binding file :-)

I guess your customer won't be happy to hear this, but I'm afraid that the additional security provided by DAI has its price: When a user changes the location, he'll have to release the binding at the old place and renew it at the new place (I believe most notebooks do that automatically when you switch them to standby mode). Without a dhcp snooping binding entry, DAI will block all ARP traffic so the client cannot be used properly.

During normal operation, the switch will update the external binding file on the server. The opposite direction (server to switch) is only used after a switch-reload to store the valid bindings locally on the switch.

You can add entries manually in exec-mode to solve such problems:

ip dhcp snooping binding vlan interface expiry <1-4294967295>

but I think this will be painful for both sides, so probably the better way would be to change the user behavior.

so I ended up naming them by switch

That's exactly how we handled the binding files too.

I'm curious if somebody can provide a better way (not only for the file-handling).

We no longer use DAI because of new policies and, quite frankly, I don't miss it. We had a lot of "false-positives" (rate-limiting) and other administrative overhead because of such problems as you have mentioned.

HTH

Rolf

[John Blakley]

Thanks again Rolf

We had a situation a couple of weeks ago where someone addressed a printer with the core switch's address and caused an outage at the branch. After finding the printer, we assumed that the person that set this up had thought they were putting the gateway address in, when in fact they were assigning the address of the printer with the core switch's address. So, I had explained to management that the best way to address something like this would be with dai and snooping, but now I'm thinking that this may be great for stationary workstations, but there are constant meetings, people roaming, etc.

I can't think of any other way to protect our core router/switches addressing. I had another situation about a month ago where someone had a phone on wireless that was addressed statically as the same address of one of their production servers...boy that took some time to find. Do you have any ideas? How have you protected your customers/company from people randomly assigning incorrect addresses?

Thanks!

John

[Rolf Fischer · Accepted solution]

John,

to avoid situations as you have described, I personally would prefer IP Source Guard rather than DAI.

Of course IPSG also depends on the dhcp snooping binding table but we never had problems like those caused by DAI rate-limiting (which you also could disable). We even used both.

Meanwhile we assign the data VLAN automatically after a successful 802.1x authentication, so for most devices we know that users don't have rights to change IP parameters. There a other VLANs as well for special equipment but, depending on the type, we're not responsible for the IP address management.

I think all this security features are available for good reason and, without doubt, using them provides a higher level of safety but it also may have some impact for the users. That's the price you have to pay, I guess

HTH

Rolf

[John Blakley]

Thanks Rolf

[Azeem Dawood]

Hi Rolf,

I have some concerns regarding DAI in our organization. i have applied DAI on all our access switches(Cisco), our DHCP server is Cisco 6509 core switch. All teh trunk ports connecting to core switch are "Trusted Interfaces with rate limit unlimited".

all the client systems are getting proper IPs from DHCP. But there is something missing behind the scene.

Please see the below DHCP DAI inspection logs taken from one of access switch.

PDOWN: Interface GigabitEthernet0/30, changed state to down
250566: Mar  9 11:30:56: %LINK-3-UPDOWN: Interface GigabitEthernet0/30, changed state to up
250567: Mar  9 11:30:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/30, changed state to up
250568: 2w2d: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/30 for pak.  Was not set
250569: 2w2d: DHCPSNOOP(hlfm_set_if_input): Clearing if_input for pak.  Was Gi0/30
250570: 2w2d: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/30 for pak.  Was not set
250571: 2w2d: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/30)

250572: 2w2d: DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST, input interface: Gi0/30, MAC da: ffff.ffff.ffff, MAC sa: 18a9.05ed.8b87, IP da: 255.255.255.255, IP sa: 0.0.0.0,

DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 18a9.05ed.8b87

250573: 2w2d: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (120)

250574: 2w2d: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/50 for pak.  Was not set
250575: 2w2d: DHCPSNOOP(hlfm_set_if_input): Clearing if_input for pak.  Was Gi0/50
250576: 2w2d: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/50 for pak.  Was not set
250577: 2w2d: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/50)
250578: 2w2d: DHCP_SNOOPING: process new DHCP packet, message type: DHCPACK, input interface: Gi0/50, MAC da: 18a9.05ed.8b87, MAC sa: 0015.2c31.4800, IP da: 192.168.120.104, IP sa: 192.168.120.1,

DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 192.168.120.104, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 18a9.05ed.8b87

250579: 2w2d: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 18a9.05ed.8b87
250580: 2w2d: DHCP_SNOOPING: can't find client's destination port, packet is assumed to be not from local switch, no binding update is needed.
250581: 2w2d: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 18a9.05ed.8b87
250582: 2w2d: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 18a9.05ed.8b87
250583: 2w2d: DHCP_SNOOPING: can't find output interface for dhcp reply. the message is dropped.

250584: Mar  9 11:31:05: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi0/30, vlan 120.([18a9.05ed.8b87/169.254.93.237/0000.0000.0000/169.254.93.237/14:31:04 Sun Mar 9 2014])
250585: 2w2d: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/30 for pak.  Was not set
250586: 2w2d: DHCPSNOOP(hlfm_set_if_input): Clearing if_input for pak.  Was Gi0/30
250587: 2w2d: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/30 for pak.  Was not set
250588: 2w2d: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/30)
250589: 2w2d: DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST, input interface: Gi0/30, MAC da: ffff.ffff.ffff, MAC sa: 18a9.05ed.8b87, IP da: 255.255.255.255, IP sa: 0.0.0.0,

DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 18a9.05ed.8b87

250590: 2w2d: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (120)
250591: 2w2d: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/50 for pak.  Was not set
250592: 2w2d: DHCPSNOOP(hlfm_set_if_input): Clearing if_input for pak.  Was Gi0/50
250593: 2w2d: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/50 for pak.  Was not set
250594: 2w2d: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/50)
250595: 2w2d: DHCP_SNOOPING: process new DHCP packet, message type: DHCPACK, input interface: Gi0/50, MAC da: 18a9.05ed.8b87, MAC sa: 0015.2c31.4800, IP da: 192.168.120.104, IP sa: 192.168.120.1,

DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 192.168.120.104, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 18a9.05ed.8b87
250596: 2w2d: DHCP_SNOOPING: direct forward dhcp replyto output port: GigabitEthernet0/30.

I have no idea what i am missing??

could you please help me out to fix this issue as soon as possible.

You can reach me at azeemb263@gmail.com

Regards,

Azeem