Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss SNA Switching Services with Cisco expert Dan McCullough. Dan is a technical marketing engineer in the InterWorks Business Division. Feel free to post any questions relating to SNA Switching Services.
Dan may not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through December 7. Visit this forum often to view responses to your questions and the questions of other community members.
What is the recommended design for redundancy in a network with SNASw at the remote branch to guard against failure of the branch router?
I am going to presume that the devices attaching to the branch router are using layer 2 LLC addresses. Our general recommendation is to use Hot Standby Router Protocol (HSRP), to achieve the fastest and most reliable failover in this scenario. In a token ring environment, you may want to consider using duplicate MAC addresses on different rings that are source route bridged together.
I would like to understand this suggestion better. I am not clear on the advantage of HSRP since
you are presuming that the branch devices are using layer2 LLC addresses and HSRP provides
failover/redundancy for layer 3 (IP) addressed devices.
Certainly HSRP is most often used for IP failover/redundancy. But it also supports coding a standby MAC address. A nice URL for HSPR, that happens to mention this MAC address capability, specifically for APPN, is;
To get a really current answer, your best bet would be to ask IBM. Having said that, I believe the informational APAR that lists the suggested maintenance for Enterprise Extender (EE) is II12223. If you are planning to use EE to simply connect two copies of VTAM, my experience is that this has been quite stable from the time it became available as a patch for V2R6, nearly two years ago. If you are also planning to add Cisco's SNASw (APPN Node) in this mix, and depending on your current VTAM level, you will want to apply the following APARs; OW37548, OW37549, and OW39559 to update Branch Extender Node function. Lastly, there are a set of APARS to consider for APPN HPR; OW43416, OW43223, OW43413, OW41980, OW38056. and OW43484.
My experience with SNA is, to say the least, limited. In fact, incorrectly answering SNA quesitons on Cisco exams is about is far as it goes. Never the less, I have a project to upgrade a channel extender environment with an ES9000 at the centeral site and a 3274 terminal server at the remote. This is all bus-and-tag. I thought I had a solution with a bus-and-tag interface option for the 3600 series router but I see it is now at end-of-sales.
I can easily switch to ESCON on the ES9000. But I doubt the terminal server can support that. So, would you recommend getting rid of the server and migrating to a terminal emulation environment of some sort? If so, what do I need on the mainframe side?
I'm not asking you to engineer a solution for us but I could use a good kick in the right direction considering the end-of-sales for bus-and-tag.
What I'm wondering is, what sort of terminal server you've got there. If it's a TN3270 Server, then the actual users are IP connected, and you simply want to move the TN3270 Server device to the ES9000 location, and route the TN3270 Clients back there. I presume you know that we do have a very nice TN3270 Server that runs on the CIP or CPA, should you want to change that out in the process.
If this is another sort of server, MS SNA Server, IBM Comm Server, etc, and is attaching non routing protocol devices, then perhaps it should stay where it is, and you should consider changing what goes on the WAN links. Consider dropping the channel extension, and use an IP transport like DLSw+ or Enterprise Extender with Cisco SNASw. Then a CIP or CPA can pick up this IP traffic at the data center and move it into the ES9000.
It's possible that there is more to this than I'm guessing. But a design using channel extension to attach a terminal server is likely to be way more expensive and complex than necessary. Use that bandwidth for IP, prioritizing the SNA traffic appropriately, and you should have a win win situation.
Many thanks. I very much would like to move the chanel extender at a minimum, and I would like even more to replace it. At this time, we have not been able to travel to the actual locations so we are going off of user-provided drawings. At the remote, we have bus-and-tag between the channel extender and what is listed as an "IBM 3274 Terminal Server." There is also bus-and-tag on the back side of the server to a SCSI tape drive. I suspect this can be replaced. Everything else on the back side is shown as serially connected terminals and a printer. So assuming I was willing to replace the terminals with PCs running some type of terminal emulation software, are you suggesting that simple ethernet connectivity to a router at the remote would do. Then put a CIP at the ES-9000 to interface the ESCON and also act as a terminal server? This sounds too good to be true.
The key to this endeavor is determining exactly what is at the other end of that bus and tag channel, and what application work these things exist to accomplish. That tape drive is a bit of a worry. Perhaps it is used to transfer batch information that is generated or collected at that remote location, back to the ES9000. You may be able to sort much of this out by getting the definitions for the devices on the channel from the systems programmer of the ES9000.
The general idea is just what you are assuming, replace the terminals with PCs, use the IP network to transport back to the data center, and place the necessary gateway device(s) there.
This might be a very simple question to you, but please don't laught at me.
If a cisco router token ring interface connecting to a token ring switch like 3900, and I'm going to do source route bridging. on the router, can I configure like this:
source-bridge 1003 1005 100 <-- is this correct? since 1003 is default trcrf and 1005 is default trbrf.
Thank you alot...
It is often confusing when dealing with source route bridging, so keep in mind that we are making Routing Information Fields (RIFs) that identify rings or groups of rings and associated bridges within a network. The router command that you suggest will probably work, if ring 1003 isn't defined anywhere else in the network. But I would suggest using a different bridge number, so that bridge 1005 doesn't occur in both the switch and the router.
Picture a network with a CIP Router connected via LAN to a SNAsw/DLSW Central Router, that is connected via TCP/IP to brach Routers. If I am moving from Bex to Eex, do I NEED CMPC+ on the CIP Router, or can I use CLAW?
At the HOST I already have a TCP/IP Profile, an XCA Major Node that activates a MAC Address, and a Switched Major Node that represents the SNAsw Router.
Do I need anything else in order to use HPR/IP?
My doubt is where the "link" is between the TCP/IP profile and the Switched Major Node (where I have CONNTYPE=APPN)...
I think I get the picture; IP from CS/390 to the SNASw router, then DLSw+ from SNASw to the branch routers. By the way, SNASw will still be a Branch Extender (BX) Node type, even when you are using Enterprise Extender (EE) for the upstream connectivity, so you get the benefits of both of these new technologies.
The quick answer is that you can definitely use CLAW. Because EE uses standard IP (with UDP), any means of routing IP datagrams into the host works fine.
The parts required, starting from the top of the stack in VTAM are;
Switched Major Node(s) for Dependant devices, and where you want to override automatic options. The only thing new or different on these is the use of an IP address instead of a MAC address on the PATH, for dialing out.
PATH1 PATH GRPNM=EEGRP1,IPADDR=10.33.33.33
There is only one XCA, and the interface that it points to is the TCP/IP stack.
EEXCA VBUILD TYPE=XCA
EETG1 PORT MEDIUM=HPRIP,VNNAME=EECSCO,VNGROUP=EEGRP1
Note that there are some new parameters to tune this port.
In the TCP/IP stack, this is the IUTSAMEH device, the internal virtual interface between IP & VTAM.
DEVICE IUTSAMEH MPCPTP AUTORESTART
LINK SAMEHLNK MPCPTP IUTSAMEH
The IP datagrams (the EE traffic) should be routed to a static VIPA address,
DEVICE VIPADEV VIRT 0
LINK VIPALINK VIRT 0 VIPADEV
which is automatically started when the stack is brought up.
So this just leaves defining interfaces, CLAW or CMPC+, as many as you like and any mix, to route traffic into the host.
The picture is exactly as you described it. The truth is that I have Bex working, and was wondering how to move it to EEx; I know what to do on the Router, but the Host portion was unclear.
I actually did not know about the IUTSAMEH device, that you called the "internal virtual interface between Ip and VTAM". Since it does not point to a defined node, I suppose that this is a standard name (?) available from CS/390 v?r? - could you complete this?
And since it does not point to a specific address, does this mean that EVERY VIPA device can be considered as an APPN Port?
You also stated that I should use the VIPA address as a destination for the EE traffic. I agree, for availability issues, but could I use a CLAW address as a destination of my APPN link (just asking...)?
Out of curiosity (since I will not be able to test this in the near future): for the XCA node, since it
does not point to any "physical" device, does it mean that it can be activated always? How exactly does it "point" to the TCPIP stack? What if I have more than one stack?
Let me start by saying, you are not moving from Bex, SNASw will still be a Branch Extender node type. You are merely adding a new transport protocol EEx.
Yes IUTSAMEH is a reserved name and the associated TRLE is automatically activated by VTAM. I'm not an expert in history, so can't tell you exactly when IUTSAMEH appeared. But EE itself has been in the last five releases, and IUTSAMEH is used by other facilities, so it's been there a while now.
No, only one VIPA address will be used as the anchor for EE. By default it will be the first defined VIPA. However there is a VTAM start option "IPADDR" that allows you to override this default. There is also, in answer to your last question, another startup option in VTAM "TCPNAME" that tells VTAM which TCP/IP stack to use, if you have more than one running.
Your question about using the CLAW address as the EE destination got me thinking. As you point out, using a VIPA is the reasonable thing to do, and certainly what the books say should be used. But I had never actually tried doing it the 'wrong' way. Now I have, and for better or worse, it failed.
In the beginning there was a dependency that the stack needed to be started before varying the XCA node active. I believe retry logic was added, a couple of releases back that removed this little operational annoyance.
I hope this makes things a little clearer. As you get closer to implementing EE, it would be a good idea to take a look at the 12-page section titled "Enterprise Extender Connections", in the IBM book "SNA Network Implementation Guide".