Design question about SNASw, DLSW and VDLC

[a.mountouris]

Hello,

I have a question about Ethernet redundancy in an APPN environment.

Let's have an example with 3 routers running SNASw that are on the SAME LAN (no vlans) as the Mainframe's OSA (one OSA only). APPN is configured on the Mainframe.

Using DLSw+, all downstream PUs are connected to the 3 routers. Can I define in the VDLC interface of each router the SAME MAC address, and this MAC address be the destination MAC of the downstream PUs?

[mbinzer · Accepted solution]

Hi,

if i understand your question correct than those 3 routers on the same ethernet lan are dlsw headend routers.

Yes, you can configure the same vdlc mac address on all 3 off them. And yes this vdlc mac address can be the destination mac address of all downstream devices.

In fact this is one of the biggest advantages you have if you use snasw and dlsw in the same router.

You can use the same vdlc mac address on all of them

and achive rdundancy this way. You can then i.e. connect the downstream router with two dlsw peers to the head end peer farm. the downstream dlsw router will learn the same mac address twice, from each head end router, and thus have always two path's available to the same host.

thanks...

Matthias

[a.mountouris]

Matthias, thank you very much for the clarification. I suppose by headend routers you mean the routers just in front of the Mainframe (OSA card). Yes, I am talking about them. We are going to use SNASw plus DLSw for connecting remote branches.

What is going on actually, is a token ring migration to ethernet. In token ring, the one OSA could be advirtised with no problems (SRB). But with ETH (TB) there is a problem. So we figured out the APPN solution, but we had to use ONE MAC only (hw restriction).

In case we went with the ethernet redundancy example as it is described in the DLSw implementation guide, can I distribute dlsw circuits to other routers except master? or only the master will take all sessions and in case of failure the back up will handle?

Best regards, Apostolos.

[mbinzer · Accepted solution]

Hi,

yes, headend routers are the ones in front of the OSA/mainframe.

If you replace a tokenring with ethernet in the data center/headend, than the snasw dlsw solution is almost perfect for you. If you use hpr/ip to connect upstream to the host you are all set.

In that case you dont advertise any mac addresses on the local ethernet between the snasw/dlsw routers and the osa since it is hpr/ip. Basicaly ip routing only.

From the clients perspective, they dont really know that there is a change since you replicate the old tokenring mac address as vdlc mac address/snasw port and the end systems still connect to them like they did before.

In respect to dlsw ethernet redundancy we have to be a bit carefull not to mix the scenarios.

Dlsw ethernet redundancy is designed for the branch. Not the data center.

If you use dlsw ethernet redundancy with ethernet switches, and in almost all cases today ethernet means ethernet switches, you configure a mac address mapping between artificiall local mac addresses and your real remote mac address of the host.

On each router you configure a unique local mac address. Than you point half of your end systems dmac to the local mac address configured on router1 and the other half to the local mac address configured on router2. That way you achive load balancing.

The two routers exchange their mapping and in case router1 looses the connection to router2, router1 will activate the mapping it learned from router2 aswell and then take over those circuits additional.

If you decide that you configure on router1 the local mac address equal to the remote mac address, because you have a large number of clients and can not simply change the damc's on all of them, than you need to configure a "dummy" mapping on router2 and router1 will get all the circuits in this example. router2 would be purely for redundancy in case router1 goes down.

If you think about this than it is clear why dlsw ethernet redundancy is designed for the branch. In the branch we map local to remote mac addresses and the remote mac addresses are the hosts. Typically there are only a limited number of host mac addresses to map.

If you turn this around and put dlsw ethernet redundancy on the host end than you have to map all clients. If you have only one or two clients this is certainly doable. But if you have a large nuber of clients this is simply not manageable.

thanks...

Matthias

[a.mountouris]

Thanks Matthias.

Is there any technical document describing this (same VDLC mac for redundancy on headend routers)?

I search the cisco web site but I found only a Token Ring to Ethernet Business case document that just references the VDLC and redundancy issue. I have also found a presentation by Steve Koretsky saying some about this subject, but I could not find a technical example describing this (even in SNASw implementation guide I could not find any hint).

One more thing (sorry if am being tiresome) is that we do not plan to use EE from the beginning, we will go first with pure APPN. Hope it is ok (?)

[mbinzer]

Hi,

this is not exactly your scenario but

it describes at least parts of it:

http://www.cisco.com/en/US/partner/tech/tk331/tk897/technologies_configuration_example09186a0080093d90.shtml

in your case you configure a dlsw peer between the snasw/dlsw head end router and the downstream branch router. Bascialy the same way you most likely had it before when you were using a tokenring in the data center.

On the snasw head end router you configure a snasw vdlc port which represents the mac address to which your downtream devices connect. Vdlc is automaticaly tied into dlsw.

You can configure the same mac address on multiple routers. And you can replicate your original tokenring host mac addresses. You can also configure multiple snasw ports with different vdlc mac addresses if you need to replicate more than one mac address.

So no need to have any client to change his dmac.

On each snasw dlsw head end router you configure also a snasw port for the upstream link. If this is done via llc2 than you simply define your physcial ethernet interface as upstream snasw port. And then you define a upstream snasw link over this port.

Each of your router has a unique ethernet interface with a unique mac address on that ethernet so you are ok, even with multiple routers going to the same upstream host.

Let me know if this makes sense for you.

thanks...

Matthias

[romney · Accepted solution]

Hi Apostolos,

there are examples of snasw and dlsw together ...

