From: Harald W. <la...@gn...> - 2001-05-31 20:30:59
|
Hi once again! I have now done a lot of testing on the new uml networking code (using the daemon to interconnect uml's). Everything seems to be working and stable, the strange do_IRQ loops (as seen with uml before the rewrite) are definitely gone now. Thanks a lot to Jeff and everybody who assisted him in the networking rewrite. The only feature (apart from the already-to-be fixed hub/switch thing) I really, really miss are multiple network segments. I am planning to do my future netfilter/iptables development using several UML's - and when you want to do firewalling/NAT testing, you need to have multiple network segments. Jeff: Are you already working on that? If not, I'll stick my head in the code and see what I can do to have support for multiple ethernet segments again. Thanks once again, -- Live long and prosper - Harald Welte / la...@gn... http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) |
From: Jeff D. <jd...@ka...> - 2001-05-31 20:41:08
|
la...@gn... said: > Everything seems to be working and stable, the strange do_IRQ loops > (as seen with uml before the rewrite) are definitely gone now. Excellent! I'm glad to hear it's holding up for you. > I am planning to do my future netfilter/iptables development using > several UML's - and when you want to do firewalling/NAT testing, you > need to have multiple network segments. As a non-network guru, I have to ask what multiple network segments means, exactly. Multiple ethernets that require some kind of bridge to pass packets between them? > Jeff: Are you already working on that? If not, I'll stick my head in > the code and see what I can do to have support for multiple ethernet > segments again. Not yet, I gladly accept patches... How did you have them before? Jeff |
From: Harald W. <la...@gn...> - 2001-05-31 21:50:48
|
On Thu, May 31, 2001 at 03:41:53PM -0400, Jeff Dike wrote: > > How did you have them before? Q. How do I make more then one network? A. You'll have to get the program uml_set into a UML for this to work. Once you have it there up can modify what network a UM-Eth-Net interface is on with this command line (while in the UML): um_eth_net_set eth0 101 This make UM-Eth-Net interface eth0 a member of network 101. Any other UM-Eth-Net interface on any other UML in network 101 can now talk to each other. > Jeff -- Live long and prosper - Harald Welte / la...@gn... http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) |
From: Harald W. <la...@gn...> - 2001-05-31 21:50:48
|
On Thu, May 31, 2001 at 03:41:53PM -0400, Jeff Dike wrote: > > I am planning to do my future netfilter/iptables development using > > several UML's - and when you want to do firewalling/NAT testing, you > > need to have multiple network segments. > > As a non-network guru, I have to ask what multiple network segments means, > exactly. Multiple ethernets that require some kind of bridge to pass packets > between them? Multiple ethernets, totally independent. i.e. I need to have three UML's in one 'ethernet' and two other uml's in another ethernet. one of them is connected to both 'ethernets' and can route between them. It basically needs uml_router to either - manage different lists of connections or - associate a 'network number' with each connection, and when we check to which other processes to send data to, we only consider other connections in the same network number > > Jeff: Are you already working on that? If not, I'll stick my head in > > the code and see what I can do to have support for multiple ethernet > > segments again. > > Not yet, I gladly accept patches... Ok, I already started. Just have to get used to this peculiar coding style in the non-kernel code... *eek* ;) > How did you have them before? i didn't have them, as even two uml's weren't even getting 100k between them before the do_IRQ() loop was hitting... But as far as I understood the concept, the previous um_net_eth_router was able to have multiple segments. > Jeff -- Live long and prosper - Harald Welte / la...@gn... http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) |
From: Jeff D. <jd...@ka...> - 2001-05-31 22:25:34
|
la...@gn... said: > It basically needs uml_router to either > - manage different lists of connections or > - associate a 'network > number' with each connection, and when we check > to which other processes to send data to, we only consider other > connections > in the same network number Both of these are possible. But will multiple ethernet devices, each attached to a different uml_router work? Henrik Nordstrom asked about the same thing, and as far as he was concerned, it was a usability thing. He wanted to be able to switch a device between different networks on the fly rather than have to specify on the command line, if I understood him properly. > Ok, I already started. Just have to get used to this peculiar coding > style in the non-kernel code... *eek* ;) heh I hate 8-char indents, you run out of horizontal room way too quickly. Although I've got a bit more used to them now. Also, I'm planning on having uml_router stop actually routing data and just act as an address server, keeping everyone up-to-date on who's on the net and where they are. The driver would actually send the data, so it would go straight from one UML to another without the router in the way. Do you have any problems with that? It would probably decrease latency, and it doesn't look like affects anything you're thinking about. Jeff |
From: Harald W. <la...@gn...> - 2001-06-01 00:00:37
|
On Thu, May 31, 2001 at 05:26:32PM -0400, Jeff Dike wrote: > Both of these are possible. But will multiple ethernet devices, each > attached to a different uml_router work? Henrik Nordstrom asked about the > same thing, and as far as he was concerned, it was a usability thing. He > wanted to be able to switch a device between different networks on the fly > rather than have to specify on the command line, if I understood him > properly. excactly. What Henrik suggests makes sense and is as flexible as we want it to have. The old um_eth_net_util-based solution had this nice feature, where a program inside uml calls an ioctl() to set the 'virtual ethernet number'. I think it is the best way to go. I'm already on my way adding this ioctl() again, and making the uml_router aware of that. multiple uml_router seem to be a bit of an overkill... we already have way enough processes :) > heh > > I hate 8-char indents, you run out of horizontal room way too quickly. > Although I've got a bit more used to them now. mh. well, I don't want to start a pointless discussion at that point :) > Also, I'm planning on having uml_router stop actually routing data and just > act as an address server, keeping everyone up-to-date on who's on the net and > where they are. The driver would actually send the data, so it would go > straight from one UML to another without the router in the way. mmh. I'd rather change it into something with shared memory, so no the cost of doing 'n' copies is not on the sender side, but every receiver has to copy it once (that approximates a bit further to a real ethernet). The problem is the synchronization. Usually we would have something like the uml_router allocates one shared memory area and one semaphore for each of them. Now any interface in any uml can be set to use this set of (shmem, semaphore) to participate in a given virtual ethernet. This way the uml_router wouldn't have to do anything, but passing shmid's and informing the uml's about the available networks. Unfortunately reality is a bit more complicated, and we cannot just use a semaphore and have our uml sleep, while there is other stuff than networking it needs to do. Any ideas on that? > Do you have any problems with that? It would probably decrease latency, and > it doesn't look like affects anything you're thinking about. no. But please wait until I'm finished with the muitiple-virtual-ethernet thing, otherwise we would end up with conflicting patches :( > Jeff -- Live long and prosper - Harald Welte / la...@gn... http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) |
From: Henrik N. <hn...@ma...> - 2001-06-01 07:03:59
|
Harald Welte wrote: > excactly. What Henrik suggests makes sense and is as flexible as we want > it to have. The old um_eth_net_util-based solution had this nice feature, > where a program inside uml calls an ioctl() to set the 'virtual ethernet > number'. I have been thinking a bit more about this, and it should be addressed from the router (with hints from the UML), not from inside the UML. When a UML connects to the router it should send * UML identity * UML interface identity It is then up to the router to decide which ethernet this connection belongs to by having a configuration table mapping UML connections to ethernet segments. If you want to move a UML from one segment to another, tell the router via a router administration channel to move the UML to another network segment. For convenience, the router configuration should be able to use wildcards to group UML interfaces into different ethernets. umid=test1, interface=eth0 ethernet 10 umid=int*, interface=eth0 ethernet 10 umid=dmz*, interface=* ethernet 11 umid=*, interface=eth0 ethernet 1 umid=*, interface=eth1 ethernet 2 umid=*, interface=* ethernet 0 Note: the "switching" as is currently done is limiting the functionality. I just realized that it is not only the broadcasts one have to deal with, One UML might also have multiple ethernet addresses or change MAC address on the fly, for example when acting as a bridge or when playing with MAC level failover. Because of this the control interface between the router and UML's needs to be MAC anonymous. Simplest approach would be to make the router a broadcast ethernet router for now, and then later extend it with ethernet bridge capability per network segment. Proper bridging requires keeping a bridging table of seen MAC addresses, and can easily get added once the basic router code is stable. -- Henrik Nordstrom MARA Systems |
From: Harald W. <la...@gn...> - 2001-06-01 16:32:25
|
On Fri, Jun 01, 2001 at 07:14:28AM +0200, Henrik Nordstrom wrote: > > I have been thinking a bit more about this, and it should be addressed from > the router (with hints from the UML), not from inside the UML. exactly. When you want to give people inside the UML root access, you don't want them to be able to select which network they are in. > When a UML connects to the router it should send > * UML identity > * UML interface identity > > It is then up to the router to decide which ethernet this connection belongs > to by having a configuration table mapping UML connections to ethernet > segments. > > If you want to move a UML from one segment to another, tell the router via a > router administration channel to move the UML to another network segment. we have agreed on having a config file, which is reloaded on SIGHUP. Control channel can be later. > For convenience, the router configuration should be able to use wildcards to > group UML interfaces into different ethernets. hm, haven't though about that yet. Well, can be seen as a future enhancement > umid=test1, interface=eth0 ethernet 10 > umid=int*, interface=eth0 ethernet 10 > umid=dmz*, interface=* ethernet 11 > umid=*, interface=eth0 ethernet 1 > umid=*, interface=eth1 ethernet 2 > umid=*, interface=* ethernet 0 > > Note: the "switching" as is currently done is limiting the functionality. I > just realized that it is not only the broadcasts one have to deal with, One > UML might also have multiple ethernet addresses or change MAC address on the > fly, for example when acting as a bridge or when playing with MAC level > failover. Because of this the control interface between the router and UML's > needs to be MAC anonymous. Simplest approach would be to make the router a > broadcast ethernet yup, agreed. And I already renamed it. router is from a network-terminology point of view just wrong. The other idea (which I'm working on right now) is: removing all data processing from the umlhubd (as I have named it now). I.e. - uml connects to umlhubd using TCP control socket - umlhubd looks up configuration entry - umlhubd returns multicast group to uml over control socket - uml joins that multicast group. So all uml's on one virtual ethernet share one multicast group, and everything one uml sends is received by all other uml's subscribed by that group. Using IP instead of unix domain sockets is no disadvantage, because we use UDP for the data transport, so there is no latency penalty By using IP multicasting, we don't have to care about copying packets, etc. - And you can have multiple uml's on different hosts have one shared network, spanning over a real (multicast-capable, of course) network. After being finished with the umlhubd side, I will start adding the multicast support to uml networking today... and I now realize, that there is not really a real need for the umlhubd anymore. We could also just specify multicast-group and port-number on the boot- commandline, and you can have instant networking without any external helper. Advantage: far less complex, no external helper. Disadvantage: need to reboot your uml if you want to change the configuration of your virtual ethernets. Anyway, as umlhubd is almost complete now (I spent way too much time on making it IPv6 aware and dropped it later again), we can have both versions (boot-time configured OR umlhubd) in the uml networking code, sharing the same multicast 'backend'. > Henrik Nordstrom > MARA Systems -- Live long and prosper - Harald Welte / la...@gn... http://www.gnumonks.org ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) |
From: Henrik N. <hn...@ma...> - 2001-06-01 16:57:16
|
Harald Welte wrote: > The other idea (which I'm working on right now) is: removing all data > processing from the umlhubd (as I have named it now). Please implement that as another transport type in UML. The daemon approach is a very simple approach with minimal requirements on the host. Multicast requires multicast support on the host, which is not available everywhere. But the idea is good (almost proposed this some days ago as a UML<->UML transport without host involvement, possibly even spanning multiple real networks, but I'd like to see a well working userspace implementation first) > We could also just specify multicast-group and port-number on the boot- > commandline, and you can have instant networking without any external helper. > Advantage: far less complex, no external helper. Disadvantage: need to reboot > your uml if you want to change the configuration of your virtual ethernets. Perfectly fine by me. But as said above this is another transport type. > Anyway, as umlhubd is almost complete now (I spent way too much time on > making it IPv6 aware and dropped it later again), we can have both versions > (boot-time configured OR umlhubd) in the uml networking code, sharing the > same multicast 'backend'. umlhubd should only care about ethernet. What kind of protocol runs on top of it does not matter. For the communication channel I think AF_UNIX is just fine for the time being, and is generally much easier to control permissions on. -- Henrik Nordstrom MARA Systems |
From: Harald W. <la...@gn...> - 2001-06-01 18:16:38
|
On Fri, Jun 01, 2001 at 06:57:23PM +0200, Henrik Nordstrom wrote: > > The other idea (which I'm working on right now) is: removing all data > > processing from the umlhubd (as I have named it now). > > Please implement that as another transport type in UML. why? > The daemon approach is a very simple approach with minimal requirements on the > host. > > Multicast requires multicast support on the host, which is not available > everywhere. ? i'm not talking about multicast routing. It's just multicast on the local machine you need... and every linux kernel > 2.2.x should have that compiled in (as well as most other free + commercial unix variants, if you are thinking about running uml there). > But the idea is good (almost proposed this some days ago as a UML<->UML > transport without host involvement, possibly even spanning multiple real > networks, but I'd like to see a well working userspace implementation first) I don't want to invest more time in the data-processed-by-umlhubd thing. Doesn't make sense to me. > > We could also just specify multicast-group and port-number on the boot- > > commandline, and you can have instant networking without any external > > helper. Advantage: far less complex, no external helper. Disadvantage: > > need to reboot your uml if you want to change the configuration of your > > virtual ethernets. > > Perfectly fine by me. But as said above this is another transport type. well, why? we have two things which neatly fit into one transport: 1. umlhubd-controlled multicast (i.e. umlhubd sends multicast address to uml) 2. boot-time-determined multicast (i.e. you specify the address at boot time) doesn't make sense to have two transports, when only the address assignment is different. > > > Anyway, as umlhubd is almost complete now (I spent way too much time on > > making it IPv6 aware and dropped it later again), we can have both versions > > (boot-time configured OR umlhubd) in the uml networking code, sharing the > > same multicast 'backend'. > > umlhubd should only care about ethernet. What kind of protocol runs on top of > it does not matter. For the communication channel I think AF_UNIX is just > fine for the time being, and is generally much easier to control permissions > on. no, i meant the uml's using IPv6 packets as their underlying transport (i.e. ethernet-in-udp-in-ipv6). Anyway, dropped that idea. > Henrik Nordstrom > MARA Systems -- Live long and prosper - Harald Welte / la...@gn... http://www.gnumonks.org ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) |
From: Henrik N. <hn...@ma...> - 2001-06-02 06:20:13
|
Harald Welte wrote: > ? i'm not talking about multicast routing. It's just multicast on the local > machine you need... and every linux kernel > 2.2.x should have that compiled > in (as well as most other free + commercial unix variants, if you are thinking > about running uml there). Multicast is an optional kernel feature quite often disabled by people not yet interested in running multicast. Using multicast IS different from the daemon approach. multicast is impossible to later extend with a bridge. Using AF_UNIX is different from using AF_INET. AF_UNIX have access permissions, AF_INET does not. -- Henrik Nordstrom MARA Systems |
From: Harald W. <la...@gn...> - 2001-06-03 17:12:36
|
On Sat, Jun 02, 2001 at 08:20:20AM +0200, Henrik Nordstrom wrote: > Harald Welte wrote: > > > ? i'm not talking about multicast routing. It's just multicast on the local > > machine you need... and every linux kernel > 2.2.x should have that compiled > > in (as well as most other free + commercial unix variants, if you are thinking > > about running uml there). > > Multicast is an optional kernel feature quite often disabled by people not yet > interested in running multicast. Yes, I noted that, and there is now a 'mcast' transport for UML networking... will post it to this mailinglist as soon as I got it running. > Henrik Nordstrom > MARA Systems -- Live long and prosper - Harald Welte / la...@gn... http://www.gnumonks.org ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) |
From: Henrik N. <hn...@ma...> - 2001-06-01 17:10:26
|
Harald Welte wrote: > > For convenience, the router configuration should be able to use wildcards to > > group UML interfaces into different ethernets. > > hm, haven't though about that yet. Well, can be seen as a future enhancement Edit config + SIGHUP is a fine administration channel, used by most daemons :-) A live channel is more interesting for statistics (i.e. packet counts received from each UML and such), and bridge control when/if there is a bridging core in the "hub". -- Henrik Nordstrom MARA Systems |
From: Henrik N. <hn...@ma...> - 2001-06-01 07:03:58
|
Jeff Dike wrote: > Both of these are possible. But will multiple ethernet devices, each attached > to a different uml_router work? Henrik Nordstrom asked about the same thing, > and as far as he was concerned, it was a usability thing. He wanted to be > able to switch a device between different networks on the fly rather than have > to specify on the command line, if I understood him properly. For now, I think that for now both mine and Haralds immediate requirements can be satisfied by running more than one router (one for each segment), but in the long run a more flexible router is required (See my previous message). This for both for flexibility and virtual network security reasons. -- Henrik |