Friday, June 16, 2006
Concerning Symmetry in NAT.
NAT with its concept of local/global and inside/outside seems conceptually very symmetrical. Thinking about this, it occurred to me that since local/global and inside/outside are all relative terms, one could take a network where NAT is being employed and swap the concepts of "inside" and "outside" and "local" and "global" and still have everything working. It seemed like a plausible hypothesis and so I decided to try it out on a simple network.
I first figured that the implementation in Cisco IOS itself might reflect that symmetry in some form. Since the software implementation in Cisco IOS is largely exposed to us, the users, via the CLI I decided to do a quick check of the CLI commands to detect the existence of that symmetry.
Hmm, that looks pretty symmetrical. Notice how the local->global in the former becomes global->local in the latter? Looks good so far.
Looking at the commands a bit more, one does see asymmetries in the CLI like
So, there is no configuration for destination address translation with "ip nat outside". But I argued with myself that the lack of an option in the latter case seems more like an implementation choice based on real-world needs rather than something radically asymmetrical in any significant sense. For instance, one could well conceive of doing destination address translation even with "ip nat outside" but it would seem that nobody does and so Cisco does not have that option in the CLI.
OK, so now in order to test the hypothesis with a simple network I set up the following network -
The routers had the configuration specified in Problem #71. To test the symmetry hypothesis, I just swapped inside <-> outside in the configuration of R2 and expected things to just work. Not surprisingly, I found that things did not work!
Looking into the problem, I realized that I was missing a fundamental asymmetry with how NAT works. That has to do with whether the NAT translation happens before the route look-up is done or if it is done after the route look-up. In the inside-to-outside
case, the routing happens before the translation while in the outside-to-inside case the translation happens before the routing. This fundamental asymmetry in the processing order with NAT prevents the configs from just working if an inside<->outside swap is done.
Thus the importance of knowing the order of processing was brought home to me. A thorough study of the document on CCO that describes the NAT order of processing proved to be a useful exercise. The variations in the order of processing for NAT seem to me to be good candidates for subject matter to be tested on for the CCIE, CCNP or maybe even the CCNA exams.
I first figured that the implementation in Cisco IOS itself might reflect that symmetry in some form. Since the software implementation in Cisco IOS is largely exposed to us, the users, via the CLI I decided to do a quick check of the CLI commands to detect the existence of that symmetry.
R2(config)#ip nat inside source ?
list Specify access list describing local addresses
route-map Specify route-map
static Specify static local->global mapping
R2(config)#ip nat outside source ?
list Specify access list describing global addresses
route-map Specify route-map
static Specify static global->local mapping
Hmm, that looks pretty symmetrical. Notice how the local->global in the former becomes global->local in the latter? Looks good so far.
Looking at the commands a bit more, one does see asymmetries in the CLI like
R2(config)#ip nat inside ?
destination Destination address translation
source Source address translation
R2(config)#ip nat outside ?
source Source address translation
So, there is no configuration for destination address translation with "ip nat outside". But I argued with myself that the lack of an option in the latter case seems more like an implementation choice based on real-world needs rather than something radically asymmetrical in any significant sense. For instance, one could well conceive of doing destination address translation even with "ip nat outside" but it would seem that nobody does and so Cisco does not have that option in the CLI.
OK, so now in order to test the hypothesis with a simple network I set up the following network -
The routers had the configuration specified in Problem #71. To test the symmetry hypothesis, I just swapped inside <-> outside in the configuration of R2 and expected things to just work. Not surprisingly, I found that things did not work!
Looking into the problem, I realized that I was missing a fundamental asymmetry with how NAT works. That has to do with whether the NAT translation happens before the route look-up is done or if it is done after the route look-up. In the inside-to-outside
case, the routing happens before the translation while in the outside-to-inside case the translation happens before the routing. This fundamental asymmetry in the processing order with NAT prevents the configs from just working if an inside<->outside swap is done.
Thus the importance of knowing the order of processing was brought home to me. A thorough study of the document on CCO that describes the NAT order of processing proved to be a useful exercise. The variations in the order of processing for NAT seem to me to be good candidates for subject matter to be tested on for the CCIE, CCNP or maybe even the CCNA exams.
