[Xorp-users] RIPng issue

Paweł Sroczyński leniwiec16 at gmail.com
Wed May 21 15:13:20 PDT 2014


Hi Avinash,

Thanks for your reply. I didn't know about the "ip link" command, quite
useful one. All interfaces are up and running.

I did the test you proposed. There is no connectivity  between R2 and R3
eth1 interface. R2 has learned the route to fdb0:777:4dce:2ca1::/64 network
but R3 didn't learned the route to fdb0:777:4dce:3b87::/64. So the last
interface which responds to ping from R2 is R1 eth2
(fdb0:777:4dce:2ca1::1).

tcpdump on R1 eth2:
root at router:~# tcpdump -i eth2
tcpdump: WARNING: eth2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
00:02:58.694024 IP6 fe80::a00:27ff:fea3:ff3e.521 > ff02::9.521:  ripng-resp
2: ::/0 (255) fdb0:777:4dce:2ca1::/64
00:03:00.851341 IP6 fe80::a00:27ff:fea3:ff3e.521 > ff02::9.521:  ripng-req
dump
00:03:29.931314 IP6 fe80::a00:27ff:fea3:ff3e.521 > ff02::9.521:  ripng-resp
2: ::/0 (255) fdb0:777:4dce:2ca1::/64
00:03:30.851452 IP6 fe80::a00:27ff:fea3:ff3e.521 > ff02::9.521:  ripng-req
dump

tcpdump on R3 eth1:
root at router:~# tcpdump -i eth1
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
00:03:29.930363 IP6 fe80::a00:27ff:fea3:ff3e.521 > ff02::9.521:  ripng-resp
2: ::/0 (255) fdb0:777:4dce:2ca1::/64
00:03:30.850598 IP6 fe80::a00:27ff:fea3:ff3e.521 > ff02::9.521:  ripng-req
dump
00:04:00.851172 IP6 fe80::a00:27ff:fea3:ff3e.521 > ff02::9.521:  ripng-req
dump
00:04:02.271207 IP6 fe80::a00:27ff:fea3:ff3e.521 > ff02::9.521:  ripng-resp
2: ::/0 (255) fdb0:777:4dce:2ca1::/64

Any ideas?

Pawel


2014-05-21 23:35 GMT+02:00 Avinash Sridharan <avinash.sridharan at gmail.com>:

