Kevin P. Fleming wrote: > Peter Stuge wrote: > >> The other is to NETMAP each VLAN into a different IP network. There >> is a NAT target in the kernel for this. This is NAT, so your >> applications may suffer with this option too. NETMAP is a 1:1 >> mapping of IP addresses from one IP network to another. This does not >> scale too well since there's only a limited number of private IP >> networks reserved. > > > His source networks were all 10.1.1.0/24, so he could easily remap to > the 172.16.0.0/12 space and have room for thousands of NAT'ed networks > (probably more than his system can handle). For that matter, he could > remap to a large portion of 10.0.0.0/8 and have room for more networks > than VLANs can even support (4096, IIRC). Remapping is definitely an option, given the amount of address space floating around. We'll likely scale up into the hundreds of subnets, but no where near thousands of subnets that are addressable. Don't worry, I won't leave this one hanging. :) I'll be compiling a new kernel and iptables, both with support for vrf and CONNMAP, and testing it in the morning. Reports of success or failure will follow. At the moment, the thinking is that vrf, although is looks a little sketchy to get working, seems to be closer to what we originally had in mind, although it will require some trickiness with inetd.conf calling a script, which chvrf's, then calls tftpd (very doable, I believe). Alternatively, Jason's response about CONNMAP seems to be better supported and integrated into the existing tool sets, so I'm certainly going to try both and see how they compare for manageability. Aaron S. Joyner
