[Info-vax] tcpip gateway question

[Jan-Erik Söderholm]

Anton Shterenlikht wrote:
> On Wed, Sep 09, 2009 at 12:54:32AM +0000, John Santos wrote:
>> In article <mailman.12.1252413824.17612.info-vax_rbnsn.com at rbnsn.com>, 
>> mexas at bristol.ac.uk says...> 
>>> On Tue, Sep 08, 2009 at 11:36:48AM +0000, John Santos wrote:
>>>> In article <mailman.10.1252405909.17612.info-vax_rbnsn.com at rbnsn.com>, 
>>>> mexas at bristol.ac.uk says...> 
>>>>> I've a VMS cluster on a local 10.10.10.0/24 network.
>>>>>
>>>>> I'm trying to set up one of the VMS nodes
>>>>> to also sit on the University network 137.222.0.0/16.
>>>>>
>>>>> So I used tcpip$config and configured the two interfaces as:
>>>>>
>>>>>    1  -  WE0 Menu (EWA0: TwistedPair 100mbps)
>>>>>    2  -  137.222.187.238/16  mech-cluster238       Configured,Active          
>>>>>
>>>>>    3  -  WE1 Menu (EWB0: TwistedPair 100mbps)
>>>>>    4  -  10.10.10.1/24       vav                   Configured,Active          
>>>>>  
>>>>>
>>>>> I added the default University gateway, 137.222.187.250, and
>>>>> name servers 137.222.10.36 and 137.222.10.39 with tcpip$config
>>>>> options
>>>>>                  3  -  Routing               
>>>>>                  4  -  BIND Resolver         
>>>>>
>>>>> I've ssh server and client enabled on this node.
>>>>>
>>>>> My problem is that I cannot even ping the gateway.
>>>>>
>>>>> Does this look reasonable:
>>>>>
>>>>> $ tcpip show route
>>>>>   
>>>>>                              DYNAMIC
>>>>>   
>>>>> Type           Destination                           Gateway
>>>>>   
>>>>> AN    0.0.0.0                               137.222.187.250
>>>>> AN    10.10.10.0/24                         10.10.10.1
>>>>> AH    10.10.10.1                            10.10.10.1
>>>>> AH    127.0.0.1                             127.0.0.1
>>>>> AN    137.222.0.0/16                        137.222.187.238
>>>>> AH    137.222.187.238                       137.222.187.238
>>>>> $ 
>>>>>  
>>>>>
>>>>> many thanks for any advice or a link to a relevant manual.
>>>> Your net mask is almost certainly wrong.  No one has a class B on an
>>>> ethernet segment anymore!  My guess is you can't see the name servers
>>>> because your VMS system is trying to send directly to them and it
>>>> needs to go through your router.
>>>>
>>>> Can you ping the router (137.222.187.250) by address?  If not,
>>>> your LAN might be subnetted to smaller than a /24 and you should
>>>> have a local router to get to the rest of it.  But most likely,
>>>> your netmask should be 255.255.255.0 (/24).  Ask your network
>>>> people...
>>> John, thank you.
>>>
>>> Yes, the netmask should be /24, I just confirmed this with my
>>> networks administrator. I changed the configuration, but the
>>> result is still the same.
>>
>> In another followup, you posted the output of ipconfig and it
>> looked like the netmask had been fixed, but there was still
>> something funny about the broadcast addresses.
>>
>> Both interfaces had a broadcast address of 137.222.255.255,
>> IIRC.  You had noticed that this seemed bogus for the 10.10.10.0
>> network (should be 10.10.10.255, since it's a /24), but
>> also it is wrong for the 137.222.187.0 network (it should be
>> 137.222.187.255 since it's also a /24.)  But I don't know
>> what effect this would have.  Anyone know if it could possible
>> be breaking ARP?
>>
>> I have noticed in the past that if you muck around trying to
>> fix IP configuration stuff in UCX (aka "Hewlitt-Packard
>> Transmission Control Protocol/Internet Protocol Services for
>> OpenVMS", no wonder everyone calls it by the obsolete "UCX"
>> name :-) :-) :-)) it doesn't always reset everything correctly,
>> but if you totally shut down and reboot, it does.  So you can
>> think you've got everything set up correctly (and you're right),
>> but some little difference bites you back.  I've always found
>> these things (like the broadcast mask being wrong) can be fixed
>> without rebooting, but many times the problem isn't obvious!
> 
> I rebooted this node several times, no change.
> 
> In addition to my previous MAC change observation, I discovered
> that all nodes in the cluster have their current MAC addresses
> for the first interface, either EWA0 (alpha) or EIA0 (i64) changed
> to a range of incremental MAC numbers from AA-00-04-00-03-08 to
> -06-08 (4 nodes). However, all MAC addresses for second interfaces,
> EWB0 or EIB0 are left at default settings.
> 
> I'm really puzzled by this. Is this an expected behaviour?
> Is this something to do with VMS cluster or DECnet?
> Can I insist that the current MAC address for a particular
> interface is left as default setting?
> 
> many thanks
> 

DECnet when started change the MAC address. And it's built up
based on the DECnet area.node address in som e way, if I'm not wrong.