cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4218
Views
0
Helpful
7
Replies

Entering an "access-list permit" kills outside interface/GRE tunnel

Greg Dent
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

7 Replies 7

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

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!

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

"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

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.

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

Yeah, I will start giving that one a try. Didnt realise Cisco had added that one to the command set!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: