From: Simon Baxter (Simon.Baxter@xxxxxxxxxxxxxx)
Date: Thu Dec 07 2000 - 00:34:54 GMT-3
cool.
sorted.
I'm happy!!
scary thing to be 4 days before the big day!!
-----Original Message-----
From: zhangxianqi [mailto:zhangxqi@gitc.com.cn]
Sent: Thursday, December 07, 2000 1:36 PM
To: Simon Baxter
Cc: ccielab@groupstudy.com
Subject: Re: More DLSW peer questions...
hi, Simon,
The Icanreach wont pass between on-demand-peer,If you want the Icanreach
information pass between peers,the peer must be full meshed.
Regards
----- Original Message -----
From: Simon Baxter <Simon.Baxter@au.logical.com>
To: Simon Baxter <Simon.Baxter@au.logical.com>; Wetherton, Warren
<warren.wetherton@csfb.com>; Justin Menga <Justin.Menga@computerland.co.nz>;
CCIE Group Study (E-mail) <ccielab@groupstudy.com>
Sent: Thursday, December 07, 2000 9:39 AM
Subject: RE: More DLSW peer questions...
> I also just tried this with
>
> ----BOT-----------4500-----------R1
> group70 grp70bdr grp80bdr
>
> and the icanreach stuff is only sent from a group-peer to it's border peer
-
> it's not sent to the neighbor border peer.
>
> ie
>
> BOT has a dlsw icanreach-mac, 4500 learns of it (unconfirm) but doesn't
pass
> it to R1 regardless of whether R1 is a grp70 peer or a grp80 bdr-peer.
>
> I guess once there's a station on either remote segment sending out
explorer
> frames the reachabilities/capabilities get passed???
>
> -----Original Message-----
> From: Simon Baxter
> Sent: Thursday, December 07, 2000 11:10 AM
> To: 'Wetherton, Warren'; Simon Baxter; Justin Menga; 'CCIE Group Study
> (E-mail)'
> Subject: RE: More DLSW peer questions...
>
>
> I gather this won't happen unless there's a canureach sent though...
>
> BOT-4500-R1
>
> *****************
> BOT#sh dlsw re
> DLSw Local MAC address reachability cache list
> Mac Addr status Loc. port rif
> 0009.d481.dbdf FOUND LOCAL TBridge-001 --no rif--
>
> DLSw Remote MAC address reachability cache list
> Mac Addr status Loc. peer
>
> DLSw Local NetBIOS Name reachability cache list
> NetBIOS Name status Loc. port rif
>
> DLSw Remote NetBIOS Name reachability cache list
> NetBIOS Name status Loc. peer
> *****************
> 4500#sh dlsw re
> DLSw Local MAC address reachability cache list
> Mac Addr status Loc. port rif
>
> DLSw Remote MAC address reachability cache list
> Mac Addr status Loc. peer
> 0009.d481.dbdf FOUND REMOTE 2.2.2.2(2065)
>
> DLSw Group MAC address reachability cache list
> Mac Addr Group
>
> DLSw Local NetBIOS Name reachability cache list
> NetBIOS Name status Loc. port rif
>
> DLSw Remote NetBIOS Name reachability cache list
> NetBIOS Name status Loc. peer
>
> DLSW Group NetBIOS Name reachability cache list
> NetBIOS Name Group
> ****************
> R1#sh dlsw re
> DLSw Local MAC address reachability cache list
> Mac Addr status Loc. port rif
>
> DLSw Remote MAC address reachability cache list
> Mac Addr status Loc. peer
>
> DLSw Local NetBIOS Name reachability cache list
> NetBIOS Name status Loc. port rif
>
> DLSw Remote NetBIOS Name reachability cache list
> NetBIOS Name status Loc. peer
>
> R1#
>
> ??
> -----Original Message-----
> From: Wetherton, Warren [mailto:warren.wetherton@csfb.com]
> Sent: Thursday, December 07, 2000 11:01 AM
> To: 'Simon Baxter'; Justin Menga
> Subject: RE: More DLSW peer questions...
>
>
> R2 is border - it will forward CUR to other borders and peers in its own
> group. R3 (remote peer) will recieve CUR and respond with ICR which is
then
> relayed back to R1. R1 will receive ICR and based on information in the
ICR
> will establish connection to R3 for frames to flow.
>
> > -----Original Message-----
> > From: Simon Baxter [SMTP:Simon.Baxter@au.logical.com]
> > Sent: Thursday, December 07, 2000 11:39 AM
> > To: Justin Menga; 'Wetherton, Warren'; Simon Baxter
> > Subject: RE: More DLSW peer questions...
> >
> > How will R1 initiate a connection? It won't actually establish a
peering
> > relationship with R3 will it? It doesn't have any of the remote peer's
> > details....
> >
> > -----Original Message-----
> > From: Justin Menga [mailto:Justin.Menga@computerland.co.nz]
> > Sent: Thursday, December 07, 2000 6:09 AM
> > To: 'Wetherton, Warren'; 'Simon Baxter'; Justin Menga
> > Subject: RE: More DLSW peer questions...
> >
> >
> > Hi,
> >
> >
> > If you have the following DLSW connections (physical topology is
> > irrelevant):
> >
> > R1-------------R2---------------R3
> >
> > You configure R2 as a border peer for group x. You define R1 and R3 as
> > promiscuous and belonging to group x, and define R2 as a configured peer
> > on
> > each router. On R2 you configure both peers.
> >
> > e.g.
> >
> > R1 (x.x.x.x):
> >
> > dlsw local-peer peer-id x.x.x.x group 10 promiscuous
> > dlsw remote-peer 0 tcp y.y.y.y
> >
> >
> > R2 (y.y.y.y):
> >
> > dlsw local-peer peer-id y.y.y.y group 10 border
> > dlsw remote-peer 0 tcp x.x.x.x
> > dlsw remote-peer 0 tcp z.z.z.z
> >
> > R3 (z.z.z.z):
> >
> > dlsw local-peer peer-id z.z.z.z group 10 promiscuous
> > dlsw remote-peer 0 tcp y.y.y.y
> >
> > If R1 needs to initiate a connection to R3 it can do so in this
> > configuration. Use show dlsw peers to confirm, the connection type on
R1
> > should be pod and on R3 should be prom.
> >
> > Regards,
> >
> > Justin Menga MCSE+I CCNP CCSE ASE
> > WAN Specialist
> > Computerland New Zealand
> > PO Box 3631, Auckland
> > DDI: (+64) 9 360 4864 Mobile: (+64) 25 349 599
> > mailto: justin.menga@computerland.co.nz
> >
> >
> > -----Original Message-----
> > From: Wetherton, Warren [mailto:warren.wetherton@csfb.com]
> > Sent: Wednesday, 6 December 2000 1:10 p.m.
> > To: 'Simon Baxter'; Justin Menga
> > Subject: RE: More DLSW peer questions...
> >
> >
> > I will take the Sydney lab in Feb -- be interested to hear of your
> > experiences. re the Dlsw peering, refer to the following url
> >
> > http://www.cisco.com/warp/public/697/1.html
> >
> > my understanding is
> >
> > 1. spokes still need to be promiscuous for on-demand to work
> > 2. border acts as hub to send CUR's and ICRs' between spokes and to
other
> > borders.
> > 3. return ICR from border to spoke contains sending DLSw peer address
> > allows
> > the on-demand peering to happen (must have promiscuous enabled on
spokes)
> >
> > hope this helps,
> > warren
> >
> > > -----Original Message-----
> > > From: Simon Baxter [SMTP:Simon.Baxter@au.logical.com]
> > > Sent: Wednesday, December 06, 2000 11:19 AM
> > > To: Justin Menga; 'Simon Baxter'; CCIE Group Study (E-mail)
> > > Subject: RE: More DLSW peer questions...
> > >
> > > Such as?
> > >
> > > dynamic peers still require configuration
> > > promisusous peers still require connection from configured peers
> > >
> > > aren't all these options a method of peering - albeit only from one
end?
> > >
> > > Is there no way for 2 spoke peers, only configured for peering with
> > their
> > > group border peer, to communicate without configuring any more on the
> > > spokes
> > > than :
> > >
> > > dlsw local peer x.x.x.x group 1
> > > dlsw remot peer 0 tcp x.x.x.x
> > >
> > >
> > > cheers...
> > >
> > >
> > > PS Justin, is this your 1st attempt? I'm in Sydney next Tues for my
> > > #2....hear the lab's changed a bit - and lawrence the proctor has been
> > > replaced with henry....
> > >
> > >
> > > Simon
> > >
> > > -----Original Message-----
> > > From: Justin Menga [mailto:Justin.Menga@computerland.co.nz]
> > > Sent: Tuesday, December 05, 2000 7:55 PM
> > > To: 'Simon Baxter'; CCIE Group Study (E-mail)
> > > Subject: RE: More DLSW peer questions...
> > >
> > >
> > > Peers within a group do not require full meshing. You can use the
> > > on-demand
> > > features to allow peers to peer with another within the group.
> > >
> > > -----Original Message-----
> > > From: Simon Baxter [mailto:Simon.Baxter@au.logical.com]
> > > Sent: Tuesday, December 05, 2000 8:13 PM
> > > To: CCIE Group Study (E-mail)
> > > Subject: More DLSW peer questions...
> > >
> > >
> > > Can the members of a peer group share resources via the border peer?
> > Or
> > > do
> > > all peers within a group have to be fully meshed??
> > >
> > >
> > >
> > > cheers!!
> > >
> > > (in advance)
> > >
> > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:25:59 GMT-3