[Xorp-users] value of ttl for ripng

admin galerie expo01 at free.fr
Thu Mar 6 14:22:20 PST 2008


Hi Pavlin,

I have three different questions if you have a little time for me.
The first is about the current CVS repository : yesterday, I applied 
the patch you gave me to the source code I had extracted some days ago. 
The modified files (.cc and .hh) where in the right version (1.27 and 
1.13) so all went well and the result was satisfying. But today, 
knowing that you had commited the fix, we decided to extract again the 
source code from your CVS repository, then recompiled and tested. And 
we have, with this release only, a problem with xorp_fea, which after 
launch dies a horrible death (signal 11, SEGV). Do you know of any 
problem recently appeared in this process ? (xorp_fea in the current 
CVS version is not the same as xorp_fea some days ago)

The second question is about rip : by default, xorp_rip and xorp_ripng 
publish routes with metric=0. This is not accepted by our Juniper peer, 
which says that metric shall be between 1 and 16. So in the policies I 
added in the "then" clause a statement "metric: 1", which fixed the 
Juniper bad mood. Is it ok to fix this problem in such a way ?

And third, in the ripng published routes, I see the following :         
        ::/0      metric: 255
What does it mean ?

Thanks for your support,

Vincent



Le 6 mars 08, à 05:59, Pavlin Radoslavov a écrit :

