sider the need to test for two types of traffic: the original request and the resulting reply. An ACL must be created for each test. The ACL for the reply is created dynamically when the ACL for the original request is matched. Cisco calls the way that reflexive access lists are configured nesting, though the configuration doesn't look like nested code to most programmers. Continuing with the preceding example, let's create a reflexive access list for Telnet. We want host A to be able to telnet to host B, but we'll deny everything else. This scenario is overly restrictive for most real-world applications, but it'll help illustrate the functionality of reflexive access lists. To configure reflexive access lists, we must create one ACL for outbound traffic and one for inbound traffic. First, we'll create a named access list called TelnetOut: ip access-list extended TelnetOut permit tcp host 10.0.0.10 host 20.0.0.20 eq telnet reflect GAD deny ip any any Reflexive Access Lists Reflexive access lists can only be created using named access lists. This ACL is pretty straightforward, except for the addition of reflect GAD at the end of the permit line. This will be the name of the temporary access list created by the router when this permit entry is matched. The entry deny ip any any is not necessary, as all access lists include this by default, but I've included it here for clarity and to show the counters incrementing as traffic is denied later. Next, we'll create a named access list called TelnetIn: ip access-list extended TelnetIn evaluate GAD deny ip any any This access list has no permit statements, but it has the statement evaluate GAD. This line references the reflect line in the TelnetOut access list. GAD will be the name of the new access list created by the router. To make these access lists take effect, we need to apply them to the router. We'll apply TelnetOut to interface E1 outbound, and TelnetIn to interface E1 inbound. Fig- ure 25-6 illustrates. Inside Outside 10.0.0.0/24 20.0.0.0/24 TelnetOut ACL applie