cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
970
Views
0
Helpful
6
Replies

Basic ACL config question

Chris Mickle
Level 1
Level 1

When using NAT overload what, if any, is the difference between the following two access-list entries? I've seen it documented both ways and both appear to work the same way. Is there any situation where you would want to use one over the other?

access-list 100 permit ip 0.0.0.0 255.255.255.255 any

access-list 100 permit ip any any

Also, I've read in documentation that using the any any access list entry for NAT is discouraged. Is that strictly for security or are there other reasons; processing overhead for instance? Of corse this question would only apply in situations where all attached subnets should use NAT.

Thanks

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Chris,

Those two ACL lines are entirely equivalent. The word any is simply a shorthand for 0.0.0.0 255.255.255.255 and in fact, whenever you enter 0.0.0.0 255.255.255.255 in your ACL, IOS will automatically replace it with any:

Router(config)# do show access-lists

Router(config)# access-list 100 permit ip 0.0.0.0 255.255.255.255  any
Router(config)#
Router(config)# do show access-lists
Extended IP access list 100
    10 permit ip any any
Router(config)# do show run | i access-list
access-list 100 permit ip any any
Router(config)#

Also, I've read in documentation that using the any any access list entry for NAT is discouraged.

Yes, that is true. Besides the obvious functional and security implications of blindly allowing any traffic to be translated by NAT/PAT, you really should not allow your NAT/PAT to apply to packets that have already been translated. I may be in error but I faintly recall playing with NAT on a fairly old IOS (12.3 at most, probably 12.2) where I used an permit ip any any kind of ACL, and I saw that the IOS generated multiple translation entries for a single packet, as if it was translated multiple times. Since then, I was not able to reproduce the behavior, so there could have been something else in play, but that was the first time I realized that it makes no sense to have an ACL that allows the translated traffic to be translated again.

Of corse this question would only apply in situations where all attached subnets should use NAT.

Just to be sure you are aware of it: NAT can apply to traffic sourced from any network, not just a directly connected network. You can have a large topology over several routers with multiple end networks, and still have a single router do the NAT/PAT for this entire topology. It would require configuring an ACL that covers all internal networks, but it is a common deployment scenario.

Feel welcome to ask further!

Best regards,
Peter

View solution in original post

6 Replies 6

Peter Paluch
Cisco Employee
Cisco Employee

Hi Chris,

Those two ACL lines are entirely equivalent. The word any is simply a shorthand for 0.0.0.0 255.255.255.255 and in fact, whenever you enter 0.0.0.0 255.255.255.255 in your ACL, IOS will automatically replace it with any:

Router(config)# do show access-lists

Router(config)# access-list 100 permit ip 0.0.0.0 255.255.255.255  any
Router(config)#
Router(config)# do show access-lists
Extended IP access list 100
    10 permit ip any any
Router(config)# do show run | i access-list
access-list 100 permit ip any any
Router(config)#

Also, I've read in documentation that using the any any access list entry for NAT is discouraged.

Yes, that is true. Besides the obvious functional and security implications of blindly allowing any traffic to be translated by NAT/PAT, you really should not allow your NAT/PAT to apply to packets that have already been translated. I may be in error but I faintly recall playing with NAT on a fairly old IOS (12.3 at most, probably 12.2) where I used an permit ip any any kind of ACL, and I saw that the IOS generated multiple translation entries for a single packet, as if it was translated multiple times. Since then, I was not able to reproduce the behavior, so there could have been something else in play, but that was the first time I realized that it makes no sense to have an ACL that allows the translated traffic to be translated again.

Of corse this question would only apply in situations where all attached subnets should use NAT.

Just to be sure you are aware of it: NAT can apply to traffic sourced from any network, not just a directly connected network. You can have a large topology over several routers with multiple end networks, and still have a single router do the NAT/PAT for this entire topology. It would require configuring an ACL that covers all internal networks, but it is a common deployment scenario.

Feel welcome to ask further!

Best regards,
Peter

Thanks for the detailed explanation. I figured it was the same, but I'm still in the beginning phase of learning so I wanted to make sure that my assumption was correct. I haven't really gotten in depth with NAT/PAT yet. I understand the basic principle of how it works as I have been in IT for a long time (just now starting to really learn Cisco) as a Windows Server admin, but the details are still a little fuzzy.

