Section 7: IOS and IP Features (10 Points)


  • Configure R8 so that when R6 FastEthernet4/0 (10.60.60.1) connects to virtual IP address 10.80.80.12, that traffic is actually sent to R2 Serial 0/0 (10.90.90.1). When R1 receives the traffic from R6, it should see the source address of 10.8.8.2 for this operation. Do not perform any policy routing in your solution.

This is an advanced NAT question. At first glance, you might have felt that this could be achieved by using "NAT on a Stick" where you would use a combination of NAT statements in conjunction with policy routing to achieve the desired result; however, policy routing is not permitted. In this scenario, a static NAT statement is required on R8 to proxy-arp for 10.80.80.12 (as this IP address does not exist) and to change the destination to 10.90.90.1. A further NAT statement is required to change return traffic destined for 10.8.8.2 to 10.60.60.1. Finally, a NAT pool changes the source IP address of traffic flowing toward 10.90.90.1. If you have configured this correctly as shown in Example 3-77, you have scored 5 points.

Example 3-77. R8 NAT Configuration
 interface FastEthernet0/0  ip address 10.80.80.3 255.255.255.0  no ip redirects  ip nat outside ! ip nat pool test 10.8.8.2 10.8.8.2 netmask 255.255.255.240 ip nat inside source static 10.90.90.1 10.80.80.12 ip nat inside source static 10.60.60.1 10.8.8.2 ip nat outside source list 199 pool test access-list 199 permit ip host 10.60.60.1 host 10.80.80.12 

NOTE

This will not work correctly unless you disable ip redirects on R8 FastEthernet0/0. Remember to test with extended pings from R6 to ensure your source address is 10.60.60.1.


Example 3-78 shows the testing procedure, using an extended ping from R6 to the virtual IP address of 10.80.80.12; NAT debugs on R8, and an ICMP debug on R2 shows the entire process.

Example 3-78. NAT Testing and Verification
 R6#ping Protocol [ip]: Target IP address: 10.80.80.12 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.60.60.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.80.80.12, timeout is 2 seconds: Packet sent with a source address of 10.60.60.1 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 4/6/8 ms ________________________________________________________________ R8#debug ip nat 01:25:30: NAT*: s=10.60.60.1->10.8.8.2, d=10.80.80.12 [195] 01:25:30: NAT*: s=10.8.8.2, d=10.80.80.12->10.90.90.1 [195] 01:25:30: NAT*: s=10.90.90.1, d=10.8.8.2->10.60.60.1 [195] 01:25:30: NAT*: s=10.60.60.1->10.8.8.2, d=10.80.80.12 [196] 01:25:30: NAT*: s=10.8.8.2, d=10.80.80.12->10.90.90.1 [196] 01:25:30: NAT*: s=10.90.90.1, d=10.8.8.2->10.60.60.1 [196] 01:25:30: NAT*: s=10.60.60.1->10.8.8.2, d=10.80.80.12 [197] 01:25:30: NAT*: s=10.8.8.2, d=10.80.80.12->10.90.90.1 [197] 01:25:30: NAT*: s=10.90.90.1, d=10.8.8.2->10.60.60.1 [197] 01:25:30: NAT*: s=10.60.60.1->10.8.8.2, d=10.80.80.12 [198] 01:25:30: NAT*: s=10.8.8.2, d=10.80.80.12->10.90.90.1 [198] 01:25:30: NAT*: s=10.90.90.1, d=10.8.8.2->10.60.60.1 [198] 01:25:30: NAT*: s=10.60.60.1->10.8.8.2, d=10.80.80.12 [199] 01:25:30: NAT*: s=10.8.8.2, d=10.80.80.12->10.90.90.1 [199] 01:25:30: NAT*: s=10.90.90.1, d=10.8.8.2->10.60.60.1 [199] ________________________________________________________________ R2#debug ip icmp 01:25:30: ICMP: echo reply sent, src 10.90.90.1, dst 10.8.8.2 01:25:30: ICMP: echo reply sent, src 10.90.90.1, dst 10.8.8.2 01:25:30: ICMP: echo reply sent, src 10.90.90.1, dst 10.8.8.2 01:25:30: ICMP: echo reply sent, src 10.90.90.1, dst 10.8.8.2 01:25:30: ICMP: echo reply sent, src 10.90.90.1, dst 10.8.8.2 

  • Manipulate the EIGRP authentication to change the keys as follows: The first key should remain active from the time you started this lab today and remain active for two days after that; the second key should then become active permanently. Allow an overlap of 20 minutes but ensure that all EIGRP routers have a common synchronized time source provided by one of your routers to ensure reliable operation.

You are required to configure an additional Key Chain and appropriate Key Management. Your original Key Chain should include an accept-lifetime and send-lifetime with a duration of 172800 seconds (2 days); the additional key should begin 1 day, 23 hours, and 40 minutes later to allow for the 20-minute overlap, this key should then have a lifetime, which is infinite. A synchronized time source can only be Network Time Protocol (NTP) to ensure that each EIGRP router has a synchronized clock and manages its keys effectively. If you do not configure R2 as the NTP master, you could run into problems as this is the only router that has direct connections to the other EIGRP routers; if, for example, you configured R1 as the master, R3 can only access the NTP server via an EIGRP route. This might not appear to be a problem on the surface but just see what happens when you reset your routers. If you configured this correctly as shown in Example 3-79 through Example 3-82, you have scored 3 points.

Example 3-79. EIGRP Key Chain Configuration for R1, R2, and R3
 key chain Brussels  key 1   key-string Asterix   accept-lifetime 09:00:00 Jul 18 2004 duration 172800   send-lifetime 09:00:00 Jul 18 2004 duration 172800  key 2   key-string Obelix   accept-lifetime 08:40:00 Jul 20 2004 infinite   send-lifetime 08:40:00 Jul 20 2004 infinite 

NOTE

An alternate solution to configuring duration can be to configure the end time.


Example 3-80. R2 NTP Configuration
 R2# clock set 15:01:00 18 july 2004 R2#conf t R2(config)#ntp master R2(config)#^Z 

Example 3-81. R1 NTP Configuration
 ntp server 10.90.90.1 

Example 3-82. R3 NTP Configuration
 ntp server 172.16.0.1 

  • Configure R7 not to send each character of a Telnet session as a separate CPU interrupt to your network devices. Characters should be buffered until an acknowledgment is received to reduce CPU interrupts and improve on bandwidth limitations.

By default, each Telnet character actually causes a CPU interrupt. To enable the buffering feature, you need to configure R7 with the service nagle command. If you have configured this correctly, you have scored 1 point.

  • Prevent the configuration prompt from being displayed on R5 when in config mode.

The command no service prompt prevents the configuration prompt from being displayed; the usual prompt is still displayed in EXEC mode. If you have configured this correctly as shown in Example 3-83, you have scored 1 point.

Example 3-83. R5 Service Prompt Configuration
 R5(config)#no service prompt config R5#conf t 00:24:14: %SYS-5-CONFIG_I: Configured from console by console Enter configuration commands, one per line.  End with CNTL/Z. int fast 0/0 no shut exit exit R5# 




CCIE Routing and Switching Practice Labs
CCIE Routing and Switching Practice Labs
ISBN: 1587051478
EAN: 2147483647
Year: 2006
Pages: 268

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net