Multiple interfaces on one subnet

Kevin Brown wrote:
> Hello all,
>
> For my small wireless ISP, I plan on putting a cluster of access
points
> on separate NIC's on my linux router. All of the IP's that the
> customers and the router nics have will be on the same subnet. I am

Is there any reason they _need_ to be on the same subnet? See below.

> trying to do a prototype of this using a private network but with no
> luck. The test is as follows:
>
> eth0: 192.168.2.4 (hooks into my home network)
> eth1: 192.168.3.100 (hooks into laptop -- 192.168.3.1)
> eth2: 192.168.3.102 (hooks into laptop -- 192.168.3.2)
>
> I took out the subnet routes (route del -net 192.168.3.0/24) and then

> added the laptops to their interfaces:
>
> route add 192.168.3.1 dev eth1
> route add 192.168.3.2 dev eth2
>
> But that does not work. If I ping from 192.168.3.2 to 192.168.3.102,

> the ICMP reply seems to come out of eth1. What am I missing, is what
I
> am trying to do even possible?
>
> Thanks in advance,
> Kevin Brown.

What you are observing is "normal" for a Linux box with multiple nics
on the same segment. There are ways to combat this behavior that are
_usually_ quite successful, but in your case ...

As you already noted, your Linux box can indeed act as a _router_.
That is it can forward packets from one subnet to another subnet (ie.,
from one nic to another nic). If I were you, I would place each nic on
a separate subnet. It solves your immediate problem and is much more
flexible/scalable if you decide to place switches downstream. And to
tell the truth, I can't think of any advantages to your current, all on
one subnet approach. They _may_ exist, I just can't think of any.

Also from the way you mention ISP and customers I would _definitely_
use separate subnets for each nic. If you need more than one host per
subnet, use a downstream switch.

Anyway, you _will_ need some handy docs. The LDP HOWTOs (
http://www.tldp.org/docs.html ) are essential as well as these two for
more brain teasing problems:

http://lartc.org/howto/
http://linux-ip.net/html/
Start here for your current problem:
http://linux-ip.net/html/adv-multi-ethernet.html
hth,
prg
email above disabled



prg

Hello all,

For my small wireless ISP, I plan on putting a cluster of access points
on separate NIC's on my linux router. All of the IP's that the
customers and the router nics have will be on the same subnet. I am
trying to do a prototype of this using a private network but with no
luck. The test is as follows:

eth0: 192.168.2.4 (hooks into my home network)
eth1: 192.168.3.100 (hooks into laptop -- 192.168.3.1)
eth2: 192.168.3.102 (hooks into laptop -- 192.168.3.2)

I took out the subnet routes (route del -net 192.168.3.0/24) and then
added the laptops to their interfaces:

route add 192.168.3.1 dev eth1
route add 192.168.3.2 dev eth2

But that does not work. If I ping from 192.168.3.2 to 192.168.3.102,
the ICMP reply seems to come out of eth1. What am I missing, is what I
am trying to do even possible?

Thanks in advance,
Kevin Brown.

Kevin Brown wrote:
> My reasoning is that when I buy my public subnet (the customers' ip
> addresses), it's cheaper to buy just one. If extra configuration
means
> saved money, then it is worth it, unless there are significant
> disadvantages to this approach.
>
[snip]
> Kevin Brown.

OK, so you will offer your clients their own public IP and they will
all be on the same subnet.

Therefore, your Linux "router" will also be on that same subnet. What
you need then is not a _router_ but a bridge -- routers connect
different subnets, bridges connect different physical segments of the
same IP segment.

Thus your Linux outfacing nic (eth0) will connect to the ISP on x.x.x.1
while the client side nic (eth1) will _bridge_ to a switch which
connects to the APs. 8 and even 16 port switches are much
cheaper/easier to maintain in this situation IMO.

Google "linux ethernet bridge" (about 326,000 English pages) and you
should find plenty to get you going. The bridging code also provides
access to iptables, etc.

This will also help keep you from having to set up and maintain NAT,
DNS, and DHCP and whatever else would be needed to set up your clients
on a separate network.

Of course, if your ISP puts _your_ Linux box on a separate subnet from
your clients then you're back to needing a router. In that case, eth1
(the client side nic) will be on a different subnet from eth0. Still,
you (at least I) would use a switch immediately downstream of eth1 to
connect the APs.

hth,
prg
email above disabled

My reasoning is that when I buy my public subnet (the customers' ip
addresses), it's cheaper to buy just one. If extra configuration means
saved money, then it is worth it, unless there are significant
disadvantages to this approach.

prg wrote:
> As you already noted, your Linux box can indeed act as a _router_.
> That is it can forward packets from one subnet to another subnet (ie.,
> from one nic to another nic). If I were you, I would place each nic on
> a separate subnet. It solves your immediate problem and is much more
> flexible/scalable if you decide to place switches downstream. And to
> tell the truth, I can't think of any advantages to your current, all on
> one subnet approach. They _may_ exist, I just can't think of any.
>

Kevin Brown.