[Xorp-users] Unreachable default route.

[Pavlin Radoslavov]

> > * I didn't commit the changes related to the "no vif found"
> >   XLOG_WARNING() inside fea/data_plane/io/io_ip_socket.cc for the
> >   following two reasons:
> >   - Rate-limiting of warning messages should be implemented in a
> >     generic way rather than adding extra code everywhere we might
> >     have XLOG_WARNING() message.
> >   - We don't want to have any hard-coding like "pif_index == 1",
> >     because it might be true for Linux, but not in general.
> >     Also, someone might be playing with the loopback interface and
> >     might want to see the warning messages.
> >   Said that, I think my preference is to change the XLOG_WARNING()
> >   to XLOG_TRACE() so the log message can be explicitly enabled or
> >   disabled as needed.
> >   I haven't committed yet the XLOG_TRACE() change, pending to see
> >   whether it will work for you.
> >   
> When I get interface add/deletion working, and the busy-spin in xorpsh 
> fixed,
> I plan to add bpf filters to the sockets, which should make that error 
> message
> truly an error.  Either way, I can keep a small patch in the code I use 
> if needed.

>From educational purpose I'd be interested to see what the
particular BPF filters will look like.
However, as I mentioned in some of the earlier emails on the subject
I still need to be convinced (with numbers) that this is a
bottleneck issue.
The numbers I am looking at is something along the lines:
currently there could be up to X concurrently XORP
instances. With BPF filters the number is X*Y (where Y should be
larger than 1.0 :)
If there is no practical difference then there is no point of adding
the extra complexity.
Also, I'd prefer there is a generic solution that can be applied,
because BPF might not always be available.

> > * I didn't commit the getenv("XORP_RIB_STATIC_DISTANCE") hack,
> >   because my preference is that we stay away from such hacks. Adding
> >   it in one place will open the door to start doing the same
> >   elsewhere.
> >   Instead, you should keep pushing on us to implement it properly :)
> >   Alternatively, you could submit the patch with the proper solution ;)
> >   
> For now, I'll keep the hack in my version of xorp.  The interface 
> add/delete problems
> are of higher priority, but I might get to working on this eventually if 
> you don't
> beat me to it.

I don't want to discourage you, but fixing it properly might not be
trivial and might require considerable amout of changes and
understanding lots of details about RIB (including probably changing
the add_route XRL API between the protocols and the RIB).
Said that, if it is not high priority for you, your best strategy
could be to keep pushing us to do it :)

Regards,
Pavlin