[Xorp-users] Unreachable default route.

[Ben Greear]

Pavlin Radoslavov wrote:
> Ben Greear <greearb at candelatech.com> wrote:
>
>   
>> Ok, I think this is working now...patch is attached.
>>
>> In addition to the 'unreachable' feature, this also includes the
>> hack to let the 'static' priority be set though an environment
>> variable, and a slight modification of the error logging for
>> receiving pkts not destined for this Xorp's interfaces.
>>
>> If it is more convenient, I can cut those extra two things
>> out of the patch, but I would also be happy if they went into
>> Xorp proper.  I understand the getenv hack is not a long term
>> solution, but it is better than nothing, and if the variable is
>> not set, you get the current default behaviour.
>>
>> Please look for 'TODO' in the patch, as I had a few questions
>> as to whether I did it right.  It seems to be working right on
>> Linux:
>>
>> 10.2.0.0/24 via 10.0.0.1 dev rddVR1  proto xorp  metric 2 notify
>> 10.0.0.0/24 dev rddVR1  scope link
>> 10.4.0.0/24 dev rddVR44  scope link
>> 10.1.0.0/24 via 10.4.0.2 dev rddVR44  proto xorp  metric 2 notify
>> 10.3.0.0/24 via 10.0.0.1 dev rddVR1  proto xorp  metric 2 notify
>> unreachable default  proto xorp  metric 1 notify
>>
>>
>> cfg-file snippets:
>>
>> interfaces {
>>      interface my_discard {
>>          unreachable: true
>>          vif my_discard {
>>          }
>>      }
>> }
>>
>> protocols {
>>      static {
>>          interface-route 0.0.0.0/0 {
>>              next-hop-interface: "my_discard"
>>              next-hop-vif: "my_discard"
>>          }
>>      }
>> }
>>     
>
> Ben,
>
> I committed your patch modulo some changes as described below:
>
> * In your patch there was a reference to RTF_UNREACHABLE.
>   This flag doesn't exist on BSD (actually Web search didn't return
>   any match), so I removed it.
>   
Ok, sounds fine.
> * 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.

> * I didn't commit any of the OSPF changes, because on closer
>   investigation there was no place where the "unreachable" flag for
>   a route was actually set.
>   After discussing it with Atanu, it is not clear what exactly means
>   to have "unreachable" support inside OSPF.
>   According to Atanu, OSPF uses internally the discard routes to add
>   them to the kernel when announcing aggregated routes.
>   If you have something specific in mind with regard to OSPF, please
>   discuss it with Atanu, and after that we can add it to XORP.
>   
Ok, that sounds fine too.
> * 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.
> BTW, I tested it on both Linux and FreeBSD-6.2, and it seems to
> work. Nice job!
>   

Excellent!  Thanks for the help and for accepting the patch!

Ben

> Thanks,
> Pavlin
>   


-- 
Ben Greear <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com