06-03-2012 10:32 AM - edited 03-04-2019 04:33 PM
I apply extended ACL on my router cisco 1941, but it didn't work. So I tried to apply standard ACL, it's work. I'm not sure about my cisco 1941 IOS is support extended ACL. My cisco IOS is
Cisco CISCO1941/K9
c1900-universalk9-mz.SPA.151-4.M1.bin
-----------------------------------------------------------------
Technology Technology-package Technology-package
Current Type Next reboot
------------------------------------------------------------------
ipbase ipbasek9 Permanent ipbasek9
security None None None
data None None None
Below is extended and standard ACL that I use to test apply on cisco 1941 gigabit ethernet interface
interface GigabitEthernet0/0
ip address 172.29.1.2 255.255.255.0
ip access-group 7 in
ip flow ingress
duplex auto
speed auto
access-list 7 permit any
Result: All traffic can pass this interface
Standard IP access list 7
10 permit any (688 matches)
----------------------------
interface GigabitEthernet0/0
ip address 172.29.1.2 255.255.255.0
ip access-group 100 in
ip flow ingress
duplex auto
speed auto
access-list 100 permit ip any any
Result: All traffic never pass this interface
Extended IP access list 100
10 permit ip any any
--------------------------
How can I solve this problem ?? Is it IOS bug or limit feature on hardware.
Solved! Go to Solution.
06-04-2012 04:08 AM
for some reason it can not ping itself. try reload router. if it not helps try another image.
06-04-2012 04:37 AM
This certainly seems to be buggy behavior. Access list 100 applied on the interface with ip access-group 100 in should work and the ping should be successful. I am surprised that it is not working. I do have a few suggestions:
- if this router is covered by a maintenance agreement then opening a case with Cisco TAC would be a good thing to do.
- I wonder if some other access list number might work. If you tried, for example access-list 150 permit ip any any and apply it to the interface does it make any difference.
- c1900-universalk9-mz.SPA.151-4.M1.bin has been improved and updated. Can you try c1900-universalk9-mz.SPA.151-4.M4.bin and see if it works better?
HTH
Rick
06-04-2012 08:10 AM
Hi Rick,
I tried to change number of extended access-list, but the result still the same. So I'll chenge ios to c1900-universalk9-mz.SPA.151-4.M1.bin or c1900-universalk9-mz.SPA.151-4.M3.bin (There are only two version of 1941ios in my server.) and I'll update result again.
Thanks
WIT
06-05-2012 06:13 PM
Dear Rick,
I upgrade ios to c1900-universalk9-mz.SPA.151-4.M3.bin, so it already worked
Thanks
WIT
06-06-2012 05:06 AM
WIT
I am glad that you have resolved the problem. Thank you for posting back to this discussion and telling us that it is fixed and how you fixed it. That is certainly a buggy behavior and a pretty basic behavior that was broken. This will serve as a reminder that sometimes when we have a problem that it may not be our config at fault but a problem in the behavior of the router.
And thank you for using the rating system to indicate that the problem is resolved. It makes the forum more useful when people can read a question and can know that the problem was resolved. Your marking has contributed to this process.
HTH
Rick
06-26-2012 02:04 PM
I found the same problem , the problem is relate to the bug ID CSCtt19027.
Refer as,
CSCtt19027 from bug tool kit
1st Found-In
15.2T
15.2(1.14)T
15.2(1.14)T0.1
15.2(2.1)T
15.2(2.2)T
15.2(2)T
15.2(2)T0.8
Fixed-In
15.2(2.4)T
15.2(2)T0.9
15.2(1)T2
Thanks,
Bunyawat Bualek
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