Ohh no, my sincere apologies if I appeared pissed off - least of my
intentions. Surely, discussion is why we are on here, the first instance.
Sadiq
On Thu, Jun 16, 2011 at 5:25 PM, Narbik Kocharians <narbikk_at_gmail.com>wrote:
> WOW.
>
>
>
> I dont know what pissed you off, but if you dont have the capacity to
> discuss and simply discuss, you should not participate.
>
>
> The reason *I did not think* of that command is because you are receiving
> errors that is generated by DAI, to be more specific an ARP reply,* if
> this port was trusted*, you will NOT receive any errors, so what you
> stated does not apply here. Read what you pasted.
>
>
> We all know how DAI relies on DHCP snooping, there is no argument about
> that, I guess we are looking at this from two angles. My statement below is
> what you are saying, i am interpreting the error, you are guessing the
> cause.
>
> *DAI is telling you that the host that sent an APR request on G2/18 which
> happens to be in VLAN 20, with an IP address of 10.1.1.1 and a MAC address
> of "0022.5ac1.202a" was NOT in the DHCP snooping DB, but the actual message
> came from DAI. *
>
> Relax.
>
>
> On Thu, Jun 16, 2011 at 8:57 AM, Sadiq Yakasai <sadiqtanko_at_gmail.com>wrote:
>
>> Narbik,
>>
>> I will not degenerate into a baseless argument here. I am just shocked at
>> why you argue when you should know better.
>>
>> And whats below? This is not a DHCP Snooping Trust but a DAI Trust port:
>>
>>
>>
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12
.2_52_se/configuration/guide/swdynarp.html#wp1039756
>>
>> Step 5
>>
>> *ip arp inspection trust*
>>
>> Configure the connection between the switches as trusted.
>>
>> By default, all interfaces are untrusted.
>>
>> The switch does not check ARP packets that it receives from the other
>> switch on the trusted interface. It simply forwards the packets.
>>
>> For untrusted interfaces, the switch intercepts all ARP requests and
>> responses. It verifies that the intercepted packets have valid IP-to-MAC
>> address bindings before updating the local cache and before forwarding the
>> packet to the appropriate destination. The switch drops invalid packets
and
>> logs them in the log buffer according to the logging configuration
specified
>> with the *ip arp inspection vlan logging* global configuration command.
>> For more information, see the "Configuring the Log Buffer"
section<http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/re
lease/12.2_52_se/configuration/guide/swdynarp.html#wp1047405>
>> .
>>
>> Secondly, the log message below says something: this DAI works in
>> combination with DHCP Snooping. If you have a host that has DHCP'd and is
>> working just fine and that host's entry if somehow cleared out of the DHCP
>> Snooping Binding Table, thats a scenario that would end up with the log
>> message below. As we all know, there are quite a number of reasons the
>> problem could be created from. With the limited information and lack of
>> configuration from the initial poster of this query, one can only
speculate
>> what the cause is and hence a solution.
>>
>> Below is another excerpt from the Cisco feature documentation:
>>
>> "Dynamic ARP inspection determines the validity of an ARP packet based on
>> valid IP-to-MAC address bindings stored in a trusted database, the DHCP
>> snooping binding database." More here:
>>
>>
>>
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12
.2_52_se/configuration/guide/swdynarp.html#wp1041210
>>
>> I will not continue participating in this discussion now since we are all
>> entitled to our opinions, end of the day.
>>
>> Sadiq
>>
>>
>>
>> On Thu, Jun 16, 2011 at 4:26 PM, Narbik Kocharians
<narbikk_at_gmail.com>wrote:
>>
>>> Sadiq,
>>>
>>> It is NOT, i totally disagree with that. First of all there is no such
>>> thing as "DAI trusted port", you can have a snooping trusted port BUT not
>>> DAI trusted port. The first thing you want to do when troubleshooting is
to
>>> see where the message came from which feature generated the message so
you
>>> can understand the problem.
>>>
>>> secondly if you see the message he posted you will see that the error is
>>> coming from DAI:
>>>
>>> *%SW_DAI-4-DHCP_SNOOPING*_DENY: 1 Invalid ARPs (Req) on Gi2/18, vlan
>>> 20.([0022.5ac1.202a/10.1.1.1/0000.0000.0000/10.0.176.16/17:38:05 AST Sun
>>> Jun 12
>>> 2011])
>>> Which tells me that the message is generated by DAI. NOW......DAI is
>>> telling you that the host that sent an APR request on G2/18 which happens
to
>>> be in VLAN 20, with an IP address of 10.1.1.1 and a MAC address of
>>> "0022.5ac1.202a" was NOT in the DHCP snooping DB, but the actual message
>>> came from DAI.
>>> If you think the problem is DHCP snooping, just disable DAI and the
>>> problem will go away. So it's DAI and not snooping.
>>>
>>> Maybe a static entry in the snooping DB for this host will fix the
>>> problem for you.
>>>
>>>
>>>
>>> On Thu, Jun 16, 2011 at 2:31 AM, Sadiq Yakasai
<sadiqtanko_at_gmail.com>wrote:
>>>
>>>> By default, DAI relies on DHCP Snooping DB for operation. The exception
>>>> is when things are statically defined.
>>>>
>>>> It is therefore errorneous to make statements like "the message has
>>>> nothing to do with DHCP Snopping"!
>>>>
>>>> When DHCP Snooping and DAI are configured on a switch and all operations
>>>> occur dynamically, then a host with static IP address connecting to a
port
>>>> that is not a DAI trusted port will spew out that message. And this is
>>>> because the host's information is not present in the DHCP snooping
binding
>>>> table.
>>>>
>>>> Sadiq
>>>>
>>>> On Thu, Jun 16, 2011 at 6:36 AM, Narbik Kocharians <narbikk_at_gmail.com
>>>> > wrote:
>>>>
>>>>> I agree with Piotr, the message has nothing to do with DHCP Snopping,
>>>>> they
>>>>> are generated by "DAI" Dynamic Arp inspection. Do you have DAI
>>>>> configured on
>>>>> your switches?
>>>>> On Wed, Jun 15, 2011 at 7:54 PM, Alexei Monastyrnyi <
>>>>> alexeim73_at_gmail.com>wrote:
>>>>>
>>>>> > You can also try using arp inspection trust on that switch-port with
>>>>> static
>>>>> > IP.
>>>>> >
>>>>> > HTH
>>>>> > A.
>>>>> >
>>>>> > On 13 June 2011 01:48, Piotr Matusiak <pitt2k_at_gmail.com> wrote:
>>>>> >
>>>>> > > Hi,
>>>>> > >
>>>>> > > This message is generated by DAI feature not DHCP Snooping. It is
>>>>> caused
>>>>> > by
>>>>> > > device connected to port g2/18. Check this out. It seems there is
>>>>> someone
>>>>> > > connected to that port with static IP address of 10.1.1.1 with MAC
>>>>> of
>>>>> > > 0022.5ac1.202a so that DHCP Snooping has note registerd it in its
>>>>> > database.
>>>>> > > If this host is valid in your network and must have static IP
>>>>> configured,
>>>>> > > then add static binding to the DHCP Snooping database (ip dhcp
>>>>> snooping
>>>>> > > binding...)
>>>>> > >
>>>>> > > Regards,
>>>>> > > --
>>>>> > > Piotr Matusiak
>>>>> > > CCIE #19860 (R&S, Security), CCSI #33705
>>>>> > > Technical Instructor
>>>>> > > website:
www.MicronicsTraining.com<http://www.micronicstraining.com/><
>>>>> http://www.micronicstraining.com/> <
>>>>> > http://www.micronicstraining.com/> <
>>>>> > > http://www.micronicstraining.com/>
>>>>> > > blog: www.ccie1.com
>>>>> > >
>>>>> > > If you can't explain it simply, you don't understand it well
>>>>> enough -
>>>>> > > Albert Einstein
>>>>> > >
>>>>> > >
>>>>> > > 2011/6/12 <roykhan123_at_hotmail.com>
>>>>> > >
>>>>> > > > Dear All,
>>>>> > > >
>>>>> > > > I am facing problem in my network is that i am getting DHCP
>>>>> snooping
>>>>> > Deny
>>>>> > > > log
>>>>> > > > messages continue in my switches. I knows that how dhcp snooping
>>>>> is
>>>>> > > working
>>>>> > > > but
>>>>> > > > i do not knows why this is appearing in the switch, when there is
>>>>> no
>>>>> > dhcp
>>>>> > > > server connected that ports and every thing is working fine.
>>>>> > > >
>>>>> > > > %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi2/18,
>>>>> vlan
>>>>> > > >
20.([0022.5ac1.202a/10.1.1.1/0000.0000.0000/10.0.176.16/17:38:05AST
>>>>> > Sun
>>>>> > > > Jun 12
>>>>> > > > 2011])
>>>>> > > >
>>>>> > > > 1. Is this because of Virus. that cause the machine to generate
>>>>> this
>>>>> > > error.
>>>>> > > > I
>>>>> > > > saw this problem before there was a virus.
>>>>> > > > 2. I dont knows about the servers may be some services is
>>>>> running
>>>>> > inside
>>>>> > > > the
>>>>> > > > server that cause the server to generate this request Or some
>>>>> thing
>>>>> > else
>>>>> > > >
>>>>> > > > Note some there is no virus on the machine and still this error
>>>>> is
>>>>> > occur
>>>>> > > on
>>>>> > > > the
>>>>> > > > machine... I really do not Why this happening and how i fix this
>>>>> issue.
>>>>> > > >
>>>>> > > > Currently I am getting this message and there is no issue with
>>>>> the
>>>>> > > Machine
>>>>> > > > it
>>>>> > > > self
>>>>> > > >
>>>>> > > > Port configuration
>>>>> > > >
>>>>> > > > interface GigabitEthernet2/9
>>>>> > > >
>>>>> > > > switchport
>>>>> > > > switchport access vlan 19
>>>>> > > > switchport mode access
>>>>> > > > switchport voice vlan 16
>>>>> > > > ip arp inspection limit rate 128
>>>>> > > > no ip address
>>>>> > > > spanning-tree portfast
>>>>> > > > spanning-tree bpduguard enable
>>>>> > > > end
>>>>> > > > !
>>>>> > > > ip dhcp snooping
>>>>> > > > ip dhcp snooping vlan 19,16
>>>>> > > > !
>>>>> > > >
>>>>> > > > kindly advise
>>>>> > > >
>>>>> > > > Take care
>>>>> > > >
>>>>> > > >
>>>>> > > > Blogs and organic groups at http://www.ccie.net
>>>>> > > >
>>>>> > > >
>>>>> _______________________________________________________________________
>>>>> > > > Subscription information may be found at:
>>>>> > > > http://www.groupstudy.com/list/CCIELab.html
>>>>> > >
>>>>> > >
>>>>> > > Blogs and organic groups at http://www.ccie.net
>>>>> > >
>>>>> > >
>>>>> _______________________________________________________________________
>>>>> > > Subscription information may be found at:
>>>>> > > http://www.groupstudy.com/list/CCIELab.html
>>>>> >
>>>>> >
>>>>> > Blogs and organic groups at http://www.ccie.net
>>>>> >
>>>>> >
>>>>> _______________________________________________________________________
>>>>> > Subscription information may be found at:
>>>>> > http://www.groupstudy.com/list/CCIELab.html
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> *Narbik Kocharians
>>>>> *CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>>>>> www.MicronicsTraining.com <http://www.micronicstraining.com/> <
>>>>> http://www.micronicstraining.com/>
>>>>> Sr. Technical Instructor
>>>>> *Ask about our FREE Lab Voucher with our Boot Camps*
>>>>> YES! We take Cisco Learning Credits!
>>>>> Training & Remote Racks available
>>>>>
>>>>>
>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>
>>>>> _______________________________________________________________________
>>>>> Subscription information may be found at:
>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> CCIEx2 (R&S|Sec) #19963
>>>>
>>>
>>>
>>>
>>> --
>>> *Narbik Kocharians
>>> *CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>>> www.MicronicsTraining.com <http://www.micronicstraining.com/>
>>> Sr. Technical Instructor
>>> *Ask about our FREE Lab Voucher with our Boot Camps*
>>> YES! We take Cisco Learning Credits!
>>> Training & Remote Racks available
>>>
>>>
>>
>>
>> --
>> CCIEx2 (R&S|Sec) #19963
>>
>
>
>
> --
> *Narbik Kocharians
> *CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> www.MicronicsTraining.com <http://www.micronicstraining.com/>
> Sr. Technical Instructor
> *Ask about our FREE Lab Voucher with our Boot Camps*
> YES! We take Cisco Learning Credits!
> Training & Remote Racks available
>
>
-- CCIEx2 (R&S|Sec) #19963 Blogs and organic groups at http://www.ccie.netReceived on Thu Jun 16 2011 - 18:01:18 ART
This archive was generated by hypermail 2.2.0 : Fri Jul 01 2011 - 06:24:28 ART