Hi all,
Thanks for the replies so far.
On Mon, May 18, 2009 at 7:43 PM, Dale Shaw <dale.shaw_at_gmail.com> wrote:
> I'm more interested in the way you approach NAT tasks
> in terms of logic, strategy and troubleshooting. I personally haven't
> found a resource yet that gives me the background theory I require to
> get the most out of practice labs.
I think where my problem lies is in the 'ip nat' command line syntax.
I find it incredibly counter-intuitive, DocCD is hopeless, and the
context-sensitive help doesn't .. help. I read the task and it makes
sense, but then I get bogged down at the CLI.
I waste time determining which interface(s) should be inside and
outside, when it shouldn't really matter. Of course, it does, because
the options for translations are not the same for "ip nat inside [..]"
and "ip nat outside [..]". In the back of my mind, I know that
translating packets arriving on the outside interface is possible with
an "ip nat inside [..]" command, and vice versa.
I spent a few hours last night just focused on Cisco's implementation
and theory, and it has helped, so I'll continue along that path. I
also picked up a few troubleshooting tips - obvious stuff like 'debug
ip packet' against an ACL that matches the traffic you need to
translate, 'debug ip nat' and interpreting the output, enabling
process switching for better insight into packet flows, 'debug arp' to
reveal when a route or an alias is needed, and so on..
Any other suggestions are welcome. In the meantime I'll be attempting
to figure out a way to master the 'ip nat' command syntax.
cheers,
Dale
Blogs and organic groups at http://www.ccie.net
Received on Tue May 19 2009 - 08:01:35 ART
This archive was generated by hypermail 2.2.0 : Mon Jun 01 2009 - 07:04:43 ART