you wrote: > On Wed, 29 Jan 2003, Dave Cornejo wrote: > > > local network is 192.168.1.0/24 > > > > 192.168.1.4 > > | > > | > > 192.168.1.1 -- ethernet -- 192.168.1.2 / global IP addr -- internet > > | > > | > > 192.168.1.3 > > > > now, the rules: > > > > 1) .1 may directly exchange packets with .4 and .2 only, it may not > > exchange packets with .3 directly. > > > > 2) .2 may directly exchange packets with any host > > > > 3) .2 acts as the gateway to the internet > > > > the problem is that I need to be able to set up the routing tables so > > that if .1 needs to connect to .3 that it goes through .2. > > The "cleanest" way to do this would be by subnetting. You could have .2 > on two subnets, with one of the subnets having only the .1 host, while the > other subnet has the rest of the hosts.
I over-simplified the problem - I'm not talking about 4 hosts on pure Ethernet here, I'm really talking about hundreds to thousands with some portions running over radio. The rules change dynamically and pretty frequently (like potentially on the order of seconds) - I have a routing daemon that knows how the rules are changing and I need to get this into a routing table. Subnetting on this scale won't work, and since some hosts will need to participate in multiple subnets, you run into the problem of dynamically managing subnets and aliasing the interface (easy enough at small scale) We have this running on Linux, but it's my belief that we're actually exploiting a bug or flaw in the Linux routing. The closest I've gotten is to set add a route like this on .1: .1 has a netmask of 0xffffffff route add 192.168.1.2 -interface fxp0 (hope I'm remembering this right) which yields the packets getting transmitted with but with the MAC address of .1, so .2 never recognizes the packet. > However, you would want to tell .1 to route packets for .3 to .2. This > can be done with a simple entry in the routing table on .1. If you don't > "trust" .1 or can't modify it's routing table, then you would need to > setup a transparent firewall. Then you need to tell .2 to redirect > packets from .1 to .3. If you want packets from .3 to .1 to go through .2 > as well, you would do the same thing, but the other way around > (change/reverse the addresses). As for _how_ to do this with FreeBSD, you > could use ipfw to redirect the packets. This would be done with the "fwd" > keyboard. Check the manpage ipfw(8) for more details. ipfw is an interesting suggestion, I'll have to look at that. > You could also do some kind of layer 2 filtering/rewriting between .3 and > the rest of the Ethernet. > > However, if your goal is to have .2 see all of the packets from .3 to .1, > then there's a better way of doing it. If you are using an Ethernet hub, > then every host on the LAN will already see every packet that is sent by > every host. If you are using an Ethernet switch, you might be able to > tell the switch that one of the ports should see every packet sent to the > LAN. In the world of cisco, this is known as 'port monitoring'. I'm not > sure about other vendors however. Can't rely on that because as I noted above we're using some wireless links in here and (having worked on the IOS code) port monitoring is often busted anyway. > > If it > > needs to connect to .4 or .2 it can do that directly. To make things > > even more fun, any number of hosts may join or leave the network at > > any point and the lists of which hosts have direct connectivity is > > dynamic. But I think that if I can solve the above problem that I'll > > have what I need to solve the rest of it. > > To be quite honest, I think you need to read up a bit more on how TCP/IP > and Ethernet work. In general (and this is not 100% true, since there > are other rules), all hosts on a LAN (well, subnet) will have "direct > connectivity" to each other. There is no process for hosts to "join" an > IP/Ethernet network, they simply just start sending and receiving > > packets. In a pure Etherenet environment yes, but the problem I'm trying to solve is that I can't rely on the network connection being reliable or static. I've gotten the problem down to dealing with the FreeBSD routing and interface driver code, but I don't quite have my brain around the whole concept of BSD routing - I'm going through the 4.4BSD internals book, but time is short and I'm being lazy here... > > I have a solution that uses Linux, but I'm reasonably certain that it > > really uses a flaw in the Linux kernel to work as it's dicey to set > > up, requires a specific order of steps and requires a reboot when > > things like the hosts IP address changes. > > > > Do you know what this is called? Or can you atleast describe this method > in more detail? I might even have the completely wrong idea about what > you're trying to accomplish. Unfortunately, I've only witnessed it and it requires some voodoo - you set the interface netmask to 0xffffffff and then there's something with an entry to the subnet I think it may have been setting the default route to the subnet (i.e. 192.168.1.0) but that doesn't sound right. Then add the route to the device with something like "route add 192.168.1.2 -dev eth0" But this is flakey > Hope this helps, and I hope I didn't confuse you. :) No, the ipfw is an interesting idea - thanks for your reply... dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) "There aren't any monkeys chasing us..." - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
