Whatever happened to IPv6?

IPv4 is pretty much everywhere. It uses 32-bit addresses, which means (and you can check the maths on this) that there is a finite number of IP addresses that people can use – 4,294,967,296 addresses, in fact. Although the number of available addresses seems pretty large, you only have to look round at how online everything is to recognize that those addresses will run out. In fact, they already have – although techniques such as Network Address Translation (NAT), classful network design, and Classless Inter-Domain Routing have helped to keep everything working.

Back in the 1990s people (including me) were writing about the address limitation of IPv4, and the proposed solution was IPv6, which, after a very long gestation period, became commercially available in 2006. World IPv6 Launch day was as recently as 6 June 2012. The big selling point of IPv6 is that it uses 128-bit addressing, which results in far more addresses being available for people to use – 340,282,366,920,938,463,463,374,607,431,768,211,456 apparently.

An IPv4 address looks like: 192.169.1.62. An IPv6 address looks like: 2001:0db8:85a3:0042:0000:8a2e:0370:7334. And that’s the problem that many organizations face. How to they convert from IPv4 to IPv6? How do they translate their addresses? How do they test these new addresses when they need to maintain a working business environment?

William Data Systems (WDS) has come up with a new module for its ZEN system called the ZEN Application Gateway – or ZAG. WDS has found that many of its customers are currently facing the costs and risks of changes to applications, networks, and hardware. ZAG helps implement IPv6 under z/OS by minimizing the need for companies to make any changes to their applications, hardware, or networks. ZAG users can input IPv4 and get out IPv6, or they can do things the other way round.

And while z/OS sites are able to run separate IPv4 and IPv6 stacks – in fact, keeping the two IP stacks segregated like this may be something many chose to do because it enables them to keep their IPv6 testing traffic separate from their production IPv4 traffic – one thing they could use ZAG for is to sit in between the two stacks and act as a bridge, allowing IPv6 clients in one stack to access IPv4 applications in another stack (and vice versa). Obviously, sites could do achieve the same thing without ZAG, but they would need to weigh up the additional costs and risks (as well as management time) resulting from application, network, and hardware changes.

According to WDS’s press release, ZAG “allows customers to:

• Test new IPv6 applications using their existing IPv4 infrastructure
• Access their IPv4 applications from new IPv6 clients
• Segregate their IPv6 and IPv4 traffic on different IP stacks
• Act as a bridge, allowing traffic to connect between IPv6 and IPv4 stacks
• Provide pseudo Network Address Translation (NAT) capabilities in an IPv6 environment, which is very useful if you want to hide internal IPv6 addresses from the outside world.”

If you are at SHARE in Anaheim between 5 and 10 August, WDS will be demonstrating their ZEN suite on a Raspberry Pi. WDS comment this is: “just in case hardware budgets keep reducing!” Adding that one lucky delegate will win the Raspberry Pi in the SHARE prize draw. 

Here’s a photo of their Raspberry Pi in action!

Moving from the limited IPv4 to IPv6 is something that people have been talking about for a long time. It now looks like the time to actually migrate is here. Anything that makes the job easier (and the painless) has got to be a good thing.

Sunk without trace

There was a time when using the trace facility was really the final strategy. You’d perhaps have tried everything else to find what was going wrong first. And when nothing seemed to have worked, you’d equip yourself with all the necessary manuals – and that could be quite a few – and run the trace and start the hard job of interpreting the results. And then try to fix the problem. Those days are long gone thanks to more modern software tools, but, to many people, the memories linger on!

I recently bumped into William Data Systems’ Tony Amies, who took the time to show me some of the things he was working on. And one of those things was making trace much, much, more user friendly.

Tony showed me WDS’s ZEN product, which, as you may know, allows lots of network monitoring information to be collated and viewed from anywhere using a browser. Information can appear as coloured boxes, which once you clicked on them display more-and-more information in a clever drill-down manner. Fairly quickly, you can identify the component that has exceeded some predetermined threshold.

WDS has a number of products in the ZEN family and you can use buttons on the browser to switch between them – giving you information about different aspects of performance. ZIM the ZEN IP MONITOR can detect error conditions, then ZEN TRACE and SOLVE (ZTS – which used to be called EXIGENCE) can be used to start, stop, and view traces. Now that has got to be so much easier than in the Old Days!

Tony showed how a TCP trace could be carried out in seconds, explaining that there were lots of commands embedded in it. Tony explained how network tracing can be so difficult. For example, using Enterprise Extender, which allows SNA applications to run over TCP networks, results in encapsulated messages. Tony demonstrated software that was able to look inside the message to see what was there – in terms of different types of header. He then explained how this works with FMH5, UDP, IP, APPN, HPR, and more. He explained that sites using the Cisco load balancing GRE tunnelling protocol can also be opened to see the true header for the message. All very clever stuff – and no manuals in sight.

In fact, on a number of occasions a right mouse click on some information in the display would produce a pop-up box explaining exactly what some term or other actually meant. So there was no need for any manuals. The display could show delays, highlight response time problems, and the TCP window size.

Tony also showed me a piece of software that drew a diagram of a Sysplex Distributor – which shows the IP addresses and links on a mainframe system. The software also highlighted where there were issues. And, like the rest of the software we looked at, you could drill down to find exactly where any problem were. In fact, Tony was sure that this would allow customers to identify potential issues before their users did. Behind the scenes, information from netstat and other commands were being used to drive the display.

We talked about customers being able to build business service views of what was going on their system and how useful that would be for each of their customers. That kind of bespoke requirement wasn’t something that Tony could necessarily build into the software, but all it requires is a knowledge of REXX to make it happen. And most z/OS sites have at least one person who code in REXX.

