rsrb with multiple ring groups on head ends with one phy ring?

[jvogler]

working on an issue for a customer and I cant find good documentation on this anywhere for multiple ring-groups

have 2 routers, each with 2 ring groups connected on a mau terminating multiple serial connections (wan, hence the rsrb) and utilizing rsrb tcp with local ack. The configuration was done sometime ago. It was set up to utilize frame which now they are using ptp t1s. I see in the remote routers they are forwarding pakcets to both routers to ring 20. (there are 2 routers if one fails then it is meant to learn its path to the CIP through the other router)

---------router1

source-bridge ring-group 30

source-bridge ring-group 31

blahblah peers tcp local-ack

int t0

source-bridge 20 1 30 <----notice bridge 1

source-bridge spanning

int t1

source-bridge 20 1 31 <----notice bridge 1

source-bridge spanning

--------router2

source-bridge ring-group 30

source-bridge ring-group 31

blahblah peers tcp local-ack

int t0

source-bridge 20 2 30 <----notice bridge 2

source-bridge spanning

int t1

source-bridge 20 2 31 <----notice bridge 2

source-bridge spanning

I thought the physical rings had to be different in order to run parrallel links. Or are different bridge #'s feasible? The end issue they are having is that when links bounce, they are not releasing the tcp session and the show llc shows remote sides as busy and the head end as connected. (then obviously removal of local ack fixed the issue)

Not ready to live without local ack... could the same ring # on both routers be the issue since they are on the same mau and destined for the same location?

==MAU to CIP==

| | | | all physical connection on mau are ring 20

router1 router2

| | | | | ring groups 30 and 31 configured on both routers with 1 statement to each router in the network per router (so each remote side is only connected to either ring group 30 or 31 (not both since you can only do over token ring) and the show source-bridge is showing forwards to each head end router's physical ring 20. I thought I would see one with forwards the other 0 since first response, but then saw the bridge # differed.)

[dixho]

The requirements for SRB are as follows:

1. unique ring number for a MAU or MAUs connected by Ring In and Ring Out

2. unique ring bridge ring combination

The network design is fine. Because both routers connect to the same MAU which has ring number assigned, you need a different bridge number to comply rule #2 above.

Where do you issue show llc2? Is it router 1, router 2, or the remote routers? Whatever device you enter show llc2, the station remote to this router does not release the llc2 circuit. You need to do a show llc2, show source, show tcp and show rif on another router.

[jvogler]

remote routers show busy while the 2 head ends are in normal states

the remote will show busy with a rif thru router 1 on the head end and then the router 2 may show normal

I removed local ack and everything is happy, as well as I am trying ot pursaude this user to dlsw and that worked as well with no issues.

so even though the router 1 may be 2 hops out, router 2 may be 3 hops away and they are forwarding to both to the same destination (cip) that is not an issue?

I like dlsw since i can speicfy a backup peer and linger parameters, anything like that with rsrb? I am tempted to go back in and enter the peers in the correct order (so it will local ack and rif the path the correct way, but was hoping I could make one headned change compared to 100 remotes)

[dixho]

When the router 1 or 2 establishes a LLC2 circuit with the CIP, it remembers the RIF to the CIP. At the same time, it remembers the IP address of the remote peers. (show rif shows the information) Hop count should not be a problem. Also, the peer order should not been an issue.

What is the IOS version? I have been working in TAC for 3 years, I have not worked on similar issue.

Most customers have moved to DLSw . DLSw is the way to go. If your customer really wants to trouble shoot this problem, you may want to open a TAC case.

[jvogler]

case was opened over a month ago with no luck or serious help. Have had great luck in the past with tac, but this one was frustrating and nothing was done.

case#D039413

And the remote routers connect directly to the cip with LLC2. (end to end connection, not remote to router 1 and 2 to CIP)

show llc shows the local mac of the gateway and the cip token.

the network goes like this

rr = remote router

fr= frame relay

ptp= ptp t1

rtr1 and rtr2 = router 1 and 2

rr--fr--rr--ptp--rtr1 and rtr2 ---rr---cip

I have tried numerous things on this and its apparent that the only option is dlsw and I have pressed the issue enough to start on it with test segments.

my theory was when the host queried the gateway, its first reply was local-ack on rtr2 (could be rtr1 but for theory we will say rtr2) which was giving back RR and the other end was actually in a disconnect state and sending rnr's to the rtr1 (in this exapmple the host was talking thru rtr2 to the remote side and the remote side was trying the opposite router) which local ack would reply to the supervisor frames

what was causing the problems in my opinion is the host provider does not utilize local ack since they only have lanned token rings and the customer provides their own wan routers. So the explorer would be answered quicker by the other router and that would be the source route bridged path to the remote side, where the other sides local ack and rif cache was routing through the opposite router. Unfortunately the site where we collected the data on I can not test since I have transitioned it to dlsw to solve their issues and show them the benfits of dlsw