Configuring NTP

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.