[Info-vax] tcpip gateway question

[Anton Shterenlikht]

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

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 331 5924