Hands-On Lab: Configuring Dynamic NAT

This hands-on lab configures dynamic NAT using a pool of public addresses, verifying that internal hosts are assigned public addresses from the pool on a first-come, first-served basis and that translations expire once idle.

Dynamic NAT ConfigurationNAT PoolTranslation Timeout

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure dynamic NAT on a router using a defined pool of public addresses, verify internal hosts are translated to addresses from that pool as they generate traffic, and observe a translation expire after its host goes idle.

Lab Purpose

Dynamic NAT, discussed earlier in this series, maps private addresses to public addresses drawn from a pool rather than a fixed one-to-one static mapping, assigned as traffic actually occurs — useful when a limited number of public addresses need to serve a larger set of occasionally active internal hosts.

Lab Topology

R1
  Gi0/0 (inside): 192.168.55.1/24
  Gi0/1 (outside): 203.0.113.30/30

Internal hosts: PC-A (192.168.55.10),
                PC-B (192.168.55.11)

Public address pool: 203.0.113.40 - 203.0.113.42

Task 1: Configure Basic Addressing and Interfaces

Configure both interfaces, marking Gi0/0 as inside and Gi0/1 as outside.

Task 2: Define the NAT Pool

Create a NAT pool named PUBLIC-POOL covering the three addresses shown.

Task 3: Define an ACL Identifying Eligible Internal Traffic

Create a standard ACL matching the internal subnet.

Task 4: Link the ACL to the Pool

Configure dynamic NAT, associating the ACL with the pool.

Task 5: Verify Dynamic Translation Occurs

Generate traffic from PC-A and PC-B and confirm each receives a distinct address from the pool.

Task 6: Observe Translation Expiration

Allow the translations to sit idle and confirm they eventually clear from the table.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.55.1 255.255.255.0
R1(config-if)# ip nat inside
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 203.0.113.30 255.255.255.252
R1(config-if)# ip nat outside
R1(config-if)# no shutdown

R1(config)# ip nat pool PUBLIC-POOL 203.0.113.40 203.0.113.42 netmask 255.255.255.252

R1(config)# access-list 1 permit 192.168.55.0 0.0.0.255

R1(config)# ip nat inside source list 1 pool PUBLIC-POOL

PC-A> ping 203.0.113.1
PC-B> ping 203.0.113.1

R1# show ip nat translations

Pro  Inside global     Inside local      Outside local  Outside global
icmp 203.0.113.40      192.168.55.10     203.0.113.1    203.0.113.1
icmp 203.0.113.41      192.168.55.11     203.0.113.1    203.0.113.1
-- Each host received a DIFFERENT address
-- from the pool, assigned on a first-come,
-- first-served basis as their traffic began

-- After leaving both hosts idle for several
-- minutes (default idle timeout is 24 hours
-- for TCP, shorter for other protocol types):

R1# show ip nat translations
-- (entries eventually clear once idle timeout
--  expires, freeing the pool addresses for
--  reuse by other hosts)

Key Takeaway

Dynamic NAT still requires one public address per simultaneously active internal host, since it remains fundamentally a one-to-one mapping at any given moment — with only 3 addresses in this pool, a fourth simultaneously active host would fail to get translated at all until one of the existing translations expires, which is exactly the scaling limitation that PAT, covered in the next lab, was designed to solve.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه