From: Rick Burts (burts@xxxxxxxxxxxxxx)
Date: Mon Jan 22 2001 - 15:50:13 GMT-3
Vikas
I think it would help to have a good understanding of the
difference between promiscuous peering and peer-on-demand
(which depends on the promiscuous keyword but is more than
just promiscuous). Promiscuous peering is that one router
includes on its local-peer the promiscuous capability and
the other router includes a specific remote-peer statement.
In promiscuous peering the DLSw session is set up when the
router with the specific remote-peer statement initializes.
This peering is set up before there is any end station
traffic or any attempt to establish DLSw circuits.
Peer-on-demand is more what you are describing and is
dependent on traffic looking for a remote destination to
find the remote peer and establish DLSw peering session.
Rick
Rick Burts, CCSI CCIE 4615 burts@mentortech.com
Mentor Technologies 240-568-6500 ext 6652
133 National Business Parkway 240-568-6515 fax
Annapolis Junction, Md 20701
Chesapeake Network Solutions has now become Mentor Technologies.
Mentor Technologies is a certified Cisco Training Partner and also
a Cisco Professional Services partner.
We offer most of the Cisco training courses.
We also offer training in Checkpoint Firewall software and
Fore Systems (now Marconi) and MicroMuse.
We also provide network consulting services including
design, management, and problem solving.
We have 24 CCIEs on our staff.
On Sun, 21 Jan 2001, Vikas Gupta wrote:
> Fred,
>
> How would R4 and R5 initiate first session when they
> don't have any explicit remote-peer statements, they
> will only accept connections (not initiate) and then
> dlsw traffic can pass thru once the connection is
> made. In this case the very first session has to be
> from R2. Let's say any SNA device on R5 or R4 is
> trying to connect to a SNA host anywhere in the
> network and let us assume that there is nothing in the
> Dlsw cache, the first thing Dlsw will do is send
> explorers to all remote-peers but in this case there
> are no remote-peer statements configured and hence
> explorers will not be sent anywhere. If the SNA device
> would have been on R2 side , explorers will be sent to
> R4 and R5 as they are defined in remote-peer
> statements.
>
> Atleast this is my understanding. Any comments??
>
> Vikas
>
> --- Fred Ingham <fningham@worldnet.att.net> wrote:
> > Agree on source-bridge ring group statement
> > unnecessary on Ethernet
> > routers. Disagree on which routers can initiate
> > sessions. Remote peer
> > statement only needs to be done on one side. R4 and
> > R5 can initiate
> > sessions to R2. R4 will not be able to initiate
> > session with R5 and
> > vice versa.
> >
> > Fred.
> >
> > "Hebert, Cory J (cory.hebert@wcom.com)" wrote:
> > >
> > > Tin,
> > >
> > > You wont need to use the statement "source-bridge
> > ring-group 200" on R5
> > > if there are no token ring interfaces present.
> > >
> > > The only thing with your configuration that I
> > think might cause a problem
> > > is that if R4 and R5 needed to initiate sessions,
> > they have no remote-peer
> > > statements to do so (that is, of course, assuming
> > they would be initiating
> > > sessions). The only way your configs would work is
> > only if hosts on the
> > > token ring segment of R2 were to initiate the
> > sessions (because R2 has the
> > > explicit remote peer statements).
> > >
> > > Hope this helps...
> > >
> > > Cory
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com
> > [mailto:nobody@groupstudy.com]On Behalf Of
> > > BUI, TIN T (SBCSI)
> > > Sent: Saturday, January 20, 2001 10:22 PM
> > > To: 'Ccielab (E-mail)'
> > > Subject: Another dlsw question
> > >
> > > I posted this a couple of weeks ago and everyone
> > seem to think my
> > > configuration would work, but after reading some
> > more, I think I'm missing
> > > the statement "source-bridge ring-group 200" on
> > R5. Reason is that from R5
> > > to R2 we are going from ethernet to Token ring.
> > Did everyone miss this or
> > > would this configuration actually work? I don't
> > have the correct equipment
> > > to test out this configuration so that's why I'm
> > asking. thanks
> > >
> > > Scenario: Configure R2, R4, and R5 for DLSW.
> > Configure filter so that the
> > > only protocol that is transported via dlsw is
> > netbios and apply this filter
> > > to R2 remote peer statements.
> > >
> > > R5:
> > > dlsw local-peer peer-id 150.100.5.5 group 100
> > promiscuous
> > > dlsw bridge-group 1
> > > int loopback 0
> > > ip address 150.100.5.5 255.255.255.0
> > > int e0
> > > bridge-group 1
> > > bridge 1 protocol ieee
> > >
> > > R2:
> > > source-bridge ring-group 200
> > > dlsw local-peer peer-id 150.100.2.2 group 100
> > border
> > > dlsw remote-peer 0 tcp 150.100.4.4
> > lsap-output-list 200
> > > dlsw remote-peer 0 tcp 150.100.5.5
> > lsap-output-list 200
> > > int loopback 0
> > > ip address 150.100.2.2 255.255.255.0
> > > int token0
> > > source-bridge 25 1 200
> > > source-bridge spanning
> > > access-list 200 permit 0xF0F0 0x0101
> > >
> > > R4:
> > > source-bridge ring-group 400
> > > dlsw local-peer peer-id 150.100.4.4 group 100
> > promiscuous
> > > int loopback 0
> > > ip address 150.100.4.4 255.255.255.0
> > > int token0
> > > source-bridge 26 1 400
> > > source-bridge spanning
> > >
> > >
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:27:39 GMT-3