From: John Neiberger (neiby@xxxxxxxxxx)
Date: Thu Apr 11 2002 - 19:01:46 GMT-3
That document is incorrect. I currently have a TAC case
(documentation change request) open with them. I figured they
would have fixed it by now since they've known about it for
over a week. :-)
John
---- On Thu, 11 Apr 2002, Jeongwoo Park (jpark@wams.com) wrote:
> Jason and Guys,
> According to this link,
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/
121cgcr/ibm_
> c/bcprt2/bcddlsw.htm#xtocid1133246
> "Dlsw remote-peer 0 frame-relay interface serial 0 100 pass-
thru" was
> configured with 'frame-relay map llc2 100'
>
> Should it have been configured with 'frame-relay map dlsw
100'?
>
> JP
>
> -----Original Message-----
> From: Jason Sinclair [mailto:sinclairj@powertel.com.au]
> Sent: Thursday, March 14, 2002 2:36 PM
> To: 'Narvaez, Pablo'; Jason Sinclair; A Yigit Zorlu; Bob
Sinclair
> Cc: ccielab@groupstudy.com
> Subject: RE: DLSW direct encaps
>
> Hickito,
>
> For direct encaps it is not the RIF that is passed-thru it is
that the
> LLC2
> frame is not locallly-acked and is acked via the remote end.
Now when
> talking about mapping the rules are as follows:
>
> When using direct
>
> Dlsw remote-peer 0 frame-relay interface serial 0 100 pass-
thru #####
> must
> use frame-relay map dlsw 100
>
> With lite
>
> Dlsw remote-peer frame-relay interface serial 0 100 ########
must use
> frame-relay map llc2 100
>
> This is because when using light the data is reliably
transported in
> LLC2.
> With direct encaps it is transported via DLSW transport.
>
> Let me know if you need more info.
>
> Cheers,
>
>
> Jason Sinclair
> Manager, Network Support Group
> POWERTEL
> Ground Level, 55 Clarence Street,
> SYDNEY NSW 2000
> AUSTRALIA
> office: + 61 2 8264 3820
> mobile: + 61 416 105 858
> * sinclairj@powertel.com.au
>
>
>
> -----Original Message-----
> From: Narvaez, Pablo
[mailto:Pablo.Narvaez@getronics.com]
> Sent: Friday, 15 March 2002 04:30
> To: Jason Sinclair; A Yigit Zorlu; Bob
Sinclair
> Cc: ccielab@groupstudy.com
> Subject: RE: DLSW direct encaps
>
> Hey Guys, I was looking at the posts and
couldn't get a
> clear idea of DLSw Direct encap y Lite encap ..
>
> I understand that Lite does local ack whereas
Direct encap
> let the RIF pass thru the link, right? ...
>
> Now, regarding the configuration please correct
me if wrong:
>
> Direct encap:
> dlsw local-peer peer-id 1.1.1.1
> dlsw remote-peer 0 frame-relay interface serial
0 100
> pass-thru
>
> int ser 0
> ip add 1.1.1.2 255.255.255.0
> frame-relay map llc2 100 brodcast
>
>
> Direct encap:
> dlsw local-peer peer-id 1.1.1.1
> dlsw remote-peer 0 frame-relay interface serial
0 100
>
> int ser 0
> ip add 1.1.1.2 255.255.255.0
> frame-relay map llc2 100 brodcast
>
> Is it that the only one difference between
these two encap
> modes is the keyword "pass-thru" in the end of the remote-peer
> statement? ...
>
> Aside from that, I have the option to use in
the end of the
> remote-peer the keyword "rif-pass-thru"? what is the
difference
> between "pass-thru" and "rif-pass-thru"? which
should I use
> to accomplish Direct and Lite encap?
>
> And one more thing, in the interface I can use
either:
> frame-relay map llc2 or frame-relay dlsw ....
what is the
> "fr map dlsw" command for? and when should I use it? ...
>
>
> Thanks in advance!!!
>
> Cheers,
>
> -hockito-
>
>
> -----Original Message-----
> From: Jason Sinclair
[mailto:sinclairj@powertel.com.au]
> Sent: Lunes, 11 de Marzo de 2002 05:02 p.m.
> To: 'A Yigit Zorlu'; Jason Sinclair; 'Bob
Sinclair'
> Cc: ccielab@groupstudy.com
> Subject: RE: DLSW direct encaps
>
>
> Yigit,
>
> You use it for the local-peer. Let's say you
have an address
> on your token
> ring, loopback and serial int. You must use the
local-peer
> peer-id with the
> address of the serial int NOT the loop or the
token. I have
> also verified
> this behaviour with Cisco and they have
concurred with these
> findings. I
> believe they are updating the doco
appropriately.
>
> Regards,
>
> Jason Sinclair
> Manager, Network Support Group
> POWERTEL
> Ground Level, 55 Clarence Street,
> SYDNEY NSW 2000
> AUSTRALIA
> office: + 61 2 8264 3820
> mobile: + 61 416 105 858
> * sinclairj@powertel.com.au
>
>
>
> -----Original Message-----
> From: A Yigit Zorlu
[mailto:alec_cisco@yahoo.com]
> Sent: Monday, 11 March 2002 17:04
> To: 'Jason Sinclair'; 'Bob Sinclair'
> Cc: ccielab@groupstudy.com
> Subject: RE: DLSW direct encaps
>
> Jason,
>
> I am confused. Where do you use ip
address in direct
> encapsulation ?
>
> Please check :
> o Dlsw local-peer
> o dlsw remote-peer 0 frame-relay
interface
> serial 0 100
> pass-thru
> o interface serial 0
> o frame-relay map dlsw 100 br
>
> Yigit
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]On Behalf
> Of
> Jason Sinclair
> Sent: Monday, March 11, 2002 3:15 AM
> To: 'Bob Sinclair'; Jason Sinclair
> Cc: ccielab@groupstudy.com
> Subject: RE: DLSW direct encaps
>
>
> Bob,
>
> Direct must be point to point. When
using direct you
> must also use
> the IP
> address on the serial int NOT a
loopback or a
> token/ether, etc. I am
> not
> sure why, but from my testing the
remote side must
> ack the frames
> and thus
> when you use any int that is not the
directly
> connected int, the L2
> frame is
> then routed to the next int. That is
also why only
> p2p works I
> guess!
> Remember with DLSW Lite this does not
matter as the
> frame is locally
> acknowledged. This is only an issue
when using the
> pass-thru
> command.
>
> I have some dynamic peer stuff that
works. Basically
> dynamic peer
> circuits
> and the peer connection are only
brought up when
> there is traffic
> destined
> for the remote side (I guess that is
fairly
> obvious). I have had
> success
> doing this when using a dest-mac
statement under the
> remote-peer as
> you can
> better control the dynamic peer. Some
configs are as
> follows which
> create a
> host and a FEP and also two DLSW
routers runnning
> dynamic over HDLC.
> Nothing
> fancy, I am not using loopbacks just
the serial
> ints.
>
> When you start it up the peers will
connect and 2
> circuits will
> establish.
> If you shut the token on HostA, the
circuits will
> drop and after 20
> minutes
> the peers will disconnect. You can drop
this timer
> if that is too
> long. Also
> as I have specified the dest-mac, the
peers will
> only establish for
> this
> address as dynamic peers only establish
after all
> filter rules are
> met.
>
>
> Also remember to bit-swap the mac
addresses on the
> host or FEP if
> you are
> doing token to ether as you are
statically defining
> the remote mac
> and dlsw
> will not swap it for you in this
instance.
>
> Let me know if you have any trouble
using this or
> have other DLSW
> questions.
> I am at work right now and can't access
my home lab,
> but if you have
> any
> problems I will re-create tonight. This
is all from
> the top of my
> head at
> the moment!!
>
>
>
>
>
>
> HostA-------tokenring---------DLSWA--------serial--------
DLSWB--------tokenr
> ing----------FEP
>
>
> HostA (PU2)
> dspu host PU2 xid-snd 01712345 rmac
4000.1111.0001
> rsap 4 lsap 4
> retry-timeout 5
> !
> dspu host PU3 xid-snd 01712345 rmac
4000.1111.0001
> rsap 8 lsap 8
> retry-timeout 5
> !
> interface TokenRing0
> mac-address 4000.3000.0002
> no ip address
> ring-speed 16
> dspu enable-host lsap 4
> dspu enable-host lsap 8
> dspu start PU2
> dspu start PU3
>
>
> DLSWA
> Dlsw local-peer peer-id 1.1.1.1
> Dlsw remote-peer 0 tcp 1.1.1.2 dynamic
inactivity 20
> dest-mac
> 4000.1111.0001
>
> !
> Int s0
> Ip address 1.1.1.1 255.255.255.252
>
>
> DLSWB
> Dlsw local-peer peer-id 1.1.1.2
promiscuous
> !
> int s0
> ip address 1.1.1.2 255.255.255.252
> clock rate 64000
>
>
> FEP(PU4)
> dspu pu PU2 xid-rcv 01712345
> !
> dspu pu PU3 xid-rcv 01712345
> !
> interface TokenRing0
> mac-address 4000.1111.0001
> no ip address
> ring-speed 16
> dspu enable-pu lsap 4
> dspu enable-pu lsap 8
>
> Cheers,
>
> Jason Sinclair
> Manager, Network Support Group
> POWERTEL
> Ground Level, 55 Clarence Street,
> SYDNEY NSW 2000
> AUSTRALIA
> office: + 61 2 8264 3820
> mobile: + 61 416 105 858
> * sinclairj@powertel.com.au
>
>
>
> -----Original Message---
--
> From: Bob Sinclair
> [mailto:bsin@erols.com]
> Sent: Monday, 11
March 2002 09:03
> To: Jason Sinclair
> Cc:
ccielab@groupstudy.com
> Subject: Re:
DLSW direct
> encaps
>
> Jason,
>
> Since you have some
experience with
> this, maybe you
> could
> confirm my understanding. Is it true
that direct
> encapsulation over
> frame
> relay is only point-point. I don't
mean subif type,
> but that if you
> had a
> hub and spoke configuration, one could
not do direct
> encap spoke to
> spoke.
> Does that sound right?
>
> Also, do you have a
working config
> for dynamic
> peers? I
> have not been able to get this to work
or to find a
> good example.
>
> Thanks
>
> ----- Original Message -
----
> From: "Jason Sinclair"
> <sinclairj@powertel.com.au>
> To:
<ccielab@groupstudy.com>
> Sent: Sunday, March 10,
2002 6:24 PM
> Subject: DLSW direct
encaps
>
>
> > All,
> >
> > FYI - direct
encapsulation over
> frame relay with
> IETF does
> not work in any
> > version of IOS from
12.0 - 12.2
> (don't know about
> before).
> It works fine
> > with Cisco encaps
however. I spent
> three days
> playing with
> this and in the
> > end using a frame
analyser and
> debug frame packet
> you see
> that DLSW
> > manipulates the IETF
frame to the
> point where it
> has an
> "ILLEGA:" value in
> > it. Just thought this
might be
> interesting to
> someone.
> >
> > Regards,
> >
> > PS - I have the debug
output if
> anyone wants it.
> >
> > Jason Sinclair
> > Manager, Network
Support Group
> > POWERTEL
> > Ground Level, 55
Clarence Street,
> > SYDNEY NSW 2000
> > AUSTRALIA
> > office: + 61 2 8264
3820
> > mobile: + 61 416 105
858
> > *
sinclairj@powertel.com.au
> >
> >
> >
> >
> >
>
>
>
****************************************************************
******
> > PowerTel Limited,
winners of
> > Broadband Wholesale
Carrier of the
> year,
> CommsWorld
> Telecomms Awards 2001
> > Best Emerging Telco,
Australian
> Telecom Awards
> 2001
> >
> >
>
>
>
****************************************************************
******
> > This email (including
all
> attachments) is intended
> solely
> for the named
> > addressee. It is
confidential and
> may contain
> commercially
> sensitive
> > information. If you
receive it in
> error, please
> let us
> know by reply email,
> > delete it from your
system and
> destroy any copies.
> >
> > This email is also
subject to
> copyright. No part
> of it
> should be reproduced,
> > adapted or
transmitted without the
> prior written
> consent
> of the copyright owner.
> >
> > Emails may be
interfered with, may
> contain
> computer
> viruses or other defects
> > and may not be
successfully
> replicated on other
> systems.
> We give no
> > warranties in
relation to these
> matters. If you
> have any
> doubts about
> > the authenticity of
an email
> purportedly sent by
> us,
> please contact us
> > immediately.
> >
> >
>
>
>
****************************************************************
******
> >
>
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:58:05 GMT-3