When learning Cisco IOS, students often ask, what happens if there is conflicting information? Cisco IOS order of operations plays an important role in how a router processes traffic and makes choices, especially if there are two possible answers.
If you’re simply using the most basic features of the router, chances are good that you’ll never have to think about the order of operations. However, when configuring features such as Network Address Translation (NAT), Quality of Service (QoS), and encryption, it’s essential to understand the order of operations in order to configure these features successfully.
Using the Cisco IOS actually involves two different order of operations tables, details of which can be found at the hyperlinks by clicking the items:
NAT Order of Operations
In its most basic form, NAT translates one IP address to another IP address.
When the router uses this order of operations, it takes the inbound packet, starting at the top and moves down the list. If the packet is from a NAT inside-designated interface, it uses the inside-to-outside list. If the packet is from an outside-to-inside interface, it uses that list.
Here’s the order of operations for the inside-to-outside list:
- If IPSec, then check input access list
- Decryption-for Cisco Encryption Technology (CET) or IPSec
- Check input access list
- Check input rate limits
- Input accounting
- Policy routing
- Routing
- Redirect to Web cache
- NAT inside to outside (local to global translation)
- Crypto (check map and mark for encryption)
- Check output access list
- Inspect context-based access control (CBAC)
- TCP intercept
- Encryption
Here’s the order of operations for the outside-to-inside list:
- If IPSec, then check input access list
- Decryption-for CET or IPSec
- Check input access list
- Check input rate limits
- Input accounting
- NAT outside to inside (global to local translation)
- Policy routing
- Routing
- Redirect to Web cache
- Crypto (check map and mark for encryption)
- Check output access list
- Inspect CBAC
- TCP intercept
- Encryption
Let’s say that you have an IP packet coming in from an outside-to-inside interface. When translating that packet, you want to use an access control list to block traffic from certain IP addresses. Which IP address should you put in the ACL-the IP address before the packet’s translation (i.e., the public IP address), or the IP address after the packet’s translation (i.e., the private address)?
By checking the order of operations, you can determine that the “NAT outside to inside” operation occurs after the “Check input access list” task. Therefore, you would use the public IP address in the ACL because the packet hasn’t gone through NAT.
On the other hand, what if you want to create a static route for traffic going through NAT? Should you use the public (outside) or private (inside) IP address? In this case, you would use the private (inside) IP address because the traffic has already gone through NAT when it gets to the “Routing” operation.
QoS Order of Operations
The Quality of Service (QoS) order of operations is another important list to know. Of course, this is only really important if you’re using QoS. But if you are, you need to be familiar with it.
Here’s the order of operations for inbound traffic to the router:
- QoS Policy Propagation through Border Gateway Protocol (BGP)-or QPPB
- Input common classification
- Input ACLs
- Input marking-class-based marking or Committed Access Rate (CAR)
- Input policing-through a class-based policer or CAR
- IPSec
- Cisco Express Forwarding (CEF) or Fast Switching
Here’s the order of operations for outbound traffic from the router:
- CEF or Fast Switching
- Output common classification
- Output ACLs
- Output marking
- Output policing-through a class-based policer or CAR
- Queueing-Class-Based Weighted Fair Queueing (CBWFQ) and Low Latency Queueing (LLQ))-and Weighted Random Early Detection (WRED)
Being familiar with the order of operations is vital when it comes to understanding how the traffic within a router is flowing and how to control that traffic. In my experience, the NAT order of operations is most important when you’re using any combination of NAT, crypto, ACLs, routing, or other features on the list.
Without a proper understanding of the order of operations, you can spend an entire week troubleshooting a basic NAT and ACL combination-without any luck. Knowing about the order of operations can really make a difference.
Using Cisco IOS to block access to Web Sites
Some routers in the network act as Internet gateways, and a common desire is to restrict access to web sites that are inappropriate or dangerous. To enable this functionality using Cisco IOS, there are a couple of things that must be accomplished:
- Configure a DNS Server so the router can look up web site addresses. This is handy as you can now use ‘www.cellstream.com’ instead of knowing the specific IP address.
- Configure Access Control Lists to block the web sites
- Apply the Access Control List filter to the appropriate interface
Lets look at the configuration process to accomplish the steps above.
Configuring a DNS server
Let’s say we want to block access to a xxx porn site like www.xxxwebs.com . The router needs to resolve www.xxxwebs.com using a DNS server. So, to configure a DNS server, use the ip name-server command. Here’s an example:
cell_ce01(config)# ip name-server X.X.X.X Y.Y.Y.Y
X.X.X.X above is the primary DNS server IP Address, and Y.Y.Y.Y is a backup DNS server for the router to use to resolve DNS names. This doesn’t affect any traffic flowing through the router; the router will use these DNS servers when we ping a Web server by name. Here’s an example:
cell_ce01# ping www.cellstream.com
Translating “www.cellstream.com”…domain server (X.X.X.X) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 66.137.1.137, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/10/40 ms
Create the ACL to Block the Site
To actually block the web site, we need to create an access control list (ACL) to define exactly what we want to block. Here’s an example:
cell_ce01(config)# access-list 101 deny tcp any host www.xxxwebs.com eq www
Translating “www.xxxwebs.com”…domain server (X.X.X.X) [OK]
cell_ce01(config)# access-list 101 permit tcp any any eq www
! to allow all other web traffic
This ACL shown will deny all Web traffic from any source going to the specified Web site. After blocking that traffic, it will also allow all other Web traffic from any source to any destination. Finally, because of the implied deny, it will deny all other traffic.
What if you want to determine which IP addresses are trying to go to the blocked Web site? You can log this information using the log keyword. Here’s an example:
cell_ce01(config)# access-list 101 deny tcp any host www.xxxwebs.com eq www log
Important Note:
Here’s one issue to keep in mind. After you enter the first line of the ACL above, notice how the router used the DNS server to resolve the DNS name. It then replaced the IP address that the hostname resolved to in the ACL. Here’s a closer look at the configuration:
cell_ce01# show run | include access-list 101
access-list 101 deny tcp any host Z.Z.Z.Z eq www
Instead of the web address, the router has replaced it with Z.Z.Z.Z. This is a nice feature, but it can be problematic for a couple of reasons. First, the IP address entered is only the first IP address that the DNS server responded to. If this is a large Web site that has multiple servers (such as a search engine), the ACL only contains the first IP address that the DNS server responded with-you’ll need to manually block the other IP addresses. Here’s an example:
C:/> nslookup www.google.com
Server: DNSSERVER
Address: X.X.X.X
Non-authoritative answer:
Name: www.l.google.com
Addresses: 64.233.167.104, 64.233.167.147, 64.233.167.99
Aliases: www.google.com
In addition, if the IP address of the blocked Web server changes, your ACL will remain the same. You would need to manually update the ACL.
Apply the ACL to an Interface
We created this ACL with the assumption that it’s blocking traffic from our local netwok that’s going out to the Internet. That’s because we formatted the ACL with source then destination.
Because of this design, we need to apply the ACL in the OUTBOUND direction on the router, or bette said, the interface going to the Internet:
cell_ce01(config)# int serial 0/1
cell_ce01(config-if)# ip access-group 101 out
All attempts now to reach the web site will be blocked by the router.
We hope this helps you with uderstanding both NAT and QoS Order of operations.