> Without adding the eth2::1 interface of  R2 and eth2::2 interface of R3 to
> XORP , can you test the connectivity between R2 and R3 in linux. Also, once
> you have configured the interfaces in XORP you can "ip link" on linux shell
> to verify the addresses configured on the specific interfaces to make sure
> that they are up and configured correctly in the linux kernel.
>
> -Avinash
>
>
> On Wed, May 21, 2014 at 2:13 PM, Paweł Sroczyński <leniwiec16 at gmail.com>wrote:
>
>> Hi All,
>> I'm trying to configure RIPng in a simple 3 router topology without
>> success. I'm using XORP 1.8.5 installed on the latest stable Debian version
>> 7.5. Network is as follows:
>>
>>     First 48bit of each subnet are:
>>     FDB0:777:4DCE::/48
>>
>>          eth1::2  eth2::1
>>     +---------+R2+-----------+
>>     |                        |
>>     |                        |
>>     |                        |
>>     |:3B87/64                |:888/64
>>     |                        |
>>     |                        |
>> eth1|::1        :2CA1/64     +eth2::2
>>   R1+----------------------+R3
>>      eth1::1             eth1::2
>>
>> Sorry for bad ASCII.
>>
>> The problem I encountered is that after launching XORP on each router
>> only R1 and R2 have complete routing table.
>>
>> Route table on R1:
>> student at router> show route table ipv6 unicast final
>> fdb0:777:4dce:888::/64  [rip(120)/1]
>>                 > to fe80::a00:27ff:feb1:9514 via eth1/eth1
>> fdb0:777:4dce:2ca1::/64 [connected(0)/0]
>>                 > via eth2/eth2
>> fdb0:777:4dce:3b87::/64 [connected(0)/0]
>>                 > via eth1/eth1
>> fe80::/64       [connected(0)/0]
>>                 > via eth1/eth1
>>
>> Route table on R2:
>> student at router> show route table ipv6 unicast final
>> fdb0:777:4dce:888::/64  [connected(0)/0]
>>                 > via eth2/eth2
>> fdb0:777:4dce:2ca1::/64 [rip(120)/1]
>>                 > to fe80::a00:27ff:fe4d:c528 via eth1/eth1
>> fdb0:777:4dce:3b87::/64 [connected(0)/0]
>>                 > via eth1/eth1
>> fe80::/64       [connected(0)/0]
>>                 > via eth1/eth1
>> Route table on R3:
>> student at router> show route table ipv6 unicast final
>> fdb0:777:4dce:888::/64  [connected(0)/0]
>>                 > via eth2/eth2
>> fdb0:777:4dce:2ca1::/64 [connected(0)/0]
>>                 > via eth1/eth1
>> fe80::/64       [connected(0)/0]
>>                 > via eth1/eth1
>>
>> I've run tcpdump on each interface and it seems there is absolutely
>> nothing going on on R2<->R3 link. Why is that is beyond my comprehension. I
>> also enabled traceoptions, you can see results below:
>> R1:
>> [ 2014/05/21 22:41:09.941083 TRACE xorp_ripng RIP ] adding RIB route
>> fdb0:777:4dce:2ca1::/64
>> [ 2014/05/21 22:41:09.941529 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:2ca1::/64
>> [ 2014/05/21 22:41:09.941575 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:2ca1::/64
>> [ 2014/05/21 22:41:09.941691 TRACE xorp_ripng RIP ] adding RIB route
>> fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:09.941742 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:09.941773 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:19.610982 TRACE xorp_ripng RIP ] Packet on
>> 7f000101-00005c1f-0000bd2f-0e680000 from interface eth1 vif eth1
>> fe80::a00:27ff:feb1:9514/521 24 bytes
>>
>>
>> R2:
>> [ 2014/05/21 22:41:19.613244 TRACE xorp_ripng RIP ] Packet on
>> 7f000101-00005bf4-00057451-0b880000 from interface eth1 vif eth1
>> fe80::a00:27ff:fe4d:c528/521 64 bytes
>> [ 2014/05/21 22:41:19.613527 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:2ca1::/64
>> [ 2014/05/21 22:41:19.613551 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:2ca1::/64
>> [ 2014/05/21 22:41:19.613579 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:19.613593 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:19.634655 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:2ca1::/64
>> [ 2014/05/21 22:41:19.634693 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:2ca1::/64
>> [ 2014/05/21 22:41:19.634721 TRACE xorp_ripng RIP ] Was filtered: 0,
>> Accepted: 1
>> [ 2014/05/21 22:41:19.634735 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:19.634748 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:21.637290 TRACE xorp_ripng RIP ] Was filtered: 0,
>> Accepted: 1
>> [ 2014/05/21 22:41:21.642894 TRACE xorp_ripng RIP ] adding RIB route
>> fdb0:777:4dce:888::/64
>> [ 2014/05/21 22:41:21.643075 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:888::/64
>> [ 2014/05/21 22:41:21.643115 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:888::/64
>> [ 2014/05/21 22:41:21.643178 TRACE xorp_ripng RIP ] adding RIB route
>> fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:21.643214 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:21.643242 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:3b87::/64
>> [ 2014/05/21 22:41:56.522666 TRACE xorp_ripng RIP ] Packet on
>> 7f000101-00005bf4-00057451-0b880000 from interface eth1 vif eth1
>> fe80::a00:27ff:fe4d:c528/521 44 bytes
>>
>>
>> R3:
>>  2014/05/21 22:41:27.245528 TRACE xorp_ripng RIP ] adding RIB route
>> fdb0:777:4dce:888::/64
>> [ 2014/05/21 22:41:27.245866 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:888::/64
>> [ 2014/05/21 22:41:27.245907 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:888::/64
>> [ 2014/05/21 22:41:27.246016 TRACE xorp_ripng RIP ] adding RIB route
>> fdb0:777:4dce:2ca1::/64
>> [ 2014/05/21 22:41:27.246057 TRACE xorp_ripng RIP ] Running import filter
>> on route fdb0:777:4dce:2ca1::/64
>> [ 2014/05/21 22:41:27.246085 TRACE xorp_ripng RIP ] Running source match
>> filter on route fdb0:777:4dce:2ca1::/64
>>
>> Configuration on each router is parallel to this one:
>>
>> interfaces {
>>     restore-original-config-on-shutdown: true
>>     interface eth1 {
>>         description: "link between R1 and R2"
>>         disable: false
>>         vif eth1 {
>>         disable: false
>>             address FDB0:777:4DCE:3B87::1 {
>>                 prefix-length: 64
>>                 disable: false
>>             }
>>             address fe80::a00:27ff:fe4d:c528 {
>>                 prefix-length: 64
>>                 disable: false
>>             }
>>         }
>>     }
>>     interface eth2 {
>>         description: "link between R1 and R3"
>>         disable: false
>>         vif eth2 {
>>         disable: false
>>             address FDB0:777:4DCE:2CA1::1 {
>>                 prefix-length: 64
>>                 disable: false
>>             }
>>             address fe80::a00:27ff:febe:336e {
>>                 prefix-length: 64
>>                 disable: false
>>             }
>>         }
>>     }
>> }
>>
>> fea {
>>     unicast-forwarding6 {
>>         disable: false
>>     }
>> }
>>
>> policy {
>>     policy-statement export-connected {
>>         term export {
>>             from {
>>                 protocol: "connected"
>>                 network6 <= ::/0
>>             }
>>         }
>>     }
>> }
>>
>> protocols {
>>     ripng {
>>         export: "export-connected"
>>         interface eth1 {
>>             vif eth1 {
>>                 address fe80::a00:27ff:fe4d:c528 {
>>                     disable: false
>>                 }
>>             }
>>         }
>>         interface eth2 {
>>             vif eth2 {
>>                 address fe80::a00:27ff:febe:336e {
>>                     disable: false
>>                 }
>>             }
>>         }
>>         traceoptions {
>>             flag all {
>>                 disable: false
>>             }
>>         }
>>     }
>> }
>>
>> I've double and triple-checked all the link-local addresses etc. so
>> addressing should be fine. Why R3 is not participating in the route
>> exchange process as it's supposed to?
>>
>> I will greatly appreciate any help to find the root of the problem.
>>
>> Thanks and regards,
>> Pawel
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20140522/ecee0aa5/attachment-0001.html 


More information about the Xorp-users mailing list