Lastly, we talked about problem resolution when you have two or more systems that don’t seem to be talking to each other. Currently, you need to log into each system and run traces to find out which of the systems has the problem. Tony plans to implement a ‘grouptrace’ feature that allows the user to tell the software to run a trace on these two (or more) systems. The results will come back from both systems and be visible from the browser. The results will be displayed in timestamp order and it will be possible to see on which of the systems the problem is. As easy that.

Too often we’d be sunk without a trace facility. Now we have an example of a way to be able to use trace across multiple systems and simply click to drill down to identify the problem.

Who cares about SyslogD on a mainframe?

Unix System Services (USS) on a mainframe basically allows Unix applications to run and communicate. Running under USS is Syslog Daemon or SyslogD. This is an important system component because it’s part of z/OS’s Intrusion Detection and prevention Services (IDS). SyslogD receives detailed event messages, such as security violations, as well as messages from many other communications services such as FTP and AT-TLS, plus messages from routers, switches, and other network-based devices.

So, in the event of a hacker trying to log-on to your mainframe, how would you know? And when would you know? Surprisingly, many sites appear to ignore the information written to SyslogD completely! While other sites look at what has happened, perhaps a minute ago, perhaps an hour ago, perhaps yesterday!

What you probably need is some way to be alerted about what’s happening now. And, as this is 2010, you probably want the alert to come through to your mobile phone. And you then want to be able to jump on any browser, see where the trouble lies, and fix it. What are the chances of there being software that does that?

Well, let me confirm that it does exist and I’ve seen it.
WDS (www.willdata.com) has rather nice mainframe-based HTTP server software that front-ends their mainframe monitoring products. It’s called ZEN and it allows users of their products to access information through a browser – almost any browser. Their products are called ZEN EE Security, ZEN IP Monitor, or similar, but are perhaps better known by their old names of Ferret, Implex, etc. The products can monitor APPN, EE, FTP, IP, SNA, OSA, and USS. Each of these programs effectively has a DLL that allows them to plug in to the HTTP server. This can then respond to messages by ignoring them, sending a command, running a REXX EXEC, or sending an e-mail. It’s completely automated and configurable to what the users want. ZEN can also run utilities such as PING, TRACEROUTE, and NSLOOKUP commands. And, in addition to input from WDS’s programs and SyslogD, it also receives network messages and ECMS console contents.

For the end user, working from a browser, windows can be opened and closed, resized, refreshed, whatever. The windows can show number data and regularly-updated graphical displays. In fact, a variety of different graphs can be monitored in different windows at the same time, allowing end-users to monitor what’s going on in real-time. The drawing of the graphs is all handled in JavaScript (JSON, in fact), and AJAX is used so only the parts of the display that change are sent from the server to the browser, which speeds up communication considerably. It’s possible to drill-down through the alert information on screen, for example, to one particular type of alert, on a particular day, during a particular time range.

Now, the type of display I want on, say, a 17 inch laptop screen is not the same as on a 3 inch smart phone screen. You might think this would be a bit of a fly in the ointment. The truth is that WDS has a solution to even this problem.

Looking to the future, what else could we ask them to do with their excellent end-user interface? Might it not make sense to automate the monitoring of other things and use the browser-based interface to see what’s going on? Is there a way this could be done for, say, other Linux boxes? We’ll have to wait and see.

But whatever software monitor you choose, and however you choose to display it, it makes sense to ensure that SyslogD is not being ignored.

Managing mainframes from your phone

William Data Systems has come up with a clever way of managing your mainframe network from an iPhone. Now as soon as you see the word iPhone, you probably think it’s an app and you’re going to have to get all your users synchronizing with iTunes before they can use it or update it. The truth is, it’s a much cleverer idea than that!

Let’s start at the beginning, WDS (William Data Systems) has a z/OS network management suite called ZEN, which has a number of really useful components that you can find out more about from their Web site (www.willdata.com). Their customers wanted an easy way to keep up-to-date with what was happening with their networks. And one thing everyone has these days is a mobile (cell) phone – so why not come up with a way of monitoring the network from your phone?

What WDS did, was to utilize the browser on iPhones – Safari, the same one that comes as standard on Macs – and allow users to monitor and manage their mainframe networks from there.

Now because Safari is an integral part of the iPhone, the technology works for all iPhone users. As I said at the beginning, there’s no problem of resynchronizing every user by getting them to plug their phones into iTunes. There’s no fuss about accessing the App Store. It’s all there on the browser.

As more-and-more companies are asking for z/OS network monitoring and management to be done remotely when needed using a single mobile device that support people would be carrying with them, this solution seems to tick all the boxes. If a problem is found, then the techie can find a laptop and fix it, or use the phone to call the service centre and get someone there to fix it. Either way, the problem is solved, perhaps before users have begun to notice. Interestingly, the solution can be used from an iPad. In that case, the screen is big enough for a techie to actually use instead of a laptop – and solve the problem immediately.

What if your organization doesn’t use iPhones? What if you’ve rolled out Blackberrys? Well in that case, WDS has a solution available. If your organization uses Symbian or Android (or anything else), then WDS are developing a solution for your smart phone right now.

It may all seems like something from a 1990s sci fi film, but monitoring your z/OS network from your mobile phone is a solution that’s available now.

And finally, as a mainframe professional, I am hoping that you will be willing to complete the annual user survey at www.arcati.com/usersurvey11. If the company you work for is a vendor, consultant, or service provider, then please ensure their information is included in the vendor information form at www.arcati.com/vendorentry.