DLSW ER+ at the central site

[YORGOS KATSIKOGIANNIS]

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

[mbinzer]

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

[YORGOS KATSIKOGIANNIS]

1. This is exactly what I am looking for. The ‘dmac for local clients connecting to the host...’

Could the local clients be any remote clients or even clients on the site where host resides?

2. In a pure ethernet environment does this make any difference? Also, could the cip and the dlsw router be the same router? That means that the HOST has a direct interface on the DLSW routers. Please correct me, if I am wrong.

‘…the drawback that you need to pick a vlan where to connect them’ means that no bridging can take place from multiple vlans in this case? If no bridging can take place from multiple vlans, is there any option to do so?

Could a strict MAC filtering technique be used between two spokes using DLSW+ ER to eliminate unwanted explorer traffic?

Many thanks

[mbinzer]

Hi,

1.

with local clients i refer to those clients beeing local to the host end routers. The remote clients are all coming in via dlsw.

2.

The cip and dlsw router can be the same router. You can simply terminate the dlsw peer on the cip router and do srb into the cip lan tokenring x to reach the host mac address.

In fact that is the simplest way to achive redundancy if you have i.e. 2 host end cip routers.

It simply depends on the amount of remote peers and the amount of traffic you have.

When i refer to "pick a vlan to connect the local clients to" i try to say that this is for the clients local to the host end router.

I am still making a distinct difference between the clients connected on a ethernet segment behind the remote router. And those clients who are physically on the same site than the host end dlsw routers.

You can certainly use multiple vlans aswell but then again what you want to avoid is to bridge all the clients together into one large vlan.

You can certainly use one ethernet segement/vlan and attach it to i.e. both cip routers and bridge it together. However your ethernet switch cam table can for every given mac address in any given vlan only point to exactly one port. So if you have two cip routers with the same dmac in this vlan your cam table on the switch can only point to one of the two routers at a time.

As long as this would be stable that will work. However if for some reason you get a change in the cam table your setup can fall apart.

Also in a ethernet environment it is simply not allowed to have the same mac address twice in the same vlan.

Snasw with hsrp is the most elegant solution to this problem. but it requires quite some changes on the host itself.

If you have 2 cip routers attached to the same ethernet vlan and those cip routers advertise the same mac address than you always have a problem with the cam table of your ethernet switches.

That is why i talk so much about creating separate vlans to keep this distinct. so that you only have always one machine advertising the host mac address per vlan.

You can configure dlsw+ ER at the host end but you will run very quickly into trouble with the fact that you need a dlsw transparent mac address mapping for every remote client. That is the reason why we do not propose this solution. This is not managable.

It will work if you do this between i.e. two hosts. In that case the number of mac addresses is very limited. But if you have 600 clients than you would need 600 dlsw transparent mappings configured on the host end. Dlsw+ ER is clearly designed for the branch.

thanks....

Matthias

[YORGOS KATSIKOGIANNIS]

Mathias,

thank you very much for every single answer and the detailed description that you posted.

I have two more questions regarding the DLSW+ ER on the remote branches; I have made a couple of assumptions, because there is only limited information available regarding DLSW+ ER. Please correct me, if I am wrong.

The multicast mac-address is locally significant and is only populated between the two dlsw routers and only in the broadcast domain that you configure. Let's say, if you have many vlans, each vlan announces and accepts only its own multicast mac-address (i.e. 9999.9999.9999)

You may create different multicast mac-address for each vlan.

The local-mac (under the dlsw transparent map statement) should not be advertised in the show dlsw reachability output, but in the show dlsw transparent map output.

If the last statement is true, I have this setup and I am seeing the local-map in the local dlsw reachability cache (no rif) and the mac-address of the DLSW+ ER router mac-address in the DLSW+ remote mac address reachability cache (with max lf-size 1500).

I have tried this before (not this case) and I have seen that they didnot show up.

Any ideas are more than welcome.

I really thank you very much in advance.

Cheers ..

[mbinzer]

Hi,

yes, the er multicast mac address has only significance in the ethernet segment/vlan between the two dlsw ER routers.

Each vlan can have the same dlsw er multicast address or different ones. that doesnt really matter. Always provided that you dont bridge the vlans together somewhere.

yes, you can create different dlsw ER mulitcast mac addresses, a unique one per vlan. Some customers simply count, some carry the vlan in there again.

About what shows up in the reachability cache:

