[Xorp-users] value of ttl for ripng
Pavlin Radoslavov
pavlin at ICSI.Berkeley.EDU
Fri Mar 7 04:23:41 PST 2008
admin galerie <expo01 at free.fr> wrote:
> 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)
Yesterday I committed some changes to the FEA.
I think there was a bug inside those changes, so I temporary
reversed them pending further investigation:
Revision Changes Path
1.58 +5 -7; commitid: 4e1f47d1305c41a7; xorp/fea/iftree.cc
1.61 +7 -9; commitid: 4e1f47d1305c41a7; xorp/fea/iftree.hh
Please pull again the latest FEA code from CVS and make sure the
above two files are the correct version.
> 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 ?
What is your RIP and policy configuration without the above "then"
clause that you use to fix the metric?
If you use a policy like the following, is the RIP/RIPng metric for
connected routes actually advertised as zero?
policy {
policy-statement export-connected {
term 100 {
from {
protocol: "connected"
}
}
}
}
If this is the case, then this is a bug, so please submit it into
Bugzilla.
In the mean time you could use the "metric: 1" fix in the "then"
clause.
> And third, in the ripng published routes, I see the following :
> ::/0 metric: 255
> What does it mean ?
Where do you see it?
Route "::/0" is the default route (the equivalent of 0.0.0.0/0 for
IPv4), so basically the above says that the metric for the default
route is 255.
Regards,
Pavlin
> 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
> >
>
>
> _______________________________________________
> 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