Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: network problem w/ ioc
From: johill@lanl.gov (Jeff Hill)
To: "Maren Purves" <m.purves@jach.hawaii.edu>, "Dale L. Brewe" <brewe@pnc.aps.anl.gov>
Cc: "Chip Watson" <Chip.Watson@jlab.org>, <tech-talk@aps.anl.gov>
Date: Wed, 25 Aug 1999 14:34:59 -0600
All,

In my experience, specifying a "gateway IP" in the boot parameters
causes a draconian route to be installed which causes _all_ traffic
to be sent to the router (gateway) even if the traffic is for the
IOC's local subnet. If the IOC must boot from off subnet, then a
"gateway IP" must be specified in the boot parameters. If so, then it
nearly always best to, in the startup script, delete the route resulting 
from specifying a "gateway IP" in the boot parameters, and replace it 
with a different route. 

Using routeAdd "0" , "x.x.x.x" causes a default route to be installed 
that sends all traffic that does not match a more specific route to 
a router (gateway). Since there is typically already a route installed 
for the local subnet, this usually results in local traffic being sent
to the local subnet and all other traffic being sent to the router 
(gateway).

It is worth mentioning that careful configuration of the routes can
be used as a crude form of access control. By default IOCs do not have a
route to off subnet hosts unless a "gateway IP" is specified in the boot
parameters. Likewise, a default route (routeAdd "0" , "x.x.x.x") allows
contact with _any_ off subnet machine. Alternatively, you can specify
that only contact with a particular subnet is allowed by specifying
a route to subnet y.y.y.0 through router x.x.x.x (routeAdd "y.y.y.0" , 
"x.x.x.x").

To examine the routes in your vxWorks host type "routeShow".

Jeff

> 
> yes, the routers could act differently depending on how they are/were 
> programmed. We don't use "routeAdd" as long as we stay on the same 
> subnet. I just looked up an old startup file where the ioc (temporarily, 
> we were still testing then) was on a different subnet than the devices 
> it was connected to, and in that case we used a routeAdd that had the 
> router's address and the subnet specified.
> My understanding is that a routeAdd "0" , "x.x.x.x" tells the router 
> that all traffic is going "out" (and the programming of the router
> decides whether "out" really means "out" or not).
> 
> Maren Purves
> 
> 
> Dale L. Brewe wrote:
> > 
> > Chip
> > Well, something along these lines seems plausible, I guess, altho the
> > gateway has not changed, nor have the ioc parameters. However, these
> > problems surfaced a few days after a new main switch/router was 
> installed.
> > Clearly the problem seems to be at a pretty basic level, as I 
> have troubles
> > pinging the ioc with no CA clients running. I haven't found 
> anything that
> > looks bad in either hardware or software. In the  ioc startup, I have
> > routeAdd "0", "x.x.x.x"  for our subnet gateway. Is this 
> correct? It worked
> > before, but could the routers be acting differently for some reason?
> > Dale
> > At 08:08 AM 8/25/99 , Chip Watson wrote:
> > >Dale,
> > >
> > >Your problem is similar to one I tracked down at PSI. If you
> > >have a gateway (default routing node) improperly set in the
> > >boot parameters of the IOC, then the following scenario can
> > >happen:
> > >
> > >(1) the first client connects, but the ioc sends all traffic for
> > >that client through the gateway
> > >
> > >(2) the gateway eventually sends a message to the ioc telling it
> > >what the correct ethernet address for that host is (it doesn't want
> > >to carry traffic unnecessarily)
> > >
> > >(3) the ioc mistakenly updates the gateway address instead of
> > >installing an explicit host entry
> > >
> > >(4) the second client connects, and the ioc attempts to route
> > >all traffic through the gateway again, but now it uses the
> > >"updated" address for the gateway, which is client one
> > >
> > >(5) client one refuses to forward the packets (lazy, huh?), so
> > >the ioc appears to drop off the net for everyone except the
> > >first client to have connected
> > >
> > >Log into the ioc via the console if you can, and you can watch
> > >this scenario play out.  Then, check your boot parameters and
> > >either fix or remove the gateway entry.
> > >
> > >Chip
> 


References:
Re: network problem w/ ioc Maren Purves

Navigate by Date:
Prev: Re: network problem w/ ioc Dale L. Brewe
Next: mv162 vs. VPIC-616 PCI Carrier Bill Brown
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: network problem w/ ioc Dale L. Brewe
Next: mv162 vs. VPIC-616 PCI Carrier Bill Brown
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·