IBM Support

Routing with the Netfinity ESCON Adapter - Servers

Troubleshooting


Problem

Routing with the Netfinity ESCON Adapter for Servers.

Resolving The Problem

Source
RETAIN tip H17205

Overview
This tip is on how to handle routing when using the Netfinity ESCON adapter.

Affected configurations
The system is any of the following IBM servers:

  • a Netfinity 7000-M10 server, Type 8680, any Model.
  • a Netfinity 7000 server, Type 8651, any Model.
  • a Netfinity 5500-M20 server, Type 8662, any Model.
  • a Netfinity 5500-M10 server, Type 8661, any Model.
  • a Netfinity 5500 server, Type 8660, any Model.
  • a Netfinity 5000 server, Type 8659, any Model.

The system is configured with the following option:
  • Netfinity ESCON Adapter, Option p/n10L7358, FRU p/n10L7439

Solution

Routing with the Netfinity ESCON Adapter.

Scenarios

1. Default configuration (No IP forwarding enabled, No Routing service installed).
With Channel-to-Channel (CTC), the ESCON link with the host, is on it's own network or subnetwork and the LAN Adapters are on their own networks. Without further configuration, this means that the Host can communicate with the Netfinity, and a LAN device can communicate with the Netfinity. But the Host cannot reach a LAN device via the Netfinity, or vise versa.

This configuration produces the least amount of network traffic and is preferred if all traffic from the host is intended only for the Netfinity, i.e., the IP application that the host seeks a connection with is running on the Netfinity. This configuration is also the most secure since no one can access the Host via the ESCON Connection.

2. IP Forwarding enabled (with No Routing service installed).

This feature in the NT TCP/IP configuration, will allow packets to pass through the Netfinity server. However, since the Netfinity is not routing (or broadcasting routes), either the client or an external router must have a static route defined showing the Netfinity as the path to the destination (IBM host) network. In this case, if a LAN client on the same Ethernet segment as the Netfinity sends a packet to the Host address that is on the Netfinity's ESCON segment, either the client or it's router will recognize the Address and send it to the Netfinity who will forward it to the host. Remote Clients may also access the Host but only if the router has broadcast the Static route.

The IBM host must also have a route defined for the originating network. Otherwise, a packet may come to the host via ESCON, but the response may be routed back by the IBM host over a different link. This method can be very efficient for allowing traffic to flow through the Netfinity to local networks and predetermined routes. It is not intelligent and does not make or maintain any routing tables - all routing is external and must be manually configured. It is ideal for allowing a limited number of clients connect via the Netfinity.

3. IP Forwarding and Routing Service.

NT comes with a Routing service that supports RIP. Other Routing protocols are available. With this method the Netfinity will be a router - maintaining Routes, broadcasting it's routing table to other Routers, and building it's routing table from received routing broadcasts. This is the best method if you want all routes on the host and LAN to be available. This eliminates the need for manual configuration of static routes.

The routing is only limited by restrictions imposed by the Host configuration or LAN Router configuration. The down side of this method would be additional processor utilization required by the Routing protocol (probably not significant), additional traffic caused by the routing protocol, and ensuring necessary security.

Case Notes

1. RIP is running on the IBM Host (OROUTED), but not on NT.

The PTP (point-to-point, CTC or MPCPTP) link must be defined as passive in TCPIP.ETC.GATEWAYS dataset.

2. RIP is running on IBM HOST (OROUTED), and NT.

a. Subnets must be used. The Host recognizes subnet broadcasts but not generic network broadcasts.

b. The IBM Routing table can be viewed using the MVS command "Netstat Route". This table is generated from the BSDROUTINGPARMS, TCPIP.ETC.GATEWAYS, and RIP packets. If a network is defined in RIP packets from multiple links, METRICs (hops) are used to determine the route to be added to the routing table. An undesirable route can be discouraged by adding METRICs in the BSDROUTINGPARMS. Static routes can be added in the TCPIP.ETC.GATEWAYS.

3. RIP is enabled on NT but not on IBM Host.

a. Make the PTP link the default route in the IBM configuration or,

b. Define all networks in the Gateways section of TCPIP.PROFILE. Otherwise clients will be able to send packets to the Host, but the Host will not respond or will send the responses over another link.

Debugging ROUTES

A. MVS

- Use the MVS NETSTAT GATE command for static routing (Gateways in TCPIP.PROFILE)
- Use the MVS NETSTAT ROUTE command for OROUTED

B. NT

- Use the ROUTE PRINT command to view routing table (if RIP is enabled).

- Use TRACERT xxx.xxx.xxx.xxx to show all the hops in path.

C. Send and Receive verification

It is important to verify that data is sent and received over the desired link.

NETMON can be used on the NT server for this purpose. A common problem is for data to go in one door and out another, resulting in poor performance.

- Ping the host from a client, both the ICMP echo and reply should be seen in the NETMON trace.

- Ping the client from the host, both the ICMP echo and reply should be seen in the NETMON trace.
 

Document Location

Worldwide

Operating System

Older System x:Operating system independent / None

[{"Type":"HW","Business Unit":{"code":"BU016","label":"Multiple Vendor Support"},"Product":{"code":"HWN01","label":"Older System x->Netfinity 7000"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Line of Business":{"code":"","label":""}},{"Type":"HW","Business Unit":{"code":"BU016","label":"Multiple Vendor Support"},"Product":{"code":"HWN04","label":"Older System x->Netfinity 5500"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Line of Business":{"code":"","label":""}},{"Type":"HW","Business Unit":{"code":"BU016","label":"Multiple Vendor Support"},"Product":{"code":"HWN05","label":"Older System x->Netfinity 5000"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Line of Business":{"code":"","label":""}},{"Type":"HW","Business Unit":{"code":"BU016","label":"Multiple Vendor Support"},"Product":{"code":"HWN18","label":"Older System x->Netfinity 5500 M10"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Line of Business":{"code":"","label":""}},{"Type":"HW","Business Unit":{"code":"BU016","label":"Multiple Vendor Support"},"Product":{"code":"HWN19","label":"Older System x->Netfinity 5500 M20"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Line of Business":{"code":"","label":""}},{"Type":"HW","Business Unit":{"code":"BU016","label":"Multiple Vendor Support"},"Product":{"code":"HWN20","label":"Older System x->Netfinity 7000 M10"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
28 January 2019

UID

ibm1MIGR-4HVR6R