Mastering NAT and PAT Configuration & Verification for CCNP 350-401 ENCOR: Cisco IOS Deep Dive

Ever found yourself on a Friday night, command line glowing, trying to figure out why your new branch office can't reach the Internet—yet every NAT config looks perfect? Trust me, if you’ve ever been there, you’re in good company. Honestly, I’ve seen engineers with years under their belts trip over NAT more times than I can count—maybe it’s a misconfigured ACL, flipping inside and outside by accident, forgetting to punch in the 'overload' keyword, or just chasing their tail through translation tables that seem to play hide-and-seek. The reality: NAT and PAT are foundational for modern network engineers, and absolute must-haves for the CCNP 350-401 ENCOR exam.
This deep-dive brings you beyond basic theory. We're going to dig into all the essentials—starting with the basics and quickly turning up the heat with advanced, real-world scenarios. I'll walk you through hands-on Cisco IOS XE configs (yep, including the gnarly VRF and IPv6 transition setups), then we'll tackle how to prove it actually works, how to sniff out problems, what this all means for security, and how to deal with those curveballs the exam loves to throw at you. I’m not just going to hand you the theory—I've got some real, slightly embarrassing field stories and lab exercises lined up, all so you can sidestep the pitfalls I’ve stumbled into and get your NAT/PAT working without the headache.
Why NAT and PAT Still Matter
NAT (that’s Network Address Translation) and PAT (Port Address Translation—sometimes you’ll hear folks call it NAT overload) are what let your private, behind-the-scenes IPv4 addresses talk to the big, wild Internet, even though there aren't nearly enough public addresses to go around. But honestly, NAT’s not just about squeezing more life out of the public IPv4 pool. It’s not just about squeezing more devices onto your network, either. You’ve gotta think about keeping your environment locked down, making sure things can grow without falling apart, and honestly, playing by all those policy and compliance rules that auditors love to remind us about—because, let’s face it, those are just as critical as everything else. At the CCNP level, you need to understand not only how NAT works, but why it behaves in certain ways: its effect on routing, security, troubleshooting, and application flows.
Hang in there with me, and when we wrap up, you’re going to walk away feeling like: ‘Okay, I can actually handle this stuff now!' Here’s what you’ll be able to tackle:
- Master NAT/PAT concepts and address translation theory
- Configure Static NAT, Dynamic NAT, PAT, and advanced NAT (VRF, NAT64) on Cisco IOS XE
- Verify and troubleshoot NAT using show/debug outputs and real-world diagnostics
- Tackle those trickier scenarios—think security gotchas, scaling issues, and keeping everything humming along even if a device drops out
- Use proven approaches and steer clear of the classic 'NAT traps' that can catch even folks who should know better
- Get your hands dirty with real labs, tricky troubleshooting challenges, and practice questions that’ll feel right at home on the CCNP exam
Let’s Break Down NAT and PAT: What They Really Are, Why We Use Them, and When They Matter
Basically, NAT jumps in and rewrites the IP addresses on packets as they move through your router or firewall. Most of the time, this is so your private, RFC 1918 addresses can sneak out to the Internet and actually get a reply back. But that’s not all—NAT comes to the rescue if you’re dealing with overlapping networks after a merger, segmenting your DMZ, or even bridging the gap between IPv6 and old-school IPv4.
- Static NAT: One-to-one mapping between an inside and outside address. It actually works both ways—you’ll get translations from inside-to-outside and outside-to-inside, no matter who starts the conversation.
- Dynamic NAT: Many-to-many mapping using a pool of public addresses. If the pool is exhausted, new sessions are dropped.
- PAT (NAT Overload): Many-to-one mapping—multiple devices share a public IP, differentiated by port numbers. Most common for Internet edge.
Inside/Outside, Local/Global—Address Terms Demystified
These terms are a favorite for CCNP exam questions. Here’s your cheat sheet:
Term | Description | Example |
---|---|---|
Inside Local | Private IP (before NAT) | 192.168.10.10 |
Inside Global | Public IP (after NAT) | 203.0.113.10 |
Outside Local | Remote IP as seen by inside host | 8.8.8.8 |
Outside Global | Actual IP of external host | 8.8.8.8 |
Let’s talk about those classic RFC 1918 private address blocks we always end up dealing with:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
If you see addresses outside these ranges internally, investigate—incorrect boundaries can cause major routing or NAT issues.
NAT Types & Operational Theory—How Translation Happens
Let’s see NAT in action:
Static NAT Packet Flow
[192.168.10.10] ---(inside)---> [Router: 192.168.10.10 <=> 203.0.113.10] ---(outside)---> [8.8.8.8]
Dynamic NAT with Pool
Here’s another: 192.168.10.11 from the inside hits your router, grabs a public address from the NAT pool (could be anything between 203.0.113.11 and 203.0.113.13), and then jets off towards the Internet.
PAT (NAT Overload)
Take this scenario: both 192.168.10.12 and 192.168.10.13 (with different source ports) want out, but they all squeeze through the same public IP (203.0.113.10) using different outbound port numbers—yeah, that’s PAT in action!
How NAT Actually Does Its Thing—The Order of Operations on Cisco IOS XE
Understanding when NAT is applied is vital for troubleshooting. Here’s the packet flow:
- Input ACL (interface-based, before NAT) is checked upon packet arrival.
- Routing decision is made.
- NAT translation is applied (using source/destination, interface roles, ACLs).
- Output ACL (interface-based, after NAT) is checked.
- QoS, encryption, and other output features are applied.
- Packet is forwarded out the interface.
Pro Tip: Policy routing (PBR) is applied before NAT. If you have both, be mindful of the order.
Security & Design Considerations
- NAT is not a firewall. Yeah, NAT makes your internal IPs invisible to the outside world, but don’t get lulled into a false sense of security. Stray packets can still sneak their way in if you’re not running a real, stateful firewall to back things up—and trust me, that’s when weird stuff happens.
- Application Impact: NAT can break protocols that embed IPs in payloads (FTP, SIP, H.323, IPsec ESP), unless fixed by an Application Layer Gateway (ALG) or manual rules.
- Performance: NAT uses router CPU and memory; in high-scale environments, hardware offload or performance tuning is essential.
- NAT Leakage: Misconfiguration can expose private addresses (“leakage”). Always audit translation rules and outbound flows.
Let’s Get Practical—How to Actually Set Up NAT on Cisco IOS
Here’s how I like to lay out NAT configs on IOS XE—no fluff, just what you need for real-life use and exam day.
First things first: Tag your interfaces as inside or outside. Seriously, double-check this—get it wrong, and nothing else will matter.
interface GigabitEthernet0/1 ! (let’s call this your inside interface) ip address 192.168.10.1 255.255.255.0 ! (your private side) ip nat inside ! interface GigabitEthernet0/2 i ip address 203.0.113.2 255.255.255.252 ! (your outside/public interface—where you talk to the world) ! (and here’s your public-facing side) ip nat outside
Tip: Always double-check interface roles. Swapped roles = nonfunctional NAT.
Static NAT Example
ip nat inside source static 192.168.10.10 203.0.113.10 ! (your static NAT, front and center—nothing fancy, just reliable translation) ! (classic static one-to-one mapping)
- Bottom line? You’re just handcuffing 192.168.10.10 on your LAN directly to 203.0.113.10 on the public Internet—it’s a one-to-one relationship, no funny business.
- Oh, and by the way, that mapping works both ways—doesn’t matter if you’re sending or receiving, the translation happens in both directions.
Dynamic NAT with Pool Example
ip access-list standard NAT_INSIDE ! (you’ve seen this before, but it’s worth repeating for your ACL references) ! (here comes the list of what you actually want NATed) permit 192.168.10.0 0.0.0.255 ! (this says, 'match anything in 192.168.10.0/24') ! ip nat pool NATPOOL 203.0.113.20 203.0.113.30 netmask 255.255.255.224 ! (all your public pool addresses in a row) ip nat inside source list NAT_INSIDE pool NATPOOL ! (this pulls matching users and hands them an address from the pool)
- ACL selects inside hosts for translation.
- Pool range must match your public IP allocation.
PAT (NAT Overload) Example
ip access-list standard NAT_INSIDE ! (you’ve seen this before, but it’s worth repeating for your ACL references) ! (here comes the list of what you actually want NATed) permit 192.168.10.0 0.0.0.255 ! (this says, 'match anything in 192.168.10.0/24') ! ip nat inside source list NAT_INSIDE interface GigabitEthernet0/2 overload ! (this is your bread-and-butter PAT config—everyone shares the interface’s address)
- "overload" enables PAT—without it, you get dynamic NAT.
- The interface’s public IP is used for all inside hosts.
PAT with Multiple Public IPs
ip nat pool PATPOOL 203.0.113.21 203.0.113.23 netmask 255.255.255.224 ! (a pool for overloaded PAT—more addresses, more capacity) ip nat inside source list NAT_INSIDE pool PATPOOL overload ! (lets you squeeze a ton of inside hosts out using multiple public IPs and ports)
- Each public IP in the pool increases the available port range (approx. 64,000 TCP/UDP ports per IP).
- Port exhaustion can still occur—monitor pool usage in large deployments.
PAT Port Allocation Table
Outside IPs | Available Translations (approx.) | When Exhausted |
---|---|---|
1 | ~64,000 | New sessions dropped or reused; users see failures |
3 | ~192,000 | Better scaling, but still monitor for spikes |
NAT Types Overview
You’ll notice, the magic of NAT is really about lining up these moving parts correctly—each type (static, dynamic, PAT) just tweaks the formula a bit. Like, static NAT’s your one-on-one dance, always the same partner, while PAT throws a party—tons of inside hosts can pile through a single public IP as long as they each bring a unique port number.
[192.168.10.0/24] --Gi0/1-- [NAT Router] --Gi0/2-- [203.0.113.0/30, Internet] ! (left side: your LAN, right side: the wild, wild web) | | (Static) (PAT) | | 192.168.10.10 <=> 203.0.113.10 All users share 203.0.113.2
How to Actually Check If Your NAT’s Doing Its Job
- show ip nat translations — Display active NAT entries
- show ip nat statistics — Pool usage, translation stats
- debug ip nat — Real-time translation events (use with caution)
Router# show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 203.0.113.10:5 192.168.10.10:5 8.8.8.8:1 8.8.8.8:1 tcp 203.0.113.2:40000 192.168.10.11:1234 8.8.4.4:80 8.8.4.4:80
- Those 'inside local/global' and 'outside local/global' columns—they’re your cheat sheet for figuring out which way traffic’s being NATed and spotting hang-ups when you’re troubleshooting.
- For PAT, watch port numbers for uniqueness and reuse.
Router# show ip nat statistics Total active translations: 8 (2 static, 6 dynamic; 6 extended) Pool NATPOOL: 10 addresses, 3 in use, 0 free Hits: 52925 Misses: 102
- If you’re seeing a bunch of 'Misses,' it usually means some of your traffic isn't matching any NAT rule or maybe you slipped up with your ACL config.
- Pool "in use" = translation saturation; add more IPs or switch to PAT as needed.
NAT Logging and Auditing
ip nat log translations syslog logging buffered 4096 logging trap informational
- Enables logging of NAT translation events to syslog. Useful for compliance and troubleshooting.
- Monitor logs for “leaked” internal addresses; configure SNMP for automated alerts on pool exhaustion.
Troubleshooting NAT/PAT—A Systematic Approach
NAT troubleshooting is about methodical checks and understanding packet flow. Here’s a streamlined checklist:
- Confirm correct ip nat inside/outside on interfaces
- Ensure ACLs match intended traffic (correct subnets, wildcard masks)
- Verify NAT pool sizes and usage
- Check for “overload” keyword on PAT configs
- Trace routing—ensure return packets traverse the same NAT device
- Review security ACLs and firewall rules (before/after NAT translation)
- Use show and debug commands for translation status
Here’s Where NAT Usually Trips You Up—And What to Do About It:
- Pool exhaustion: Add more addresses or migrate to PAT.
- Missing overload: Only a few sessions work; add “overload.”
- Asymmetric routing: Ensure bidirectional flows cross the same NAT router.
- ACL errors: Fix incorrect or missing subnet entries.
- Application failures: Check for ALG issues (see below).
Let’s roll up our sleeves: Troubleshooting Tricks for the Real World
- Monitor NAT table size and CPU usage with
show processes cpu
,show platform hardware capacity
. - Capture packets on inside/outside interfaces (
monitor capture
on IOS XE) to verify pre- and post-NAT addresses. - Troubleshoot multi-router NAT by tracing the full packet path and ensuring only one NAT translation per direction.
- Use
clear ip nat translation *
to reset translations during troubleshooting (in lab environments).
Advanced NAT Topics (CCNP and Real-World Context)
VRF-Lite Aware NAT
When connecting overlapping address spaces (e.g., mergers), VRF-aware NAT lets you translate between VRF instances:
ip vrf CustomerA rd 100:1 ! interface GigabitEthernet0/3 ip vrf forwarding CustomerA ip address 10.10.10.1 255.255.255.0 ! (assigning an IP on your VRF interface) ip nat inside ! ip nat inside source static 10.10.10.5 203.0.113.105 vrf CustomerA ! (this sets up static NAT inside VRF context—super handy for overlapping networks)
- Heads up: Not every fancy NAT feature plays nice with VRF or on every router out there—double-check your IOS XE version or you could get a nasty surprise.
Making IPv6 and IPv4 Play Nice: NAT64 in the Real World
NAT64 is basically your bridge—if you’ve got IPv6-only devices but your resources are still stuck on IPv4, NAT64 gets your packets across that divide (and yeah, it’s key if you want to actually roll out IPv6 without breaking everything). Note: NAT64 configuration differs from classic NAT.
interface GigabitEthernet0/2 nat64 enable ! nat64 prefix 64:ff9b::/96 ! (that’s your well-known NAT64 prefix—kind of the default for translation magic) nat64 v4 pool NAT64-POOL 192.0.2.0 192.0.2.255 prefix-length 24 ! (this is your IPv4 pool that IPv6 hosts are mapped to) nat64 translation timeout 600 ! nat64 rule 1 match ipv6 2001:db8:1::/64 ipv4 192.0.2.0/24 pool NAT64-POOL ! (this rule ties it all together—who gets translated and where they land)
- Prefix 64:ff9b::/96 is the standard well-known NAT64 prefix (per RFC 6052).
- If you’re doing DNS64 so your IPv6-only clients can find IPv4 servers, you’ll need to set up either the router’s built-in DNS64 or point your clients at a DNS64 service that knows when to fake an AAAA record.
- Not all applications support translation; test thoroughly.
NAT66 (IPv6-to-IPv6 NAT): Rarely used, not recommended by IETF, but may be seen in some enterprise environments. Cisco supports it on select platforms.
Application Layer Gateways—The Unsung Heroes (or Villains) When NAT Gets Tricky
Not all apps play nice with NAT—protocols like FTP, SIP, and H.323 often need a little help from ALGs to rewrite the IPs buried inside their actual data. ALGs are enabled by default for common protocols but may need to be disabled if they interfere:
! Global config mode no ip nat service sip udp port 5060 ! Disable SIP ALG (if SIP phones have issues) ip nat service ftp tcp port 21 ! Enable FTP ALG (if FTP is broken)
- Not all platforms/IOS versions support every ALG.
- Symptoms of ALG problems: failed connections, call drops, broken file transfers.
Protocol | ALG Default | Troubleshooting Tip |
---|---|---|
FTP | Enabled | Disable if passive mode fails; enable for active FTP |
SIP | Enabled | Disable if SIP phones can't register or call |
H.323 | Enabled | Disable for custom VoIP deployments |
NAT and Routing Protocols
Routing updates are not NATed—only transit traffic is. Static NAT mappings may require static routes, especially for inbound services.
- Dynamic routing protocols (EIGRP, OSPF) operate on pre-NAT addresses within the internal network.
- On the Internet edge, ensure default routes and summarization are in place.
NAT Hairpinning (Loopback)
NAT hairpinning (NAT loopback) allows internal hosts to access internal servers via the external, NATed public IP. Essential for scenarios like internal clients accessing DMZ services.
ip nat inside source static 192.168.10.10 203.0.113.10 ! (your static NAT, front and center—nothing fancy, just reliable translation) ! (classic static one-to-one mapping) ip nat enable hairpinning
- Check platform support—some Cisco platforms require additional configuration or do not support NAT hairpinning.
NAT and High Availability (HA)
For redundancy, HSRP/VRRP or stateful NAT is used. Only stateful NAT (SNAT) shares translation tables between routers—otherwise, active flows are lost during failover.
ip nat stateful redundancy 1 redundancy name NAT-RED ! interface Gi0/2 i ip address 203.0.113.2 255.255.255.252 ! (your outside/public interface—where you talk to the world) ! (and here’s your public-facing side) ip nat outside redundancy name NAT-RED
- Stateful NAT is not supported on all platforms; check compatibility.
- Test failover to ensure session preservation—critical for enterprise edge.
Security Implications and Best Practices
NAT and Security
NAT hides private IPs but does not provide real security. Unsolicited inbound traffic can still reach your network unless blocked by a stateful firewall. I always say: team up NAT with a real firewall, throw in IDS/IPS, and make sure your logging is dialed in.
- Routinely check your NAT rules—I've seen more than one shop leak internal addresses or mix up translations by accident.
- Monitor for pool exhaustion as a possible DoS vector.
- For compliance, log translation events and monitor for unexpected external flows.
NAT Table Scaling and Performance
Large NAT tables consume memory and CPU. Monitor with:
show ip nat statistics show platform hardware capacity show processes cpu sorted
- If you’re running heavy traffic through a beefy router, lean on hardware-accelerated NAT like CEF to take the performance load off your CPU.
- In busy environments, don’t be afraid to tweak your translation timeouts so you’re not drowning in stale entries:
ip nat translation timeout 300
When You’re Dealing With More Than One Vendor or Multiple ISPs
The NAT knobs and dials don’t look the same everywhere—what works on Cisco might throw you for a loop on Juniper, Fortinet, Palo Alto, or anyone else. Seriously, don’t wing it on cross-vendor setups—check the docs or you’ll spend all afternoon troubleshooting something silly. For dual-ISP environments, use policy NAT or twice NAT for route-based translation.
Real-World Use Cases & Case Studies
Case Study: Overlapping IPs after Merger
Two companies, each using 10.0.0.0/8, need connectivity. Solution: deploy VRF-lite and NAT between VRFs.
ip vrf CompanyA ip vrf CompanyB ! interface Gi0/1 ip vrf forwarding CompanyA ip address 10.0.0.1 255.0.0.0 ! (classic 10-dot address for your internal side) ip nat inside ! interface Gi0/2 ip vrf forwarding CompanyB ip address 10.0.0.2 255.0.0.0 ip nat outside ! ip nat inside source static vrf CompanyA 10.0.0.100 172.16.0.100 vrf CompanyB
- Test all cross-company apps; document translation policies.
Enterprise Internet Edge NAT
- PAT for general Internet traffic; static NAT for inbound services.
- Audit translation tables regularly for compliance and unused mappings.
- Scale pools and monitor translations to avoid service impact.
NAT in DMZ/Firewall Environments
- Deploy NAT at the perimeter, before or after the firewall as dictated by security policy.
- Static NAT for DMZ servers; ensure hairpinning for internal access to DMZ via public IPs.
Best Practices & Common Pitfalls
- Document every NAT rule: purpose, owner, expiration.
- Monitor for “NAT leaks” and accidental exposure.
- Remove unused pools, ACLs, and test all application flows after changes.
- Pair NAT with stateful firewalls—not as a replacement for real security.
Lab Scenarios—Hands-On Practice
Lab 1: Dual-Router Static/Dynamic NAT (with VRF-lite)
[HostA: 192.168.10.100]---(Gi0/1)[R1]Gi0/2---(192.168.20.1/24)[R2]Gi0/3---(203.0.113.1/30)[Internet]
- Configure R1 Gi0/1 as inside, Gi0/2 as outside.
- Apply dynamic NAT for 192.168.10.0/24 using a pool; static NAT for HostA.
- Add VRF-lite if testing overlapping subnets.
ip nat pool DYN_POOL 203.0.113.5 203.0.113.6 netmask 255.255.255.252 ip nat inside source list NAT_INSIDE pool DYN_POOL ip nat inside source static 192.168.10.100 203.0.113.100
Lab 2: PAT for Internet Access
[LAN: 10.1.1.0/24]---(Gi0/0)[Router]Gi0/1---(198.51.100.2/30)[Internet] ip nat inside source list NAT_LAN interface Gig0/1 overload
- Test with multiple hosts; observe translation scaling, port allocation, and pool exhaustion.
Lab 3: Stateful NAT High Availability (HSRP + SNAT)
[LAN]---[R1]---[Internet] |___[R2]___|
- Configure HSRP for default gateway failover.
- Enable stateful NAT redundancy:
ip nat stateful redundancy 1 redundancy name NAT-HA
- Test session preservation during failover.
Lab 4: NAT64 and IPv6-to-IPv4 Internet Access
[IPv6 Host]---[Router/NAT64]---[IPv4 Internet]
- Configure NAT64 prefix and pool as shown above.
- Test IPv6-only host accessing IPv4-only site (e.g., ping 64:ff9b::c000:201 for 192.0.2.1).
Lab 5: Troubleshooting Drill—Broken NAT Config
- Given a misconfigured NAT setup (wrong inside/outside, missing overload, pool too small, incorrect ACL), diagnose and fix.
- Practice reading
show
/debug
output and resolving translation failures.
CCNP 350-401 ENCOR Exam Preparation
Blueprint Mapping Table
Exam Objective | Covered Feature | Suggested Practice |
---|---|---|
Configure/verify NAT, PAT | Static, dynamic, PAT | Lab 1, 2 |
Configure/verify advanced NAT | VRF-lite, NAT64, HA | Lab 3, 4 |
Troubleshoot NAT issues | Order of operations, ACLs, pool exhaustion, asymmetric routing | Lab 5, troubleshooting checklist |
Address Term Mnemonic
“Local before NAT, Global after NAT.”
Draw the packet flow and label each term for scenario questions.
Scenario-Based Practice Questions
- You see traffic from 192.168.1.20, but
show ip nat translations
shows no entry. What’s the first thing to check?
Answer: Does the NAT ACL match this host? Is the correct interface labeled “ip nat inside”? - Users report intermittent Internet drops;
show ip nat statistics
shows pool “in use” = pool size. Solution?
Answer: Pool exhausted—add IPs, migrate to PAT, or tune session timeouts. - An internal host can’t access a DMZ server via its public IP. What’s the likely issue?
Answer: NAT hairpinning not enabled/supported. - After failover, active sessions drop. What did you miss?
Answer: Stateful NAT not configured—only HSRP/VRRP is running.
Show/Debug Output Interpretation Drill
Pro Inside global Inside local Outside local Outside global tcp 203.0.113.2:40000 192.168.10.11:1234 8.8.4.4:80 8.8.4.4:80
Question: What type of NAT is this?
Answer: PAT (overload)—TCP ports are being translated.
Exam Pitfalls Table
Pitfall | How to Avoid |
---|---|
Missing “ip nat inside/outside” | Label interfaces in diagrams/configs |
Forgetting “overload” on PAT | Double-check syntax in config review |
ACLs mismatch traffic | Verify subnets, wildcards, and intended flows |
Confusing inside local/global | Draw address flow diagrams before answering |
Timed Lab Challenge
Set a timer for 30 minutes: Given a scenario (Internet edge with DMZ, overlapping internal networks via VRF, IPv6 transition), configure NAT/PAT, verify, and troubleshoot to meet all requirements.
Summary
- Be methodical: always check interface roles, NAT rules, ACLs, and pools.
- Use verification commands and logs to diagnose issues—don’t guess.
- Understand NAT’s impact on routing, security, and applications.
- Practice advanced scenarios: VRF, NAT64, stateful failover, asymmetric routing.
- Document every rule and test every application after changes.
- Know exam “gotchas”—practice reading show/debug output, draw diagrams, and work under time pressure.
With consistent practice, NAT/PAT will become a reliable tool in your network and exam arsenal. When you deploy a complex NAT scenario flawlessly—or ace a scenario question in the CCNP—you’ll know you’ve mastered one of the most critical skills in networking.
Stay curious, keep breaking (and fixing) things in the lab, and you’ll be ready for both the exam and the real world. Good luck!
References
- Cisco IOS XE NAT Configuration Guides (16.x, 17.x series)
- RFC 1918: Address Allocation for Private Internets
- RFC 3022: Traditional NAT
- RFC 6052: IPv6 Addressing of IPv4/IPv6 Translators (NAT64)
- CCNP ENCOR 350-401 Official Cert Guide
- Cisco Command References: NAT/PAT “show” and “debug” commands
- Cisco Security Best Practices for NAT
- Cisco NAT64/DNS64 Deployment Guide