Experimental Physics and Industrial Control System
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
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024