RE: How to deal with two network interfaces?

[Vladis Korobov <korobov@mail.desy.de>]

On Tue, 6 Nov 2001, Jeff Hill wrote:

>
> > Vladis Korobov wrote:
> > >
> > >    If CA clients (for example, MEDM screen) connected before the second
> > > interface was attached all is OK. I can get and put PVs from MEDM screen.
> > > But if I close this screen and then try to open it again after "ei" interface
> > > already attached, I can't access anymore the PVs. The same for the telnet
> > > connection to the slave and 'caget' and 'caput' requests.
> >
> > It sounds like the plc network has offerred a "better" TCP/IP route than
> > the sm one, so further connections may be going via the wrong port.  Use
> > routeShow before and after starting the second network and see what
> > routing changes occur.
>
> agree
>
> >
> > >    Is it possible anyhow to coexist for both of these interfaces and not to
> > > interfere with each other: for CA connections to go always via "sm" interface
> > > and for the PLC's ones only via "ei" interface? Or this is impossible,
> > > and the last attached interface becomes the master?
> >
> > It should be, but you may have to reorder your startup slightly.  Jeff
> > Hill will no doubt confirm or contradict this, but I think you may have to
> > start the second network interface before iocInit - there's no way of
> > telling the Channel Access server that a new network interface is present,
> > and I think it may need to know (although that may not be true if you'll
> > only ever use that subnet for PLC communications, never CA.  In that case
> > I suspect your problem is routing, maybe you're not setting the subnet
> > mask for the new interface properly?).
> >
> > You should probably experiment with setting the EPICS_CA_ADDR_LIST
> > environment variable in this configuration too - we found that EPICS
> > running on the Master IOC was generating duplicate beacons (which shows up
> > as excess network traffic and nameserver usage but doesn't stop anything
> > working) and have to set EPICS_CA_AUTO_ADDR_LIST=NO and explicitely set
> > EPICS_CA_ADDR_LIST to get it to work properly.
> >
> > In your case you'll probably need the Master's EPICS_CA_ADDR_LIST set to
> > the broadcast address of the main network segment plus the IP address of
> > the Slave IOC.  On the slave you can stop CA from broadcasting to the PLC
> > network by setting EPICS_CA_ADDR_LIST to the broadcast address of the sm
> > network (or should that be the broadcast of the main network, I'm not sure
> > - Jeff?).
> >
>
> I think that I understand correctly that EPICS is running on the "slave"
> and that the "master" is functioning only as a router.

It's true.

>
> The answer to your questions depends on how the routing is set up in VME
> processor that is functioning only as a vxWorks router. VxWorks routing
> configuration is full of subtle pitfalls so no matter what solution you choose
> I would read carefully the sections in the vxWorks manuals on routing.
> When you are done and things appear to be working correctly I would get
> a copy of the program "casr" present in EPICS R3.14 and verify that there
> are not false CA beacon anomalies occurring on your network resulting from
> bad routes. This can result in excessive CA broadcast traffic if you have
> clients with many unresolved channels. There should be no output from casw
> if IOC are not rebooting. Further, if I was setting this up I would rely
> heavily on use of ping combined with a network sniffer.
>
> It may be possible to set up proxy arp so that the "slave" appears to be
> just another host on the main network. In this case CA will work correctly
> only if you enable CA's ports 5064 and 5065 with proxyPortFwdOn(). This
> approach might be desirable because the CA configuration might
> not differ from the default. The routing set up in your "slave" may not
> be trivial in this case however, but at least this will not impact
> the users when they configure CA clients. I have not set up a vxWorks proxy
> arp networks and I would need to carefully read the manuals before giving
> more specific advise.
>
> Otherwise, if  subnet routing is used then the following will be
> required if the vxWorks router will forward a broadcast for the main network.
>
> On the CA server's host (on the "slave"):
> Set EPICS_CA_AUTO_ADDR_LIST=NO
> Set EPICS_CA_ADDR_LIST to broadcast address of main network
>
> Otherwise, if subnet routing is used then the following will be
> required if vxWorks will not forward a broadcast to the main network.
>
> On the CA server's host (on the "slave"):
> Set EPICS_CA_AUTO_ADDR_LIST=NO
> Set EPICS_CA_ADDR_LIST to the list of hosts that will be a client of
> this IOC.
>
> On a workstation that is on the main network set EPICS_CA_ADDR_LIST
> to the IP address of the "slave" that is an EPICS IOC.
>
> Jeff
>

It was the unlucky coincidence. The subnet address of main network
was 112, and of PLC network was 113. The broadcast address for both
networks was the same 113.255 ! We've changed the subnet address
for the PLC network, assigned it to the new attached interface (and, of
course, changed the broadcast address for this interface to the
PLC broadcast). The route table on the slave after attaching of "ei"
interface looks like:


ROUTE NET TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
0.0.0.0          131.169.112.16   3      2       2109          sm0
131.169.219.0    131.169.219.101  1      1       18516         ei0
131.169.112.0    131.169.112.79   1      5       37894         sm0
------------------------------------------------------------------------

ROUTE HOST TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
131.169.219.0    131.169.219.101  5      0       0             ei0
127.0.0.1        127.0.0.1        5      1       0             lo0
------------------------------------------------------------------------


So, now it works OK. I can access PVs any time. The telnet, 'caget'
and 'caput' also work. I'll test this in more details. In the future
we'd like to have only one board with two hardware interface. Now I
understand, how to configure them.

I thank you all for your advise,

Vladislav.