From: Terrence Rouse \(trouse\) (trouse@cisco.com)
Date: Wed Aug 11 2004 - 12:30:50 GMT-3
Yes you are right I did have the higher/lower ip address thing backwards.
Thanks.
But I think you missed my point if you don't focus on the CCO scenerio you
will see what I am saying. They never make it to CONNECT State, I guess you
have to set it up. But thanks again.
There is a difference b/w the NAT router being BETWEEN the peers and being
ON one of the peers. But I guess as long as you recognize an issue with
DLSW and NAT you should be okay either way b/c the recommend fix fixes
either issues. My scenerio (or the one in this lab) would be SIMILAR (or the
equivalent of) to doing the following when NAT is configure ON R5: (kind of
hard to explain over email)
R5:
Dlsw local-peer peer-id 10.50.50.1 promiscuous
R8:
Dlsw local peer peer-id 10.8.8.8
Dlsw remote-peer 0 tcp 10.5.5.5
This will never work and will never reach CONNECT state b/c the remote peer
id does not match the local peer id. This is the fundamentals of DLSW but
NAT introduced this problem. This is why changing the local peer-id on R5
to 10.5.5.5 works.
I am okay now. We can close this thread unless someone else has comments.
-----Original Message-----
From: john matijevic [mailto:matijevi@bellsouth.net]
Sent: Wednesday, August 11, 2004 10:59 AM
To: trouse@cisco.com; ccielab@groupstudy.com
Subject: RE: CCIE PRACTICE LABS (cisco press) lab1
Hello Trouse,
"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". Again from the document:
http://www.cisco.com/en/US/tech/tk331/tk336/technologies_tech_note09186a
0080093db6.shtml
"Problem
DLSw plus (DLSw+) peers establish a connection between Routers A and C, but
do not stay connected.
Router A thinks its DLSw TCP session is between itself (123.112.5.10) and
123.112.1.19, which is the Router C IP address once it goes through NAT.
Router A concludes that it has the higher IP address, so it thinks it must
tear down the TCP connection on its local port 2065.
Router C thinks its DLSw TCP session is between itself (172.10.1.1) and
123.112.5.10. Router C thinks it has the higher IP address and that it must
tear down the TCP connection on its local port 2065.
As a result, both TCP sessions are torn down, leaving the routers in a
DISCONNECT state." So its based on the higher IP address not the lower IP
address, as you had mentioned above.
So its not that each think it is the lower IP address and drops the
connection, it is the exact opposite.
You are saying that if you change the local peer address on R5 to a lower ip
address the NAT does not break anything and that is correct because now the
ip address is lower 10.5.5.5 is lower than 10.8.8.8. So that would be an
alternative solution to the problem, but would break earlier requirement
where it tells you to peer from VLAN4 interface of R5.
I hope I helped you understand better,
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: Terrence Rouse (trouse) [mailto:trouse@cisco.com]
Sent: Wednesday, August 11, 2004 10:26 AM
To: 'john matijevic'; ccielab@groupstudy.com
Subject: RE: CCIE PRACTICE LABS (cisco press) lab1
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