Not sure if i understand you here correct. But the dlsw mapped local mac address

is a dmac. From the client to the router. We cache the source mac address from the client, not the dmac.

This is under the assumption that the client opens the connection.

Are you maybe dialing out? Not exactly sure what we cache in this case i would need to try.

Dialout means the host end opens the connection.

thanks...

Matthias

[YORGOS KATSIKOGIANNIS]

Mathias,

suppose that there are many ethernet end stations pointing the same single dmac (host).

If sb created vlans and he kept the same dmac then he should have to bridge the vlans. With two remote DLSW routers, this would cause a lot of unwanted explorer traffic.

Either you devise different local-mac (DLSW ER) or you use a single ethernet segment but again you have to be aware of STP and the bridging between the two dlsw routers.

Is there any other option with two dlsw routers, many vlans and the same dmac on the ethernet end stations (at the remote site)?

Many Thanks

Yorgos

[mbinzer]

Hi,

"

If sb created vlans and he kept the same dmac then he should have to bridge the vlans. With two remote DLSW routers, this would cause a lot of unwanted explorer traffic.

"

no, even if you have lots of vlans with all clients connecting to the same dmac you can configure the same mapping on each vlan with

dlsw ER. Dlsw ER does not bridge between the vlan's. Also there is no spanning tree running with a dlsw ER configuration. Dlsw ER is

essentially transparent bridging without the normal transparent bridging process.

The original idea of dlsw ER was that you configure your dlsw transparent map ... statements in a sense that on router1 you create

mac address local1 and on router2 you create mac address local2. both of them are mapped to the real remote mac address of the host.

Now you would split up your clients so that half of them connect to local1 and the other half to local2. That way you have

redundancy and also load sharing on a single vlan/ethernet segment.

However what our customers quickly came up with is the fact that a lot of people simply can not so easyly change the dmac on i.e. 600

already installed client machines.

So what our customers actually came up with is to configure on router1 a mapping local == remote and on router2 you configure a dummy

mapping which is not really used, unless your host does dialout and selects router2.

With this mechanism you can alternate the local == remote mappings on i.e. the even vlans you do it on router1 and on the odd vlan's

you do it on router2. That way you also get a sort of loadsharing.

The only other way of having two routers active in the same vlan/ethernet segment is to use a little trick and let spanning tree

work in your favour.

What you typically have is a ethernet segment/vlan, clients in that vlan and two routers attached to the vlan/ethernet switch.

You add a additional link betweeen the two routers. If you have multiple vlans this can be another trunk. And put the same

bridge-group on this one than on the vlan you are having your clients on.

I.e. for vlan 10 you use bridge-group 10, for vlan 20 you use bridge group 20.... that way you dont create one big bridged vlan.

Now on the extra link between the two routers you put an access list on the bridge group to allow only bpdu's between the two

machines. And you manipulate the bridge port priority so that allways the port into one of the two routers, into dlsw, blocks.

Never the port on the extra link.

that way you have two routers active, you configure simple transparent bridging into dlsw and always one of the two routers

into dlsw is blocked by the spanning tree. We have customers doing this aswell.

thanks....

Matthias

[YORGOS KATSIKOGIANNIS]

Matthias,

this is now clear enough. I really thank you very much for your patience and explanations.

Yorgos

[axfalk]

Matthias, how is the local mac address is determined? thnx

[mbinzer]

Hi,

i am not sure to which "local mac address" you are referring. There are multiple cases mentioned in this discussion.

1. In the case of using snasw together with hsrp you configure a hsrp mac address and this one is the dmac for your local clients. You can decide whatever mac address you want to use for this case. If your clients have already a configured dmac you may use this one, or you can choose to use a totally new one. You just have to be sure that it is unique within your vlan/ethernet segment.

2. In the case of using dlsw ER we mentioned

the case with dlsw transparent mappings where local mac == remote mac. In this case the local mac would be the real host mac. And the local dummy mac configured on the second routers mapping statement is a purely artificial one, made up by you. It is not really used unless your host does dial out and picks the path via the second router. The dummy mac address also needs to be unique on a per vlan base.

3. In the case where you configure dlsw ER with a local mac1 on router 1 and a local mac2 on router 2 and you split your end systems to connect half of them to local mac1 and the other half to local mac2. In this case both mac addresses are having only a local significance and are made up by you. You just need to make sure that they are unique within your vlan.

thanks...

Matthias