From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Crocker Date: Mon, 03 Mar 2003 14:35:35 +0000 Subject: Re: [LARTC] Virtual Routers would this work? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org > 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@crocker.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/