Re: [LARTC] Virtual Routers would this work?

[Matthew Crocker <matthew@crocker.com>]

> 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/