Today I’ll wrap up discussions of NAT before moving on to another topic next week. If you didn’t catch Tuesday’s NAT question, go back and read over it before taking a look at today’s post, in which I’ll explain the answers. Next, I’ll plan to move on to another of the topics in my CCNA survey from a few weeks back – click here to see the survey. Or maybe I’ll stir up the dust again with some broader comments on the value of Cisco certifications.
As usual, I’ve put the actual multi-choice answers at the bottom of this post so that you won’t accidentally see them, for those of you who may still want to look back at the question.
Tuesday’s question actually tests you on most of the important parts of a NAT overload (PAT) configuration, all in one question. While a multiple-choice question, if you’re a little iffy on all the details of a NAT configuration, this question may have caused a little trouble, or at least the feeling that you were unsure on a few points. Also, note that Cisco does tell you the number of correct answers – this question has 3 – but I didn’t tell you the number of answers just to make it more challenging.
Answer A tests you knowledge of whether the public IP addresses used by source NAT have to be on the serial link’s subnet, or not. There’s nothing particularly tricky here – it’s just a factoid to know, one that you’d know if you’d seen a similar example. It’s fine to use a subnet that’s on another interface, loopback or otherwise, as long as the address range is a registered public IP address range.
Answer B again tests a simple configuration fact, but with some subtle wording in the question. The question’s first sentence says “…all the private IP addresses in network 192.168.1.0/24…”, and the NAT pool has only 14 addresses. So, the config needs to use overload – otherwise, R1 could only support 14 concurrent hosts connecting towards the Internet – and the overload parameter is needed on the ip nat inside command (the whole command should be ip nat inside source list 1 pool fred overload). So, while the configuration of the overload (aka PAT) feature is easy, the question was possibly subtle enough to cause a problem.
Answers C and D test your knowledge of which interfaces need an ip nat outside or ip nat inside command, respectively. The interface connected to the side of the internetwork that uses private IP addresses needs an ip nat inside command, and in this case, Fa0/0 indeed has that command. Similarly, any public interfaces through which packets should be forwarded need an ip nat outside command, so in this case, S0/1/0 needs the ip nat outside command (and it does not). FYI, the loopback interface needs neither an ip nat outside or ip nat inside command, because the packets are not forwarded in/out the loopback interface.
Answer E represents probably the most obscure fact required for this question. R1 will change the private IP addresses in the packets to the public address range off its loopback interface, so routers in the Internet need to know how to route packets to that subnet. That’s true of any NAT/PAT configuration. In this case, either R1 must advertise a route for 192.31.7.0/28 to the ISP router, or the ISP router needs a static route for that same subnet. Without that route, PC1’s attempt to browse could fail, because the routers in the Internet would not know where to forward packets in subnet 192.31.7.0/28.
Finally, for answer F, the existing ACL does indeed match the exact set of IP address off interface Fa0/0. FYI, to find the ACL wildcard mask that can be used to match a particular subnet, subtract the subnet mask (255.255.255.0 in this case, for Fa0/0) from 255.255.255.255, giving a wildcard mask of 0.0.0.255, as shown in the access-list 1 command.
If you have any requests for the next technical topic for CCNA, fire away with a post here, and feel free to tell me which part(s) seem to give the most trouble – and I’ll try to address those. Thanks…
Correct answers: B, C, E
