On 8/8/07, Brian Candler <B.Candler@xxxxxxxxx> wrote: > Here's an interesting problem which I'd like to hear suggestions on. > > Many networked devices that you buy off-the-shelf come preconfigured on a > static IP address; for example, many home routers are 192.168.1.1, Cisco > 800-series routers are 10.10.10.1, etc. > > Now, I want to build a workstation for configuring these sorts of devices > before they get shipped out into the field. This will involve telnetting to > them, performing tftp transfers and so on. The whole process can take > several minutes, so ideally I'd like to be able to do this to several > devices concurrently. But how can I do that, if they all have the same IP > address? > > The setup would look something like this, if using VLANs: > > Linux server > +-----------------+ eth0.1 10.10.10.1 +----------+ > | process 1 --|-------------------------| router 1 | > | | +----------+ > | | eth0.2 10.10.10.1 +----------+ > | process 2 --|-------------------------| router 2 | > | | +----------+ > | | eth0.3 10.10.10.1 +----------+ > | process 3 --|-------------------------| router 3 | > | | +----------+ > | | eth0.4 10.10.10.1 +----------+ > | process 4 --|-------------------------| router 4 | > | | +----------+ > +-----------------+ > > Now, I don't think that NATing the targets will help me here, because as far > as I know it's not possible to configure multiple local interfaces with the > same subnet. It would also require each interface to have its own isolated > ARP table. > > What I'm thinking is that it may be possible using raw sockets to send > packets, and libpcap to receive the responses. That means that ARP would be > handled entirely in userland. However, in order to telnet the router, I > would also need a complete TCP stack which runs entirely in userland. Is > such a thing publically available? (*) > > I also remember reading about a modular software router called "Click": > http://www.read.cs.ucla.edu/click/ > Would this be able to handle what I want? It seems to be aimed at layer 3 > forwarding, but if it doesn't have a TCP stack and sockets API, could I > interface it to a kernel TCP socket somehow? > > I'm not looking for stellar performance - a few hundred packets per second > would be fine. The "Linux server" would ideally be a small MIPS box running > OpenWrt, such as the Buffalo WHR-G54S; this gives me a CPU plus five port > VLAN switch for about $50. The easiest solution is just to buy four of > these, but then the wiring gets messy on the desktop :-) > > This choice of hardware, with only 4MB flash and 16MB RAM, would rule out > "heavyweight" solutions such as running four separate Linux kernels under > VMware or UML. > > Any other suggestions or comments welcome... maybe I'm just missing a trick. > > Regards, > > Brian. > > (*) I came across this paper: > http://nms.csail.mit.edu/~kandula/data/daytona.pdf > but I can't find the actual code published anywhere. Also, a bunch of links at > http://tcp.cs.st-andrews.ac.uk/index.shtml?stacks&400000 > of which many are broken or point to projects that either are incomplete > or have not released code. > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > you have mentioned only eth0 in the figure, I dont know how you can connect to multiple devices using single interface. if you are able to connect then I am assuming that you are using a switch in between. I would say you can use vlan aware switch. the port in which eth0 is connected will be configured for all vlan-ids and the other ports on which the routers are connected will be configured only for the corresponding vlan-id. The only problem I feel can occur in the learning phase of the switch is whether it will forward arp requests on the basis of vlan-id or broadcast to all ports. If it broadcasts it will be a problem. -- Thanks Pankaj Jain - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
