Hi Peter Solution 2 is fine but we need to add the mac-addresses.
If we need a solution that is very scalable that doesn't need to us to add the mac-addresses, then I think using ip source guard is the best solution. But still, in non-DHCP environments, we need to add static bindinds :-( With regards Kings On Thu, Apr 15, 2010 at 11:17 PM, Peter Debye <[email protected]> wrote: > Hello, > > In the context of VLAN filtering (VACL) the mac access-list matches on > non-IP traffic only. > (IP ARP is considered as such, btw). Hence, imho, it is senseless to > put both mac and ip > address matches within the same vlan access-map entry: the AND (and it > is AND, Brandon > is right) between non-IP and IP will never get true. > > The drops which Kingsley is seeing in his example are not due to 10 > entry but are owing > to the default no-match behaviour of vlan access-maps. > > Now, to address the task of blocking ARP spoofing using VACL I can suggest > two strategies: > 1) block _all_ IP ARP traffic in the vlan with: > mac access-list extended ARP > permit any any 0x806 0x0 > vlan access-map BLOCK_ARP > action drop > match mac address ARP > (This VACL doesn't affect IP traffic.) > All hosts on the vlan must have ARP mapping configured > statically, like > arp -s A.B.C.D xx--xx-xx-xx-xx-xx > Not a very scalable solution but it may fit well the situation when > all traffic from hosts > must traverse a router. > > 2) permit ARP packets from a locally defined list of hosts only: > mac access-list ext ARP_MAC > permit host <mac1> any 0x806 0x0 > permit host <mac2> any 0x806 0x0 > ... > vlan access-map NO_SPOOF > action forward > match mac address ARP_MAC > > With that a rogue host will not be able to spoof the ARP mappings as its > ARP packets will be blocked on the vlan by the default rule. > Again, not a very scalable solution as you need to maintain a list of > mac's, > but for smaller lans it's okay. > > ============================================== > > > Date: Thu, 15 Apr 2010 10:22:37 -0500 > From: bwalla <[email protected]> > Subject: Re: [OSL | CCIE_Security] Solutiion for ARP spoofing > To: Kingsley Charles <[email protected]> > Cc: "[email protected]" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Interesting. In the case that it's an OR match only, this solution > wouldn't actually work. The reason that I grouped the mac and IP match > statments in the same access-map sequence is because I assumed that it > would default to 'AND', OR being if you dropped them in different > sequences. > > Bummer. > > -Buck > > On Thu, Apr 15, 2010 at 2:30 AM, Kingsley Charles < > [email protected]> wrote: > > > Hi Brandon > > > > I just checked and it seems the vlan access-map is making "OR" logic > > between the matching criterias. With following config, either it > > matches mac acl "king" or IP acl "123". > > > > vlan access-map king 10 > > action drop > > match mac address king > > match ip address 123 > > > > While the route-maps uses "AND" logic between the criteria. > > > > > > With regards > > Kings > > > > On Thu, Apr 15, 2010 at 12:27 PM, Brandon Carroll <[email protected] > >wrote: > > > >> Kings, > >> > >> It's a logical and like a route-map. > >> > >> Regards, > >> > >> Brandon Carroll - CCIE #23837 > >> Senior Technical Instructor - IPexpert > >> Mailto: <[email protected]>[email protected] > >> Telephone: +1.810.326.1444 > >> Live Assistance, Please visit: <http://www.ipexpert.com/chat> > >> www.ipexpert.com/chat > >> eFax: +1.810.454.0130 > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