On your last point, I have recently been made aware of that as I have been experimenting in my home lab with static routing and RIP. All of the scenarios I have setup thus far have used NAT to provide the lab access to the real internet.

I do have one other, unrelated question that I just thought of in regard to my home lab...

I have 6 routers in my lab including (2) 2610XM routers and a 2811. The 2610s each have 2 WIC1 DSU-T1 cards and the 2811 has 3 WIC1 DSU-T1-V2 cards. I can create point-to-point serial links between them with no problem, but if I try to make one of the 2811's cards the DCE by issuing the clock rate command, I get an error saying that the command only applies to DCE interfaces. Is this a limitation with the V2 version of the WICs or is there something else at play? It hasn't caused me a problem other than a minor annoyance because if I am using a point-to-point link I have to make sure I plan the topology so that the 2610XMs are the DCE.

Thanks for your assistance!

Hi Chris,

You are very much welcome.

if I try to make one of the 2811's cards the DCE by issuing the clock rate command, I get an error saying that the command only applies to DCE interfaces. Is this a limitation with the V2 version of the WICs or is there something else at play?

Cisco serial interfaces can act both as DCE and DTE interfaces, and the particular mode of operation in fact depends on the serial cable that is connected to them. The cable (its internal wiring) tells the card whether it should operate as a DCE or a DTE endpoint. So if the router believes you have a DTE cable connected to it then it will refuse the clock rate command. If the both connectors of the particular serial cable are identical, you could try to reverse the cable (exchange both ends between the same routers) and test the clock rate again - now, the 2600XM router should complain and the 2811 should be happy.

You can always ask the router about the type of cable it believes it is connected to by issuing the show controllers serial x/y/z command. The output is extremely technical but somewhere at the very top of the output, check for an indication of either a DCE or a DTE cable along with its type (V.35, X.21, RS-449, ...).

It should be noted that in typical real world scenarios, the router would be a DTE device, and so would use a DTE cable that would connect to a modem on the other end, and the modem would be doing the DCE job. For lab purposes, modems are ignored, and we're using back-to-back serial cables that make one router act as DTE, and the other router as a DCE device.

Best regards,
Peter

I appreciate the info.

I ran the show controllers command on both routers and can not find an indication of DCE or DTE and cable type in the output.

The output of the 2610XM which is the DCE bellow. Note the serial link is up/up and I can ping between them. The same command on the 2811 gives me a similar output with no indication that I can find of DCE or DTE.

R3#sh controllers s0/0
Interface Serial0/0
Hardware is PowerQUICC MPC860 with Integrated FT1 CSU/DSU module
 TX and RX clocks detected.
idb at 0x819AA1F8, driver data structure at 0x819B1FCC
SCC Registers:
General [GSMR]=0x2:0x00000030, Protocol-specific [PSMR]=0x8
Events [SCCE]=0x0000, Mask [SCCM]=0x001F, Status [SCCS]=0x06
Transmit on Demand [TODR]=0x0, Data Sync [DSR]=0x7E7E
Interrupt Registers:
Config [CICR]=0x00367F80, Pending [CIPR]=0x04008800
Mask   [CIMR]=0x40204000, In-srv  [CISR]=0x00000000
Command register [CR]=0x600
Port A [PADIR]=0x0000, [PAPAR]=0xFFFF
       [PAODR]=0x0000, [PADAT]=0xA5FB
Port B [PBDIR]=0x03A0F, [PBPAR]=0x0200E
       [PBODR]=0x00000, [PBDAT]=0x3E75D
Port C [PCDIR]=0x00C, [PCPAR]=0x000
       [PCSO]=0x0A0,  [PCDAT]=0xFC0, [PCINT]=0x00F
