Re: Stale entries in RT_TABLE_LOCAL

[Alex Sidorenko <alexandre.sidorenko@hp.com>]

On March 9, 2011 08:50:27 PM Julian Anastasov wrote:
>         Aha, it seems the problem happens when the
> both lines are executed while there is another address on
> device and the last added address becomes secondary
> for the 1st, eg:

Hi Julian,

this is correct - you need another address on device. I used iptest.sh script 
for testing as it is easier and less error-prone than adding addresses 
manually. In additon, it reinserts 'dummy' module so that every time we start 
with a clean slate.

>         Alex, what is the kernel version and can you test
> 
> it on different kernels?

I tested this on SLES10 (2.6.16 kernel), RHEL5 (2.6.18 kernel) and 
Ubuntu/Maverick (2.6.35 kernel)

> 
> IP1: 192.168.140.31/22, primary
> IP2: 192.168.142.109/23, primary
> IP3: 192.168.142.109/22, secondary for primary IP1
> 
>         It is the route for IP3 that is leaked, with prefsrc=IP1.
> We create local route for secondary IPs with prefsrc=ItsPrimaryIP.
> Both local routes for 109 differ in prefsrc (fa_info). But on
> deletion only one route is deleted due to last_ip check - the first
> because on deletion prefsrc is not matched, fib_table_delete
> does not work in symmetric way. So, the local route created
> for IP3 remains no matter the deletion order.
> If we decide to create one unique local route for this case,
> there is a risk device unregistration to remove
> it (fib_sync_down_dev with force > 0). 

Yes, but do we _really_ need to be able to add the same IP multiple times 
(with different masks)? If not, we can just return an error when someine tries 
to add the same IP again with different mask.

Regards,
Alex

-- 
------------------------------------------------------------------
Alexandre Sidorenko             email: asid@hp.com
WTEC Linux			Hewlett-Packard (Canada)
------------------------------------------------------------------