Hi,
you are saying you have 3 routers connected to tokenring networks.
I assume you are saying 1 in the branch and 2 at the headend.
Can you clearify when you say "the first equipment start to down". Is this the dlsw peer or the dlsw circuits?
If my understanding is correct it should be the dlsw circuits. When you have a configuration like i think you have than you must configure on the headend the same virtual ring-group on both routers. you are using 150 on the promiscuous one and 200 on the other one.
In that case if both are connected to the same branch you will create problems in the dlsw reachability cache. A test frame from the branch will come to the first one, get's put on the tokenring and then forwarded back out to the branch via the second router, since they use different virtual-ring numbers they can not detect that this is not what should happen. As such the dlsw reachability cache learns the remote mac addresses local and remote and from then on you have a problem.
Try to configure i.e. 150 as virtual ring group in both. So chang the second router to
source-bridge ring-group 150
dlsw local-peer peer-id 167.28.190.111
dlsw remote-peer 0 tcp 10.69.1.46
interface TokenRing 1/0
..
..
..
source-bridge 1088 10 150
soruce-bridge spanning
If you configure multiple routers on the same physical ring with the same ring-group number than you MUST make sure that you configure different bridge numbers in the source-bridge statement to make the rif strings unique.
In your case:
first router:
source-bridge 1088 3 150
second one
source-bridge 1088 10 150
Ok. If your problem is that the dlsw peer goes down to the first router when you enable the second one, than this is a different discussion.
Than it needs to be looked at what causes the peer to fail.
I would suggest to open a tac Service Request so that the issue can be propperly documented and worked to a solution.
thanks...
Matthias
