CCIE Practical Studies, Volume I
| < Free Open Study > |
Lab 32: Configuring Static NAT and DSLw ”Part II
Lab Walkthrough
After completing the physical installation of the serial link and the two Ethernet segments, establish IP connectivity between the appropriate subnets. Use EIGRP as the routing protocol on all routers. Be sure that you do not route the subnet 210.168.1.0/24 with EIGRP. Beginning with the green_bay router, define which networks will be the inside and outside networks. In this lab, networks 198.100.1.0/24 and 190.10.5.4/30 are outside networks, while 210.168.1.0/24 and 190.10.1.0/24 are inside networks. Configure the E0 port with the ip nat inside command, and configure the S0 port with the ip nat outside command. Next, you must ensure that IP connectivity exists between the IP subnet 190.10.1.0/24 and the rest of the network. Do this by creating a loopback interface and using an IP host address from the 190.10.1.0/24 subnet. You should be able to ping this address/subnet from the harms_co router when routing is established. Example 15-20 lists the commands needed to accomplish the first two steps on NAT configuration. Example 15-20 Configuring NAT on the green_bay Router
green_bay(config)# int e0 green_bay(config-if)# ip nat inside green_bay(config-if)# int s0 green_bay(config-if)# ip nat outside green_bay(config-if)# exit green_bay(config)# router eigrp 7 green_bay(config-router)# network 190.10.0.0 green_bay(config-router)# ^Z green_bay# You now can define what addresses you want to translate with NAT. On the green_bay router, you want to translate address 210.168.1.250 to 190.10.1.2 and 210.168.1.254 to 190.10.1.1. This can be done with the following global NAT command: ip nat inside source static 210.168.1.250 190.10.1.2 ip nat inside source static 210.168.1.254 190.10.1.1 At this point, the workstation 210.168.1.250 can reach the rest of the network. Hosts on the outside networks also can reach 210.168.1.250 and 210.168.1.254 through 190.10.1.2 and 190.10.1.1, respectively. Example 15-21 shows the NAT table from the green_bay router. Example 15-21 show ip nat translations on the green_bay Router
green_bay# show ip nat trans Pro Inside global Inside local Outside local Outside global tcp 190.10.1.2:1084 210.168.1.250:1084 198.100.1.50:21 198.100.1.50:21 --- 190.10.1.2 210.168.1.250 --- --- --- 190.10.1.1 210.168.1.254 --- --- green_bay# Example 15-22 lists the chippewa_falls configuration and the green_bay configuration, respectively. Example 15-22 chippewa_falls and green_bay Router Configurations
hostname chippewa_falls ! <<<text omitted>>> ! interface Ethernet0 ip address 198.100.1.1 255.255.255.0 ! interface Serial0 ip address 190.10.5.5 255.255.255.252 no fair-queue clockrate 2000000 ! <<<text omitted>>> ! router eigrp 7 network 198.100.1.0 network 190.10.0.0 ________________________________________________________________________________________________ hostname green_bay ! <<<text omitted>>> ! interface Loopback20 ip address 190.10.1.3 255.255.255.0 no ip directed-broadcast ! interface Ethernet0 ip address 210.168.1.254 255.255.255.0 no ip directed-broadcast ip nat inside ! interface Serial0 ip address 190.10.5.6 255.255.255.252 no ip directed-broadcast ip nat outside no ip mroute-cache no fair-queue ! <<<text omitted>>> ! router eigrp 7 network 190.10.0.0 ! ip nat inside source static 210.168.1.250 190.10.1.2 ip nat inside source static 210.168.1.254 190.10.1.1 <<<text omitted>>> The optional portion of this lab exploits a DLSw issue with NAT. First, you will walk through the configuration as specified. Configure DLSw using 210.168.1.254 as the local peer on the green_bay router, with a remote peer pointing toward 198.100.1.10. Example 15-23 shows the DLSw configuration. Example 15-23 DLSw Configuration Using 210.168.1.254 as the Local Peer on the green_bay Router with a Remote Peer Pointing Toward 198.100.1.10
dlsw local-peer peer-id 210.168.1.254 dlsw remote-peer 0 tcp 198.100.1.10 dlsw bridge-group 1 ! interface Ethernet0 ip address 210.168.1.254 255.255.255.0 no ip directed-broadcast ip nat inside bridge-group 1 Example 15-24 shows the configuration of DLSw on the harms_co router. Example 15-24 DLSw Configuration on the harms_co Router
dlsw local-peer peer-id 198.100.1.10 promiscuous dlsw bridge-group 1 ! interface Ethernet1 ip address 198.100.1.10 255.255.255.0 media-type 10BaseT bridge-group 1 This configuration is correct; however, DLSw will encounter an error because of NAT. By watching the peers, you can observe that they never connect, despite the fact that there is IP connectivity between them. RFC 1795 specifies how TCP connections are handled with a control vector. During the capabilities exchange, a control vector is negotiated. DSLw uses two TCP sessions for data exchange. Cisco routers will use only one TCP session and will tear down the other TCP connection. When the router determines what TCP session to tear down, it looks for the highest IP address on the peer statement and drops that TCP connection. In this lab, the harms_co router believes that its IP address is 198.100.1.10 and that the remote peer address is 190.10.1.1. Therefore, it tears down its TCP connection. On the green_bay router, it sees its IP address as 210.168.1.254 and the remote peer address as 198.100.1.10. Therefore, it tears down its TCP connection. Because both sides tear down what they believe is the highest IP address, the connection is terminated . Example 15-25 demonstrates this with the debug dlsw peer and debug dlsw core commands. Example 15-25 debug Showing the Teardown of TCP Sessions
harms_co# 02:21:02: DLSw: passive open 190.10.1.1(11009) -> 2065 02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:TCP-RD PIPE OPENED st ate:DISCONN 02:21:02: DLSw: dtp_action_c() opening write pipe for peer 190.10.1.1(2065) 02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:DISCONN->WWR_RDOP 02:21:02: DLSw: Async Open Callback 190.10.1.1(2065) -> 11006 02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:TCP-WR PIPE OPENED st ate:WWR_RDOP 02:21:02: DLSw: dtp_action_i() write pipe opened for peer 190.10.1.1(2065) 02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:WWR_RDOP->WAIT_CAP 02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:SSP-CAP MSG RCVD stat e:WAIT_CAP 02:21:02: DLSw: dtp_action_j() cap msg rcvd from peer 190.10.1.1(2065) 02:21:02: DLSw: Recv CapExId Msg from peer 190.10.1.1(2065) 02:21:02: DLSw: Unknown CV D9 with length 3 from peer 190.10.1.1(2065) 02:21:02: DLSw: Pos CapExResp sent to peer 190.10.1.1(2065) 02:21:02: DLSw: CapExId Msg sent to peer 190.10.1.1(2065) 02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:WAIT_CAP->WAIT_CAP 02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:SSP-CAP MSG RCVD stat e:WAIT_CAP 02:21:02: DLSw: dtp_action_j() cap msg rcvd from peer 190.10.1.1(2065) 02:21:02: DLSw: Recv CapExPosRsp Msg from peer 190.10.1.1(2065) 02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:WAIT_CAP->WAIT_CAP 02:21:02: DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP 02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:SSP-CAP EXCHANGED sta te:WAIT_CAP 02:21:02: DLSw: dtp_action_k() cap xchged for peer 190.10.1.1(2065) 02:21:02: DLSw: closing read pipe tcp connection for peer 190.10.1.1(2065) 02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:WAIT_CAP->PCONN_WT 02:21:02: DLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_W T 02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:TCP-PEER CONNECTED st ate:PCONN_WT 02:21:02: DLSw: dtp_action_m() peer connected for peer 190.10.1.1(2065) 02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:PCONN_WT->CONNECT 02:21:02: DLSw: dlsw_tcpd_fini() for peer 190.10.1.1(2065) 02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:ADMIN-CLOSE CONNECTIO N state:CONNECT 02:21:02: DLSw: dtp_action_b() close connection for peer 190.10.1.1(2065) 02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:CONNECT->DISCONN 02:21:03: DLSw: freeing 190.10.1.1 The workaround for this problem is to ensure that both sides of the DLSw connection view the other peers in a consistent numerical order. Instead of translating to 190.10.1.0/24, you need to translate to an IP address higher than 198.100.1.10, such as 199.100.1.0/24. This way the local peer on the green_bay router will always be the higher of the two peers, even through NAT translations. A quicker workaround is to add a loopback interface to the harms_co router that is lower then 190.10.1.1, and making this the new local peer. For example, you can add a loopback interface with the IP address of 100.100.1.1 and make this the new local peer, as done in Example 15-26. Example 15-26 Configuring a Loopback Interface as the Local Peer
dlsw local-peer peer-id 100.100.1.1 promiscuous dlsw bridge-group 1 ! interface Loopback20 ip address 100.100.1.1 255.255.255.0 Now, you can add a new remote peer to the green_bay router pointing at 100.100.1.1, and the DLSw peer will connect through a NAT translation. |
| < Free Open Study > |