On Thu, Oct 2, 2014 at 8:05 PM, Eric S. Johansson <[email protected]> wrote: > > On 10/2/2014 10:24 PM, Joel Wirāmu Pauling wrote: >> >> I.e Your topology looks like this : >> >> [(Remote LAN) - VPN Client]---[INTERNET]---(Local >> LAN)[WAN][LAN][REMOTE-LAN]) >> >> Your Local LAN knows nothing about Remote LAN and Vice versa. There is >> just a single Inteface/Client member that is a member of REMOTE-LAN. >> So to get traffic from Local LAN to Remote LAN all Local-LAN traffic >> needs to be masqueraded to that Single interface. > > > ah, thanks for the clarification. my function oriented topology looks like > this: > > [ 34-38 target lan - vpn server - fw ] - - - [ I ] - + -( fw - vpn client - > - - lan - - - workerbees(6) ) > + -( rw worker bee ) > + -( rw worker bee ) > + -( cerowrt worker bee ) ... > > I don't think the natted form is going to work terribly well because all the > WB's need access to all the target machines. Also our routing tables are… > significant
Personally I find the output of ip route show to be much more readable and usable nowadays. > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt > Iface > 0.0.0.0 73.38.246.1 0.0.0.0 UG 0 0 0 > ge00 > 10.42.66.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.1.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.2.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.3.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.4.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.5.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.6.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.7.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.8.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.9.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.10.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.11.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.12.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.13.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.14.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.43.15.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 Ideally you should be able to shrink that 10.43 network into a single 10.43.0.0/20 route. > 10.199.188.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > 10.199.188.193 0.0.0.0 255.255.255.255 UH 0 0 0 > tun0 > 73.38.246.0 0.0.0.0 255.255.254.0 U 0 0 0 > ge00 > 172.30.42.0 0.0.0.0 255.255.255.224 U 0 0 0 > se00 > 172.30.42.0 0.0.0.0 255.255.255.0 ! 0 0 0 * > 172.30.42.64 0.0.0.0 255.255.255.224 U 0 0 0 > sw00 > 172.30.42.96 0.0.0.0 255.255.255.224 U 0 0 0 > sw10 > 192.168.9.0 10.199.188.193 255.255.255.0 UG 0 0 0 > tun0 > > and WTH is this? > 172.30.42.0 0.0.0.0 255.255.255.0 ! 0 0 0 * That is what is called a "covering route". The interfaces in cerowrt are all /27s out of a single /24. Just as you could just do a 10.43.0.0/20 route instead of the 16 10.43 routes above. So we export via babel that single /24 by creating an "unreachable" route for it, which is visible externally to the router, and internally to the router we have the /27s that override the /24, that are not visible outside the router. Clear as mud, right? Here is part of my route table. Old Cerowrt used to export 9 routes visible to other routers.. 172.21.0.0/27 dev ge00 proto kernel scope link src 172.21.0.18 172.21.0.64/27 via 172.21.0.1 dev ge00 proto babel onlink 172.21.0.96/27 via 172.21.0.1 dev ge00 proto babel onlink 172.21.0.128/27 via 172.21.0.1 dev ge00 proto babel onlink ... add the host gateway and the other 4 interfaces... Toronto exports 1 (or 2) depending on the alternate paths available The s+ and gw+ devices 172.21.18.0/24 via 172.21.0.7 dev ge00 proto babel onlink The ge00 device is on another network, covered in this route 172.21.3.0/24 via 172.21.0.7 dev ge00 proto babel onlink less exported routes = smaller routing packets, smaller routing tables, faster routing updates, less route lookups while transferring data, and better use of the distance->vector mechanisms, and so on. In terms of scaling factors this makes it feasible to route together at least 700 boxes without too much fear of overwhelming anything. (But I haven't got around to resimulating the results, like so many other things - and the limit at least used to be some inefficient code in babeld, not any inherent limit to the protocol) > > --- eric > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
