more SNASw q&a, redundancy on OSAs

[a.mountouris]

Hello dear Forum,

we have established a connection between a cisco running SNASw and a Mainframe through two OSA interaces. Thus we have defined two links under the same port (Ethernet1 of the router). But we see only one link as active while the other is pending retrying.

This is not a problem, however if we want a redundancy how can we accomplish that? If the active link fails for some reasn, how is it possible to have the pending link to take over?

If we configure :

snasw port PORT ethernet1

snasw link LINK1 port PORT tgp high

snasw link LINK2 port PORT tgp low

gives the desired result?

Regards, Apostolos.

[romney]

Hi Apostolos,

tgp is not the answer. That should only be used to differentiate between links over different types of ports (i.e. tgp high on ee links and tgp low on slower backup isdn dial links).

With EE you have to remember that your redundancy comes primarily within IP. You should design the IP network between snaswitch and the mainframe such that if a switch fails there is another path, and HPR keeps the sessions up while the IP routing recovers itself. Having more than one link isn't necessary for handling these kind of failures in the IP network fabric.

The only advantage you gain with two EE links to the same mainframe is if one OSA adapter itself fails. If that's what you desire then I don't see why it shouldn't work. You need to determine if the second link is never coming up or is coming up and then going down over and over again.

Look in the pdlog (show snasw pdlog all | linkname) to see if the second link is ever coming active. If not, can you ping each OSA's VIPA address from the snaswitch router? Try stopping the first link and see if the second one comes active and stays active.

If the second link is coming active and then dropping over and over again it is likely because of the DISCNT setting on the VTAM EE PU definition. If you haven't predefined the PU then you need to add a MODEL PU definition. The key is to specify DISCNT = NO. Any other value for DISCNT causes the link/PU to be identified as a limited resource, which means it will be disconnected if there is no traffic for a period of time.

- Ray

[htranphu]

Since the upstream interface is with OSA, I assume that you are using EE, correct? There really is no good reason to configure tgp on the 2 links on the same port like in your case, please remove it (it may cause reachability problem especially in case of connection network). I also assume that the 2 links are destined to 2 different IP addresses of the 2 separate TCP/IP stacks on the host. Both links should come up active, with one carrying CP-CP sessions; if you want to favor one link over the other then add "nns" option to that link; CP-CP sessions will be carried on that link whenever it's active.

If you still experience the problem, collect the dlc trace (configure snasw dlctrace, and show snasw dlctrace det all) and look at the exchange over the retrying link.

Thanks,

tran

[a.mountouris]

Hello ray and tran,

we discarded the tgp configuration and we proceeded with configuring "nns" on one link LINK1(remember that both links point to the same VTAM through two different OSA mac addresses). Then, when we stopped the LINK1, the appn connectivity between VTAM and Router stopped and started through the LINK2 (the other link).

Unfortunatelly we can not use HPR/IP for some reason, otherwise we would have VIPA and no problem with redundnacy. Is this workaround (nns config on one of the to links) valid for our case?

Regards, tolis.

[htranphu · Accepted solution]

nns is merely used to tell which link you prefer to carry CP-CP sessions, not for redundancy. The fact that you configure 2 upstream links already gives you redundancy: if the link carrying CP-CP sessions fails, SNASw will try CP-CP sessions with the other link.

tran

[a.mountouris]

Tran you are absolutely right. We have tried without coding any parameters on links and it worked just fine.

[romney]

Sorry I got off on a tangent with the EE discussion.

Have you been able to identify why the second link was constantly retrying?

- Ray

[a.mountouris]

Not actually,

what we have noticed is that if we code two links under the same port, with destinations to two different OSAs, only one of them is active. Isn't it what we should expect?

[romney]

No, you have two different links with rmacs that match two different OSAs, so I don't see why they can't both be active at the same time. Can you pase in the snasw configuration including the rmacs?

How do you define the PUs for these links on VTAM ... do you use DYNPU or are they predefined explicitly? If you don't allow dynamic PUs and you only have one PU configured with the snasw router CPNAME then that would explain why the second link can't come up. If you do predefine the PUs pasting in those definitions from the switched major node would be helpful as well.

- Ray

[j.verboom]

To be able to use HPR/IP (Enterprise Extender) on the Mainframe you must enable APPN functionality in VTAM.