Receive Ring
        rmd(680126B0): status 9000 length 1A address 7D69D24
        rmd(680126B8): status 9000 length 62 address 7D6A3A4
        rmd(680126C0): status 9000 length 1A address 7D6AA24
        rmd(680126C8): status 9000 length 1A address 7D6B0A4
        rmd(680126D0): status 9000 length 145 address 7D6B724
        rmd(680126D8): status 9000 length 1A address 7D6BDA4
        rmd(680126E0): status 9000 length 62 address 7D6C424
        rmd(680126E8): status 9000 length 1A address 7D6CAA4
        rmd(680126F0): status 9000 length 1A address 7D6D124
        rmd(680126F8): status 9000 length 1A address 7D6D7A4
        rmd(68012700): status 9000 length 62 address 7D6DE24
        rmd(68012708): status 9000 length 1A address 7D6E4A4
        rmd(68012710): status 9000 length 1A address 7D6EB24
        rmd(68012718): status 9000 length 62 address 7D6F824
        rmd(68012720): status 9000 length 1A address 7D6FEA4
        rmd(68012728): status 9000 length 1A address 7D66924
        rmd(68012730): status 9000 length 1A address 7D662A4
        rmd(68012738): status 9000 length 62 address 7D66FA4
        rmd(68012740): status 9000 length 1A address 7D67624
        rmd(68012748): status 9000 length 145 address 7D67CA4
        rmd(68012750): status 9000 length 1A address 7D68324
        rmd(68012758): status 9000 length 62 address 7D689A4
        rmd(68012760): status 9000 length 1A address 7D69024
        rmd(68012768): status B000 length 1A address 7D696A4
Transmit Ring
        tmd(68012770): status 5C00 length 18 address 7D8E5F4
        tmd(68012778): status 5C00 length 18 address 7D8E9B4
        tmd(68012780): status 5C00 length 14E address 7DA24B4
        tmd(68012788): status 5C00 length 18 address 7D8EFF4
        tmd(68012790): status 5C00 length 18 address 7C01D94
        tmd(68012798): status 5C00 length 18 address 7C00354
        tmd(680127A0): status 5C00 length 18 address 7C00994
        tmd(680127A8): status 5C00 length 18 address 7C00D54
        tmd(680127B0): status 5C00 length 18 address 7C01114
        tmd(680127B8): status 5C00 length 14E address 7DA2B94
        tmd(680127C0): status 5C00 length 18 address 7C01894
        tmd(680127C8): status 5C00 length 18 address 7C01C54
        tmd(680127D0): status 5C00 length 18 address 7D8D474
        tmd(680127D8): status 5C00 length 18 address 7D8D834
        tmd(680127E0): status 5C00 length 18 address 7D8DBF4
        tmd(680127E8): status 7C00 length 18 address 7D8E234
tx_limited=0(16)
SCC GENERAL PARAMETER RAM (at 0x68013C00)
Rx BD Base [RBASE]=0x26B0, Fn Code [RFCR]=0x18
Tx BD Base [TBASE]=0x2770, Fn Code [TFCR]=0x18
Max Rx Buff Len [MRBLR]=1548
Rx State [RSTATE]=0x18008440, BD Ptr [RBPTR]=0x2720
Tx State [TSTATE]=0x18000548, BD Ptr [TBPTR]=0x27D0
SCC HDLC PARAMETER RAM (at 0x68013C38)
CRC Preset [C_PRES]=0xFFFF, Mask [C_MASK]=0xF0B8
Errors: CRC [CRCEC]=0, Aborts [ABTSC]=0, Discards [DISFC]=0
Nonmatch Addr Cntr [NMARC]=0
Retry Count [RETRC]=0
Max Frame Length [MFLR]=1608
Rx Int Threshold [RFTHR]=0, Frame Cnt [RFCNT]=65138
User-defined Address 0000/0000/0000/0000
User-defined Address Mask 0x0000

buffer size 1524
PowerQUICC SCC specific errors:
0 input aborts on receiving flag sequence
0 throttles, 0 enables
0 overruns
0 transmitter underruns
0 transmitter CTS losts
0 aborted short frames

R3#

Chris,

My apologies, I have mistaken your WIC cards for serial cards; in reality, your WIC modules are T1 modules using ISDN PRI T1 framing.

I actually doubt that on these modules, the clock rate command makes any sense whatsoever, because T1 has a fixed physical parameter set. When you actually configure the clock rate on either side of the link, does the command appear on the interface when you check the show running-config output?

Best regards,
Peter

No it does not.

Your explanation also makes sense to me because even though I set the clock rate at 64000 the interface can still transfer data at ~T1 speeds 1.5Mbps so it seems that the clock rate command, although no error is given, has no effect on the interfaces.

I learned how to configure back to back serial links between routers a while ago from a source I don't remember. I think maybe that source was using routers with serial cards instead of the WICs in it's examples and I just didn't know enough to establish the difference.

So all this still begs the question of why the WICs in the 2811 can't be the DCE?