08-20-2013 03:25 AM - edited 03-04-2019 08:49 PM
Hi guys,
So I'm trying to update an access-list on one of our project site routers. We've had to add in some entries to allow for our new SIP phones to go out over the internet.
So I've removed the access lists, meaning the router is open to the internet, with a view to add it back in in the correct order with the new entrires for the SIP provider's servers.
However, as soon as I add the first line, which is "access-list 150 permit gre any any", my connection drops and wont come back until the router is reloaded.
I am doing this remotely over a GRE tunnel, but I've done this many times in the past without it causing a problem. I completely do not understand why a PERMIT entry should kill the GRE tunnel and outside interface of the router, when that EXACT entry was previously in the ACL. I hadn't even gotten to the new entries before it killed the link.
Any ideas? Is there a specific order I need to enter this in perhaps? Some clarification on this would also help - like I've mentioned, I've done this exact same process, with the exact same ACL entries to a lot of routers in the past without a problem. This particular router is a Cisco 1801 running IOS 12.4(24)T8.
Thanks
Solved! Go to Solution.
08-20-2013 03:47 AM
If you didn't remove the ACL from the interface before entering your first ACE, then after entering the first line your effective ACL looks like the following:
access-list 150 permit gre any any
access-list 150 deny ip any any
The last line is the invisible implicit deny any.
The right way to reconfigure it would be to go into interface-config-mode, do a "no ip access-group 150 in" and then reconfigure the ACL. After that you reapply the ACL to the interface.
The easier way to edit an ACL is to first do a "sh ip access-list 150". There you see sequence-numbers in front of each line. Now you can edit the ACL with "ip access-list ext 150" and add new lines by using an unused sequence or delete a line with "no SEQ".
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
08-20-2013 03:47 AM
If you didn't remove the ACL from the interface before entering your first ACE, then after entering the first line your effective ACL looks like the following:
access-list 150 permit gre any any
access-list 150 deny ip any any
The last line is the invisible implicit deny any.
The right way to reconfigure it would be to go into interface-config-mode, do a "no ip access-group 150 in" and then reconfigure the ACL. After that you reapply the ACL to the interface.
The easier way to edit an ACL is to first do a "sh ip access-list 150". There you see sequence-numbers in front of each line. Now you can edit the ACL with "ip access-list ext 150" and add new lines by using an unused sequence or delete a line with "no SEQ".
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
08-20-2013 03:58 AM
Top man, that was indeed it - I had left the ACL on the outside interface while adding it back. The implicit deny was at the end and the only reason I had to re-add the ACL in the first place.
Been looking at Cisco CLI for too long and my eyes glazed over!
Oh well, I assumed it was going to be something noob-like, many thanks!
08-20-2013 07:20 AM
Just to add, I've used "reload in x" command and this saves me from a lot of trouble. Just don't forget to do a "reload cancel."
Sent from Cisco Technical Support iPhone App
08-20-2013 07:33 AM
"reload in x" is a little bit 80ies ... Today you use "configure terminal revert timer X" and when you have done a "configure confirm". If you can't confirm, probably something went wrong and the config is reverted to the version when configuration started. The fainthart that doesn't trust this rollback can additionally issue a "reload in X" with a longer time then used with revert.
http://www.cisco.com/en/US/docs/ios-xml/ios/fundamentals/command/C_commands.html#wp5638445690
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
08-20-2013 08:56 AM
Yeah, I always make use of the 'reload in x' command. 80's or not, it works! It was the only way I could get this router back!
Juniper/JUNOS have done it correctly I think, at least better than Cisco. You always work on the config in NVRAM, not running config, and you have to commit changes when you are done. I always hated working on a live config, but Cisco dont seem to want to change it
Thanks for all your replies.
08-20-2013 09:02 AM
With the "config revert" it is a little bit like the JUNOS way. And the users normally don't realize that something went wrong as with a reload ... ;-)
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
08-20-2013 09:21 AM
Yeah, I will start giving that one a try. Didnt realise Cisco had added that one to the command set!
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