02-25-2012 05:00 PM - edited 03-07-2019 05:11 AM
All,
What is the best way to debug/troubleshoot VACL's ?
This question is posed simply but the background is as follows:
SW1---SW2---SW3---R4
VLAN 46 Trunked between SW1--SW2--SW3, and Layer3 interface between SW3 and R4 (10.10.46.4)
VACL applied to SW1 SVI as per below:
vlan access-map DROP 30
action drop
match ip address R4
vlan access-map DROP 40
action forward
ip access-list standard R4
permit 10.10.46.4
Now the question here is not that the VACL is disfunctioning but if I am to "debug ip icmp" or "debug ip packet" I do not see any output, is this because of the hardware based processing of the switches (3560's) ? Moreover if the VACL is disabled I do see output ie: ICMP Type 0 reply messages being generated.
Debugging platform acl vacl, shows some output but it seems to relate to every other configured VLAN not related to the one in question ie: VLAN46
hacl_input_access_check: 761: for vlanid 107 label_info->invlm.vlmap is NULL
hacl_input_access_check: 761: for vlanid 28 label_info->invlm.vlmap is NULL
hacl_input_access_check: 761: for vlanid 28 label_info->invlm.vlmap is NULL
hacl_input_access_check: 761: for vlanid 107 label_info->invlm.vlmap is NULL
hacl_input_access_check: 761: for vlanid 105 label_info->invlm.vlmap is NULL
hacl_input_access_check: 761: for vlanid 28 label_info->invlm.vlmap is NULL
hacl_input_access_check: 761: for vlanid 102 label_info->invlm.vlmap is NULL
hacl_input_access_check: 761: for vlanid 107 label_info->invlm.vlmap is NULL
Look forward to your feedback.
02-25-2012 05:18 PM
Well, your VACL is created but not applied is on any vlan at layer2 level.
Secondly to see the debug output, please enable terminal monitor on your console.
Hope that helps.
Thanks
Rizwan Rafeek
02-25-2012 05:19 PM
Hi All, forgot to mention
vlan filter DROP vlan-list 46
Is configured, as I say it works but what is the best debug ?
term mon, logging console is enabled.
02-25-2012 05:31 PM
You could create ACL and associate the source and destination in the ACL and map the ACL to debug.
02-25-2012 05:51 PM
Hi Rizwan,
Thanks for your reply.
Tried that also ie: applied a Src Dest Extended ACL, applied to a debug ip packet and nothing.
Again when VACL is disabled it happily debugs and I see plenty of output below is an excerpt:
SW1
Debug ip packet 101 detail (where 101 is simply matching on any ICMP from Src 10.10.46.4 [R4] Dst 10.10.46.7 [SW1])
IP: s=10.10.46.4 (Vlan46), d=10.10.46.7, len 100, input feature
ICMP type=8, code=0, MCI Check(63), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
This may be normal behaviour, just wondered what exactly is going on, is TCAM stopping the ICMP in its tracks before CPU gets a hold of it ? And if so, what debugs would apply ?
VH
02-25-2012 07:42 PM
Yes, "VACLS are processed in hardware." layer, therefor you will not see output related to layer3 application.
Here is a reference below, you might want to read further.
Thanks
02-25-2012 08:16 PM
Ok, so the only way I can see to verify is by way of the following output:
SW1#show access-lists hardware counters
L3 ACL INPUT Statistics
Drop: All frame count: 4973
Drop: All bytes count: 367232
Whereby there is an indicative increase in drops when vlan filter is applied.
Seems as though the platform (3560) I am running on does not include a Log option with the VLMAP drop action , but the 6500 platform does. The reason that I wanted to discuss this topic was for remote assistance purposes, ie: I don't even receive an administrative prohibited message back from SW1 on R4 when the VACL is applied, which makes sense if the CPU is not touching the ICMP packet.
VH
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide