From: Terrence Rouse \(trouse\) (trouse@cisco.com)
Date: Wed Aug 11 2004 - 11:26:06 GMT-3
Hi john,
Thanks for the reply, but I beg to differ. I do understand that scenerio
and it is slighly different, in the sense that the NAT router is between the
two DLSW peers and translating both IP address on both sides so that each
thinks it is the lower IP address and drops the connection. In my scenerio
the NAT router is one of the DLSW peers and the therefore there will still
only be one router with a lower ip address and thus only one router will
drop the session and NOT both as in reference CCO doc. Lets ignore the
solution for now as I know it fixes both of these problem b/c it ignores ALL
DLSW traffic in NAT'ing. I think the problem is that the LOCAL PEER ID must
match the the received packed from the remote peer (R8). If I change the
local peer id to 10.5.5.5 on R5 the NAT does not break anything. But as
long as the LOCAL peer id is 10.50.50.1 and R5 is responding to traffic sent
from 10.5.5.5 (which does not match the LOCAL peer ID). The DLSW peer
cannot be established. Notice that in my scenerio the DLSW peer never make
it to CAP_EXC nor CONNECT so it is a more fundamental problem.
In the CCO doc states the following:
Debugs in Routers A and C show that the connection gets past CAP_EXG, and
reaches the CONNECT state. The Cisco implementation of DLSw specifies that,
instead of using two TCP sessions between Router A and Router C, one TCP
connection is dropped when a connection is established between the two
routers.
Any other comments.
Thanks
BTW, I was not at networker but I will be next time. Thanks again
-----Original Message-----
From: john matijevic [mailto:matijevi@bellsouth.net]
Sent: Wednesday, August 11, 2004 12:09 AM
To: trouse@cisco.com; ccielab@groupstudy.com
Subject: RE: CCIE PRACTICE LABS (cisco press) lab1
Hello Trouse,
Were you at networkers? Name is familiar.
Anyways I have labbed up this lab and just about completed.
19:55:04: DLSw: START-TPFSM (peer 10.8.8.8(2065)): event:DLX-KEEPALIVE REQ
state :CONNECT
19:55:04: DLSw: dtp_action_q() keepalive request from peer
10.8.8.8(2065)
19:55:04: DLSw: Keepalive Response sent to peer 10.8.8.8(2065))
19:55:04: DLSw: END-TPFSM (peer 10.8.8.8(2065)): state:CONNECT->CONNECT
19:55:04: DLSw: dlsw_tcpd_fini() for peer 10.8.8.8(2065)
19:55:04: DLSw: tcp fini closing connection for peer 10.8.8.8(2065)
19:55:04: DLSw: START-TPFSM (peer 10.8.8.8(2065)): event:ADMIN-CLOSE
CONNECTION state:CONNECT
19:55:04: DLSw: dtp_action_b() close connection for peer 10.8.8.8(2065)
19:55:04: DLSw: END-TPFSM (peer 10.8.8.8(2065)): state:CONNECT->DISCONN
Actually, there is only 1 dlsw session between the 2 routers. We only have 2
routers that are involved in this scenario. So what happened is that nat
broke the session because of the ip address translation. R5 is configured
for the local-peer id as 10.50.50.1 and the remote-peer connection as
10.8.8.8. Without nat there is no drop session.
r5#sh dlsw peer
Peers: state pkts_rx pkts_tx type drops ckts TCP
upti
TCP 10.8.8.8 DISCONN 0 0 conf 0 0 -
Total number of connected peers: 0
Total number of connections: 0
In conclusion, what is happening is that both connections are dropping
because both routers think they have the higher ip address, so they drop
both of the connections, and the result is a disconnect. The solution
excludes dlsw from being natted. I have found the following document very
helpful in seeing this issue.
http://www.cisco.com/en/US/tech/tk331/tk336/technologies_tech_note09186a
0080093db6.shtml
Please visit my forum on my website to discuss any other issues with these
practice labs, as I am giving support for them. I hope that helps you.
Sincerely,
John Matijevic, CCIE #13254, MCSE, CNE, CCEA
Network Consultant
Hablo Espanol
305-321-6232
http://home.bellsouth.net/p/PWP-CCIE
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
trouse@cisco.com
Sent: Tuesday, August 10, 2004 11:36 PM
To: ccielab@groupstudy.com
Subject: CCIE PRACTICE LABS (cisco press) lab1
Just want to make sure I am not crazy. I am aware of the issues with
NAT and DLSW. Where the DLSW peers are both dropped their tcp session
because of IP address. However, I do not think this is a problem for this
lab one. B/C with or without nat only one tcp session is dropped so DLSW
peer is able to function under these conditions and SHOULD be okay. But
they describe this problem in the solution. While the solution does fix any
NAT/DLSW issues, I think the actual problem in this scenerio is that the
local peer-id on R5 no longer matches what R8 is using once it is NAT'ed.
R8 will use 10.5.5.5 but the local peer-id is 10.50.50.1. I capture the
following debug.
1w4d: DLSw: START-TPFSM (peer 10.8.8.8(2065)): event:ADMIN-OPEN CONNECTION
state:DISCONN
1w4d: DLSw: dtp_action_a() attempting to connect peer 10.8.8.8(2065)
1w4d: DLSw: END-TPFSM (peer 10.8.8.8(2065)): state:DISCONN->WAIT_WR
1w4d: DLSw: Async Open Callback 10.8.8.8(2065) -> 11024
1w4d: DLSw: START-TPFSM (peer 10.8.8.8(2065)): event:TCP-WR PIPE OPENED
state:WAIT_WR
1w4d: DLSw: dtp_action_f() start read open timer for peer 10.8.8.8(2065)
1w4d: DLSw: END-TPFSM (peer 10.8.8.8(2065)): state:WAIT_WR->WAIT_RD
1w4d: DLSW: peer 10.8.8.8 using incorrect ip address 10.5.5.5 <====this is
the problem in my opinion, not the dropping of both peers as described.
1w4d: should match local-peer peer-id 10.50.50.1
1w4d: DLSw: dlsw_tcpd_fini() for peer 10.8.8.8(2065)
1w4d: DLSw: tcp fini closing connection for peer 10.8.8.8(2065)
1w4d: DLSw: START-TPFSM (peer 10.8.8.8(2065)): event:ADMIN-CLOSE CONNECTION
state:WAIT_RD
1w4d: DLSw: dtp_action_b() close connection for peer 10.8.8.8(2065)
1w4d: DLSw: END-TPFSM (peer 10.8.8.8(2065)): state:WAIT_RD->DISCONN
Can somone confirm or deny my analysis.
See sample lab here
http://www.ciscopress.com/content/images/1587051478/samplechapter/158705
1478content.pdf
Thanks
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:41 GMT-3