[Xorp-users] xorp RIPng

Hansi hantongs at gmail.com
Sun Nov 18 21:56:29 PST 2007


Hello Pavlin,

Thank you for answering my queries. Please see inline response below.

On Nov 17, 2007 1:56 PM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > Finally, I was able to establish a peering between two RIPng routers.
> > :) However, I noticed something odd. Shouldn't it be that RIP peerings
> > will be established even though no policy on connected/static routes
> > have been exported yet? During my exploration, I have observed that
> > upon enabling RIPng on both XORP machines, only the XORP router which
> > was enabled first would display that a peering has been established
> > through invoking "show ripng peer statistics all". The other router,
> > upon invoking the same command, displays "There are no known peers".
> > However, when policies are exported to the RIPng protocol, both would
> > now display that a peering has been established.
>
> This is an artifact of how the "Request" packets are transmitted in
> the XORP implementation: the request packets are transmitted
> periodically only if there is no neighbor (e.g., see rip/port.hh and
> rip/port.cc and search for "request_table").
>
> I quickly looked into the spec (RFC 2080) and the spec doesn't say
> that the "Request" packets have to be transmitted periodically
> (i.e., the "Request" packets do not have the function of Hello
> packets that are usually seen in other protocols).
>
> Hence, what you see is an interesting (though slightly confusing)
> corner case that shouldn't break anything.
>
> Once you start exporting some routes (e.g., "connected") then there
> should be no more confusion.
>
>
> > When configuring RIPng and the network has converged, should the next
> > hop address be the link-local address of the next-hop router or the
> > global unicast address? Because from what I'm seeing upon invoking
> > netstat -rna, this is returned:
> >
> > Internet6:
> > Destination                       Gateway                       Flags      Netif
> >  Expire
> > ::/96                             ::1                           UGRS        lo0
> > ::1                               ::1                           UHL         lo0
> > ::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
> > 2001:ec0:4000:beef::/64           link#2                        UC          vr0
> > 2001:ec0:4000:beef::1             00:13:d4:d8:68:08             UHL         lo0
> > 2001:ec0:4000:beef::2             00:15:f2:3d:ac:91             UHLW        vr0
> > 2001:ec1:4001:10af::/64           link#1                        UC          sk0
> > 2001:ec1:4001:10af::1             00:19:5b:85:cf:c7             UHL         lo0
> > 2001:ec1:4001:10af:219:5bff:fe2f:1468 00:19:5b:2f:14:68             UHLW
> > sk0
> > 2001:ec2:4002:fa11::/64           fe80::215:f2ff:fe3d:ac91%sk0  UG1         sk0
> >
> > The destination network is 2001:ec2:4002:fa11::/64 and the next hop
> > router address happens to be fe80::215:f2ff:fe3d:ac91%sk0. Please
> > refer to this link for the network topology as well as the interface
> > assignments.
> >
> > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-November/002176.html
> >
> > I'm just confused of fe80::215:f2ff:fe3d:ac91%sk0. This happens to be
> > the link local address of the next hop router w/c is router two. The
> > interface should be vr0 and not sk0.
>
> The nexthop should be the link-local address of the neighbor (on the
> connected interface).
> However, there was a bug the way the incoming interface was
> calculated for IPv6 so that's why probably are seeing the wrong
> interface. I just committed a fix, hence please try the latest code
> from CVS.
>

   The CVS code downloaded from the XORP CVS repository still exhibits
the same bug issue. The wrong interface is still being used as the
incoming interface as seen using netstat.

> > Looking further, I found this:
> >
> > admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
> > 2001:ec0:4000:beef::/64 [rip(120)/1]
> >                 > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0
> > 2001:ec2:4002:fa11::/64 [rip(120)/1]
> >                 > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0
> >
> > These results were take from router 1 indicating that in order to get
> > to network 2001:ec2:4002:fa11::/64, the next hop address should be
> > fe80::215:f2ff:fe3d:ac91. But how come it is via sk0? sk0 happens to
> > be the interface facing the client. Shouldn't it be vr0 instead? This
> > behavior is also inherent in router 2.
> >
> > I can confirm that RIPng is now working because of these logs:
> >
> > 05:41:28.005579 IP6 (hlim 1, next-header: UDP (17), length: 92)
> > fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
> > 4:
> >         ::/0 (255)
> >         2001:ec0:4000:beef::/64
> >         2001:ec1:4001:10af::/64
> >         fe80::/64
>
> <DEL>
>
> > However I'm also seeing these messages from stdout:
> >
> > [ 2007/11/15 05:45:14 INFO xorp_ripng RIP ] RIP port
> > vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> > fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> > [ 2007/11/15 05:45:49 INFO xorp_ripng RIP ] RIP port
> > vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> > fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> > [ 2007/11/15 05:46:18 INFO xorp_ripng RIP ] RIP port
> > vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> > fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> > [ 2007/11/15 05:46:51 INFO xorp_ripng RIP ] RIP port
> > vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> > fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> > [ 2007/11/15 05:47:19 INFO xorp_ripng RIP ] RIP port
> > vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> > fe80::215:f2ff:fe3d:ac91:521 - linklocal route
>
> Those can be safely ignored.
> Anyway I committed another fix so now they should be gone.

Thanks! I'm no longer seeing these errors now.
>
> Please let me know whether the latest CVS code works for you.
>
> Regards,
> Pavlin
>



More information about the Xorp-users mailing list