From: Williams, Glenn (WILLIAMSG@xxxxxxxxxxxxx)
Date: Tue Apr 16 2002 - 09:23:38 GMT-3
Hi,
Got a chance to play with this one. I noted that Jonghwan said:
"but dlsw peer connected cocstantly one by one. ex. r1 connect r2 first, and
r1 connect r3 as soon as disconnect r2. in this time, r1 disconnect r3
because inactivity, then reconnect r2, an so on..."
Well initially I had the same problem. I think the reason R1 connects to R3
is because it sees that connection to R2 is down (even though it is only
resting because there is no traffic) and because R3 is backup for R2 it goes
active. Not quite sure why R2 goes active again when R3 times out. R3 can
time out by dynamic inactivity or linger. But I found what seems to keep
the whole thing quiet. It seems that R3, even though it is backup to R2
needs to know that R2 is allowed to have no activity and it seems to be
resolved by adding the "circuit-inactivity" parameter onto the definition of
R3 when creating it on R1. In other words this lets the backup connection
go to a resting state when there is no traffic there either. So it seems
that R3 can know that quiet time is allowed and everything is ok.
Also in this setup we can remove any dynamic inactivity statements from
everyone except the definition of R2 on R1. So only R1 needs to have it.
r1
dlsw local-peer peer-id 1.1.1.1
dlsw remote-peer 0 tcp 2.2.2.2 dynamic inactivity 1 keepalive 0 timeout 30
dlsw remote-peer 0 tcp 3.3.3.3 backup-peer 2.2.2.2 linger 1 keepalive 0
timeout 30 circuit-inactivity 1
dlsw bridge-group 1
r2
dlsw local-peer peer-id 2.2.2.2 passive
dlsw remote-peer 0 tcp 1.1.1.1 keepalive 0 timeout 30
dlsw bridge-group 1
r3
dlsw local-peer peer-id 3.3.3.3 passive
dlsw remote-peer 0 tcp 1.1.1.1 keepalive 0 timeout 30
dlsw bridge-group 1
BTW, I also set the retry "timeout 30" only because my hope is that
something does not retry when the line is trying to go quiet. Probably does
not make that much difference.
This still needs to be played with a little more but it was something that
seemed to at least stop the bouncing.
GW
-----Original Message-----
From: Lupi, Guy [mailto:Guy.Lupi@eurekaggn.com]
Sent: Monday, April 15, 2002 11:37 AM
To: Williams, Glenn; 'Jonghwan Hyon'
Cc: 'ccielab@groupstudy.com'
Subject: RE: dslw backup peer(again) - help!
Hmmm, maybe your right then. I always thought that the timeout disconnected
a peer at the end, maybe I am incorrect. I will definitely put this in the
lab this weekend and see what the deal is.
-----Original Message-----
From: Williams, Glenn [mailto:WILLIAMSG@PANASONIC.COM]
Sent: Monday, April 15, 2002 12:20 PM
To: Lupi, Guy; 'Jonghwan Hyon'
Cc: 'ccielab@groupstudy.com'
Subject: RE: dslw backup peer(again) - help!
I don't know. It is a guess. But according to CCO, the timeout means:
"Configures the retransmit time limit for TCP. The valid range is 5 to 1200
seconds. The default is 90 seconds."
When I read that it seems like retransmitting something already sent before
giving up, not holding a connection open.. But I never tried it
I was hoping that even though R2 did not initiate, it could still close the
connection by the dynamic inactivity timer. So I need to test. Guess I
still don't fully know DLSW.
GW
-----Original Message-----
From: Lupi, Guy [mailto:Guy.Lupi@eurekaggn.com]
Sent: Monday, April 15, 2002 11:07 AM
To: Williams, Glenn; 'Jonghwan Hyon'
Cc: 'ccielab@groupstudy.com'
Subject: RE: dslw backup peer(again) - help!
Would the dynamic statement on r2 and r3 do anything though? With the
passive command the router does not initiate any peering sessions, but it
will accept them from this neighbor if the neighbor initiates it, so I don't
see the use of the dynamic statement on them or on r1's remote peer for r2.
Using the timeout and keepalives should cause r1 to disconnect r2 after a
period of 90 seconds of inactivity, as far as I understand it. This is
definitely one for the lab this weekend.
-----Original Message-----
From: Williams, Glenn [mailto:WILLIAMSG@PANASONIC.COM]
Sent: Monday, April 15, 2002 12:01 PM
To: Lupi, Guy; 'Jonghwan Hyon'
Cc: 'ccielab@groupstudy.com'
Subject: RE: dslw backup peer(again) - help!
Guys,
According to the requirement, this is what I would try. Not near routers so
is a best guess.
1. make the dlsw connection between ethernet on R1 and R2, R3. prefer the R2
connection and if R2 connection is failed then connect R3. (may not
permit use promiscuous option)
2. if thers is no traffic on the dlsw connection, then disconnect, and if
the traffic occur again, then reconnect.(i think that it refer to dynamic
option)
r1
dlsw local-peer peer-id 1.1.1.1
dlsw remote-peer 0 tcp 2.2.2.2 dynamic inactivity 5 keepalive 0
dlsw remote-peer 0 tcp 3.3.3.3 backup-peer 2.2.2.2 linger 1 keepalive 0
dlsw bridge-group 1
r2
dlsw local-peer peer-id 2.2.2.2 passive
dlsw remote-peer 0 tcp 1.1.1.1 dynamic inactivity 5 keepalive 0
dlsw bridge-group 1
r3
dlsw local-peer peer-id 3.3.3.3 passive
dlsw remote-peer 0 tcp 1.1.1.1 dynamic inactivity 5 keepalive 0
dlsw bridge-group 1
-----Original Message-----
From: Lupi, Guy [mailto:Guy.Lupi@eurekaggn.com]
Sent: Monday, April 15, 2002 7:56 AM
To: 'Jonghwan Hyon'
Cc: 'ccielab@groupstudy.com'
Subject: RE: dslw backup peer(again) - help!
Don't worry about your english, my Korean is pretty rusty these days :). In
the following config, I think this would work assuming you can't use the
promiscous option. Does it happen to say which way the dynamic connection
should be? This is interesting. If r1 is the one sending all traffic, and
r2 and r3 don't have to initiate any connections, I would think the
following would work. R1 would contact r2 when there is traffic to send,
and if it couldn't reach r2 it would try r3. In either case, after 90
seconds of inactivity the peer should disconnect. This only works if r1 is
the initiator of the sessions though, in this config r2 and r3 could not
initiate sessions due to the passive option. I would have to put it up in
the lab to truly test it, perhaps one of the dlsw gurus could help us out on
this one? Note that you cannot use the promiscous option.
r1
r1
dlsw local-peer peer-id 1.1.1.1
dlsw remote-peer 0 tcp 2.2.2.2 keepalive 0 timeout 90
dlsw remote-peer 0 tcp 3.3.3.3 backup-peer 2.2.2.2 keepalive 0 timeout 90
dlsw bridge-group ???
r2
dlsw local-peer peer-id 2.2.2.2 passive
dlsw remote-peer 0 tcp 1.1.1.1 keepalive 0 timeout 90
dlsw bridge-group ???
r3
dlsw local-peer peer-id 3.3.3.3 passive
dlsw remote-peer 0 tcp 1.1.1.1 keepalive 0 timeout 90
dlsw bridge-group ???
-----Original Message-----
From: Jonghwan Hyon [mailto:jerry@datacraft-korea.com]
Sent: Sunday, April 14, 2002 9:25 PM
To: Lupi, Guy
Subject: Re: dslw backup peer(again) - help!
the requirement is that
1. make the dlsw connection between ethernet on R1 and R2, R3. prefer the R2
connection and if R2 connection is failed then connect R3. (may not
permit use promiscuous option)
2. if thers is no traffic on the dlsw connection, then disconnect, and if
the traffic occur again, then reconnect.(i think that it refer to dynamic
option)
3. conclusion : use dlsw dynamic option with dynamic option!
sorry for my poor english!
regards,
----- Original Message -----
From: "Lupi, Guy" <Guy.Lupi@eurekaggn.com>
To: "'Jonghwan Hyon'" <jerry@datacraft-korea.com>; <ccielab@groupstudy.com>
Sent: Monday, April 15, 2002 3:44 AM
Subject: RE: dslw backup peer(again) - help!
> I'm not sure that this configuration will work as is, what are you trying
to
> solve, what is the exact requirement? That would help us approach it
> better. The reason r1 keeps connecting the peer at r2 is because you have
a
> remote peer statement for it, if you make r1 passive in the local peer
> statement it won't attempt to make connections on it's own, but that would
> not fulfill what I think is the other requirement. As I said, post the
> exact requirement and maybe we can work through it.
>
> ~-----Original Message-----
> ~From: Jonghwan Hyon [mailto:jerry@datacraft-korea.com]
> ~Sent: Sunday, April 14, 2002 2:11 PM
> ~To: ccielab@groupstudy.com
> ~Subject: dslw backup peer(again) - help!
> ~
> ~
> ~hi, group
> ~
> ~i have a 3 router, anmed r1, r2, and r3.
> ~i want to configure that r1 connect to r2 and r3 as dynamic,
> ~and r3 as a backup peer for r3.
> ~(assume that there is no routing problem!)
> ~
> ~r1
> ~ dlsw local-peer peer-id 1.1.1.1
> ~ dlsw remote-peer 0 tcp 2.2.2.2 keepalive 0
> ~ dlsw remote-peer 0 tcp 3.3.3.3 backup-peer 2.2.2.2 linger 5
> ~keepalive 0
> ~
> ~r2
> ~ dlsw local-peer peer-id 2.2.2.2
> ~ dlsw remote-peer 0 tcp 1.1.1.1 dynamic inactivity 7
> ~
> ~r3
> ~ dlsw local-peer peer-id 3.3.3.3
> ~ dlsw remote-peer 0 tcp 1.1.1.1 dynamic inactivity 7
> ~
> ~but dlsw peer connected cocstantly one by one.
> ~ex. r1 connect r2 first, and r1 connect r3 as soon as disconnect r2.
> ~in this time, r1 disconnect r3 because inactivity, then
> ~reconnect r2, an so on...
> ~
> ~what's the matter? give me the way to complete this, please!
> ~
> ~best regards,
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:58:09 GMT-3