http://www.cisco.com/en/US/partner/tech/tk331/tk336/technologies_design_guide09186a0080237a53.shtml#wp594008

but you are correct that there isn't an example showing the same vdlc target mac address for multiple snaswitch routers. Perhaps we need to look at adding something.

There are various ways to have the remote dlsw routers determine which headend snasw/dlsw router to use, but multiple active peers as Matthias has suggested seems to be the most popular method. It's only downside is that load balancing is done randomly depending on which headend peer replies first. If you want to control the load balancing you have to use costing in some organized fashion.

Regarding EE upstream, that is usually the final solution, so many customers take that on the same time that they implement the TR to Eth migration. EE has the advantage that the underlying IP network provides the redundancy and HPR allows for sessions to stay up when there are problems in that IP network. If you are using APPN you can still achieve a similar result, but you have to a) enable HPR on the appn links, b) provide for redundancy by having multiple links upstream, thus allowing HPR to pathswitch to a new route when a link goes down.

- Ray

[a.mountouris]

Matthias and Ray,

many many thanks for the clarification. Now the picture is much more clear.

Let me summarize using the following example:

>

+-----+

| | Mainframe

+--!--+

OSA

!

---------------- (ETH)

| | |

RouterA RouterB RouterC

\ | /

{DLSW cloud}

|

BranchRouter

| (ETH)

End user(PC)

>

i) Mainframe and 3 headend routers will be configured to use APPN (SNASw on cisco).

ii) On each cisco router, a port definition will be coded that will point to OSA (plus the CPNAME and link definition).

iii) On each cisco router, a VDLC definition will be coded connecting SNASw traffic to DLSW. All three VDLC interfaces will have the SAME MAC and SAME ring values.

iv) DLSW will have to be in place between the headend routers and all branch routers (multiple active peers as Matthias suggested).

v) The destination MAC coded at the end user PC will be the VDLC MAC address.

vi) Ethernet redundancy could be used at branches, if branches had 2 routers.

vii) EE is the best and recommended solution. This can be implemented immediatelly after the APPN on mainframe is active. Then, when defining SNASw on cisco headend routers, the port can be coded to have destination address the VIPA address of the Mainframe (or if TCPIP/PLEX is in place the DVIPA). Routing protocols such as OSPF or RIP, plus HSRP techniques can be used for redundancy.

EE area will be between headend cisco and Mainframe, whereas DLSW area between headend cisco and branches.

>

Given the above, all branches's end PCs can be coded having destination address the SAME MAC.

Am I right?

[mbinzer · Accepted solution]

Hi,

yes you are right as far as i am concerned.

Only a view minor comments:

iii)

the vdlc mac address on the router is actually coded as part of the snasw port definition.

Also you can have the same source-bridge ring-group number but you dont have to. Those ring numbers are purely internal to the individual router.

They are not seen from the outside world.

iv)

if you use multiple active peers on the branch router than you should add the following to the branch router.

dlsw timer explorer-wait-time 2

this will allow the router to wait for 2 seconds after a canureach is send out ( the branch router is searching for a mac address ) until all icanreach responses are received back,from the head end peers, and the dlsw reach cache is updated. And then the route makes a decision based on its configuration which peer to use.

The default behaviour is that we always use the first icanreach that comes back and try to establish the session.

In respect to loadbalancing you can configure:

dlsw load-balance round-robin

on the branch router. That would instruct the router to try always alternating to bring up the circuits.

Or if you want to do it manual you configure a cost parameter on the remote peer and point one peer to the lower cost, prefered, and the other peer to the higher cost.

And then alternate with half of your routers and configure the costing the other way around.

It is purely depending on things like, are your two peers equal to each other or is one a backup of the other, has one peer more bandwidth, ect..

Both methods are in use by customers.

thanks...

Matthias

[a.mountouris]

Matthias and Ray thanks again. This discussion has enlightened the design of the network in question.

[romney]

With respect to your comment ...

"Then, when defining SNASw on cisco headend routers, the port can be coded to have destination address the VIPA address of the Mainframe (or if TCPIP/PLEX is in place the DVIPA)."

EE only works with static VIPAs, so even if you have a PLEX environment you still have to use a separate static VIPA for each OSA which will use EE.

- Ray

[a.mountouris]

Hello again,

refering to the first question, where there are 3 headend routers playing the role of the DLSw peers of the reomote branches.

Can I use the SNASw on the switch (6509) that connects these routers to the OSA cards (routers will not run SNASw in this case, APPN will be only between M/frame and 6509)?

Which are the implications in this design?

Can the branches still use the VDLC MAC, defined on the switch this time, as their destination? Will the headend routers be able to pass the MAC info through the dlsw?

[mbinzer]

Hi,

catalyst 6500 does not support snasw. Only dlsw is supported on the cat6500.

In general, yes you can use different routers for dlsw and snasw. However in this case you need a llc2 connection from the dlsw routers to the snasw routers.

Just a "bridged" layer 2 connection.

Since this is a flat layer 2 connection you have to be carefull not to create loops again. So you can not simply connect all the dlsw routers and snasw routers on a common ethernet. You would create a loop again. You have to use either separate physical interfaces between the dlsw router and each snasw router, or if you use a switch in the middle you can use trunks with different vlans and then separate the llc2 traffic that way.

It is not a simple token ring where you have a rif field which determines where a packet comes from and where it is supposed to go to!!

If you use dlsw and snasw in the same router and then use hpr/ip upstream you avoid exactly those problems. Since the layer2, llc2 connection only exists in the router internal. Upstream you would do just ip.

thanks...

Matthias