From: john matijevic (matijevi@bellsouth.net)
Date: Wed Aug 11 2004 - 11:58:55 GMT-3
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