[Xorp-hackers] Problems with flat IP addressing in XORP+Click

Pavlin Radoslavov pavlin@icir.org
Wed, 02 Feb 2005 13:52:27 -0800


Julian,

Please replace inside fea/fticonfig_entry_set_click.cc all instances
of:

    if (fte.is_connected_route())
        ;       // XXX: accept directly-connected routes

with:

    if (fte.is_connected_route())
        return true;    // XXX: don't add/remove directly-connected routes

[There should be 4 of them]

Apparently, the original xorp_fea_click_config_generator itself
also initializes the routing table lookup element with the directly
connected routes, and they point to the local-delivery output port.
Please let me know if this fixes the problem for you, and then I
will apply the change to the code in the CVS repository.

Thanks,
Pavlin


> We are currently working with XORP+Click for building a router for a wireless 
> ad-hoc environment, that means that we are using flat address (/32). Because 
> of this, we were having some problems and now we think that we understood 
> what is happening. It seems that XORP does not take into consideration this 
> particular case when all addresses are /32.
> 
> In our scenario we had 2 nodes directly connected (A and B) and a simple 
> protocol running over XORP that exchanges information between them and create 
> the needed routes for them to communicate. We also used a KernelTun element 
> to capture every packet generated by the node and route it according to the 
> Click routing table (since every node in the network is supposed to act as a 
> router and as a host at the same time).
> 
> Well, the problem arises when we try to ping one node from the other. If we 
> ping node B from node A, node B replies the ping but also sends ICMP redirect 
> error messages. We think that the problem is that when we configure nodes to 
> a flat IP (e.g., 10.0.0.1/32), XORP creates a "connected" route like the one 
> below:
> 
> Network 10.0.0.1/32
>    Nexthop := 10.0.0.1
>    Metric := 0   Protocol := connected   Interface := eth0   Vif := eth0
> 
> Then, this route is added into the LinearIPLookup click element overwriting 
> the original rule (generated by the awk script) to 10.0.0.1/32 (which is the 
> local delivey). 
> 
> Originally we had:
> 
>    -> _xorp_rt :: LinearIPLookup(10.0.0.1/32 1)  // Output 1 is local delivery
> 
> We suppose that the rule shown above will add a rule telling that 10.0.0.1/32 
> should go to the output 0 (that represents eth0). As a consequence, the rule 
> above is useless and a ping packet that arrives to this node is sent to the 
> host through Linux (we use userlevel click) and a copy is directed to eth0 
> (and, since it comes from eth0, an ICMP Redirect Error is generated). 
> 
> We know that in the case of a wireless environment, there is no sense on 
> sending redirect errors, but even though, we think that in the case of /32 IP 
> addresses, this route should not be added to _xorp_rt. Are we right?