RE: DLSW and passthru

From: simon hart (simon.hart@btinternet.com)
Date: Wed May 18 2005 - 03:35:44 GMT-3


Bob,

As I understand it, using the pass-thru statement determines whether the
transport mechanism to the remote peer on Frame Relay will be either Direct
or DLSW lite.
This is peculiar to Frame Relay.
If you were conducting direct encapsulation on say HDLC, then the pass-thru
statement would be meaningless - because HDLC does not support DLSW-lite -
therefore everything is passed forward anyway.

Direct Encapsulation

1. dlsw remote-peer 0 frame-relay interface serial 0/0 513 pass-thru
2. dlsw frame map dlsw 513 broadcast

Now these two statements together ensure that the traffic is sent with no
local acknowledgements - hence pass through.

DLSW Lite

1. dlsw remote-peer 0 frame-relay interface serial 0/0 513
2. dlsw frame map llc2 513 broadcast

Now there will be local acknowledgement, hence DLSW lite.

The only 'coding' difference between the two methods is the addition of the
pass-thru statement. By adding this you are forcing the router to forward
on llc2 to the distant end. And with each method you need to tell frame
relay how to encapsulate. If you use the wrong encapsulation method it will
not work.

Lastly - I would suggest that the CCIE bootcamp manual is incorrect.

HTH

Simon

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Bob Nelson
Sent: 18 May 2005 02:38
To: ccielab@groupstudy.com
Subject: DLSW and passthru

All:

I have searched the archives on this site and still do not have a good
handle on this issue. Can someone clarify this?

What I have researched:

1. TCP and LLC2 encapsulation have local acknowledgement and reliable
transport
2. FST and Direct do not have either local acknowledgement or reliable
transport.
         Sources: Solie - CCIE Practical Studies Vol 1 page 898 - Cisco
DLSw+ Design and Implementation Guide - pages 12-14

Statements in documentation that confuse me:
    Cisco IOS Bridging and IBM Networking Guide page BC-291 (under the
Direct configuration heading)
          dlsw remote-peer 0 frame-relay interface serial 0/1 pass-thru
         "Specifying the pass-thru option configures the router so that the
traffic will not be locally acknowledged
         (DLSw+ normally locally acknowledges traffic to keep traffic on the
WAN to a minimum)"

    Question 1 - Why do we need the pass-thru option here since by default
Direct encapsulation does not
     perform local acknowledgement. (see #2 above)

    Cisco DLSw+ Design and Implementation Guide - pages 12-14 (Advanced
Configuration Section)
        dlsw remote-peer 0 frame-relay interface serial 01 33 pass-thru
        int s1
        frame-relay map dlsw 33
        "In this example, data-link connection identifier (DLCI) 33 on
serial interface 1 will be used to transport DLSw+ traffic.
        Specifying pass-thru implies that the traffic is not locally
acknowledged. Leaving pass-thru off will cause the
        traffic to be locally acknowledged, which means it is transported in
LLC2 to ensure reliable delivery."

    Question 2 - Again, why specify pass-thru when Direct encapsulation does
not do local acknowledgment anyway?
    Additionally, how can leaving pass-through off magically make this
configuration transport packets using LLC2
    without changing the frame-relay map statement from dlsw to frame-relay
map llc2 33?

    A CCIE bootcamp student manual
        dlsw remote-peer 0 frame-relay interface 0/1 201 pass-thru
        "The pass-thru option can be added to other remote-peer methods as
well.
        This will prevent the local acknowledgements and keepalives from
going across the WAN"

Question 3 - My understanding of the pass-thru is that this will not perform
local acknowledgement and
will pass both the acknowledgements and keepalives end-to-end. Is this what
pass-thru actually does or
does it prevent local acknowledgements? Additionally, why do we need this
if according to Cisco, Direct
encapsulation does not support local acknowledgements and keepalives are
end-to-end.

Thanks,

Bob



This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:11:58 GMT-3