1 1.2 pooka $NetBSD: README.txt,v 1.2 2010/03/29 02:11:14 pooka Exp $ 2 1.1 pooka 3 1.1 pooka Using rump it is possible to build a router test setup consisting 4 1.1 pooka of thousands of NetBSD IP stacks within a single host OS, one 5 1.1 pooka networking stack per application process. Each IP stack instance 6 1.1 pooka has its own set of interfaces, addresses and routing tables. These 7 1.1 pooka instances may or may not share the same code, i.e. it is possible 8 1.1 pooka to do compatibility testing of new features. The advantage over 9 1.1 pooka using full-fledged virtual OS setups (qemu, Xen, etc.) is scalability: 10 1.1 pooka the rump IP router base runtime takes less than 500kB of memory 11 1.1 pooka per instance. 12 1.1 pooka 13 1.1 pooka The code is _ONLY AN EXAMPLE_ as opposed a fully featured test kit. 14 1.1 pooka Some code tweaking is probably required to make this do what you 15 1.1 pooka want. Usage examples follow. 16 1.1 pooka 17 1.1 pooka To use one single rump networking stack instance with access to 18 1.1 pooka two real networks, you need tap and bridge on the host system (yes, 19 1.1 pooka this involves some memory copies. the resulting router setup can 20 1.1 pooka still saturate a GigE, though. it should not be difficult to bring 21 1.1 pooka performance to be ~the same as an in-kernel stack, but haven't 22 1.1 pooka managed to implement that yet). 23 1.1 pooka 24 1.1 pooka Anyway, the following can be done with the current code: 25 1.1 pooka 26 1.1 pooka /* 27 1.1 pooka * Usage: 28 1.1 pooka * 29 1.1 pooka * # ifconfig yourrealif0 up 30 1.1 pooka * # ifconfig tap0 create 31 1.1 pooka * # ifconfig tap0 up 32 1.1 pooka * # ifconfig bridge0 create 33 1.1 pooka * # brconfig bridge0 add tap0 add yourrealif0 34 1.1 pooka * # brconfig bridge0 up 35 1.1 pooka * # 36 1.1 pooka * # ifconfig yourrealif1 up 37 1.1 pooka * # ifconfig tap1 create 38 1.1 pooka * # ifconfig tap1 up 39 1.1 pooka * # ifconfig bridge1 create 40 1.1 pooka * # brconfig bridge1 add tap1 add yourrealif1 41 1.1 pooka * # brconfig bridge1 up 42 1.1 pooka * # 43 1.1 pooka * # ./router virt0 192.168.1.1 255.255.255.0 192.168.1.255 \ 44 1.1 pooka * # virt1 192.168.2.1 255.255.255.0 192.168.2.255 45 1.1 pooka * 46 1.1 pooka * This will bind virtN to tapN and act as a router. 47 1.1 pooka */ 48 1.1 pooka 49 1.1 pooka As brilliant ascii art, it would look something like this: 50 1.1 pooka 51 1.1 pooka network network 52 1.1 pooka ^ ^ 53 1.1 pooka | | 54 1.1 pooka /----v-------------\ /------------v----\ 55 1.1 pooka kernel | realif0 <-> tap0 | | tap1 -> realif1 | 56 1.1 pooka \---------------^--/ \---^-------------/ 57 1.1 pooka -------------------------|-------------------|-------------------- 58 1.1 pooka /----v-------------------v----\ 59 1.1 pooka user | virt0 <-> rump IP <-> virt1 | 60 1.1 pooka \-----------------------------/ 61 1.1 pooka 62 1.1 pooka (ok, no more drawing) 63 1.1 pooka 64 1.1 pooka The addresses configured to the rump virt0 and virt1 interfaces 65 1.1 pooka will be visible on the physical network, and their traffic can be 66 1.1 pooka examined with e.g. wireshark. You can also use wireshark on 67 1.1 pooka tap0/tap1. 68 1.1 pooka 69 1.1 pooka The alternate approach is to use purely internal simulation. The 70 1.1 pooka shmif rump driver uses a memory-mapped file as an ethernet "bus" 71 1.1 pooka between multiple rump networking stack instances. Just use 72 1.1 pooka rump_pub_shmif_create() in the code. This can also of course be 73 1.1 pooka combined with the tap setup, and you can have setups where border 74 1.1 pooka nodes talk to an internal mesh of shmif's. Semi-drawn, it looks 75 1.1 pooka like this: 76 1.1 pooka 77 1.1 pooka net1 <-> virt0, shm0 <-> shm1, shm2 <-> .... <-> shmN, virt1 <-> net1 78 1.1 pooka (rump0) (rump1) .... (rumpN) 79 1.1 pooka 80 1.1 pooka Linear setups (where router n talks to exactly router n-1 and n+1) 81 1.1 pooka can be easily autogenerated. Here's a snippet of executed commands 82 1.1 pooka I used to start a few hundred routers (NOTE! the usage of the 83 1.1 pooka example code is different!): 84 1.1 pooka 85 1.1 pooka ./a.out 10.0.0.1 10.0.0.255 /tmp/rumpshm_0 0 10.0.1.2 10.0.1.255 /tmp/rumpshm_1 10.0.1.1 86 1.1 pooka ./a.out 10.0.1.1 10.0.1.255 /tmp/rumpshm_1 10.0.1.2 10.0.2.2 10.0.2.255 /tmp/rumpshm_2 10.0.2.1 87 1.1 pooka ./a.out 10.0.2.1 10.0.2.255 /tmp/rumpshm_2 10.0.2.2 10.0.3.2 10.0.3.255 /tmp/rumpshm_3 10.0.3.1 88 1.1 pooka ./a.out 10.0.3.1 10.0.3.255 /tmp/rumpshm_3 10.0.3.2 10.0.4.2 10.0.4.255 /tmp/rumpshm_4 10.0.4.1 89 1.1 pooka .... 90 1.1 pooka ./a.out 10.0.252.1 10.0.252.255 /tmp/rumpshm_252 10.0.252.2 10.0.253.2 10.0.253. 91 1.1 pooka 255 /tmp/rumpshm_253 10.0.253.1 92 1.1 pooka ./a.out 10.0.253.1 10.0.253.255 /tmp/rumpshm_253 10.0.253.2 10.0.255.1 10.0.255. 93 1.1 pooka 255 /tmp/rumpshm_255 0 94 1.1 pooka 95 1.2 pooka (see startrouters.sh for a script to produce that output) 96 1.1 pooka 97 1.1 pooka Easy but slightly more interesting setups, such as a M^N matrix 98 1.1 pooka (hyper-matrix?) are also possible, but left as an exercise to the 99 1.1 pooka reader. 100 1.1 pooka 101 1.1 pooka Compiling the router depends a little on what networking domain 102 1.1 pooka and what interface you want to use for testing. The very basic 103 1.1 pooka setup with IP+virtif will get you quite far: 104 1.1 pooka 105 1.1 pooka cc rumprouter.c -lrumpnet_virtif -lrumpnet_netinet -lrumpnet_net -lrumpnet \ 106 1.1 pooka -lrump -lrumpuser -lpthread 107