DLSW ER+ at the central site

Question

The network topology that I have is two MSFCs and two external routers at central site and two MSFCs and two external routers at the remote site.
DLSW is activated on the external routers. In regards to DLSW+ ER at the central site, only one translational or transparent bridge can be active at a time. Manual intervention is required to cause a router to take over for the other router. Is there any other way to have some means of dlsw redundancy (w/o manual intervention) at the central site (for ethernet environment only)?
Second, DLSW ER+ cannot be deployed easily at the central site, since you need a lot of dlsw mapping. On the other hand, you also need local SNA PUs to be able and reach the CIP (both located at the central site) but reside on a different broadcast domain. Any ideas?
Thanks

Answer 1

Hi,
on the central side, host end, there are a couple of things you can do.
The potential solutions mentioned below are in the order that cisco would prefer.
1.
The most clean thing to do is to upgrade and configure the mainframe for appn and allow hpr/ip between the host end router and the host.
You will need to run dlsw/vdlc/snasw in the host end routers to be able to do this.
It also requires that you have ip connectivity to the mainframe.
If you do this than the mac address, the remote devices connect to, is configured as a snasw vdlc port in the routers. Both of them are active all the time, the remotes will learn the remote mac address over both peers and as such you have automatic, non manual intervention, redundancy, loadbalancing. The mac addresses in this case only exist in the central router. Nowhere else. The remote device does not know anything about this change.
Each of the head end dlsw/vdlc/snasw routers will have at least one hpr/ip uplink to the host. This is routed ip traffic into the mainframe.
In that case you can also define the physical ethernets as snasw ports, do hsrp on it and configure a hsrp mac address, this mac address would then be used as dmac for local clients connecting to the host.
2.
If for some reason you can not do the appn/snasw configuration you still have some options.
If you are using cisco cip's with csna today than you most likely have on path into the mainframe today for each mac address.
You can configure multiple vlans between the dlsw router and the cip router, i.e. dot1q trunk, and on the cip router you can configure multiple virtual ring groups and more than one csna path statement into the host. At the end you attach each vlan to one of the channel path, configure srtlb for each vlan into a unique vring, and then configure a different adapter number on each of the internal tokenring lans with the same mac address.
On the dlsw router you can configure multiple bridge groups into dlsw and each of those bridge groups goes to a different vlan. If you do this with two dlsw routers going to the same cip router you then end up with two channel access's and one vlan on each of the dlsw routers. If you do it to two cip routers you need 4 vlans. Just make sure that you dont bridge the vlans together.
The remotes learn than the remote mac address over both peers and your redundancy is established.
For the local clients this solution has the draw back that you need to pick a vlan where to connect them. There is no automatic redundancy, like hsrp in the first example, for those.
3.
You can enable both dlsw routers towards a single bridge-group and apply a mac address filter inbound to the bridge group only allowing the mac address/es of the hosts as source mac address.
That way you kill the potential loop on the head end. You will also need to put on as much restrictive filtering as possible to only allow the traffic that is wanted.
thanks...
Matthias