The problem I'd be concerned about (refer to KPTD [1]) would be the possible interaction/interference with connection tracking. Perhaps someone more familiar with the workings of iptables can address this concern. Would the connection tracking mechanism circumvent the return packet traversing the PREROUTING mangle chain? (Connection tracking happens first, according to the KPTD....)
Connection tracking shouldn't be a problem. Each VLAN will be using its own public IP address for NAT. The connection table will have a mapping from a private IP to a unique public IP per VLAN. As long as I can fwmark the packets as they enter the router and maintain that mark until they exit on the correct interface I think it will all work. I'm going to try playing with it later today.
Yikes! Good question on ICMP. I have no idea about the interaction
between an inbound (already fwmark'd) packet and the generation of ICMP!
Well, we can always modify the kernel if the resulting ICMP doesn't maintain the fwmark.
: Example: an ARP (who has 192.168.1.1) from in on VLAN5, How can I get
: the kernel to send its response on VLAN5?
The ARP replies will go out the interface on which the query arrived.
You aren't doing anything "funky" with ARP are you? Just straight up ARP?
No proxy ARPing or anything like that?
Yep, just plain old ARP
Warning! The fwmark does not survive the local box. The fwmark feature
is an attribute of the in-memory representation of the packet as it's
handled by the linux router. As soon as the packet has left the box, the
fwmark datum is lost.
Also, I was under the impression from above that the NAT would happen on
the 2 GigE linux box, not on an upstream router. Which way would it be?
Correct. NAT will occur on the Linux box. I have a cisco 3550 'downstream' of it to handle the traffic shaping on each VLAN and a couple Cisco 7500's 'upstream' to handle the Internet routing.
The multiple ARP table question is also one I can't answer. Maybe Julian....
Certainly, the neighbor table itself supports entries for IP addresses on
multiple interfaces, so the same IP could be in the neighbor table with
different associations on each interface. An example:
Imagine a host has two connections to same media segment. After causing
an ARP lookup on each interface, there are per-device entries in the
neighbor table:
# ping -c 1 -I eth0 10.10.20.33 > /dev/null 2>&1 # ping -c 1 -I eth1 10.10.20.33 > /dev/null 2>&1 # ip neigh show 10.10.20.33 dev eth1 lladdr 00:80:c8:f8:4a:51 nud reachable 10.10.20.33 dev eth0 lladdr 00:80:c8:f8:4a:51 nud reachable
In my case the same IP will be two different MAC address on different machines on different VLANs
I don't think you'd have any trouble with setting up 100 routing tables
for each 192.168.1.0/24 via its own interface. I would add the RPDB rules
at a relatively low priority so that other rules could be inserted above.
for ID in $( seq 1 100 ) ; do ip rule add fwmark $ID table $ID prio $( expr 5000 + $ID ) ip route add 192.168.1.0/24 dev vlan$ID table $ID done ip route flush cache
: ICMPs: What happens when a client tries to ping the linux box : (192.168.1.1). If I fwmark all incoming packets on a VLAN will the : kernel respond with a packet using the same fwmark?
I don't know. Maybe somebody else on the list can answer this one....
Matthew...this is a very interesting question, and I'm quite intrigued by
your approach. Please let us (the LARTC list) know if you do prove that
this can or cannot be done using the current tools available under linux.
Sadly, the Netscreen may be able to fulfill your need with less effort.
I'll be installing RH 8.0 on the box today and will play around with it. Hopefully I can dedicate enough time to it today to make it work. The netscreen is easier on the brain but a lot harder on the wallet. It also doesn't have the geek factor like a linux box does. I'm not pushing all that much data so the linux box should do fine if I can get it configured properly.
Thanks for the input
-Matt
-- Matthew Crocker Vice President Crocker Communications
w. 413-746-2760 f. 413-746-3704 e. matthew@xxxxxxxxxxx
