[Olsr-dev] advanced policy routing patch

[Sven-Ola Tuecke]

Hi otti,

yes - should be the correct source. Just wanted to make sure. The man.gz is 
in the CVS? Ugly - didn't noticed that until now. Having a separate 
RtTableDefault sounds resonable now - thank you...

// Sven-Ola

----- Original Message ----- 
From: "otti" <(spam-protected)>
To: <(spam-protected)>
Sent: Thursday, December 27, 2007 2:04 PM
Subject: Re: [Olsr-dev] advanced policy routing patch


> Hi Sven!
>
> Am Donnerstag, den 27.12.2007, 13:26 +0100 schrieb Sven-Ola Tuecke:
>> your patch will not apply (at least, you diffed' a .gz by accident). This
>> patch is against kamikaze-cvs? That may be rather old anyhow. You may 
>> retry
>> it against olsrd-cvs.
>
> it's a patch against
> cvs -z3 -d:pserver:(spam-protected):/cvsroot/olsrd co
> -P olsrd-current
>
> Plaese tell me if this is the correct source to work on.
>
> the .gz is the man page (I added new config options). I don't know if
> theres a plain text version to patch against, if there is one i can
> change the patch.
>
>> And I don't get it - in what scenario an extra policy defroute will help
>> here? a) user wants inet from the mesh or b) user supplies inet to the 
>> mesh
>> or c) user confused by polrouting and fiddles with different default 
>> routes
>> too much? Did you notice the following passage in 
>> src/linux/kernel_routes.c?
>>
>> #else /* !LINUX_POLICY_ROUTING */
>>  if (0 == rt->rt_dst.prefix_len && 253 > olsr_cnf->rttable)
>>  {
>>   /*
>>    * Users start whining about not having internet with policy
>>    * routing activated and no static default route in table 254.
>>    * We maintain a fallback defroute in the default=253 table.
>>    */
>>   olsr_netlink_route(rt, AF_INET, 253, RTM_NEWROUTE);
>>  }
>>  return olsr_netlink_route(rt, AF_INET, olsr_cnf->rttable, RTM_NEWROUTE);
>> #endif /* LINUX_POLICY_ROUTING */
>
> That's not my code (it's allready included in the source),
> i just added an option to turn that off.
>
> What i really wanted (and did), is adding an option to split the
> olsrd routing table into a table containing the default route
> and one for the rest.
>
> Why splitting the table makes policy routing easyer/more powerfull:
>
> There are some things that wont work with the way policy routing is done 
> in
> freifunk-firmware now.
>
> If someone does an HNA annoucement of a network that is not in the
> subnet olsrd runs on, it won't get routed by the olsr table, because
> there is no ip rule for that subnet (network addresses in ip rule are
> not comming from olsrd). We really need to use multible different
> subnets within one olsrd cloud in Graz (we have private an public ip
> addresses in the net) and i think in Vienna it's needed too (they have
> 2 different public ip ranges)
>
> A more clean solution for policy routing (without network addresses in
> ip rule!) looks like:
>
> #!/bin/sh
> iptables -t mangle -F
> iptables -t mangle -A PREROUTING -i $OLSR_DEVICE1 -j MARK --set-mark 1
> iptables -t mangle -A PREROUTING -i $OLSR_DEVICE2 -j MARK --set-mark 1
>
> ip route del default
> ip route add default via $defgw table default
>
> ip rule add fwmark 1 lookup olsr-default
> ip rule add lookup main
> ip rule add lookup olsr
> #ip rule del pref 32766 #optionally delete second main table
>
> (spam-protected):~# cat /etc/olsrd.conf | grep Rt
> RtTable 111
> RtTableDefault 112
> RtDuplicateV4Def no
>
> (spam-protected):~# cat /etc/iproute2/rt_tables
> 111     olsr
> 112     olsr-default
> 255     local
> 254     main
> 253     default
> 0       unspec
>
>