[Xorp-users] xorp RIPng
Hansi
hantongs at gmail.com
Thu Nov 15 23:03:57 PST 2007
Hello Pavlin,
Just to be sure that I'm not mistaken on the problem that I reported,
I disabled XORP then ran route6d. (this is just for comparative
purposes)
Here are the details by the way:
ROUTER 1
$ ifconfig -a | more
sk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=b<RXCSUM,TXCSUM,VLAN_MTU>
inet6 fe80::219:5bff:fe85:cfc7%sk0 prefixlen 64 scopeid 0x1
inet 172.16.0.1 netmask 0xffff0000 broadcast 172.16.255.255
inet6 2001:ec1:4001:10af::1 prefixlen 64
ether 00:19:5b:85:cf:c7
media: Ethernet autoselect (1000baseTX <full-duplex,flag0,flag1>)
status: active
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::213:d4ff:fed8:6808%vr0 prefixlen 64 scopeid 0x2
inet 200.10.0.1 netmask 0xffffff00 broadcast 200.10.0.255
inet6 2001:ec0:4000:beef::1 prefixlen 64
ether 00:13:d4:d8:68:08
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
plip0: flags=108851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,NEEDSGIANT> mtu 15
00
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000
$netstat -rna | more
Internet6:
Destination Gateway Flags Neti
f 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: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%vr0 UG vr0
ROUTER 2
$ ifconfig -a | more
sk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=b<RXCSUM,TXCSUM,VLAN_MTU>
inet6 fe80::219:5bff:fe2f:146a%sk0 prefixlen 64 scopeid 0x1
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
inet6 2001:ec2:4002:fa11::1 prefixlen 64
ether 00:19:5b:2f:14:6a
media: Ethernet autoselect (100baseTX <full-duplex,flag0,flag1>)
status: active
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::215:f2ff:fe3d:ac91%vr0 prefixlen 64 scopeid 0x2
inet 200.10.0.2 netmask 0xffffff00 broadcast 200.10.0.255
inet6 2001:ec0:4000:beef::2 prefixlen 64
ether 00:15:f2:3d:ac:91
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
plip0: flags=108851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,NEEDSGIANT> mtu 150
0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000
$netstat -rna | more
Route Table:
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::2 00:15:f2:3d:ac:91 UHL lo0
2001:ec1:4001:10af::/64 fe80::213:d4ff:fed8:6808%vr0 UG vr0
2001:ec2:4002:fa11::/64 link#1 UC sk0
Routing Table entry when running route6d:
2001:ec2:4002:fa11::/64 fe80::215:f2ff:fe3d:ac91%vr0 UG vr0
Routing Table entry when running XORP RIPng:
2001:ec2:4002:fa11::/64 fe80::215:f2ff:fe3d:ac91%sk0 UG1 sk0
There's a significant difference in the interfaces. Using route6d, I
was able to ping from pc to pc. And I believe that vr0 should be the
correct interface. :) No wonder why the advertised networks exhibit a
metric of 16. Here's a tcpdump when running route6d:
03:06:12.254810 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok] ripng-resp
1: 2001:ec2:4002:fa11::/64 (1)
03:06:13.916513 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok] ripng-resp
1: 2001:ec1:4001:10af::/64 (1)
03:06:37.918085 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok] ripng-resp
1: 2001:ec1:4001:10af::/64 (1)
03:06:49.255609 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok] ripng-resp
1: 2001:ec2:4002:fa11::/64 (1)
03:07:10.919883 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok] ripng-resp
1: 2001:ec1:4001:10af::/64 (1)
03:07:33.256372 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok] ripng-resp
1: 2001:ec2:4002:fa11::/64 (1)
03:07:47.921761 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok] ripng-resp
1: 2001:ec1:4001:10af::/64 (1)
03:07:58.257233 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok] ripng-resp
1: 2001:ec2:4002:fa11::/64 (1)
Appreciate your assistance on this problem.
Regards,
Hansi
On Nov 15, 2007 7:01 PM, Hansi <hantongs at gmail.com> wrote:
> Hello Pavlin,
>
> 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.
>
> 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.
>
> 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
> 05:41:31.059524 IP6 (hlim 1, next-header: UDP (17), length: 52)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok] ripng-resp
> 2:
> ::/0 (255)
> 2001:ec1:4001:10af::/64 (16)
> 05:41:32.942289 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok] ripng-resp
> 5:
> ::/0 (255)
> 2001:ec0:4000:beef::/64
> 2001:ec1:4001:10af::/64
> 2001:ec2:4002:fa11::/64 (16)
> fe80::/64
> 05:41:35.686314 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok] ripng-resp
> 5:
> ::/0 (255)
> 2001:ec0:4000:beef::/64
> 2001:ec1:4001:10af::/64 (16)
> 2001:ec2:4002:fa11::/64
> fe80::/64
> 05:42:01.260164 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok] ripng-resp
> 5:
> ::/0 (255)
> 2001:ec0:4000:beef::/64
> 2001:ec1:4001:10af::/64
> 2001:ec2:4002:fa11::/64 (16)
> fe80::/64
> 05:42:08.229241 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok] ripng-resp
> 5:
> ::/0 (255)
> 2001:ec0:4000:beef::/64
> 2001:ec1:4001:10af::/64 (16)
> 2001:ec2:4002:fa11::/64
> fe80::/64
> 05:42:32.784957 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok] ripng-resp
> 5:
> ::/0 (255)
> 2001:ec0:4000:beef::/64
> 2001:ec1:4001:10af::/64
> 2001:ec2:4002:fa11::/64 (16)
> fe80::/64
> 05:42:38.688112 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok] ripng-resp
> 5:
> ::/0 (255)
> 2001:ec0:4000:beef::/64
> 2001:ec1:4001:10af::/64 (16)
> 2001:ec2:4002:fa11::/64
> fe80::/64
> 05:43:00.533865 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok] ripng-resp
> 5:
> ::/0 (255)
> 2001:ec0:4000:beef::/64
> 2001:ec1:4001:10af::/64
> 2001:ec2:4002:fa11::/64 (16)
> fe80::/64
> 05:43:08.615122 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok] ripng-resp
> 5:
> ::/0 (255)
> 2001:ec0:4000:beef::/64
> 2001:ec1:4001:10af::/64 (16)
> 2001:ec2:4002:fa11::/64
> fe80::/64
> 05:43:31.085701 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok] ripng-resp
> 5:
> ::/0 (255)
> 2001:ec0:4000:beef::/64
> 2001:ec1:4001:10af::/64
> 2001:ec2:4002:fa11::/64 (16)
> fe80::/64
>
> 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
>
> Hope you could shed some light on this.
>
> Thanks,
> Hansi
>
>
> On Nov 15, 2007 9:49 AM, Hansi <hantongs at gmail.com> wrote:
> > On Nov 15, 2007 9:23 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > > Hansi <hantongs at gmail.com> wrote:
> > >
> > > > On Nov 15, 2007 1:52 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > > > > > Replacing the global address with the link-local IPv6 address provides
> > > > > > the same results. No peerings between two XORP machines w/ RIPng
> > > > > > enabled are established. Attached is the configuration file used.
> > > > > >
> > > > > > Also, I managed to do a trace as you instructed to:
> > > > > >
> > > > > > 2:33:20<root at demo_rtr :/usr/local/xorp/bin>)#less typescript | grep
> > > > > > "socket6_user"
> > > > > > "typescript" may be a binary file. See it anyway? y
> > > > > >
> > > > > > [ 2007/11/14 02:28:57 INFO xorp_fea XRL ] Resolving
> > > > > > xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1@127.0.0.1/socket6_user/0.1/recv_event?sockid:txt=00000000-000032e1-000ab21c-063b0000&src_host:ipv6=fe80::215:f2ff:fe3d:ac91&src_port:u32=521&data:binary=%01%01%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%10
> > > > >
> > > > > OK, the above indicates that the FEA has received and forwarded the
> > > > > UDP packet to the RIPng module.
> > > > >
> > > > > After you started using the link-local addresses in your
> > > > > configuration what is the output of "show ripng peer statistics all"
> > > > > xorpsh command? It should show something like:
> > > > >
> > > >
> > > > Yes, I did. But it displays "There are no peers" or something like
> > > > that which indicates that no peerings has been established.
> > >
> > > That's odd.
> > > What FreeBSD version are you using?
> >
> > I'm also using FreeBSD-6.2 on an amd64 architecture.
> > >
> > > It worked for me between FreeBSD-6.2 (amd64) and FreeBSD-4.10.
> > > If it still doesn't work for you, start with my configuration I sent
> > > in the previous email, but double-check that the local IPv6 address
> > > inside your ripng configuration indeed matches the link-local
> > > address on each host.
> > >
> > > This is a show-stopper and if they don't peer then the rest won't
> > > work.
> > >
> >
> > Yes, indeed. The reason why I can't move forward. Nevertheless, I'll
> > keep you posted. :)
> >
> > Thanks,
> > Hansi
> >
> >
> > > Pavlin
> > >
> > >
> > > > > user at hostname> show ripng peer statistics all
> > > > >
> > > > > * RIP statistics for peer fe80::xxxx:xxxx on rl0 rl0 fe80::yyyy:yyyy
> > > > >
> > > > > Last Active at Wed Nov 14 09:40:37 2007
> > > > >
> > > > > Counter Value
> > > > > -------------------------------- ----------------
> > > > > Total Packets Received 6
> > > > > Request Packets Received 1
> > > > > Update Packets Received 5
> > > > > Bad Packets Received 0
> > > > > Bad Routes Received 5
> > > > > Routes Active 0
> > >
> >
>
More information about the Xorp-users
mailing list