> admin galerie <expo01 at free.fr> wrote:
>
>> Hi Pavlin,
>>
>> I applied the patch, compiled and tested. It looks ok, in rip the ttl
>> is still one, and in ripng the hop limit is now 255. There seems to be
>> no regression elsewhere.
>> You can commit in CVS ! Tell me when/if it's done, so we can be sure
>> that a new checkout will bring no regression, please.
>> Thanks a lot for your quick bug fixing.
>
> I've just committed the fix:
>
> Revision  Changes                                Path
> 1.28      +13 -13;  commitid: 1ca147cf77f941a7;  
> xorp/rip/xrl_port_io.cc
> 1.14      +3 -3;  commitid: 1ca147cf77f941a7;    
> xorp/rip/xrl_port_io.hh
>
> Yes, the TTL for RIPv2 is still 1, because the RIPv2 spec
> doesn't say anything on the subject, therefore the generic rule for
> link-local multicast applies (TTL = 1).
>
> Regards,
> Pavlin
>
>> Regards,
>>
>> Vincent
>> Le 4 mars 08, à 22:54, Pavlin Radoslavov a écrit :
>>
>>> expo01 at free.fr wrote:
>>>
>>>> We are using Rip and Ripng from Xorp, and we have a problem with a
>>>> Juniper
>>>> router that accepts our Rip messages, but rejects the Ripng 
>>>> messages,
>>>> pretexting
>>>> their "ttl is 1, which is different from 255". We use Xorp 1.5-WIP. 
>>>> I
>>>> had a very
>>>> quick look at Xorp sources, and in the rip/tools directory, I found
>>>> that
>>>> ripng_announcer makes a call to comm_set_ttl(fd, 255), which seems
>>>> ok. But in
>>>> fact, that's true that our Ripng packets are finally issued with a
>>>> ttl value
>>>> equal to 1. Any idea ?
>>>
>>> I think it is a bug in XORP.
>>> Plese try the following patch, and if it works I will commit it to
>>> CVS.
>>>
>>> Thanks,
>>> Pavlin
>>>
>>> Index: xrl_port_io.cc
>>> ===================================================================
>>> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.cc,v
>>> retrieving revision 1.27
>>> diff -u -p -r1.27 xrl_port_io.cc
>>> --- xrl_port_io.cc	4 Jan 2008 03:17:34 -0000	1.27
>>> +++ xrl_port_io.cc	4 Mar 2008 21:50:41 -0000
>>> @@ -88,12 +88,12 @@ XrlPortIO<IPv4>::request_open_bind_socke
>>>
>>>  template <>
>>>  bool
>>> -XrlPortIO<IPv4>::request_ttl_one()
>>> +XrlPortIO<IPv4>::request_ttl()
>>>  {
>>>      XrlSocket4V0p1Client cl(&_xr);
>>>      return cl.send_set_socket_option(
>>> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
>>> -		callback(this, &XrlPortIO<IPv4>::ttl_one_cb));
>>> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_TTL,
>>> +		callback(this, &XrlPortIO<IPv4>::ttl_cb));
>>>  }
>>>
>>>  template <>
>>> @@ -191,12 +191,12 @@ XrlPortIO<IPv6>::request_open_bind_socke
>>>
>>>  template <>
>>>  bool
>>> -XrlPortIO<IPv6>::request_ttl_one()
>>> +XrlPortIO<IPv6>::request_ttl()
>>>  {
>>>      XrlSocket6V0p1Client cl(&_xr);
>>>      return cl.send_set_socket_option(
>>> -		_ss.c_str(), socket_id(), "multicast_ttl", 1,
>>> -		callback(this, &XrlPortIO<IPv6>::ttl_one_cb));
>>> +		_ss.c_str(), socket_id(), "multicast_ttl", RIP_NG_HOP_COUNT,
>>> +		callback(this, &XrlPortIO<IPv6>::ttl_cb));
>>>  }
>>>
>>>  template <>
>>> @@ -343,8 +343,8 @@ XrlPortIO<A>::startup_socket()
>>>  	// If we succeed here the path is:
>>>  	// request_open_bind_socket()
>>>  	// -> open_bind_socket_cb()
>>> -	//    -> request_ttl_one()
>>> -	//	 -> ttl_one_cb()
>>> +	//    -> request_ttl()
>>> +	//	 -> ttl_cb()
>>>  	//	     -> request_no_loop()
>>>  	//		-> no_loop_cb()
>>>  	//		   ->request_socket_join()
>>> @@ -379,17 +379,17 @@ XrlPortIO<A>::open_bind_socket_cb(const
>>>      _sid = *psid;
>>>      socket_manager.add_sockid(_ss, _sid);
>>>
>>> -    if (request_ttl_one() == false) {
>>> -	set_status(SERVICE_FAILED, "Failed requesting ttl/hops of 1.");
>>> +    if (request_ttl() == false) {
>>> +	set_status(SERVICE_FAILED, "Failed requesting ttl/hops.");
>>>      }
>>>  }
>>>
>>>  template <typename A>
>>>  void
>>> -XrlPortIO<A>::ttl_one_cb(const XrlError& e)
>>> +XrlPortIO<A>::ttl_cb(const XrlError& e)
>>>  {
>>>      if (e != XrlError::OKAY()) {
>>> -	XLOG_WARNING("Failed to set ttl/hops to 1");
>>> +	XLOG_WARNING("Failed to set ttl/hops.");
>>>      }
>>>      if (request_no_loop() == false) {
>>>  	set_status(SERVICE_FAILED,
>>> Index: xrl_port_io.hh
>>> ===================================================================
>>> RCS file: /usr/local/www/data/cvs/xorp/rip/xrl_port_io.hh,v
>>> retrieving revision 1.13
>>> diff -u -p -r1.13 xrl_port_io.hh
>>> --- xrl_port_io.hh	4 Jan 2008 03:17:34 -0000	1.13
>>> +++ xrl_port_io.hh	4 Mar 2008 21:50:41 -0000
>>> @@ -94,8 +94,8 @@ private:
>>>      bool request_open_bind_socket();
>>>      void open_bind_socket_cb(const XrlError& xe, const string* 
>>> psid);
>>>
>>> -    bool request_ttl_one();
>>> -    void ttl_one_cb(const XrlError& xe);
>>> +    bool request_ttl();
>>> +    void ttl_cb(const XrlError& xe);
>>>
>>>      bool request_no_loop();
>>>      void no_loop_cb(const XrlError& xe);
>>
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>




More information about the Xorp-users mailing list