Teco pointed at a possible mistake, and I actually made one (reading code is 
not easy...).


-> If you insert an entry with source and destination prefixes, it will create 
a node in the main
tree and in the subtree. 

*But*

There is no routing information in the node created in the main tree (The flag 
RTN_RTINFO is not set).

And it seems that Linux, when it finds its longest prefix for the destination, 
doesn't step back to a previous (shortest prefix) entry
if there is no matching prefix for the source address in the subtree. (It 
returns the current node, which has not valid routing information).

And then the packet is probably dropped.

Pierre


Le 31 juil. 2013 à 19:16, Pierre PFISTER a écrit :

> 
> Le 31 juil. 2013 à 18:15, Alexandru Petrescu a écrit :
> 
>> Le 31/07/2013 17:38, Wes Beebee (wbeebee) a écrit :
>>>> If no prefix is found by the longetst-matching on the src address, will a 
>>>> default be used instead?
>>>> Alex
>>>>> There is also potentially a whole destination lookup table that¹s
>>>>> entirely devoted to the ::/0 source prefix.
>>>>> - Wes
>>> My understanding is that there IS a default for source address (see the 
>>> above comment).
>> 
>> Ok.
>> 
>> The default for dst addresses leads to a nexthop.
>> 
>> The default for src addresses leads also to a nexthop?  Or to the dst of
>> another dst prefix?  Or to the nexthop of the default of dst?
>> 
>> It may sound as a rathole discussion but it is fully part of what the
>> longest-match algorithm does.
>> 
>> Alex
>> 
> 
> 
> 
> I'm not sure about how it should be done but I can say how Linux seems to do 
> it.
> 
> * Those affirmation came by looking at the code... That I didn't wrote. So I 
> cannot be 100% sure *
> 
> Linux uses a tree structure in order to perform the longest prefix lookup on 
> the destination address first.
> The found node (which has the longest prefix for the source address), CAN 
> have a subtree. 
> This subtree has the same structure as a regular routing table, but is used 
> with the source address.
> 
> This means that each node in a routing table has its own source routing 
> table. There is no
> destination lookup first and then a source lookup in a global table.
> 
> --> See fib6_lookup, and fib6_lookup_1 functions
> 
> Now, when you add a route with destination and source prefix, 
> the node for destination is created (or updated) and, then, 
> if the source routing prefix length is not null, a subtree is created (or 
> updated) and
> a node with the provided source prefix is inserted.
> 
> --> See fib6_add
> 
> Therefore, for a given node in the main tree, if there is no source routing 
> (no subtree), the route
> is always used. Otherwise, a longest prefix match is performed on the source 
> address, using the subtree. 
> If there is no corresponding node for the source (no matching prefix, where 
> the prefix length can be null), 
> then, the parent node in the destination routing table is used as default. 
> 
> So, yes, inserting a route for a destination and source prefix will create an 
> entry for the destination alone 
> (without source routing). 
> So the default route, for a source lookup, is basically the last inserted 
> next-hop for the destination prefix... 
> Which could create unexpected behaviors.
> 
> 
> Concerning the previous question, Linux actually has a RTF_GATEWAY flag. But 
> it doesn't seem to
> be used in the routing decision process. I guess it is used by other 
> protocols that like to have a 
> concept of "default router".
> 
> 
> 
> Pierre
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to