[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference lassie::ucx

Title:DEC TCP/IP Services for OpenVMS
Notice:Note 2-SSB Kits, 3-FT Kits, 4-Patch Info, 7-QAR System
Moderator:ucxaxp.ucx.lkg.dec.com::TIBBERT
Created:Thu Nov 17 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5568
Total number of notes:21492

5305.0. "Can UCX interfaces have diff. subnet masks?" by SNOFS2::JEYACHANDRAN () Thu Mar 06 1997 01:02

This is cust network diagram.

 Other sub-nets                                                 255.255.255.0
   |    |    |                                            203.0.117      |
   |    |    |                                            255.255.255.0  |
   |    |    |                   =============                  |        |
   |    |    |             WE0   |  CLK206   |   WE1            |        |
   |    |    |         10.2.32.66| Alpha VMS | 10.2.15.22       |        |
[Router 10.2.32.1]===============| 6.2-1H3   |===============[Router 10.2.8.1]
[Router 10.2.32.2] 255.255.252.0 | UCX v4.1  | 255.255.248.0 [Router 10.2.8.2]
   |    |    |                   |           |                  |        |
   |    |    |                   =============                  |        |
   |    |    |                   Default route                  |        |
   |    |    |                     10.2.32.1              203.0.118      |
   |    |    |                                            255.255.255.0  |
 Other sub-nets

WE0 interface has subnet mask 255.255.252.0
WE1 interface has subnet mask 255.255.248.0

Currently the routes are as follows:

                             DYNAMIC database

Type           Destination                           Gateway

AH    141.251.224.217                       10.2.32.2
AH    127.0.0.1                             127.0.0.1
AN    10.2.8.0                              10.2.15.22
AN    0.0.0.0                               10.2.32.1
AN    10.2.32.0                             10.2.32.66


Five questions:

1) Cust is setting up the UCX node to be nonrouting node & sets up static 
   routes only selected networks. The BAY routers use OSPF routing protocol
   so that variable subnet mask can be used. Can UCX handle 2 different 
   interfaces with different subnet masks?
2) If it can, then how does the routing decision take place as to which
   subnet mask has to be applied for a network address? 
3) With the above routing table, ping to 10.2.15.22 (interface WE1) fails, 
   but ping to 10.2.8.1 succeeds. Ping to WE0 interface address always
   succeeds. If I add an entry after deleting the entry for 10.2.8.0,
	"ucx>set route 10.2.15.0/gate=10.2.15.22/net"
   then ping to 10.2.15.22 succeeds & ping to 10.2.8.1 also succeeds.
   Any reason?

        subnet mask     11111111 11111111 11111  000 00000000
        10.2.15.22      00001010 00000010 00001  111 00010110
        10.2.8.1        00001010 00000010 00001  000 00000001

4) Is it possible to set up multiple (static) default routes to ensure a 
   redundant path if the primary router dies?

5) Addition of the following entries gives an error message.

                203.0.117.0
                203.0.118.0
                203.15.144.0 

        I would have thought a command below should work.

        UCX> set route 203.0.117.0/network/gateway=10.2.8.1
        %UCX-E-ROUTEERROR, Error processing ROUTE request
        -SYSTEM-F-UNREACHABLE, remote node is not currently reachable

        10.2.8.1 is pingable and is a Bay router.

	If I change the entry to point to the WE1 interface address -
 	UCX> set route 203.0.117.0/network/gateway=10.2.15.22,
	then route works OK.
	What is the reason?

Thanks in advance.

Daniel.

CSC, Sydney.
T.RTitleUserPersonal
Name
DateLines
5305.1Can UCX support diff mask on diff. interfaces?SNOFS2::JEYACHANDRANThu Mar 06 1997 20:428
	To make the whole thing simple - Can UCX support multiple interfaces
	with different subnet masks?

	If the answer is no, then I don' need any more help.

	Thanks in advance.

	Daniel.
5305.2Still listening!SNOFS2::JEYACHANDRANSun Mar 09 1997 17:514
	I am still listening. 

	Regards.
	Daniel.
5305.3Answer to my own queries.SNOFS2::JEYACHANDRANWed Mar 12 1997 22:4231
	With no official response for my queries, I have found the answer 
	myself.

Different Subnet masks on different interfaces:

	UCX **does not** support different subnet masks for each interface.
	The subnet mask for the first interface becomes the subnet mask for
	the entire box, though UCX allows you to configure subnet mask which
	is diff. from that of the first interface.

	This was proved by pinging different addreses. When a static route is 
	set for 10.2.8.0 network on the interface address 10.2.15.22, pinging 
	to  10.2.15.22 fails because this address happens to be on a diff. 
	subnet if you apply the mask of the first interface 255.255.252.0 in 
	stead of the mask 255.255.248.0 which is of the 2nd interface. 
	By swapping the address & the subnet mask between the interfaces, 
	ie., by making WE0 to have the address 10.2.15.22 with subnet mask of 
	255.255.248.0, pinging to 10.2.15.22 succeeds because 10.2.15.22 is 
	on the same subnet as 10.2.8.0 (subnet mask of 255.255.248.0). 

	We tried pinging several other addresses & the theory holds good.

Multiple Default Routes:

	M. T Hollinger has stated in another Notes entry that this is still in 
	the wish list & not implemented even in UCX V4.1


Daniel.

CSC, Sydney.
5305.4Isn't IP wonderful......twick.nio.dec.com::PETTENGILLmulpFri Mar 14 1997 02:4626
The world of working standards defines standards that don't specify the
whether or not this should work, in part because a large amount of the
code that is the basis for demonstrating that the existing can be implemented
don't support it.  (UCX happens to be derived from the primary implementation.)
But it also doesn't preclude it because it is useful and generally good.
Besides, to avoid having lots of complex and confusing standards, it is
better to not write a standard that would seem to imply that it should be
or is not supported; besides that would lead to technical and political wars.

This is a much better situation than, for example OSI, where issues such
as this are answered by referring to standards documents with one of three
outcomes:
	Bay is broken
	UCX is broken
	the standard is broken.

Here we have a much nicer situation,  Everything is according to spec.

This is a user error.

Of course, the fault really lies with VMS; VMS prevents IP from working
correctly.  Or is it the fact that its a DEC product.

(In a bad mood because I'm spending way too much time on nonsense, with
one sinkhole being IP dealing with the technical and political issues
which are closely related to the above problem.)