Re: I love TCPIP (not!)
The Hipersockets is strictly internal, and requires the user to point with the actual IP address. The FTP is using the external 10.x.x.x links, and those are connected to a DNS. We can actually get from one LPAR to another LPAR using the domain names, but that does not use the Hipersockets. The /32 defined routes were not used, as they are added dynamically. On Thu, 2 Nov 2006 15:58:57 +0100, Chris Mason [EMAIL PROTECTED] wrote: Matthew Thanks for letting us all know that something now works. However, there are two types of route, those to the Ethernet LAN and those to the Hipersockets links. Which of these supports your FTP work? Have you performed any testing using the other? Did you include the /32 entries that I suggested may have been added dynamically and hence do not need to be among the defined ROUTE statements? Chris Mason - Original Message - From: Matthew Stitt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, 27 October, 2006 9:31 PM Subject: Re: I love TCPIP (not!) Hi Chris; I think we've finally gotten a set of ROUTES definitions that are working. I performed an FTP to the server after settting these up according to your examples, and it worked. I'll keep monitoring things for a while. Thanks for your assistance and patience on this issue. Hopefully some others on this list learned a few things. I know I did. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Matthew Thanks for letting us all know that something now works. However, there are two types of route, those to the Ethernet LAN and those to the Hipersockets links. Which of these supports your FTP work? Have you performed any testing using the other? Did you include the /32 entries that I suggested may have been added dynamically and hence do not need to be among the defined ROUTE statements? Chris Mason - Original Message - From: Matthew Stitt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, 27 October, 2006 9:31 PM Subject: Re: I love TCPIP (not!) Hi Chris; I think we've finally gotten a set of ROUTES definitions that are working. I performed an FTP to the server after settting these up according to your examples, and it worked. I'll keep monitoring things for a while. Thanks for your assistance and patience on this issue. Hopefully some others on this list learned a few things. I know I did. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Hi Chris; I think we've finally gotten a set of ROUTES definitions that are working. I performed an FTP to the server after settting these up according to your examples, and it worked. I'll keep monitoring things for a while. Thanks for your assistance and patience on this issue. Hopefully some others on this list learned a few things. I know I did. On Tue, 24 Oct 2006 21:52:59 +0200, Chris Mason [EMAIL PROTECTED] wrote: Matthew Thanks for the response. There's a bit more detail in the NETSTAT GATE output than in the GATEWAY statement you showed us before and there is a possibly crucial difference in the hipersockets IQDIO1 entry which has managed to acquire a 1 in the third octet where you reported a 0 before. In your 11:04 pm post of Tues, Oct 17 2006, corrected in your 11:19 pm post. you provided the following: GATEWAY 10.0.0.0= Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 192.0.0.0 = IQDIO18192 0.255.255.0 0.0.0.0 DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 But the NETSTAT GATE (and NETSTAT ROUTE) indicates the following: GATEWAY 10.0.0.0= Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 10.2.12.103 = Z990CH41LNK1 1492 HOST 192.0.1.0 = IQDIO18192 0.255.255.0 0.0.0.0 192.0.1.68 = IQDIO18192 HOST DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 The LOOPBACK entry appears because of the following taken from the z/OS V1R8.0 Communications Server IP Configuration Reference manual - which appears, because of revision lines, first explicitly to be mentioned only in this level of the manual: quote 1.2.29 HOME ... The default LOOPBACK address of 127.0.0.1 is internally defined by the TCP/IP stack. If you try to define this LOOPBACK address, it is flagged as a duplicate entry. You can use a link_name value of LOOPBACK in the HOME list to define additional LOOPBACK addresses. No DEVICE or LINK statement is needed for LOOPBACK, and it cannot be started or stopped (LOOPBACK is always active). ... /quote The host entry for 10.2.12.103 is not necessary since it is included in the address range specified by your network 10.2.8.0/mask 255.255.248.0 entry. Also the host entry for 192.0.1.68 is not necessary since it is included in the address range specified by your network 192.0.1.0/mask 255.255.255.0 entry. Once this is converted to a BEGINROUTES/ENDROUTES block, we should have the following: BEGINROUTES ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 ROUTE 10.2.12.103/32 = Z990CH41LNK1 MTU 1492 ROUTE 192.0.1.0/24= IQDIO1MTU 8192 ROUTE 192.0.1.68/32 = IQDIO1MTU 8192 ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 ENDROUTES As I mentioned above, the entries with /32 are not necessary. I'm wondering whether these /32 entries are present in order to support some mechanism which requires host entries to be present in the routing table. Thus they may have been added dynamically. If this BEGINROUTES/ENDROUTES block still does not work - with or without the /32 entries, please post the results of the PING tests I described in an earlier post starting with router 10.2.8.2. As for the hipersockets interface, a PING to any and all of the partner hipersockets interfaces is the only PING test you need. When reading up on hipersockets, I noticed a claim that the hipersockets connections formed a sort-of virtual LAN. I'd be interested in whether a PING command such as 192.0.1.255 managed to elicit a response from each of the hipersockets partner interfaces. I suspect it won't as hipersockets connections probably don't mimic a LAN in all respects. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
In [EMAIL PROTECTED], on 10/18/2006 at 02:00 AM, Chris Mason [EMAIL PROTECTED] said: In fact your GATEWAY entry for the hypersockets routes is incorrect. 192 is a class C network, Is that still relevant with CIDR? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Shmuel I'm afraid that is an irrelevant question. However, you need have no shame in being ignorant of the TCP/IP for VM, later TCP/IP for MVS and Communications Server IP GATEWAY statement. The working of this statement has embedded within it the concepts of the old Class A, B and C networks with, for most of its life, the idea that you are allowed to add to these networks one and only one subnet specification. Whenever defining a non-host route, a host route being a route where a complete IP address is given or to put it another way, the subnet mask is necessarily 255.255.255.255, you need to go through some extraordinary mental contortions in order to define a subnet when the subnet doesn't happen to coincide with a net, Class A, B or C. An interesting consequence of the format of the GATEWAY statement route entry is that it is impossible to define your subnet mask so that it defines a supernet, which is logical in a semantic sense I suppose. In short the GATEWAY statement is completely ignorant of CIDR. If you have been keeping up with this thread you will know that the intent of the OP was to convert from the antediluvian GATEWAY format to the preferred current format of the BEGINROUTES/ENDROUTES block which does follow CIDR in that it allows a contiguous prefix of any length in order to represent a subnet mask. Personally I never understood why there was so much of a song and dance over how routing tables were organised and propagated. Once you needed to take account of a subnet mask, you may as well throw away the old classes and always apply a mask. It is also obvious that you scan routing table entries from the most mask bits to the least mask bits so why make a fuss over limiting the number of sets of masks involved? The major benefit of CIDR is the contiguity requirement which means a 0-32 integer can replace a 32-bit array in storage and transmission. There is also another benefit for the poor network administrator in that he/she can grasp and control what is going on rather more easily than if the bit mask has non-contiguous one bits, a feature which need not faze programming logic. Chris Mason - Original Message - From: Shmuel Metz (Seymour J.) [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, 25 October, 2006 2:49 PM Subject: Re: I love TCPIP (not!) In [EMAIL PROTECTED], on 10/18/2006 at 02:00 AM, Chris Mason [EMAIL PROTECTED] said: In fact your GATEWAY entry for the hypersockets routes is incorrect. 192 is a class C network, Is that still relevant with CIDR? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Ok, sorry it has taken me a little while to respond. Here is the output from the NETSTAT GATE command: EZZ2350I MVS TCP/IP NETSTAT CS V1R7 TCPIP Name: TCPIP 14:32:15 EZZ2635I Known gateways: EZZ2636I NetAddress FirstHopLink Pkt Sz Subnet Mask Subnet Value EZZ2637I -- -- --- -- -- EZZ2638I Defaultnet 10.2.8.2 Z990CH41 1492 none EZZ2638I 10.0.0.0 directZ990CH41 1492 0.255.248.0 0.2.8.0 EZZ2638I 10.2.12.103 directZ990CH41 1492HOST EZZ2638I 127.0.0.1 directLOOPBACK 65535 HOST EZZ2638I 192.0.0.0 directIQDIO1 8192 0.255.255.0 EZZ2638I 192.0.1.68 directIQDIO1 8192HOST And here is the output from the NETSTAT ROUTE command: EZZ2350I MVS TCP/IP NETSTAT CS V1R7 TCPIP Name: TCPIP 14:34:07 EZZ2755I Destination Gateway Flags Refcnt Interface EZZ2756I --- --- - -- - EZZ2757I Default 10.2.8.2 UGS 00 Z990CH41LNK1 EZZ2757I 10.2.8.0/21 0.0.0.0 US00 Z990CH41LNK1 EZZ2757I 10.2.12.103/32 0.0.0.0 UH00 Z990CH41LNK1 EZZ2757I 127.0.0.1/320.0.0.0 UH02 LOOPBACK EZZ2757I 192.0.1.0/240.0.0.0 US00 IQDIO1 EZZ2757I 192.0.1.68/32 0.0.0.0 UH00 IQDIO1 On Fri, 20 Oct 2006 01:01:41 +0200, Chris Mason [EMAIL PROTECTED] wrote: Richard An excellent idea. Matthew Let me build on what Richard is suggesting, in effect, the purely pragmatic approach to creating a BEGINROUTES/ENDROUTES block from your existing GATEWAY statement. Proceed as follows: 1. Set your system up with the working GATEWAY statement. 2. Issue NETSTAT GATE and note how the GATEWAY statement maps into the output of this command. Note that direct under FirstHop is the equivalent of the equal sign, =, and none under Subnet Mask is the equivalent of 0 3. Issue NETSTAT ROUTE and note what appears. 4. Create the BEGINROUTES/ENDROUTES block from what you see in the NETSTAT ROUTE output.You can ignore the Flags and Refcnt columns and you need to interpret 0.0.0.0 under Gateway as an equal sign, =. Also you'll need to add the MTU keyword and value which, in fact, you can discover by using the NETSTAT ROUTE DETAIL command. Perhaps you can let me know how I managed to give you the wrong information concerning how to perform the transformation. If this isn't clear, please post the NETSTAT GATE and NETSTAT ROUTE output. Chris Mason - Original Message - From: Richard Peurifoy [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, 19 October, 2006 10:34 PM Subject: Re: I love TCPIP (not!) Chris Mason wrote: Matthew It worries me that you are testing with FTP which really isn't the place to start when you have problems. Much better is to use PING and, possibly, take a peek at the ARP tables. Another thing to do is use NETSTAT to look at what is actually being used by TCP/IP. NETSTAT GATE will show the routes formated similar to the GATEWAY statments, while NETSTAT ROUTE will show them formated similar to the BEGINROUTES style. This will work weather you use either form of definition, or even for routes from OMPROUTE or redirects if you allow them. Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Matthew Thanks for the response. There's a bit more detail in the NETSTAT GATE output than in the GATEWAY statement you showed us before and there is a possibly crucial difference in the hipersockets IQDIO1 entry which has managed to acquire a 1 in the third octet where you reported a 0 before. In your 11:04 pm post of Tues, Oct 17 2006, corrected in your 11:19 pm post. you provided the following: GATEWAY 10.0.0.0= Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 192.0.0.0 = IQDIO18192 0.255.255.0 0.0.0.0 DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 But the NETSTAT GATE (and NETSTAT ROUTE) indicates the following: GATEWAY 10.0.0.0= Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 10.2.12.103 = Z990CH41LNK1 1492 HOST 192.0.1.0 = IQDIO18192 0.255.255.0 0.0.0.0 192.0.1.68 = IQDIO18192 HOST DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 The LOOPBACK entry appears because of the following taken from the z/OS V1R8.0 Communications Server IP Configuration Reference manual - which appears, because of revision lines, first explicitly to be mentioned only in this level of the manual: quote 1.2.29 HOME ... The default LOOPBACK address of 127.0.0.1 is internally defined by the TCP/IP stack. If you try to define this LOOPBACK address, it is flagged as a duplicate entry. You can use a link_name value of LOOPBACK in the HOME list to define additional LOOPBACK addresses. No DEVICE or LINK statement is needed for LOOPBACK, and it cannot be started or stopped (LOOPBACK is always active). ... /quote The host entry for 10.2.12.103 is not necessary since it is included in the address range specified by your network 10.2.8.0/mask 255.255.248.0 entry. Also the host entry for 192.0.1.68 is not necessary since it is included in the address range specified by your network 192.0.1.0/mask 255.255.255.0 entry. Once this is converted to a BEGINROUTES/ENDROUTES block, we should have the following: BEGINROUTES ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 ROUTE 10.2.12.103/32 = Z990CH41LNK1 MTU 1492 ROUTE 192.0.1.0/24= IQDIO1MTU 8192 ROUTE 192.0.1.68/32 = IQDIO1MTU 8192 ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 ENDROUTES As I mentioned above, the entries with /32 are not necessary. I'm wondering whether these /32 entries are present in order to support some mechanism which requires host entries to be present in the routing table. Thus they may have been added dynamically. If this BEGINROUTES/ENDROUTES block still does not work - with or without the /32 entries, please post the results of the PING tests I described in an earlier post starting with router 10.2.8.2. As for the hipersockets interface, a PING to any and all of the partner hipersockets interfaces is the only PING test you need. When reading up on hipersockets, I noticed a claim that the hipersockets connections formed a sort-of virtual LAN. I'd be interested in whether a PING command such as 192.0.1.255 managed to elicit a response from each of the hipersockets partner interfaces. I suspect it won't as hipersockets connections probably don't mimic a LAN in all respects. Chris Mason - Original Message - From: Matthew Stitt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, 24 October, 2006 4:34 PM Subject: Re: I love TCPIP (not!) Ok, sorry it has taken me a little while to respond. Here is the output from the NETSTAT GATE command: EZZ2350I MVS TCP/IP NETSTAT CS V1R7 TCPIP Name: TCPIP 14:32:15 EZZ2635I Known gateways: EZZ2636I NetAddress FirstHopLink Pkt Sz Subnet Mask Subnet Value 637I -- -- --- -- -- EZZ2638I Defaultnet 10.2.8.2 Z990CH41 1492 none EZZ2638I 10.0.0.0 directZ990CH41 1492 0.255.248.0 0.2.8.0 EZZ2638I 10.2.12.103 directZ990CH41 1492HOST EZZ2638I 127.0.0.1 directLOOPBACK 65535 HOST EZZ2638I 192.0.0.0 directIQDIO1 8192 0.255.255.0 EZZ2638I 192.0.1.68 directIQDIO1 8192HOST And here is the output from the NETSTAT ROUTE command: EZZ2350I MVS TCP/IP NETSTAT CS V1R7 TCPIP Name: TCPIP 14:34:07 EZZ2755I Destination Gateway Flags Refcnt Interface EZZ2756I --- --- - -- - EZZ2757I Default 10.2.8.2 UGS 00 Z990CH41LNK1 EZZ2757I 10.2.8.0/21 0.0.0.0 US00 Z990CH41LNK1 EZZ2757I 10.2.12.103/32 0.0.0.0 UH00 Z990CH41LNK1 EZZ2757I 127.0.0.1/320.0.0.0 UH02 LOOPBACK EZZ2757I 192.0.1.0/240.0.0.0 US00 IQDIO1 EZZ2757I 192.0.1.68/32 0.0.0.0 UH00 IQDIO1
Re: I love TCPIP (not!)
Hi Chris; No I am not using DynamicXCF in the stacks. I need to read up on this and see what the impact is. On Fri, 20 Oct 2006 02:28:39 +0200, Chris Mason [EMAIL PROTECTED] wrote: Matthew I've read up a bit about HiperSockets now and I have a question. Are you using DYNAMICXCF in order to exploit your HiperSockets connections or are you coding the definitions manually? If you are using DYNAMICXCF, the ROUTE statement will be created dynamically from the DYNAMICXCF statement so you will not need to create it yourself. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Matthew It worries me that you are testing with FTP which really isn't the place to start when you have problems. Much better is to use PING and, possibly, take a peek at the ARP tables. Let's start from first principles: There is a LAN, L, which is associated with the IP address range defined by the IP address 10.2.8.0 and subnet mask - as expressed in all implementations of IP except the old TCP/IP for VM product (which was used for TCP/IP for MVS which became the IP component of Communications Server) - 255.255.248.0 or 21 contiguous bits. We know of two interfaces connected to LAN L. One is one of the ports on your OSA feature which must have an address in the range 10.2.8.1 to 10.2.15.254. The other is a router, R, interface with address 10.2.8.2. There may be other interfaces connected to LAN L. The ROUTE statement ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 by itself should allow communication with all interfaces connected to LAN L. Thus, for example, PING 10.2.8.2 should be successful. This is the first test to try. Whether it is successful or not, a display of the ARP table on your system or the router should show MAC addresses associated with the relevant IP addresses. You should, of course, now be able successfully to PING any other interface on LAN L. One trick you might use is to issue the PING command PING 10.2.15.255 This should prompt a response from each of the interfaces connected to LAN L. Adding the ROUTE statement ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 to the ROUTE statement above should now allow communication with all interfaces which can be reached through the router R. One typical IP address to try at this stage is that of your name server - assuming it is not connected to LAN L. I hope it is clear that any PING commands up until now should use IP addresses rather than names! Only now, assuming your FTP partner is reached by means of router R, should you attempt your FTP test. Please report back your findings from these tests. You'll notice I have not mentioned the other route(s) via hypersockets. I haven't worked with this so the only guidance I have on this is your existing GATEWAY entry. If your FTP partner is accessed via hypersockets, let me know - let all of us know - and I/we will try to sort out what might be the problem there. Chris Mason - Original Message - From: Matthew Stitt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, 18 October, 2006 6:51 PM Subject: Re: I love TCPIP (not!) Thanks, Chris. I made the changes you suggested, and the FTP still failed. I wish I knew what in the GATEWAY statements causes it to work, and what in the ROUTES causes it to fail. I know that GATEWAY is out-moded, so that is why I am switching to ROUTES. I really appreciate your assistance and patience. On Wed, 18 Oct 2006 02:00:29 +0200, Chris Mason [EMAIL PROTECTED] wrote: Matthew Here's your GATEWAY statement converted to a BEGINROUTES/ENDROUTES block: GATEWAY 10.0.0.0= Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 192.0.0.0 = IQDIO18192 0.255.255.0 0.0.0.0 DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 to BEGINROUTES ; Where is the gateway? ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 ; The internal hypersockets routes ROUTE 192.0.0.0/24 = IQDIO1MTU 8192 ; All other traffic defaults here ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 ENDROUTES Note that the number of contiguous bits in the mask is 8 for the first octet (byte), 8 for the second octet and 5 for the third octet. the third octet is 5 because 248 = 128(1)+64(2)+32(3)+16(4)+8(5). In fact your GATEWAY entry for the hypersockets routes is incorrect. 192 is a class C network, the first in the class C range in fact. Thus the subnet mask field can be specified as 0 and there will be no subnet value field. As this is strictly an incorrect entry in a GATEWAY statement I would expect the following note from 1.2.27, GATEWAY in z/OS V1R8.0 Communications Server IP Configuration Reference to apply: quote 1. When an incorrect entry in a GATEWAY statement is encountered, it is discarded along with the remaining entries in the GATEWAY statement. All routes defined before the incorrect entry are added to the IP Route Table. Subsequent GATEWAY statements in the same profile data set, or VARY TCPIP,,OBEYFILE command data set, are processed. /quote Thus I would expect the hypersockets route not to be processed and the DEFAULT route not to be processed. However, you say this GATEWAY statement works so maybe the fact that the mask is strictly not necessary is ignored, the mask implied by the class of the network, 255.255.255.0, is ORed with the subnet mask value, 0.255.255.0, and the end result is as required. Syntactically, if not logically in terms of the IP class rules, the statement is correct. Incidentally
Re: I love TCPIP (not!)
Chris Mason wrote: Matthew It worries me that you are testing with FTP which really isn't the place to start when you have problems. Much better is to use PING and, possibly, take a peek at the ARP tables. Another thing to do is use NETSTAT to look at what is actually being used by TCP/IP. NETSTAT GATE will show the routes formated similar to the GATEWAY statments, while NETSTAT ROUTE will show them formated similar to the BEGINROUTES style. This will work weather you use either form of definition, or even for routes from OMPROUTE or redirects if you allow them. Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Richard An excellent idea. Matthew Let me build on what Richard is suggesting, in effect, the purely pragmatic approach to creating a BEGINROUTES/ENDROUTES block from your existing GATEWAY statement. Proceed as follows: 1. Set your system up with the working GATEWAY statement. 2. Issue NETSTAT GATE and note how the GATEWAY statement maps into the output of this command. Note that direct under FirstHop is the equivalent of the equal sign, =, and none under Subnet Mask is the equivalent of 0 3. Issue NETSTAT ROUTE and note what appears. 4. Create the BEGINROUTES/ENDROUTES block from what you see in the NETSTAT ROUTE output.You can ignore the Flags and Refcnt columns and you need to interpret 0.0.0.0 under Gateway as an equal sign, =. Also you'll need to add the MTU keyword and value which, in fact, you can discover by using the NETSTAT ROUTE DETAIL command. Perhaps you can let me know how I managed to give you the wrong information concerning how to perform the transformation. If this isn't clear, please post the NETSTAT GATE and NETSTAT ROUTE output. Chris Mason - Original Message - From: Richard Peurifoy [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, 19 October, 2006 10:34 PM Subject: Re: I love TCPIP (not!) Chris Mason wrote: Matthew It worries me that you are testing with FTP which really isn't the place to start when you have problems. Much better is to use PING and, possibly, take a peek at the ARP tables. Another thing to do is use NETSTAT to look at what is actually being used by TCP/IP. NETSTAT GATE will show the routes formated similar to the GATEWAY statments, while NETSTAT ROUTE will show them formated similar to the BEGINROUTES style. This will work weather you use either form of definition, or even for routes from OMPROUTE or redirects if you allow them. Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Matthew I've read up a bit about HiperSockets now and I have a question. Are you using DYNAMICXCF in order to exploit your HiperSockets connections or are you coding the definitions manually? If you are using DYNAMICXCF, the ROUTE statement will be created dynamically from the DYNAMICXCF statement so you will not need to create it yourself. Chris Mason - Original Message - From: Matthew Stitt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, 18 October, 2006 6:51 PM Subject: Re: I love TCPIP (not!) Thanks, Chris. I made the changes you suggested, and the FTP still failed. I wish I knew what in the GATEWAY statements causes it to work, and what in the ROUTES causes it to fail. I know that GATEWAY is out-moded, so that is why I am switching to ROUTES. I really appreciate your assistance and patience. On Wed, 18 Oct 2006 02:00:29 +0200, Chris Mason [EMAIL PROTECTED] wrote: Matthew Here's your GATEWAY statement converted to a BEGINROUTES/ENDROUTES block: GATEWAY 10.0.0.0= Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 192.0.0.0 = IQDIO18192 0.255.255.0 0.0.0.0 DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 to BEGINROUTES ; Where is the gateway? ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 ; The internal hypersockets routes ROUTE 192.0.0.0/24 = IQDIO1MTU 8192 ; All other traffic defaults here ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 ENDROUTES Note that the number of contiguous bits in the mask is 8 for the first octet (byte), 8 for the second octet and 5 for the third octet. the third octet is 5 because 248 = 128(1)+64(2)+32(3)+16(4)+8(5). In fact your GATEWAY entry for the hypersockets routes is incorrect. 192 is a class C network, the first in the class C range in fact. Thus the subnet mask field can be specified as 0 and there will be no subnet value field. As this is strictly an incorrect entry in a GATEWAY statement I would expect the following note from 1.2.27, GATEWAY in z/OS V1R8.0 Communications Server IP Configuration Reference to apply: quote 1. When an incorrect entry in a GATEWAY statement is encountered, it is discarded along with the remaining entries in the GATEWAY statement. All routes defined before the incorrect entry are added to the IP Route Table. Subsequent GATEWAY statements in the same profile data set, or VARY TCPIP,,OBEYFILE command data set, are processed. /quote Thus I would expect the hypersockets route not to be processed and the DEFAULT route not to be processed. However, you say this GATEWAY statement works so maybe the fact that the mask is strictly not necessary is ignored, the mask implied by the class of the network, 255.255.255.0, is ORed with the subnet mask value, 0.255.255.0, and the end result is as required. Syntactically, if not logically in terms of the IP class rules, the statement is correct. Incidentally, your original post said that the IP addresses of your hypersockets pseudo-LAN., as it appears to be, are 192.10.1.xxx. This isn't what you are now saying. If 192.10.1.xxx is correct, the internal hypersockets routes ROUTE statement would be as follows: ROUTE 192.10.1.0/24 = IQDIO1MTU 8192 Please post again if you need more help. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Thanks, Chris. I made the changes you suggested, and the FTP still failed. I am beginning to understand the subnet mask bit settings, but still have no clue why the Gateway statements work, but not the Route statements. And I do appreciate you being so patient with me. I know the Gateway is not to be used anymore, so I'm just trying to get this stuff to work in every mode. On Wed, 18 Oct 2006 02:00:29 +0200, Chris Mason [EMAIL PROTECTED] wrote: Matthew Here's your GATEWAY statement converted to a BEGINROUTES/ENDROUTES block: GATEWAY 10.0.0.0= Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 192.0.0.0 = IQDIO18192 0.255.255.0 0.0.0.0 DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 to BEGINROUTES ; Where is the gateway? ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 ; The internal hypersockets routes ROUTE 192.0.0.0/24 = IQDIO1MTU 8192 ; All other traffic defaults here ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 ENDROUTES Note that the number of contiguous bits in the mask is 8 for the first octet (byte), 8 for the second octet and 5 for the third octet. the third octet is 5 because 248 = 128(1)+64(2)+32(3)+16(4)+8(5). In fact your GATEWAY entry for the hypersockets routes is incorrect. 192 is a class C network, the first in the class C range in fact. Thus the subnet mask field can be specified as 0 and there will be no subnet value field. As this is strictly an incorrect entry in a GATEWAY statement I would expect the following note from 1.2.27, GATEWAY in z/OS V1R8.0 Communications Server IP Configuration Reference to apply: quote 1. When an incorrect entry in a GATEWAY statement is encountered, it is discarded along with the remaining entries in the GATEWAY statement. All routes defined before the incorrect entry are added to the IP Route Table. Subsequent GATEWAY statements in the same profile data set, or VARY TCPIP,,OBEYFILE command data set, are processed. /quote Thus I would expect the hypersockets route not to be processed and the DEFAULT route not to be processed. However, you say this GATEWAY statement works so maybe the fact that the mask is strictly not necessary is ignored, the mask implied by the class of the network, 255.255.255.0, is ORed with the subnet mask value, 0.255.255.0, and the end result is as required. Syntactically, if not logically in terms of the IP class rules, the statement is correct. Incidentally, your original post said that the IP addresses of your hypersockets pseudo-LAN., as it appears to be, are 192.10.1.xxx. This isn't what you are now saying. If 192.10.1.xxx is correct, the internal hypersockets routes ROUTE statement would be as follows: ROUTE 192.10.1.0/24 = IQDIO1MTU 8192 Please post again if you need more help. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Thanks, Chris. I made the changes you suggested, and the FTP still failed. I wish I knew what in the GATEWAY statements causes it to work, and what in the ROUTES causes it to fail. I know that GATEWAY is out-moded, so that is why I am switching to ROUTES. I really appreciate your assistance and patience. On Wed, 18 Oct 2006 02:00:29 +0200, Chris Mason [EMAIL PROTECTED] wrote: Matthew Here's your GATEWAY statement converted to a BEGINROUTES/ENDROUTES block: GATEWAY 10.0.0.0= Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 192.0.0.0 = IQDIO18192 0.255.255.0 0.0.0.0 DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 to BEGINROUTES ; Where is the gateway? ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 ; The internal hypersockets routes ROUTE 192.0.0.0/24 = IQDIO1MTU 8192 ; All other traffic defaults here ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 ENDROUTES Note that the number of contiguous bits in the mask is 8 for the first octet (byte), 8 for the second octet and 5 for the third octet. the third octet is 5 because 248 = 128(1)+64(2)+32(3)+16(4)+8(5). In fact your GATEWAY entry for the hypersockets routes is incorrect. 192 is a class C network, the first in the class C range in fact. Thus the subnet mask field can be specified as 0 and there will be no subnet value field. As this is strictly an incorrect entry in a GATEWAY statement I would expect the following note from 1.2.27, GATEWAY in z/OS V1R8.0 Communications Server IP Configuration Reference to apply: quote 1. When an incorrect entry in a GATEWAY statement is encountered, it is discarded along with the remaining entries in the GATEWAY statement. All routes defined before the incorrect entry are added to the IP Route Table. Subsequent GATEWAY statements in the same profile data set, or VARY TCPIP,,OBEYFILE command data set, are processed. /quote Thus I would expect the hypersockets route not to be processed and the DEFAULT route not to be processed. However, you say this GATEWAY statement works so maybe the fact that the mask is strictly not necessary is ignored, the mask implied by the class of the network, 255.255.255.0, is ORed with the subnet mask value, 0.255.255.0, and the end result is as required. Syntactically, if not logically in terms of the IP class rules, the statement is correct. Incidentally, your original post said that the IP addresses of your hypersockets pseudo-LAN., as it appears to be, are 192.10.1.xxx. This isn't what you are now saying. If 192.10.1.xxx is correct, the internal hypersockets routes ROUTE statement would be as follows: ROUTE 192.10.1.0/24 = IQDIO1MTU 8192 Please post again if you need more help. Chris Mason - Original Message - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Sorry, the Gateway Default should have been this: DEFAULTNET 10.2.8.2Z990CH41LNK1 1492 0 On Tue, 17 Oct 2006 16:04:40 -0500, Matthew Stitt [EMAIL PROTECTED] wrote: Thanks for the help, Chris. Here are the GATEWAY statements I've been using: 10.0.0.0 = Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 192.0.0.0 = IQDIO1 8192 0.255.255.0 0.0.0.0 DEFAULTNET 9.2.8.2Z990CH41LNK1 1492 0 On Tue, 17 Oct 2006 04:11:18 +0200, Chris Mason [EMAIL PROTECTED] wrote: Matthew I thought you said it worked with Steve's example. Now you say you still have a problem. However, you say you don't have a problem when using the GATEWAY statement. It's very easy to convert a GATEWAY statement to a BEGINROUTES/ENDROUTES block of statements. Perhaps you should post your - working - GATEWAY statement and we can convert it for you. Meantime I'll explain as best as I can the example - derived from Steve's example - I used before - although I'll skip the hypersockets part since I have no experience of that. If your hypersockets doesn't work, we'll have to deal with that separately and I'll need to do some reading. BEGINROUTES ; Where is the gateway? ROUTE 10.1.1.0/24 = ETH1 MTU 8192 ; All other traffic defaults here ROUTE DEFAULT 10.1.1.254 ETH1 MTU 8192 ENDROUTES ROUTE 10.1.1.0/24 = ETH1 MTU 8192 says that all packets in IP address range 10.1.1.1 to 10.1.1.254 are sent *directly* - directly is what the = sign says - over interface ETH1 and the maximum frame size is 8192. Since we are claiming to be able to reach all IP addresses in the range 10.1.1.1 to 10.1.1.254 *directly* over interface ETH1, we are saying that any address in that range can be the subject of an address resolution protocol (ARP) request used in order to get a MAC address for the IP address in an ARP reply. ROUTE DEFAULT 10.1.1.254 ETH1 MTU 8192 says that all other packets are sent *indirectly* and are sent initially to IP interface address 10.1.1.254 over interface ETH1 and the maximum frame size is 8192. You'll note that there will be no difficulty sending packets to IP interface address 10.1.1.254 because we just defined how to send packets to any of the IP addresses in the range 10.1.1.1 to 10.1.1.254 and 10.1.1.254 happens to be one of the IP addresses in that range. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Matthew Here's your GATEWAY statement converted to a BEGINROUTES/ENDROUTES block: GATEWAY 10.0.0.0= Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 192.0.0.0 = IQDIO18192 0.255.255.0 0.0.0.0 DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 to BEGINROUTES ; Where is the gateway? ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 ; The internal hypersockets routes ROUTE 192.0.0.0/24 = IQDIO1MTU 8192 ; All other traffic defaults here ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 ENDROUTES Note that the number of contiguous bits in the mask is 8 for the first octet (byte), 8 for the second octet and 5 for the third octet. the third octet is 5 because 248 = 128(1)+64(2)+32(3)+16(4)+8(5). In fact your GATEWAY entry for the hypersockets routes is incorrect. 192 is a class C network, the first in the class C range in fact. Thus the subnet mask field can be specified as 0 and there will be no subnet value field. As this is strictly an incorrect entry in a GATEWAY statement I would expect the following note from 1.2.27, GATEWAY in z/OS V1R8.0 Communications Server IP Configuration Reference to apply: quote 1. When an incorrect entry in a GATEWAY statement is encountered, it is discarded along with the remaining entries in the GATEWAY statement. All routes defined before the incorrect entry are added to the IP Route Table. Subsequent GATEWAY statements in the same profile data set, or VARY TCPIP,,OBEYFILE command data set, are processed. /quote Thus I would expect the hypersockets route not to be processed and the DEFAULT route not to be processed. However, you say this GATEWAY statement works so maybe the fact that the mask is strictly not necessary is ignored, the mask implied by the class of the network, 255.255.255.0, is ORed with the subnet mask value, 0.255.255.0, and the end result is as required. Syntactically, if not logically in terms of the IP class rules, the statement is correct. Incidentally, your original post said that the IP addresses of your hypersockets pseudo-LAN., as it appears to be, are 192.10.1.xxx. This isn't what you are now saying. If 192.10.1.xxx is correct, the internal hypersockets routes ROUTE statement would be as follows: ROUTE 192.10.1.0/24 = IQDIO1MTU 8192 Please post again if you need more help. Chris Mason - Original Message - From: Matthew Stitt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, 17 October, 2006 11:19 PM Subject: Re: I love TCPIP (not!) Sorry, the Gateway Default should have been this: DEFAULTNET 10.2.8.2Z990CH41LNK1 1492 0 On Tue, 17 Oct 2006 16:04:40 -0500, Matthew Stitt [EMAIL PROTECTED] wrote: Thanks for the help, Chris. Here are the GATEWAY statements I've been using: 10.0.0.0 = Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 192.0.0.0 = IQDIO1 8192 0.255.255.0 0.0.0.0 DEFAULTNET 9.2.8.2Z990CH41LNK1 1492 0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
My situation really is quite simple. I've got a network which is 10.xxx.xxx.xxx.xxx. Let's use 10.2.12.xxx as my home address. I also have an internal hipersockets address of 192.0.1.xxx. This is the configuration for all the images. As an example (a very good one), if I start a batch FTP to 10.17.252.62, I get a connection failed to respond timeout. If I use the GATEWAY statements, I do not have this problem. And thanks for the help. On Sat, 14 Oct 2006 17:54:40 +0200, Chris Mason [EMAIL PROTECTED] wrote: Matthew Sorry for the delay, I'm cleaning up posts to which I intended to reply. It may work but it won't necessarily work well. When packets are destined beyond the adjacent (gateway) router, all is = well. However, if packets are destined for another node on the same = LAN/subnetwork as the OSA feature and the adjacent router, they will go = first to the adjacent router and then to their destination, two hops = where one suffices. The adjacent router will see that a better route = exists and will potentially update your routing table using an ICMP = redirect. Thus you should see a single host routing entry for each = such destination. You may have no such destinations so it won't be an = issue. Of course, you can prevent ICMP redirects packets from adding = entries to your routing table. If you do that, you will continue with = the inefficiency of having the same packets sent twice over the same LAN = outbound.=20 I had something of a frown when I saw Steve's technique. More usual is = to replace his Where's the gateway? entry with a subnetwork route. = However, Steve can be excused I suppose because you didn't give = sufficient information. We need to know the subnetwork mask for the LAN = to which the OSA feature is attached and the remainder of the IP address = for that subnetwork. If we assume that it is 255.255.255.0 or /24 in = terms of the way a ROUTE entry is defined, that the IP address of the = subnetwork is 10.1.1.0 and that the IP address of the adjacent router is = 10.1.1.254, Steve's example becomes the following: BEGINROUTES ; All hypersocket traffic - Use your interface, not HIPERLF6 ROUTE 192.10.1.0/24 =3D HIPERLF6 MTU 8192 ; Where is the gateway? ROUTE 10.1.1.0/24 =3D ETH1 MTU 8192 ; All other traffic defaults here ROUTE DEFAULT 10.1.1.254 ETH1 MTU 8192 ENDROUTES I've also set the jumbo frame size MTU throughout on the assumption = you have Gigabit Ethernet and that you have Path MTU discovery active - = and, preferably, respected by the other routers in your network. Incidentally John McKown's templates fall down a bit on syntax as you = can probably see. Also under gateway_ipaddr in section 1.2.9, = BEGINROUTES in z/OS V1R8.0 Communications Server IP Configuration = Reference you will find the sentence The equal sign is not supported = for DEFAULT or DEFAULT6 route entry.. This means that Steve's Where's = the gateway ROUTE statement is always required and that, minimally, = there is the then just a need for a DEFAULT ROUTE statement, that is, = minimally there must be two ROUTE statements in order to be able to = specify a DEFAULT ROUTE statement. Chris Mason Previous posts in the thread: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Matthew I thought you said it worked with Steve's example. Now you say you still have a problem. However, you say you don't have a problem when using the GATEWAY statement. It's very easy to convert a GATEWAY statement to a BEGINROUTES/ENDROUTES block of statements. Perhaps you should post your - working - GATEWAY statement and we can convert it for you. Meantime I'll explain as best as I can the example - derived from Steve's example - I used before - although I'll skip the hypersockets part since I have no experience of that. If your hypersockets doesn't work, we'll have to deal with that separately and I'll need to do some reading. BEGINROUTES ; Where is the gateway? ROUTE 10.1.1.0/24 = ETH1 MTU 8192 ; All other traffic defaults here ROUTE DEFAULT 10.1.1.254 ETH1 MTU 8192 ENDROUTES ROUTE 10.1.1.0/24 = ETH1 MTU 8192 says that all packets in IP address range 10.1.1.1 to 10.1.1.254 are sent *directly* - directly is what the = sign says - over interface ETH1 and the maximum frame size is 8192. Since we are claiming to be able to reach all IP addresses in the range 10.1.1.1 to 10.1.1.254 *directly* over interface ETH1, we are saying that any address in that range can be the subject of an address resolution protocol (ARP) request used in order to get a MAC address for the IP address in an ARP reply. ROUTE DEFAULT 10.1.1.254 ETH1 MTU 8192 says that all other packets are sent *indirectly* and are sent initially to IP interface address 10.1.1.254 over interface ETH1 and the maximum frame size is 8192. You'll note that there will be no difficulty sending packets to IP interface address 10.1.1.254 because we just defined how to send packets to any of the IP addresses in the range 10.1.1.1 to 10.1.1.254 and 10.1.1.254 happens to be one of the IP addresses in that range. Chris Mason - Original Message - From: Matthew Stitt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, 16 October, 2006 5:35 PM Subject: Re: I love TCPIP (not!) My situation really is quite simple. I've got a network which is 10.xxx.xxx.xxx.xxx. Let's use 10.2.12.xxx as my home address. I also have an internal hipersockets address of 192.0.1.xxx. This is the configuration for all the images. As an example (a very good one), if I start a batch FTP to 10.17.252.62, I get a connection failed to respond timeout. If I use the GATEWAY statements, I do not have this problem. And thanks for the help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Matthew Sorry for the delay, I'm cleaning up posts to which I intended to reply. It may work but it won't necessarily work well. When packets are destined beyond the adjacent (gateway) router, all is = well. However, if packets are destined for another node on the same = LAN/subnetwork as the OSA feature and the adjacent router, they will go = first to the adjacent router and then to their destination, two hops = where one suffices. The adjacent router will see that a better route = exists and will potentially update your routing table using an ICMP = redirect. Thus you should see a single host routing entry for each = such destination. You may have no such destinations so it won't be an = issue. Of course, you can prevent ICMP redirects packets from adding = entries to your routing table. If you do that, you will continue with = the inefficiency of having the same packets sent twice over the same LAN = outbound.=20 I had something of a frown when I saw Steve's technique. More usual is = to replace his Where's the gateway? entry with a subnetwork route. = However, Steve can be excused I suppose because you didn't give = sufficient information. We need to know the subnetwork mask for the LAN = to which the OSA feature is attached and the remainder of the IP address = for that subnetwork. If we assume that it is 255.255.255.0 or /24 in = terms of the way a ROUTE entry is defined, that the IP address of the = subnetwork is 10.1.1.0 and that the IP address of the adjacent router is = 10.1.1.254, Steve's example becomes the following: BEGINROUTES ; All hypersocket traffic - Use your interface, not HIPERLF6 ROUTE 192.10.1.0/24 =3D HIPERLF6 MTU 8192 ; Where is the gateway? ROUTE 10.1.1.0/24 =3D ETH1 MTU 8192 ; All other traffic defaults here ROUTE DEFAULT 10.1.1.254 ETH1 MTU 8192 ENDROUTES I've also set the jumbo frame size MTU throughout on the assumption = you have Gigabit Ethernet and that you have Path MTU discovery active - = and, preferably, respected by the other routers in your network. Incidentally John McKown's templates fall down a bit on syntax as you = can probably see. Also under gateway_ipaddr in section 1.2.9, = BEGINROUTES in z/OS V1R8.0 Communications Server IP Configuration = Reference you will find the sentence The equal sign is not supported = for DEFAULT or DEFAULT6 route entry.. This means that Steve's Where's = the gateway ROUTE statement is always required and that, minimally, = there is the then just a need for a DEFAULT ROUTE statement, that is, = minimally there must be two ROUTE statements in order to be able to = specify a DEFAULT ROUTE statement. Chris Mason Previous posts in the thread: Matthew Stitt Tues, Jul 25 2006 10:48 pm Having fun with TCPIP. Got some systems which use the GATEWAY = statements. I want to convert them to ROUTE statements. I also have an = OSA port and a HiperSockets port defined. I want the traffic between the LPARS to use the HiperSockets, and = everything else to use the OSA port. Default route to use the OSA port. OSA is 10.x.x.x for all traffic. HiperSocket is 192.10.x.x for traffic. = Each LPAR is 192.10.1.xxx. Would someone care to help get this stuff working the way I want? --- McKown, John Tues, Jul 25 2006 11:11 pm First, change to the BEGINROUTES/ENDROUTES. It is significantly easier = to maintain=20 BEGINROUTES=20 ROUTE 10.0.0.0/8 osa MTU nnn=20 ROUTE 192.10.0.0/16 hipersocket MTU nnn=20 ROUTE DEFAULT =3D osa MTU nnn=20 ENDROUTES The will route all the 10.x.x.x addresses out the osa. The second will = route all the 192.10.x.x addresses out the hipersocket. It will then = route all other addresses out the osa. Yes, technically, the first ROUTE = of the 10.x.x.x is unnecessary because the DEFAULT will catch it. But I=20 like to have it in there anyway. Note that you can also have: BEGINROUTES=20 ROUTE 10.0.0.0/8 osa1 MTU nnn=20 ROUTE 10.0.0.0/8 osa2 MTU nnn=20 ..=20 ROUTE DEFAULT =3D osa1 MTU nnn=20 ROUTE DEFAULT =3D osa2 MTU nnn=20 ENDROUTES --- Steve Arnett Thurs, Jul 27 2006 6:51 pm Here is what I would use...others may object...grin... BEGINROUTES=20 ; All hypersocket traffic - Use your interface, not HIPERLF6=20 ROUTE 192.10.1.0/24 =3D HIPERLF6 MTU 8192 =20 ; Where is the gateway?=20 ROUTE 10.xxx.xxx.xxx/32 =3D ETH1 MTU 1492=20 ; All other traffic defaults here=20 ROUTE DEFAULT 010.xxx.xxx.xxx ETH1 MTU 1492=20 ENDROUTES =20 ; 10.xxx.xxx.xxx is your gateway address --- Matthew Stitt Thurs, Jul 27 2006 9:47 pm=20 Well, they can laugh all they want. It works. After I realized you = meant for me to substitute the actual IP address of my gateway for the=20 10.xxx.xxx.xxx example. Thanks a great bunch, Steve -- For IBM-MAIN subscribe
Re: I love TCPIP (not!)
Hree is what I would use...others may object...grin... BEGINROUTES ; All hypersocket traffic - Use your interface, not HIPERLF6 ROUTE 192.10.1.0/24 = HIPERLF6 MTU 8192 ; Where is the gateway? ROUTE 10.xxx.xxx.xxx/32 = ETH1 MTU 1492 ; All other traffic defaults here ROUTE DEFAULT 010.xxx.xxx.xxx ETH1 MTU 1492 ENDROUTES ; 10.xxx.xxx.xxx is your gateway address Matthew Stitt wrote: Having fun with TCPIP. Got some systems which use the GATEWAY statements. I want to convert them to ROUTE statements. I also have an OSA port and a HiperSockets port defined. I want the traffic between the LPARS to use the HiperSockets, and everthing else to use the OSA port. Default route to use the OSA port. OSA is 10.x.x.x for all traffic. HiperSocket is 192.10.x.x for traffic. Each LPAR is 192.10.1.xxx. Would someone care to help get this stuff working the way I want? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
Well, they can laugh all they want. It works. After I realized you meant for me to sustitue the actual IP address of my gateway for the 10.xxx.xxx.xxx example. Thanks a great bunch, Steve. On Thu, 27 Jul 2006 11:51:01 -0500, Steve Arnett [EMAIL PROTECTED] wrote: Hree is what I would use...others may object...grin... BEGINROUTES ; All hypersocket traffic - Use your interface, not HIPERLF6 ROUTE 192.10.1.0/24 = HIPERLF6 MTU 8192 ; Where is the gateway? ROUTE 10.xxx.xxx.xxx/32 = ETH1 MTU 1492 ; All other traffic defaults here ROUTE DEFAULT 010.xxx.xxx.xxx ETH1 MTU 1492 ENDROUTES ; 10.xxx.xxx.xxx is your gateway address Matthew Stitt wrote: Having fun with TCPIP. Got some systems which use the GATEWAY statements. I want to convert them to ROUTE statements. I also have an OSA port and a HiperSockets port defined. I want the traffic between the LPARS to use the HiperSockets, and everthing else to use the OSA port. Default route to use the OSA port. OSA is 10.x.x.x for all traffic. HiperSocket is 192.10.x.x for traffic. Each LPAR is 192.10.1.xxx. Would someone care to help get this stuff working the way I want? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I love TCPIP (not!)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Stitt Sent: Tuesday, July 25, 2006 3:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: I love TCPIP (not!) Having fun with TCPIP. Got some systems which use the GATEWAY statements. I want to convert them to ROUTE statements. I also have an OSA port and a HiperSockets port defined. I want the traffic between the LPARS to use the HiperSockets, and everthing else to use the OSA port. Default route to use the OSA port. OSA is 10.x.x.x for all traffic. HiperSocket is 192.10.x.x for traffic. Each LPAR is 192.10.1.xxx. Would someone care to help get this stuff working the way I want? Thanks First, change to the BEGINROUTES/ENDROUTES. It is significantly easier to maintain BEGINROUTES ROUTE 10.0.0.0/8 osa MTU nnn ROUTE 192.10.0.0/16 hipersocket MTU nnn ROUTE DEFAULT = osa MTU nnn ENDROUTES The will route all the 10.x.x.x addresses out the osa. The second will route all the 192.10.x.x addresses out the hipersocket. It will then route all other addresses out the osa. Yes, technically, the first ROUTE of the 10.x.x.x is unnecessary because the DEFAULT will catch it. But I like to have it in there anyway. Note that you can also have: BEGINROUTES ROUTE 10.0.0.0/8 osa1 MTU nnn ROUTE 10.0.0.0/8 osa2 MTU nnn ... ROUTE DEFAULT = osa1 MTU nnn ROUTE DEFAULT = osa2 MTU nnn ENDROUTES -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
