Chuck,

Thanks for your response.

> > Here's an example of some stuff in /etc/rc.conf:
> > 
> >  ifconfig_fxp0="inet 66.220.13.226/28 media 100baseTX mediaopt full-duplex"
> >  ifconfig_fxp0_alias0="inet 192.168.64.10/32"
> >  ifconfig_fxp0_alias1="inet 66.220.13.227/32"
> >  ifconfig_fxp0_alias2="inet 66.220.13.230/32"
> >  ifconfig_fxp1="inet 192.168.64.11/32"
> >  ifconfig_lo0_alias0="inet 192.168.64.9/32"
> >  ifconfig_lo0_alias1="inet 192.168.65.3/32"
> >  ifconfig_lo0_alias2="inet 192.168.65.5/32"
> > 
> > The problem is that I'm seeing the following lines repeated in my syslog:
> > 
> >  arp_rtrequest: bad gateway 192.168.64.10 (!AF_LINK)
> >  arp_rtrequest: bad gateway 66.220.13.227 (!AF_LINK)

> I infer you are trying to set up other machines (or a local jail?) on
> something like 192.168.64.8 or .4 which are trying to ARP for their
> router.

I've got public IPs for certain machines and services and a NAT firewall
that redirects these public services to private IP space behind the NAT
firewall.  I have a subnet of private IP space for interfaces (which are
bound to those interfaces), private IP space for machines and also for
the actual "services" that are being provided (bound to lo0, as I don't
care how packets get there and sometimes interfaces fail).

I have traditionally bound the "service" IPs to lo0, and it has been
working for me for a long time (this has usually been on machines with
one active NIC, however).  This lets me easily move "services" to a new
machine with very little effort.

> It doesn't make sense to do ARP over the loopback, and
> anyway, a real NIC and the loopback use different framing types.  What
> happens if you change:
>
> >  ifconfig_lo0_alias0="inet 192.168.64.9/32"
> 
> ...and so forth to:
> 
> >  ifconfig_fxp1_alias0="inet 192.168.64.9/32"
> 
> ...?

I'm not having any problems with any of the aliases on the loopback
interface, just the first two aliased IPs on fxp0.

> Oh, yes, and this does not make sense, either:
> 
> >  ifconfig_fxp0_alias0="inet 192.168.64.10/32"
> 
> ...and people put their internal 192.168 subnet as a /24:

That's one of the addresses that is causing problems.  I did not use a
wider netmask as I do not intend to route all traffic for that network
on that interface.

I have these machines set up to route packets over their interfaces.  I
was hoping/expecting that the internal routing tables would DTRT, and
also handle the case where the failure of a network interface would not
cause much trouble, as the systems could automatically handle this with
simple changes to the routing tables.

> >  ifconfig_fxp1="inet 192.168.64.11/32"

> Most unusual.  People normally only need to use IP aliases when your
> renumber an existing system and some other machine which can't be
> changed easily still needs to talk to that host using the old IP, or
> if you need to host multiple instances of something like an SSL-based
> webserver which demand a separate IP for each site due to the protocol
> limitations.

I answered this one earlier; I'm keeping your paragraph here in case I
missed something.

> If you have two NICs, they should be on separate subnets, in separate
> collision domains, unless you are doing channel bonding/CARP/FEC, in
> which case they must be specially configured for that purpose (and
> therefore would be on the same subnet only).

The NICs are, I believe, on separate subnets.  This is an area where I'm
really fuzzy.  I know that in the past I have had no problems with
machines with one "real" NIC and putting IP aliases on lo0 and the
routing "just works".

In this case I *think* the 2nd NIC on each machine is on a physically
separate network.  While I *think* I'd like these NICs on the same
physical network to have even greater "survivability" in case of a NIC
failure, I do understand there are routing issues that would make that
more difficult.

H
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to