From pavlin at icir.org  Thu Nov  1 00:13:31 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 01 Nov 2007 00:13:31 -0700
Subject: [Xorp-users] "Make All" error
In-Reply-To: Message from HJ <hengjuen@gmail.com> of "Thu,
	01 Nov 2007 14:36:49 +0800."
	<686b91b0710312336t38a7e35id81c725fc68e94c7@mail.gmail.com> 
Message-ID: <200711010713.lA17DVxn054237@possum.icir.org>

HJ <hengjuen at gmail.com> wrote:

> Hi Pavlin,
> Here is the info i collected.
> 
> 
> Make version:    GNU make 3.81
> 
> OS:                  Fedora Core 7
> 
> 
> 
> Actually *make all* doesn't change the *./configure file*. It is *make ?CB**.
> *
> 
> 
> 
> Attached is the *configure file* before and after *make ?CB*.
> THanks & Regards,
> HJ

Somehow in your email above text after "make" doesn't show up
properly.
I guess you meant "make -B" (also equivalent to "make --always-make").

This particular command will trigger the re-generation of the
./configure file before continuing with the compilation.
The regeneration requires certail versions of the autotools
(autoconf/automake/libtool) being installed.
If the versions don't match the versions we used in 1.4 to generate
./configure and friends, then the result is unpredictable.

Said that, you shouldn't use "make -B" because it is not necessary
(and as you see it breaks things if the right set of autotools is
not installed).

Just running "make" followed optionally with "make check" is
sufficient.

Regards,
Pavlin

> 
> On 11/1/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
> >
> > HJ <hengjuen at gmail.com> wrote:
> >
> > > Hi Pavlin,
> > > Here is what i tried, and still seeing error message.
> > > I am running on Fedora 6.
> >
> > It seems that somehow your ./configure has been corrupted after
> > running "make all" which is very odd.
> >
> > Could you send me a copy of your ./configure before and after you
> > run "make all".
> > Also, what is the version of "make" you are using (i.e., the output
> > of "make -v").
> >
> > Thanks,
> > Pavlin
> >
> > >
> > >    1. make clean
> > >    2. tar ??zxvf xorp-1.4.tar.gz
> > >    3. ./configure
> > >    4. make (ok with no error)
> > >    5. make all (just to verify the issue, same error on line 1921)
> > >    6. make (to verify anything wrong with *make all *command, same error
> > >    on line 1921 happen)
> > >    7. make clean
> > >    8. ./configure (same error on line 1921)
> > >    9. make (same error on line 1921)
> > >    10. make all (same error on line 1921)
> > >    11. make clean
> > >    12. tar ??zxvf xorp-1.4.tar.gz
> > >    13. ./configure (ok)
> > >    14. make all (ok with no error)
> > >    15. make (ok)
> > >    16. *make ??B (according to man help page,  it is for unconditionally
> > >    make all targets)*
> > >
> > > -        *configure.in:53: error: possibly undefined macro:
> > AM_INIT_AUTOMAKE
> > > *
> > >
> > > -        *same for :54: AM_CONFIG_HEADER*
> > >
> > > -        *:55: AM_MAINTAINER_MODE*
> > >
> > > -        *:168: AC_DISABLE_SHARE*
> > >
> > > -        *:169: AC_DISABLE_FAST_INSTALL*
> > >
> > > -        *:170: AC_LIBTOOL_WIN32_DLL*
> > >
> > > -        *:171: AC_PROG_LIBTOOL*
> > >
> > > -        *:270: AM_CONDITIONAL*
> > >
> > > -        *Make: *** [configure] Error 1*
> > >
> > >    1. make all (error on line 1921 above)
> > >    2. make ??B (error on line 1921 above)
> > >    3. make (error on line 1921 above)
> > >
> > > Please help to advice.
> > > Thanks.
> > > REgards,
> > > HJ
> > >
> > >
> > > On 11/1/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > > >
> > > > > I am trying to recompile the XORP after 1st sucessfuly compilation
> > and
> > > > > verification using GCC.
> > > > > I did such steps as mention in user guide:
> > > > > 1) ./configure
> > > > > 2) make
> > > > > 3) make check
> > > > > After these steps, i try to recompile all the target with:
> > > > > - make all
> > > > > it shows error here:
> > > > >
> > > > > ./configure: line 1921: syntax error near unexpected token 'xorp,'
> > > > >
> > > > > ./configure: line 1921: 'AM_INIT_AUTOMAKE(xorp, 1.4)'
> > > > >
> > > > > Make: *** [config.status] Error 2
> > > > >
> > > > > Can anyone help to provide some input here?
> > > >
> > > > That's odd.
> > > > First, "make" itself is suppose to compile all targets (except the
> > > > test programs) so you don't really need "make all".
> > > > Also, if you compiled everything, then "make all" should be a no-op.
> > > > It looks like something got corrupted.
> > > > Can you start with a clean XORP tree (untar from scratch) and see
> > > > whether you get same problem.
> > > >
> > > > I assume that you are running Linux, otherwise on BSD boxes you
> > > > should use "gmake" instead of "make".
> > > >
> > > > Regards,
> > > > Pavlin
> > > >
> > > >
> > > _______________________________________________
> > > Xorp-users mailing list
> > > Xorp-users at xorp.org
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> >


From shardasaiwan at gmail.com  Thu Nov  1 22:31:18 2007
From: shardasaiwan at gmail.com (sharda saiwan)
Date: Fri, 2 Nov 2007 11:01:18 +0530
Subject: [Xorp-users] separation of fea from rest of the XORP
Message-ID: <c116921d0711012231p36f670e1w1ce221ccadca3c3a@mail.gmail.com>

Hello all,

Can we separate the FEA component from rest of the XORP code?

i.e. running FEA process on one machine and rest of the XORP on another machine
so that FEA can be started, stopped and modified independently
without affecting the main router process.

What changes we need to make in the code?

HELP!!!!!!!!

regards
--sharda


From pavlin at icir.org  Fri Nov  2 20:35:41 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 02 Nov 2007 20:35:41 -0700
Subject: [Xorp-users] separation of fea from rest of the XORP
In-Reply-To: Message from "sharda saiwan" <shardasaiwan@gmail.com> of "Fri,
	02 Nov 2007 11:01:18 +0530."
	<c116921d0711012231p36f670e1w1ce221ccadca3c3a@mail.gmail.com> 
Message-ID: <200711030335.lA33ZfNT078797@possum.icir.org>

> Can we separate the FEA component from rest of the XORP code?

The FEA is a separately running process.

> i.e. running FEA process on one machine and rest of the XORP on another machine
> so that FEA can be started, stopped and modified independently
> without affecting the main router process.

You could run the FEA on separate machine, but not out-of-the-box
(yet). See the following email for some info on the subject:

http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-October/002134.html

However, you can't restart the FEA while the rest of the XORP
processes are running, because it is a critical component for the
protocol modules. For example, it is on the communication (control)
path between a routing protocol and the rest of the world. If the
FEA is restarted, then each protocol practically needs to restart.
Getting around this is going to be very complicated at best, and
this is even without considering the case when the FEA is the TCP
termination point (for BGP for example).

I am wondering why do you want to restart the FEA?
Could you describe the application/setup you have in mind.

Regards,
Pavlin

> What changes we need to make in the code?
> 
> HELP!!!!!!!!
> 
> regards
> --sharda
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From arvind at macil.in  Thu Nov  1 20:19:28 2007
From: arvind at macil.in (arvind)
Date: Fri, 02 Nov 2007 08:49:28 +0530
Subject: [Xorp-users] "Make All" error
In-Reply-To: <200710311950.l9VJoc7P087861@possum.icir.org>
References: <200710311950.l9VJoc7P087861@possum.icir.org>
Message-ID: <1193973568.3264.0.camel@localhost.localdomain>

your ./configure may not be completed successfully

On Wed, 2007-10-31 at 12:50 -0700, Pavlin Radoslavov wrote:
> > I am trying to recompile the XORP after 1st sucessfuly compilation and
> > verification using GCC.
> > I did such steps as mention in user guide:
> > 1) ./configure
> > 2) make
> > 3) make check
> > After these steps, i try to recompile all the target with:
> > - make all
> > it shows error here:
> > 
> > ./configure: line 1921: syntax error near unexpected token 'xorp,'
> > 
> > ./configure: line 1921: 'AM_INIT_AUTOMAKE(xorp, 1.4)'
> > 
> > Make: *** [config.status] Error 2
> > 
> > Can anyone help to provide some input here?
> 
> That's odd.
> First, "make" itself is suppose to compile all targets (except the
> test programs) so you don't really need "make all".
> Also, if you compiled everything, then "make all" should be a no-op.
> It looks like something got corrupted.
> Can you start with a clean XORP tree (untar from scratch) and see
> whether you get same problem.
> 
> I assume that you are running Linux, otherwise on BSD boxes you
> should use "gmake" instead of "make".
> 
> Regards,
> Pavlin
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> 




From a.greenhalgh at cs.ucl.ac.uk  Sun Nov  4 03:18:36 2007
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Sun, 4 Nov 2007 11:18:36 +0000
Subject: [Xorp-users] "Make All" error
In-Reply-To: <1193973568.3264.0.camel@localhost.localdomain>
References: <200710311950.l9VJoc7P087861@possum.icir.org>
	<1193973568.3264.0.camel@localhost.localdomain>
Message-ID: <4769af410711040318j5ca3f16cncf769788f3727375@mail.gmail.com>

This suggests to me that there are problems with autoconf and automake.

Adam

On 02/11/2007, arvind <arvind at macil.in> wrote:
> your ./configure may not be completed successfully
>
> On Wed, 2007-10-31 at 12:50 -0700, Pavlin Radoslavov wrote:
> > > I am trying to recompile the XORP after 1st sucessfuly compilation and
> > > verification using GCC.
> > > I did such steps as mention in user guide:
> > > 1) ./configure
> > > 2) make
> > > 3) make check
> > > After these steps, i try to recompile all the target with:
> > > - make all
> > > it shows error here:
> > >
> > > ./configure: line 1921: syntax error near unexpected token 'xorp,'
> > >
> > > ./configure: line 1921: 'AM_INIT_AUTOMAKE(xorp, 1.4)'
> > >
> > > Make: *** [config.status] Error 2
> > >
> > > Can anyone help to provide some input here?
> >
> > That's odd.
> > First, "make" itself is suppose to compile all targets (except the
> > test programs) so you don't really need "make all".
> > Also, if you compiled everything, then "make all" should be a no-op.
> > It looks like something got corrupted.
> > Can you start with a clean XORP tree (untar from scratch) and see
> > whether you get same problem.
> >
> > I assume that you are running Linux, otherwise on BSD boxes you
> > should use "gmake" instead of "make".
> >
> > Regards,
> > Pavlin
> >
> > _______________________________________________
> > 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
>


From hantongs at gmail.com  Mon Nov  5 22:41:35 2007
From: hantongs at gmail.com (Hansi)
Date: Tue, 6 Nov 2007 14:41:35 +0800
Subject: [Xorp-users] IPv6 intermittent connectivity
Message-ID: <2f9e317b0711052241y9c4246bse9c60ad4f66c527a@mail.gmail.com>

Hello All,

I have configured two XORP machines connected to each other using IPv6
addresses. IPv6 static routes configuration were successfully entered using
the XORP CLI. Basically the network topology would look like this:

               -----------------                      ------------------
 -----------|    Router 1    |----------------|    Router 2
|--------------
Link1        -----------------      Link         ------------------    Link3

Link1: 2001:ec1:4001:10af::1

Link: 2001:ec0:4000:beef::1
        2001:ec0:4000:beef::2

Link3: 2001:ec2:4002:fa11::1

unicast forwarding for IPv4 and IPv6 were added to the configuration. After
adding the static routes, I was able to successfully ping Link3 from Link1.
However, I notice that the ping responses were intermittent. Several skips
occured in the icmp sequence count. I tried configuring static routes for
IPv4 addresses and didn't encounter such problem. Has anyone encountered
this issue? I'm working on an isolated environment. I would appreciate if
anyone would be willing to lend a hand in helping me resolve this
intermittent connectivity issue.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071106/ad034cd8/attachment.html 

From pavlin at icir.org  Mon Nov  5 22:58:39 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 05 Nov 2007 22:58:39 -0800
Subject: [Xorp-users] IPv6 intermittent connectivity
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Tue,
	06 Nov 2007 14:41:35 +0800."
	<2f9e317b0711052241y9c4246bse9c60ad4f66c527a@mail.gmail.com> 
Message-ID: <200711060658.lA66wdDo024846@possum.icir.org>

Hansi <hantongs at gmail.com> wrote:

> Hello All,
> 
> I have configured two XORP machines connected to each other using IPv6
> addresses. IPv6 static routes configuration were successfully entered using
> the XORP CLI. Basically the network topology would look like this:
> 
>                -----------------                      ------------------
>  -----------|    Router 1    |----------------|    Router 2
> |--------------
> Link1        -----------------      Link         ------------------    Link3
> 
> Link1: 2001:ec1:4001:10af::1
> 
> Link: 2001:ec0:4000:beef::1
>         2001:ec0:4000:beef::2
> 
> Link3: 2001:ec2:4002:fa11::1

The above topology drawing was mis-alligned so please redraw it in a
simpler way and without using any tabs.

> unicast forwarding for IPv4 and IPv6 were added to the configuration. After
> adding the static routes, I was able to successfully ping Link3 from Link1.
> However, I notice that the ping responses were intermittent. Several skips
> occured in the icmp sequence count. I tried configuring static routes for
> IPv4 addresses and didn't encounter such problem. Has anyone encountered
> this issue? I'm working on an isolated environment. I would appreciate if
> anyone would be willing to lend a hand in helping me resolve this
> intermittent connectivity issue.

What OS are you running on Router 1 and Router 2?

Are you running the ping command on Router 1 or on another host
connected to Link1?
If the latter, what happens if you run ping on Router 1?

Also, what happens if you don't run XORP, but you just install the
static routes by hand?

Please send a copy of the exact ping command (incl. all
arguments) and a snapshot of the replies.


Regards,
Pavlin


From hantongs at gmail.com  Tue Nov  6 00:53:29 2007
From: hantongs at gmail.com (Hansi)
Date: Tue, 6 Nov 2007 16:53:29 +0800
Subject: [Xorp-users] IPv6 intermittent connectivity
In-Reply-To: <200711060658.lA66wdDo024846@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711052241y9c4246bse9c60ad4f66c527a@mail.gmail.com>
	<200711060658.lA66wdDo024846@possum.icir.org>
Message-ID: <2f9e317b0711060053w3f2bd5a9v925e90ca8e033597@mail.gmail.com>

Hello Pavlin,

Thank you for your quick response. Allow me to redraw my network.

                             -----------------
------------------
pc--------------------|   Router 1    |------------------|    Router 2
|---------------------pc
                    sk0    ----------------- vr0          vr0
------------------ sk0

Router 1:
vr0: 2001:ec0:4000:beef::1
sk0: 2001:ec1:4001:10af:1

Router 2:
vr0: 2001:ec0:4000:beef::2
sk0: 2001:ec2:4002:fa11::1

My goal is to establish full IPv6 connectivity from pc to pc using static
routes. I'm not sure though but I think I was able to pinpoint the cause of
the problem. Allow me to show it to you.

To isolate the problem, I shutdown XORP and manually added static IPv6
static routes to both routers 1 & 2. IPv6 connectivity was up and running
and I was able to ping the pc's end to end. Here's how I did it.


(4:18:12<root at demo_rtr :/home/hansi>)#route add -inet6
2001:ec2:4002:fa11::/64 2001:ec0:4000:beef::2
 add net 2001:ec2:4002:fa11::/64: gateway 2001:ec0:4000:beef::2


(4:19:52<root at demo_rtr :/home/hansi>)#netstat -rna | more

Routing tables

IInternet6:
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           2001:ec0:4000:beef::2         UGS
vr0
fe80::/10                         ::1                           UGRS
lo0
fe80::%sk0/64                     link#1                        UC
sk0
fe80::219:5bff:fe2f:1468%sk0      00:19:5b:2f:14:68             UHLW
sk0
fe80::219:5bff:fe85:cfc7%sk0      00:19:5b:85:cf:c7             UHL
lo0
fe80::%vr0/64                     link#2                        UC
vr0
fe80::213:d4ff:fed8:6808%vr0      00:13:d4:d8:68:08             UHL
lo0
fe80::215:f2ff:fe3d:ac91%vr0      00:15:f2:3d:ac:91             UHLW
vr0
fe80::%lo0/64                     fe80::1%lo0                   U
lo0
fe80::1%lo0                       link#4                        UHL
lo0
ff01:1::/32                       link#1                        UC
sk0
ff01:2::/32                       link#2                        UC
vr0
ff01:4::/32                       ::1                           UC
lo0
ff02::/16                         ::1                           UGRS
lo0
ff02::%sk0/32                     link#1                        UC
sk0
ff02::%vr0/32                     link#2                        UC
vr0
ff02::%lo0/32                     ::1                           UC
lo0

While using XORP to add static routes would produce:


(4:19:52<root at demo_rtr :/home/hansi>)#netstat -nra | more
Routing tables

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             link#2                        UHLW
vr0
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:ec1:4001:10af::/64/64        2001:ec0:4000:beef::2         UG1
vr0
fe80::/10                         ::1                           UGRS
lo0
fe80::%sk0/64                     link#1                        UC
sk0
fe80::219:5bff:fe2f:1468%sk0      00:19:5b:2f:14:68             UHLW
sk0
fe80::219:5bff:fe85:cfc7%sk0      00:19:5b:85:cf:c7             UHL
lo0
fe80::%vr0/64                     link#2                        UC
vr0
fe80::213:d4ff:fed8:6808%vr0      00:13:d4:d8:68:08             UHL
lo0
fe80::215:f2ff:fe3d:ac91%vr0      00:15:f2:3d:ac:91             UHLW
vr0
fe80::%lo0/64                     fe80::1%lo0                   U
lo0
fe80::1%lo0                       link#4                        UHL
lo0
ff01:1::/32                       link#1                        UC
sk0
ff01:2::/32                       link#2                        UC
vr0
ff01:4::/32                       ::1                           UC
lo0
ff02::/16                         ::1                           UGRS
lo0
ff02::%sk0/32                     link#1                        UC
sk0
ff02::%vr0/32                     link#2                        UC
vr0
ff02::%lo0/32                     ::1                           UC
lo0


Looking closely on the routing table produced by netstat would show:

Manually added routes:

2001:ec2:4002:fa11::/64           2001:ec0:4000:beef::2         UGS
vr0

Routes added by xorp:

2001:ec1:4001:10af::/64/64        2001:ec0:4000:beef::2         UG1
vr0

This is also replicated on the second router:

Manually added routes:

2001:ec1:4001:10af::/64           2001:ec0:4000:beef::1         UGS
vr0

Routes added by xorp:

2001:ec0:4000:beef::/64/64        2001:ec0:4000:beef::1         UG1
vr0

Could this possibly be a bug? Im using FreeBSD6.2 OS and XORP1.4 stable.

Thank you.


On 11/6/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> Hansi <hantongs at gmail.com> wrote:
> > Hello All,
> >
> > I have configured two XORP machines connected to each other using IPv6
> > addresses. IPv6 static routes configuration were successfully entered
> using
> > the XORP CLI. Basically the network topology would look like this:
> >
> >                -----------------                      ------------------
> >  -----------|    Router 1    |----------------|    Router 2
> > |--------------
> > Link1        -----------------      Link
> ------------------    Link3
> >
> > Link1: 2001:ec1:4001:10af::1
> >
> > Link: 2001:ec0:4000:beef::1
> >         2001:ec0:4000:beef::2
> >
> > Link3: 2001:ec2:4002:fa11::1
>
> The above topology drawing was mis-alligned so please redraw it in a
> simpler way and without using any tabs.
>
> > unicast forwarding for IPv4 and IPv6 were added to the configuration.
> After
> > adding the static routes, I was able to successfully ping Link3 from
> Link1.
> > However, I notice that the ping responses were intermittent. Several
> skips
> > occured in the icmp sequence count. I tried configuring static routes
> for
> > IPv4 addresses and didn't encounter such problem. Has anyone encountered
> > this issue? I'm working on an isolated environment. I would appreciate
> if
> > anyone would be willing to lend a hand in helping me resolve this
> > intermittent connectivity issue.
>
> What OS are you running on Router 1 and Router 2?
>
> Are you running the ping command on Router 1 or on another host
> connected to Link1?
> If the latter, what happens if you run ping on Router 1?
>
> Also, what happens if you don't run XORP, but you just install the
> static routes by hand?
>
> Please send a copy of the exact ping command (incl. all
> arguments) and a snapshot of the replies.
>
>
> Regards,
> Pavlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071106/5c3bea3a/attachment-0001.html 

From hantongs at gmail.com  Tue Nov  6 00:59:31 2007
From: hantongs at gmail.com (Hansi)
Date: Tue, 6 Nov 2007 16:59:31 +0800
Subject: [Xorp-users] IPv6 intermittent connectivity
In-Reply-To: <2f9e317b0711060053w3f2bd5a9v925e90ca8e033597@mail.gmail.com>
References: <hantongs@gmail.com>
	<2f9e317b0711052241y9c4246bse9c60ad4f66c527a@mail.gmail.com>
	<200711060658.lA66wdDo024846@possum.icir.org>
	<2f9e317b0711060053w3f2bd5a9v925e90ca8e033597@mail.gmail.com>
Message-ID: <2f9e317b0711060059l491e117bu2e0c1d6fe54663df@mail.gmail.com>

            +----------+                     +----------+
            | Source/  +---------------------+          |
            | Sender   |                sk0  | Router 1 |
            +----------+                     +-----+----+
                                                   | vr0
                                                   |
                                                   |
                                                   |
                                                   |
                                                   |
                                                   | vr0
            +----------+                     +-----+----+
            | Client/  +---------------------+          |
            | Receiver |                sk0  | Router 2 |
            +----------+                     +----------+


I hope this illustration would be better. :)



On 11/6/07, Hansi <hantongs at gmail.com> wrote:
>
> Hello Pavlin,
>
> Thank you for your quick response. Allow me to redraw my network.
>
>                              -----------------
> ------------------
> pc--------------------|   Router 1    |------------------|    Router 2
> |---------------------pc
>                     sk0    ----------------- vr0          vr0
> ------------------ sk0
>
> Router 1:
> vr0: 2001:ec0:4000:beef::1
> sk0: 2001:ec1:4001:10af:1
>
> Router 2:
> vr0: 2001:ec0:4000:beef::2
> sk0: 2001:ec2:4002:fa11::1
>
> My goal is to establish full IPv6 connectivity from pc to pc using static
> routes. I'm not sure though but I think I was able to pinpoint the cause of
> the problem. Allow me to show it to you.
>
> To isolate the problem, I shutdown XORP and manually added static IPv6
> static routes to both routers 1 & 2. IPv6 connectivity was up and running
> and I was able to ping the pc's end to end. Here's how I did it.
>
>
> (4:18:12<root at demo_rtr :/home/hansi>)#route add -inet6
> 2001:ec2:4002:fa11::/64 2001:ec0:4000:beef::2
>  add net 2001:ec2:4002:fa11::/64: gateway 2001:ec0:4000:beef::2
>
>
> (4:19:52<root at demo_rtr :/home/hansi>)#netstat -rna | more
>
> Routing tables
>
> IInternet6:
> 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           2001:ec0:4000:beef::2
> UGS         vr0
> fe80::/10                         ::1
> UGRS        lo0
> fe80::%sk0/64                     link#1
> UC          sk0
> fe80::219:5bff:fe2f:1468%sk0      00:19:5b:2f:14:68
> UHLW        sk0
> fe80::219:5bff:fe85:cfc7%sk0      00:19:5b:85:cf:c7
> UHL         lo0
> fe80::%vr0/64                     link#2
> UC          vr0
> fe80::213:d4ff:fed8:6808%vr0      00:13:d4:d8:68:08
> UHL         lo0
> fe80::215:f2ff:fe3d:ac91%vr0      00:15:f2:3d:ac:91
> UHLW        vr0
> fe80::%lo0/64                     fe80::1%lo0
> U           lo0
> fe80::1%lo0                       link#4
> UHL         lo0
> ff01:1::/32                       link#1
> UC          sk0
> ff01:2::/32                       link#2
> UC          vr0
> ff01:4::/32                       ::1
> UC          lo0
> ff02::/16                         ::1
> UGRS        lo0
> ff02::%sk0/32                     link#1
> UC          sk0
> ff02::%vr0/32                     link#2
> UC          vr0
> ff02::%lo0/32                     ::1
> UC          lo0
>
> While using XORP to add static routes would produce:
>
>
> (4:19:52<root at demo_rtr :/home/hansi>)#netstat -nra | more
> Routing tables
>
> 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             link#2
> UHLW        vr0
> 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:ec1:4001:10af::/64/64        2001:ec0:4000:beef::2
> UG1         vr0
> fe80::/10                         ::1
> UGRS        lo0
> fe80::%sk0/64                     link#1
> UC          sk0
> fe80::219:5bff:fe2f:1468%sk0      00:19:5b:2f:14:68
> UHLW        sk0
> fe80::219:5bff:fe85:cfc7%sk0      00:19:5b:85:cf:c7
> UHL         lo0
> fe80::%vr0/64                     link#2
> UC          vr0
> fe80::213:d4ff:fed8:6808%vr0      00:13:d4:d8:68:08
> UHL         lo0
> fe80::215:f2ff:fe3d:ac91%vr0      00:15:f2:3d:ac:91
> UHLW        vr0
> fe80::%lo0/64                     fe80::1%lo0
> U           lo0
> fe80::1%lo0                       link#4
> UHL         lo0
> ff01:1::/32                       link#1
> UC          sk0
> ff01:2::/32                       link#2
> UC          vr0
> ff01:4::/32                       ::1
> UC          lo0
> ff02::/16                         ::1
> UGRS        lo0
> ff02::%sk0/32                     link#1
> UC          sk0
> ff02::%vr0/32                     link#2
> UC          vr0
> ff02::%lo0/32                     ::1
> UC          lo0
>
>
> Looking closely on the routing table produced by netstat would show:
>
> Manually added routes:
>
> 2001:ec2:4002:fa11::/64           2001:ec0:4000:beef::2
> UGS         vr0
>
> Routes added by xorp:
>
> 2001:ec1:4001:10af::/64/64        2001:ec0:4000:beef::2
> UG1         vr0
>
> This is also replicated on the second router:
>
> Manually added routes:
>
> 2001:ec1:4001:10af::/64           2001:ec0:4000:beef::1
> UGS         vr0
>
> Routes added by xorp:
>
> 2001:ec0:4000:beef::/64/64        2001:ec0:4000:beef::1
> UG1         vr0
>
> Could this possibly be a bug? Im using FreeBSD6.2 OS and XORP1.4 stable.
>
> Thank you.
>
>
> On 11/6/07, Pavlin Radoslavov < pavlin at icir.org> wrote:
> >
> > Hansi <hantongs at gmail.com > wrote:
> > > Hello All,
> > >
> > > I have configured two XORP machines connected to each other using IPv6
> > > addresses. IPv6 static routes configuration were successfully entered
> > using
> > > the XORP CLI. Basically the network topology would look like this:
> > >
> >
> > >                -----------------                      ------------------
> > >  -----------|    Router 1    |----------------|    Router 2
> > > |--------------
> > > Link1        -----------------      Link
> > ------------------    Link3
> > >
> > > Link1: 2001:ec1:4001:10af::1
> > >
> > > Link: 2001:ec0:4000:beef::1
> > >         2001:ec0:4000:beef::2
> > >
> > > Link3: 2001:ec2:4002:fa11::1
> >
> > The above topology drawing was mis-alligned so please redraw it in a
> > simpler way and without using any tabs.
> >
> > > unicast forwarding for IPv4 and IPv6 were added to the configuration.
> > After
> > > adding the static routes, I was able to successfully ping Link3 from
> > Link1.
> > > However, I notice that the ping responses were intermittent. Several
> > skips
> > > occured in the icmp sequence count. I tried configuring static routes
> > for
> > > IPv4 addresses and didn't encounter such problem. Has anyone
> > encountered
> > > this issue? I'm working on an isolated environment. I would appreciate
> > if
> > > anyone would be willing to lend a hand in helping me resolve this
> > > intermittent connectivity issue.
> >
> > What OS are you running on Router 1 and Router 2?
> >
> > Are you running the ping command on Router 1 or on another host
> > connected to Link1?
> > If the latter, what happens if you run ping on Router 1?
> >
> > Also, what happens if you don't run XORP, but you just install the
> > static routes by hand?
> >
> > Please send a copy of the exact ping command (incl. all
> > arguments) and a snapshot of the replies.
> >
> >
> > Regards,
> > Pavlin
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071106/5ca0af38/attachment-0001.html 

From birkov at gmail.com  Tue Nov  6 03:25:40 2007
From: birkov at gmail.com (Manuel J Romero)
Date: Tue, 6 Nov 2007 12:25:40 +0100
Subject: [Xorp-users] Routing problem, ERROR xorp_rib:4211 RIB +138
Message-ID: <2b04cbd80711060325h42011585laac0828edfaa0f59@mail.gmail.com>

Hello everybody!

I have a problem with static routes and qualified-next-hop which is
very important for my network implementation.

I've got a static route to 10.100.153.0/24 through 10.100.153.100 (Wan
interface) and a qualified-next-hop throug (10.100.240.3) and when I
unplug the wan interface to make a probe occurs.

>>>>XORP's Routes

Routes: 5/5, Paths: 5/5
10.100.120.0/24  [connected(0)] > to 10.100.120.2   via eth3
10.100.153.0/24  [static(2)]  > to 10.100.240.3   via eth1 <- It has
changed the route
...

>>>>Kernel's Routes

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.100.153.0    *               255.255.255.0   U     0      0
0 eth2            <- This one already exists and has a better metric
than the new one.
10.100.153.0    10.100.240.3    255.255.255.0   UG    2      0
0 eth1    <- IIt has introduced a new route
.....

>>>> /var/log/messages

Oct 31 09:26:20 localhost xorp_rib: [ 2007/10/31 09:26:20  ERROR
xorp_rib:4211 RIB +138
/home/autobuild/builds/master/2007-10-24-0001/ofr/xorp/xorp/rib/rt_tab_origin.cc
delete_route ] OT: attempt to delete a route that doesn't exist:
10.100.153.0/24

When I delete the 10.100.153.0/24 with metric 0, like "xorp_rib"
wanted to do (route del -net 10.100.153.0/24) everything work fine.

Please help me, thank you


Manuel J Romero


From pavlin at icir.org  Tue Nov  6 07:02:34 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 06 Nov 2007 07:02:34 -0800
Subject: [Xorp-users] IPv6 intermittent connectivity
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Tue,
	06 Nov 2007 16:59:31 +0800."
	<2f9e317b0711060059l491e117bu2e0c1d6fe54663df@mail.gmail.com> 
Message-ID: <200711061502.lA6F2YJI029153@possum.icir.org>

> > Looking closely on the routing table produced by netstat would show:
> >
> > Manually added routes:
> >
> > 2001:ec2:4002:fa11::/64           2001:ec0:4000:beef::2
> > UGS         vr0
> >
> > Routes added by xorp:
> >
> > 2001:ec1:4001:10af::/64/64        2001:ec0:4000:beef::2
> > UG1         vr0

Interesting. Initially my first impression was that the double
/64/64 is a typo, but the raw "netstat" output also contains it.
Could you send the your XORP configuration, as well as the output of
running ping with XORP and with manual static routes.
The routes themselves are different (4002 vs 4001) which is also
add.
FYI, the "S" vs "1" flag (i.e., "UGS" vs "UG1") is normal.

Also, could you run "route -n monitor" before starting XORP, and
send the output of the messages until after XORP is started.

Thanks,
Pavlin


From pavlin at icir.org  Tue Nov  6 07:10:04 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 06 Nov 2007 07:10:04 -0800
Subject: [Xorp-users] Routing problem, ERROR xorp_rib:4211 RIB +138
In-Reply-To: Message from "Manuel J Romero" <birkov@gmail.com> of "Tue,
	06 Nov 2007 12:25:40 +0100."
	<2b04cbd80711060325h42011585laac0828edfaa0f59@mail.gmail.com> 
Message-ID: <200711061510.lA6FA4KS029270@possum.icir.org>

Manuel J Romero <birkov at gmail.com> wrote:

> Hello everybody!
> 
> I have a problem with static routes and qualified-next-hop which is
> very important for my network implementation.

Please send your XORP configuration.

Thanks,
Pavlin

> I've got a static route to 10.100.153.0/24 through 10.100.153.100 (Wan
> interface) and a qualified-next-hop throug (10.100.240.3) and when I
> unplug the wan interface to make a probe occurs.
> 
> >>>>XORP's Routes
> 
> Routes: 5/5, Paths: 5/5
> 10.100.120.0/24  [connected(0)] > to 10.100.120.2   via eth3
> 10.100.153.0/24  [static(2)]  > to 10.100.240.3   via eth1 <- It has
> changed the route
> ...
> 
> >>>>Kernel's Routes
> 
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 10.100.153.0    *               255.255.255.0   U     0      0
> 0 eth2            <- This one already exists and has a better metric
> than the new one.
> 10.100.153.0    10.100.240.3    255.255.255.0   UG    2      0
> 0 eth1    <- IIt has introduced a new route
> .....
> 
> >>>> /var/log/messages
> 
> Oct 31 09:26:20 localhost xorp_rib: [ 2007/10/31 09:26:20  ERROR
> xorp_rib:4211 RIB +138
> /home/autobuild/builds/master/2007-10-24-0001/ofr/xorp/xorp/rib/rt_tab_origin.cc
> delete_route ] OT: attempt to delete a route that doesn't exist:
> 10.100.153.0/24
> 
> When I delete the 10.100.153.0/24 with metric 0, like "xorp_rib"
> wanted to do (route del -net 10.100.153.0/24) everything work fine.
> 
> Please help me, thank you
> 
> 
> Manuel J Romero
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From birkov at gmail.com  Tue Nov  6 09:04:09 2007
From: birkov at gmail.com (Manuel J Romero)
Date: Tue, 6 Nov 2007 18:04:09 +0100
Subject: [Xorp-users] Routing problem, ERROR xorp_rib:4211 RIB +138
Message-ID: <2b04cbd80711060904l32195074i715aba1830bcd0bc@mail.gmail.com>

Hello!

Thanks a  lot for your interesting.  I have configured my routers as
simple as possible to reproduce the problem. Here is my configuration:

---------------------------------------------------------------------------
show configuration

    protocols {
        static {
            route 10.100.153.0/24 {
                next-hop: 10.100.153.101
                qualified-next-hop 10.100.240.3 {
                    metric: 2
                }
            }
            route 0.0.0.0/0 {
                next-hop: 10.100.153.1
            }
        }
    }
    policy {
    }
    interfaces {
        loopback lo {
        }
        ethernet eth0 {
            hw-id: 00:13:46:3b:d0:30
            address 10.100.250.1 {
                prefix-length: 24
            }
        }
        ethernet eth1 {
            hw-id: 00:50:ba:de:b9:1a
            address 10.100.240.1 {
                prefix-length: 24
            }
        }
        ethernet eth2 {
            hw-id: 00:50:8d:e7:19:4b
            address 10.100.153.101 {
                prefix-length: 24
            }
        }
        ethernet eth3 {
            hw-id: 00:08:54:42:b0:b5
            address 10.100.120.1 {
                prefix-length: 24
            }
        }
    }
    service {
        nat {
            rule 1 {
                type: "masquerade"
                inbound-interface: "eth3"
                outbound-interface: "eth2"
                protocols: "all"
            }
            rule 2 {
                type: "masquerade"
                inbound-interface: "eth0"
                outbound-interface: "eth2"
                protocols: "all"
            }
        }
    }
    firewall {
    }


(I skip user configuration)
-------------------------------------------------------



Situation:


Now I've got two xorp routers, they are connected to a internet router
which is connected to internet. Something like this:


|Xorp Router 1|       |Xorp Router 2|
         |                            |
         | 10.100.153.101     | 10.100.153.103
         |                            |
         |                            |
         ----|Internet router|----     10.100.153.1
                        |
                        |
                   Internet


Each Xorp router are connected to 3 lans: 10.100.120.0/24,
10.100.240.0/24 and 10.100.250.0/24 (the idea is to use VRRP in the
future), so I want that one interface (for example 10.100.153.101 from
R1 fails) the traffics goes to the R2 through an internal lan and from
it go to internet using 10.100.153.103.

Something like:

-Normal situation Server  -> 10.100.153.101 -> 10.100.153.1 -> Internet

-R1 without connection -> 10.100.240.1 -> 10.100.240.3 ->
10.100.153.103 -> 10.100.153.1 -> Internet

To make it I use "qualified-next-hop". But the problem is this when I
unplug the 10.100.153.101 connection:



*****************************Normal
situation***************************************

>>>>Xorp Routes

0.0.0.0/0               [static(1)]     > to 10.100.153.1       via eth2
10.100.120.0/24         [connected(0)]  > to 10.100.120.2       via eth3
10.100.153.0/24         [connected(0)]  > to 10.100.153.101     via eth2
10.100.240.0/24         [connected(0)]  > to 10.100.240.2       via eth1
10.100.250.0/24         [connected(0)]  > to 10.100.250.2       via eth0
127.0.0.0/8             [connected(0)]  > to 127.0.0.1          via lo


>>>>Kernel's routes:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.100.153.0    *               255.255.255.0   U     0      0        0 eth2
10.100.250.0    *               255.255.255.0   U     0      0        0 eth0
10.100.120.0    *               255.255.255.0   U     0      0        0 eth3
10.100.240.0    *               255.255.255.0   U     0      0        0 eth1
default         10.100.153.1    0.0.0.0         UG    1      0        0 eth2


>>>>Ping to 10.100.153.1 from master:

PING 10.100.153.1 (10.100.153.1) 56(84) bytes of data.
64 bytes from 10.100.153.1: icmp_seq=1 ttl=64 time=0.73 ms
64 bytes from 10.100.153.1: icmp_seq=2 ttl=64 time=0.66 ms


**********************************************


********* R1 WAN unplugged ***************

>>>>Routes

Routes: 5/5, Paths: 5/5
10.100.120.0/24         [connected(0)]  > to 10.100.120.2       via eth3
10.100.153.0/24         [static(2)]     > to 10.100.240.3       via
eth1    <- New route!
10.100.240.0/24         [connected(0)]  > to 10.100.240.2       via eth1
10.100.250.0/24         [connected(0)]  > to 10.100.250.2       via eth0
127.0.0.0/8

(Note: static route to 0.0.0.0/0 has disappeared but this problem I
will solve later)


>>>>Kernel's Routes

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.100.153.0    *               255.255.255.0   U     0      0
0 eth2            <- This one already exists the best metric
10.100.153.0    10.100.240.3    255.255.255.0   UG    2      0
0 eth1    <- new route!
10.100.250.0    *               255.255.255.0   U     0      0        0 eth0
10.100.120.0    *               255.255.255.0   U     0      0        0 eth3
10.100.240.0    *               255.255.255.0   U     0      0        0 eth1



>>>>Ping to 10.100.153.1 from R1:

PING 10.100.153.1 (10.100.153.1) 56(84) bytes of data.
>From 10.100.153.101 icmp_seq=1 Destination Host Unreachable
>From 10.100.153.101 icmp_seq=2 Destination Host Unreachable




>>>> /var/log/messages of master:


Oct 31 09:26:20 localhost xorp_fea: [ 2007/10/31 09:26:20 WARNING
xorp_fea FEA ] Got update for interface not in libfeaclient tree: eth2
Oct 31 09:26:20 localhost xorp_rib: [ 2007/10/31 09:26:20  ERROR
xorp_rib:4211 RIB +138
/home/autobuild/builds/master/2007-10-24-0001/ofr/xorp/xorp/rib/rt_tab_origin.cc
delete_route ] OT: attempt to delete a route that doesn't exist:
10.100.153.0/24



>>>> When I delete the 10.100.153.0/24 with metric 0, like "xorp_rib"
wanted to do:

route del -net 10.100.153.0/24

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.100.153.0    10.100.240.3    255.255.255.0   UG    2      0        0 eth1
10.100.250.0    *               255.255.255.0   U     0      0        0 eth0
10.100.120.0    *               255.255.255.0   U     0      0        0 eth3
10.100.240.0    *               255.255.255.0   U     0      0        0 eth1


PING 10.100.153.1 (10.100.153.1) 56(84) bytes of data.
64 bytes from 10.100.153.1: icmp_seq=1 ttl=64 time=0.554 ms
64 bytes from 10.100.153.1: icmp_seq=2 ttl=64 time=0.178 ms


All works fine!!!!

***************************************************

(Another problem is that when I plug again the cable I've to create
again the route that I had deleted manually)



Thanks a lots and please help me!


From dwilliams at system7.co.uk  Tue Nov  6 11:59:30 2007
From: dwilliams at system7.co.uk (Dominic Williams)
Date: Tue, 6 Nov 2007 19:59:30 -0000
Subject: [Xorp-users] Mulling migrating to XORP from Cisco re: BGP setup
Message-ID: <A05D9964788ED147A85B3E9540F6D7F30E0B74@earth.system7.local>

Hello all!

The company I work for develops digital publishing software and also
hosts various high traffic sites for clients using the software. 

At the moment we have a simple Level 3 connect for connectivity, and
recently made the decision to move to BGP to reduce cost and increase
redundancy. However, we realised that to route over 6 providers (5 in a
single pipe from PacketeXchange, plus a pipe to Cogent) we really should
be looking at a CISCO 7204VXR with the 1GB RAM option to hold all the
routing tables safely... 

But *OMG* the plan fell apart when we realised the insanely inflated
prices we would have to pay to get one of these devices. 

We are now hoping / wondering whether XORP can save our BGP aspirations!

We have some important questions:

- Is XORP stable enough to run a simple BGP setup for commercial Web
hosting?

- Is XORP tested with very large routing tables?

- Is there anyway we can do Netflow collection if XORP is used as the
router (we currently use Netflow to monitor and record traffic flows to
the different sites we host)?

- Has anyone got any good tips extra advice for us at this stage?

Many thanks in advance for any advice on this, and good luck to the XORP
effort!

Best, Dominic
Dominic Williams


From atanu at ICSI.Berkeley.EDU  Tue Nov  6 16:03:03 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Tue, 06 Nov 2007 16:03:03 -0800
Subject: [Xorp-users] Mulling migrating to XORP from Cisco re: BGP setup
In-Reply-To: Message from "Dominic Williams" <dwilliams@system7.co.uk> 
	of "Tue, 06 Nov 2007 19:59:30 GMT."
	<A05D9964788ED147A85B3E9540F6D7F30E0B74@earth.system7.local> 
Message-ID: <56026.1194393783@tigger.icir.org>

Hi,

The XORP BGP is stable, we test	it with full BGP feeds, we don't have
any Netflow support.

    Atanu.

>>>>> "Dominic" == Dominic Williams <dwilliams at system7.co.uk> writes:

    Dominic> Hello all!  The company I work for develops digital
    Dominic> publishing software and also hosts various high traffic
    Dominic> sites for clients using the software.

    Dominic> At the moment we have a simple Level 3 connect for
    Dominic> connectivity, and recently made the decision to move to BGP
    Dominic> to reduce cost and increase redundancy. However, we
    Dominic> realised that to route over 6 providers (5 in a single pipe
    Dominic> from PacketeXchange, plus a pipe to Cogent) we really
    Dominic> should be looking at a CISCO 7204VXR with the 1GB RAM
    Dominic> option to hold all the routing tables safely...

    Dominic> But *OMG* the plan fell apart when we realised the insanely
    Dominic> inflated prices we would have to pay to get one of these
    Dominic> devices.

    Dominic> We are now hoping / wondering whether XORP can save our BGP
    Dominic> aspirations!

    Dominic> We have some important questions:

    Dominic> - Is XORP stable enough to run a simple BGP setup for
    Dominic> commercial Web hosting?

    Dominic> - Is XORP tested with very large routing tables?

    Dominic> - Is there anyway we can do Netflow collection if XORP is
    Dominic> used as the router (we currently use Netflow to monitor and
    Dominic> record traffic flows to the different sites we host)?

    Dominic> - Has anyone got any good tips extra advice for us at this
    Dominic> stage?

    Dominic> Many thanks in advance for any advice on this, and good
    Dominic> luck to the XORP effort!

    Dominic> Best, Dominic Dominic Williams

    Dominic> _______________________________________________ Xorp-users
    Dominic> mailing list Xorp-users at xorp.org
    Dominic> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin at icir.org  Tue Nov  6 16:20:07 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 06 Nov 2007 16:20:07 -0800
Subject: [Xorp-users] Routing problem, ERROR xorp_rib:4211 RIB +138
In-Reply-To: Message from "Manuel J Romero" <birkov@gmail.com> of "Tue,
	06 Nov 2007 18:04:09 +0100."
	<2b04cbd80711060904l32195074i715aba1830bcd0bc@mail.gmail.com> 
Message-ID: <200711070020.lA70K7RS033828@possum.icir.org>

> Thanks a  lot for your interesting.  I have configured my routers as
> simple as possible to reproduce the problem. Here is my configuration:

>From your config it appears that you aren't using vanilla XORP.
Please get the latest XORP code (HEAD from anon. CVS):

http://www.xorp.org/cvs.html

Recently there was a related bug fix inside the RIB, so you should
try the latest code to see whether this will apply to your case as
well.
If it doesn't fix your problem, then we can start debugging it from
there.

Regards,
Pavlin

> ---------------------------------------------------------------------------
> show configuration
> 
>     protocols {
>         static {
>             route 10.100.153.0/24 {
>                 next-hop: 10.100.153.101
>                 qualified-next-hop 10.100.240.3 {
>                     metric: 2
>                 }
>             }
>             route 0.0.0.0/0 {
>                 next-hop: 10.100.153.1
>             }
>         }
>     }
>     policy {
>     }
>     interfaces {
>         loopback lo {
>         }
>         ethernet eth0 {
>             hw-id: 00:13:46:3b:d0:30
>             address 10.100.250.1 {
>                 prefix-length: 24
>             }
>         }
>         ethernet eth1 {
>             hw-id: 00:50:ba:de:b9:1a
>             address 10.100.240.1 {
>                 prefix-length: 24
>             }
>         }
>         ethernet eth2 {
>             hw-id: 00:50:8d:e7:19:4b
>             address 10.100.153.101 {
>                 prefix-length: 24
>             }
>         }
>         ethernet eth3 {
>             hw-id: 00:08:54:42:b0:b5
>             address 10.100.120.1 {
>                 prefix-length: 24
>             }
>         }
>     }
>     service {
>         nat {
>             rule 1 {
>                 type: "masquerade"
>                 inbound-interface: "eth3"
>                 outbound-interface: "eth2"
>                 protocols: "all"
>             }
>             rule 2 {
>                 type: "masquerade"
>                 inbound-interface: "eth0"
>                 outbound-interface: "eth2"
>                 protocols: "all"
>             }
>         }
>     }
>     firewall {
>     }
> 
> 
> (I skip user configuration)
> -------------------------------------------------------
> 
> 
> 
> Situation:
> 
> 
> Now I've got two xorp routers, they are connected to a internet router
> which is connected to internet. Something like this:
> 
> 
> |Xorp Router 1|       |Xorp Router 2|
>          |                            |
>          | 10.100.153.101     | 10.100.153.103
>          |                            |
>          |                            |
>          ----|Internet router|----     10.100.153.1
>                         |
>                         |
>                    Internet
> 
> 
> Each Xorp router are connected to 3 lans: 10.100.120.0/24,
> 10.100.240.0/24 and 10.100.250.0/24 (the idea is to use VRRP in the
> future), so I want that one interface (for example 10.100.153.101 from
> R1 fails) the traffics goes to the R2 through an internal lan and from
> it go to internet using 10.100.153.103.
> 
> Something like:
> 
> -Normal situation Server  -> 10.100.153.101 -> 10.100.153.1 -> Internet
> 
> -R1 without connection -> 10.100.240.1 -> 10.100.240.3 ->
> 10.100.153.103 -> 10.100.153.1 -> Internet
> 
> To make it I use "qualified-next-hop". But the problem is this when I
> unplug the 10.100.153.101 connection:
> 
> 
> 
> *****************************Normal
> situation***************************************
> 
> >>>>Xorp Routes
> 
> 0.0.0.0/0               [static(1)]     > to 10.100.153.1       via eth2
> 10.100.120.0/24         [connected(0)]  > to 10.100.120.2       via eth3
> 10.100.153.0/24         [connected(0)]  > to 10.100.153.101     via eth2
> 10.100.240.0/24         [connected(0)]  > to 10.100.240.2       via eth1
> 10.100.250.0/24         [connected(0)]  > to 10.100.250.2       via eth0
> 127.0.0.0/8             [connected(0)]  > to 127.0.0.1          via lo
> 
> 
> >>>>Kernel's routes:
> 
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 10.100.153.0    *               255.255.255.0   U     0      0        0 eth2
> 10.100.250.0    *               255.255.255.0   U     0      0        0 eth0
> 10.100.120.0    *               255.255.255.0   U     0      0        0 eth3
> 10.100.240.0    *               255.255.255.0   U     0      0        0 eth1
> default         10.100.153.1    0.0.0.0         UG    1      0        0 eth2
> 
> 
> >>>>Ping to 10.100.153.1 from master:
> 
> PING 10.100.153.1 (10.100.153.1) 56(84) bytes of data.
> 64 bytes from 10.100.153.1: icmp_seq=1 ttl=64 time=0.73 ms
> 64 bytes from 10.100.153.1: icmp_seq=2 ttl=64 time=0.66 ms
> 
> 
> **********************************************
> 
> 
> ********* R1 WAN unplugged ***************
> 
> >>>>Routes
> 
> Routes: 5/5, Paths: 5/5
> 10.100.120.0/24         [connected(0)]  > to 10.100.120.2       via eth3
> 10.100.153.0/24         [static(2)]     > to 10.100.240.3       via
> eth1    <- New route!
> 10.100.240.0/24         [connected(0)]  > to 10.100.240.2       via eth1
> 10.100.250.0/24         [connected(0)]  > to 10.100.250.2       via eth0
> 127.0.0.0/8
> 
> (Note: static route to 0.0.0.0/0 has disappeared but this problem I
> will solve later)
> 
> 
> >>>>Kernel's Routes
> 
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 10.100.153.0    *               255.255.255.0   U     0      0
> 0 eth2            <- This one already exists the best metric
> 10.100.153.0    10.100.240.3    255.255.255.0   UG    2      0
> 0 eth1    <- new route!
> 10.100.250.0    *               255.255.255.0   U     0      0        0 eth0
> 10.100.120.0    *               255.255.255.0   U     0      0        0 eth3
> 10.100.240.0    *               255.255.255.0   U     0      0        0 eth1
> 
> 
> 
> >>>>Ping to 10.100.153.1 from R1:
> 
> PING 10.100.153.1 (10.100.153.1) 56(84) bytes of data.
> From 10.100.153.101 icmp_seq=1 Destination Host Unreachable
> From 10.100.153.101 icmp_seq=2 Destination Host Unreachable
> 
> 
> 
> 
> >>>> /var/log/messages of master:
> 
> 
> Oct 31 09:26:20 localhost xorp_fea: [ 2007/10/31 09:26:20 WARNING
> xorp_fea FEA ] Got update for interface not in libfeaclient tree: eth2
> Oct 31 09:26:20 localhost xorp_rib: [ 2007/10/31 09:26:20  ERROR
> xorp_rib:4211 RIB +138
> /home/autobuild/builds/master/2007-10-24-0001/ofr/xorp/xorp/rib/rt_tab_origin.cc
> delete_route ] OT: attempt to delete a route that doesn't exist:
> 10.100.153.0/24
> 
> 
> 
> >>>> When I delete the 10.100.153.0/24 with metric 0, like "xorp_rib"
> wanted to do:
> 
> route del -net 10.100.153.0/24
> 
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 10.100.153.0    10.100.240.3    255.255.255.0   UG    2      0        0 eth1
> 10.100.250.0    *               255.255.255.0   U     0      0        0 eth0
> 10.100.120.0    *               255.255.255.0   U     0      0        0 eth3
> 10.100.240.0    *               255.255.255.0   U     0      0        0 eth1
> 
> 
> PING 10.100.153.1 (10.100.153.1) 56(84) bytes of data.
> 64 bytes from 10.100.153.1: icmp_seq=1 ttl=64 time=0.554 ms
> 64 bytes from 10.100.153.1: icmp_seq=2 ttl=64 time=0.178 ms
> 
> 
> All works fine!!!!
> 
> ***************************************************
> 
> (Another problem is that when I plug again the cable I've to create
> again the route that I had deleted manually)
> 
> 
> 
> Thanks a lots and please help me!
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From hantongs at gmail.com  Tue Nov  6 22:13:43 2007
From: hantongs at gmail.com (Hansi)
Date: Wed, 7 Nov 2007 14:13:43 +0800
Subject: [Xorp-users] IPv6 intermittent connectivity
In-Reply-To: <200711061502.lA6F2YJI029153@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711060059l491e117bu2e0c1d6fe54663df@mail.gmail.com>
	<200711061502.lA6F2YJI029153@possum.icir.org>
Message-ID: <2f9e317b0711062213o14ee033elf84fd67716242e4f@mail.gmail.com>

 Hello Pavlin,

            +----------+                     +----------+
            | PC1      +---------------------+          |
            |          |                sk0  | Router 1 |
            +----------+2001:ec1:4001:10af::1+-----+----+

                                                   | vr0  2001:ec0:4000:beef::1
                                                   |
                                                   |
                                                   |
                                                   |
                                                   |
                                                   | vr0  2001:ec0:4000:beef::2
            +----------+                     +-----+----+
            | PC2      +---------------------+          |
            |          |                sk0  | Router 2 |
            +----------+2001:ec2:4002:fa11::1+----------+

PC1 IPv6 address: 2001:ec1:4001:10af:219:5bff:fe2f:1468
PC2 IPv6 address: 2001:ec2:4002:fa11:200:24ff:fec4:3235

Manual Configuration of Static Routes: (no XORP)
Router 1

$ netstat -nra | more
Routing tables


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           2001:ec0:4000:beef::2         UGS
vr0

Router 2

$ netstat -nra | more
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             UHLW
vr0
2001:ec0:4000:beef::2             00:15:f2:3d:ac:91             UHL
lo0
2001:ec1:4001:10af::/64           2001:ec0:4000:beef::1         UGS
vr0
2001:ec2:4002:fa11::/64           link#1                        UC
sk0
2001:ec2:4002:fa11::1             00:19:5b:2f:14:6a             UHL
lo0
2001:ec2:4002:fa11:200:24ff:fec4:3235 00:00:24:c4:32:35
UHLW
sk0

Here are the ping results from pc1 to pc2 and vice versa:

hansi at hansi-desktop:~$ ping6 2001:ec2:4002:fa11:200:24ff:fec4:3235
PING
2001:ec2:4002:fa11:200:24ff:fec4:3235(2001:ec2:4002:fa11:200:24ff:fec4:3235)
56 data bytes
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=1 ttl=62 time=
0.650 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=2 ttl=62 time=
0.631 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=3 ttl=62 time=
0.662 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=4 ttl=62 time=
0.696 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=5 ttl=62 time=
0.735 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=6 ttl=62 time=
0.651 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=7 ttl=62 time=
0.587 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=8 ttl=62 time=
0.719 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=9 ttl=62 time=
0.670 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=10 ttl=62
time=0.706 ms


hansi at hansi-desktop:~$ ping6 2001:ec1:4001:10af:219:5bff:fe2f:1468
PING6(56=40+8+8 bytes) 2001:ec2:4002:fa11:200:24ff:fec4:3235 -->
2001:ec1:4001:10af:219:5bff:fe2f:1468
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=0 hlim=62
time=1.117 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=1 hlim=62
time=1.041 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=2 hlim=62
time=0.987 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=3 hlim=62
time=0.927 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=4 hlim=62
time=0.990 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=5 hlim=62
time=0.928 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=6 hlim=62
time=1.036 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=7 hlim=62
time=1.025 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=8 hlim=62
time=1.045 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=9 hlim=62
time=0.946 ms
16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=10 hlim=62
time=0.973 ms


Configuration of Static Routes through XORP

Router 1

$ sudo route -n monitor
Password:

got message of size 328 on Tue Nov  6 23:24:55 2007
RTM_ADD: Add Route: len 328, pid: 0, seq 0, errno 0,
flags:<UP,HOST,DONE,LLINFO,WASCLONED>
locks:  inits:
sockaddrs: <DST,GATEWAY,IFP,IFA>
 2001:ec0:4000:beef::2  vr0:0.13.d4.d8.68.8 fe80::213:d4ff:fed8:6808%vr0

got message of size 304 on Tue Nov  6 23:24:55 2007
RTM_ADD: Add Route: len 304, pid: 4927, seq 131072, errno 0,
flags:<UP,GATEWAY,DONE,PROTO1>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP>
 2001:ec2:4002:fa11:: 2001:ec0:4000:beef::2 ffff:ffff:ffff:ffff::

$ netstat -nra | more

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             link#2                        UHLW
vr0
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:ec1:4001:10af::/64/64        2001:ec0:4000:beef::2         UG1
vr0
fe80::/10                         ::1                           UGRS
lo0
fe80::%sk0/64                     link#1                        UC

Router 2

$ sudo route -n monitor
Password:

got message of size 328 on Wed Nov  7 03:23:40 2007
RTM_ADD: Add Route: len 328, pid: 0, seq 0, errno 0,
flags:<UP,HOST,DONE,LLINFO,WASCLONED>
locks:  inits:
sockaddrs: <DST,GATEWAY,IFP,IFA>
 2001:ec0:4000:beef::1  vr0:0.15.f2.3d.ac.91 fe80::215:f2ff:fe3d:ac91%vr0

got message of size 304 on Wed Nov  7 03:23:40 2007
RTM_ADD: Add Route: len 304, pid: 4593, seq 131072, errno 0,
flags:<UP,GATEWAY,DONE,PROTO1>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP>
 2001:ec1:4001:10af:: 2001:ec0:4000:beef::1 ffff:ffff:ffff:ffff:: vr0

$ netstat -nra | more
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             link#2                        UHLW
vr0
2001:ec0:4000:beef::1             00:13:d4:d8:68:08             UHLW
vr0
2001:ec0:4000:beef::2             00:15:f2:3d:ac:91             UHL
lo0
2001:ec0:4000:beef::/64/64        2001:ec0:4000:beef::1         UG1
vr0
2001:ec2:4002:fa11::/64           link#1                        UC
sk0
2001:ec2:4002:fa11::1             00:19:5b:2f:14:6a             UHL
lo0
2001:ec2:4002:fa11:200:24ff:fec4:3235 00:00:24:c4:32:35             UHLW


Here are the ping results from pc1 to pc2 and vice versa:

hansi at hansi-desktop:~$ ping6 2001:ec2:4002:fa11:200:24ff:fec4:3235
PING
2001:ec2:4002:fa11:200:24ff:fec4:3235(2001:ec2:4002:fa11:200:24ff:fec4:3235)
56 data bytes

64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=16 ttl=62
time=0.834 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=17 ttl=62
time=0.614 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=18 ttl=62
time=0.753 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=19 ttl=62
time=0.695 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=20 ttl=62
time=0.736 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=21 ttl=62
time=0.567 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=22 ttl=62
time=0.716 ms
64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=23 ttl=62
time=0.655 ms

$ ping6 2001:ec1:4001:10af:219:5bff:fe2f:1468
PING6(56=40+8+8 bytes) 2001:ec2:4002:fa11:200:24ff:fec4:3235 -->
2001:ec1:4001:10af:219:5bff:fe2f:1468
^C
--- 2001:ec1:4001:10af:219:5bff:fe2f:1468 ping6 statistics ---
179 packets transmitted, 0 packets received, 100.0% packet loss

Taking a closer look on the ping results would show that there are missing
icmp packets from sequence 1 to 15 while pinging from pc2 to pc1 translates
to a 100% packet loss.

My purpose is to add route 2001:ec2:4002:fa11::/64 through next hop address
2001:ec0:4000:beef::2 on router 1 as well as add 2001:ec1:4001:10af::/64
through next hop address 2001:ec0:4000:beef::1 on router 2.

Attached is the xorp config file. I didnt bother pasting it here since
On 11/6/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > > Looking closely on the routing table produced by netstat would show:
> > >
> > > Manually added routes:
> > >
> > > 2001:ec2:4002:fa11::/64           2001:ec0:4000:beef::2
> > > UGS         vr0
> > >
> > > Routes added by xorp:
> > >
> > > 2001:ec1:4001:10af::/64/64        2001:ec0:4000:beef::2
> > > UG1         vr0
>
> Interesting. Initially my first impression was that the double
> /64/64 is a typo, but the raw "netstat" output also contains it.
> Could you send the your XORP configuration, as well as the output of
> running ping with XORP and with manual static routes.
> The routes themselves are different (4002 vs 4001) which is also

add.


Probably a wrong destination network added to the routing table?

FYI, the "S" vs "1" flag (i.e., "UGS" vs "UG1") is normal.
>
> Also, could you run "route -n monitor" before starting XORP, and
> send the output of the messages until after XORP is started.
>
> Thanks,
> Pavlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071107/d924d8e8/attachment-0001.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorpcfg.txt
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071107/d924d8e8/attachment-0001.txt 

From pavlin at icir.org  Wed Nov  7 11:48:08 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 07 Nov 2007 11:48:08 -0800
Subject: [Xorp-users] IPv6 intermittent connectivity
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Wed,
	07 Nov 2007 14:13:43 +0800."
	<2f9e317b0711062213o14ee033elf84fd67716242e4f@mail.gmail.com> 
Message-ID: <200711071948.lA7Jm8CC048840@possum.icir.org>

Hansi <hantongs at gmail.com> wrote:

Thank you for the detailed information. I think I found the problem.

There was an IPv6-related bug in the FEA which added bogus
forwarding entries to the kernel. I just committed fix to the XORP
CVS:

Revision  Changes                               Path
1.15      +4 -21;  commitid: 4e7a473213d87ea6;  xorp/fea/data_plane/fibconfig/fibconfig_entry_set_routing_socket.cc

Interestingly, the kernel didn't catch the bogus entries, and
the FreeBSD-6.2 netstat(1) command didn't handle the error when
decoding those entries. The side effect of this was the weird
looking 2001:ec1:4001:10af::/64/64 entry.

Please get the latest code from CVS and see whether it will fix the
routing problem as well.

Thanks,
Pavlin

>  Hello Pavlin,
> 
>             +----------+                     +----------+
>             | PC1      +---------------------+          |
>             |          |                sk0  | Router 1 |
>             +----------+2001:ec1:4001:10af::1+-----+----+
> 
>                                                    | vr0  2001:ec0:4000:beef::1
>                                                    |
>                                                    |
>                                                    |
>                                                    |
>                                                    |
>                                                    | vr0  2001:ec0:4000:beef::2
>             +----------+                     +-----+----+
>             | PC2      +---------------------+          |
>             |          |                sk0  | Router 2 |
>             +----------+2001:ec2:4002:fa11::1+----------+
> 
> PC1 IPv6 address: 2001:ec1:4001:10af:219:5bff:fe2f:1468
> PC2 IPv6 address: 2001:ec2:4002:fa11:200:24ff:fec4:3235
> 
> Manual Configuration of Static Routes: (no XORP)
> Router 1
> 
> $ netstat -nra | more
> Routing tables
> 
> 
> 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           2001:ec0:4000:beef::2         UGS
> vr0
> 
> Router 2
> 
> $ netstat -nra | more
> 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             UHLW
> vr0
> 2001:ec0:4000:beef::2             00:15:f2:3d:ac:91             UHL
> lo0
> 2001:ec1:4001:10af::/64           2001:ec0:4000:beef::1         UGS
> vr0
> 2001:ec2:4002:fa11::/64           link#1                        UC
> sk0
> 2001:ec2:4002:fa11::1             00:19:5b:2f:14:6a             UHL
> lo0
> 2001:ec2:4002:fa11:200:24ff:fec4:3235 00:00:24:c4:32:35
> UHLW
> sk0
> 
> Here are the ping results from pc1 to pc2 and vice versa:
> 
> hansi at hansi-desktop:~$ ping6 2001:ec2:4002:fa11:200:24ff:fec4:3235
> PING
> 2001:ec2:4002:fa11:200:24ff:fec4:3235(2001:ec2:4002:fa11:200:24ff:fec4:3235)
> 56 data bytes
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=1 ttl=62 time=
> 0.650 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=2 ttl=62 time=
> 0.631 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=3 ttl=62 time=
> 0.662 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=4 ttl=62 time=
> 0.696 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=5 ttl=62 time=
> 0.735 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=6 ttl=62 time=
> 0.651 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=7 ttl=62 time=
> 0.587 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=8 ttl=62 time=
> 0.719 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=9 ttl=62 time=
> 0.670 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=10 ttl=62
> time=0.706 ms
> 
> 
> hansi at hansi-desktop:~$ ping6 2001:ec1:4001:10af:219:5bff:fe2f:1468
> PING6(56=40+8+8 bytes) 2001:ec2:4002:fa11:200:24ff:fec4:3235 -->
> 2001:ec1:4001:10af:219:5bff:fe2f:1468
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=0 hlim=62
> time=1.117 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=1 hlim=62
> time=1.041 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=2 hlim=62
> time=0.987 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=3 hlim=62
> time=0.927 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=4 hlim=62
> time=0.990 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=5 hlim=62
> time=0.928 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=6 hlim=62
> time=1.036 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=7 hlim=62
> time=1.025 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=8 hlim=62
> time=1.045 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=9 hlim=62
> time=0.946 ms
> 16 bytes from 2001:ec1:4001:10af:219:5bff:fe2f:1468, icmp_seq=10 hlim=62
> time=0.973 ms
> 
> 
> Configuration of Static Routes through XORP
> 
> Router 1
> 
> $ sudo route -n monitor
> Password:
> 
> got message of size 328 on Tue Nov  6 23:24:55 2007
> RTM_ADD: Add Route: len 328, pid: 0, seq 0, errno 0,
> flags:<UP,HOST,DONE,LLINFO,WASCLONED>
> locks:  inits:
> sockaddrs: <DST,GATEWAY,IFP,IFA>
>  2001:ec0:4000:beef::2  vr0:0.13.d4.d8.68.8 fe80::213:d4ff:fed8:6808%vr0
> 
> got message of size 304 on Tue Nov  6 23:24:55 2007
> RTM_ADD: Add Route: len 304, pid: 4927, seq 131072, errno 0,
> flags:<UP,GATEWAY,DONE,PROTO1>
> locks:  inits:
> sockaddrs: <DST,GATEWAY,NETMASK,IFP>
>  2001:ec2:4002:fa11:: 2001:ec0:4000:beef::2 ffff:ffff:ffff:ffff::
> 
> $ netstat -nra | more
> 
> 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             link#2                        UHLW
> vr0
> 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:ec1:4001:10af::/64/64        2001:ec0:4000:beef::2         UG1
> vr0
> fe80::/10                         ::1                           UGRS
> lo0
> fe80::%sk0/64                     link#1                        UC
> 
> Router 2
> 
> $ sudo route -n monitor
> Password:
> 
> got message of size 328 on Wed Nov  7 03:23:40 2007
> RTM_ADD: Add Route: len 328, pid: 0, seq 0, errno 0,
> flags:<UP,HOST,DONE,LLINFO,WASCLONED>
> locks:  inits:
> sockaddrs: <DST,GATEWAY,IFP,IFA>
>  2001:ec0:4000:beef::1  vr0:0.15.f2.3d.ac.91 fe80::215:f2ff:fe3d:ac91%vr0
> 
> got message of size 304 on Wed Nov  7 03:23:40 2007
> RTM_ADD: Add Route: len 304, pid: 4593, seq 131072, errno 0,
> flags:<UP,GATEWAY,DONE,PROTO1>
> locks:  inits:
> sockaddrs: <DST,GATEWAY,NETMASK,IFP>
>  2001:ec1:4001:10af:: 2001:ec0:4000:beef::1 ffff:ffff:ffff:ffff:: vr0
> 
> $ netstat -nra | more
> 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             link#2                        UHLW
> vr0
> 2001:ec0:4000:beef::1             00:13:d4:d8:68:08             UHLW
> vr0
> 2001:ec0:4000:beef::2             00:15:f2:3d:ac:91             UHL
> lo0
> 2001:ec0:4000:beef::/64/64        2001:ec0:4000:beef::1         UG1
> vr0
> 2001:ec2:4002:fa11::/64           link#1                        UC
> sk0
> 2001:ec2:4002:fa11::1             00:19:5b:2f:14:6a             UHL
> lo0
> 2001:ec2:4002:fa11:200:24ff:fec4:3235 00:00:24:c4:32:35             UHLW
> 
> 
> Here are the ping results from pc1 to pc2 and vice versa:
> 
> hansi at hansi-desktop:~$ ping6 2001:ec2:4002:fa11:200:24ff:fec4:3235
> PING
> 2001:ec2:4002:fa11:200:24ff:fec4:3235(2001:ec2:4002:fa11:200:24ff:fec4:3235)
> 56 data bytes
> 
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=16 ttl=62
> time=0.834 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=17 ttl=62
> time=0.614 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=18 ttl=62
> time=0.753 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=19 ttl=62
> time=0.695 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=20 ttl=62
> time=0.736 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=21 ttl=62
> time=0.567 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=22 ttl=62
> time=0.716 ms
> 64 bytes from 2001:ec2:4002:fa11:200:24ff:fec4:3235: icmp_seq=23 ttl=62
> time=0.655 ms
> 
> $ ping6 2001:ec1:4001:10af:219:5bff:fe2f:1468
> PING6(56=40+8+8 bytes) 2001:ec2:4002:fa11:200:24ff:fec4:3235 -->
> 2001:ec1:4001:10af:219:5bff:fe2f:1468
> ^C
> --- 2001:ec1:4001:10af:219:5bff:fe2f:1468 ping6 statistics ---
> 179 packets transmitted, 0 packets received, 100.0% packet loss
> 
> Taking a closer look on the ping results would show that there are missing
> icmp packets from sequence 1 to 15 while pinging from pc2 to pc1 translates
> to a 100% packet loss.
> 
> My purpose is to add route 2001:ec2:4002:fa11::/64 through next hop address
> 2001:ec0:4000:beef::2 on router 1 as well as add 2001:ec1:4001:10af::/64
> through next hop address 2001:ec0:4000:beef::1 on router 2.
> 
> Attached is the xorp config file. I didnt bother pasting it here since
> On 11/6/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
> >
> > > > Looking closely on the routing table produced by netstat would show:
> > > >
> > > > Manually added routes:
> > > >
> > > > 2001:ec2:4002:fa11::/64           2001:ec0:4000:beef::2
> > > > UGS         vr0
> > > >
> > > > Routes added by xorp:
> > > >
> > > > 2001:ec1:4001:10af::/64/64        2001:ec0:4000:beef::2
> > > > UG1         vr0
> >
> > Interesting. Initially my first impression was that the double
> > /64/64 is a typo, but the raw "netstat" output also contains it.
> > Could you send the your XORP configuration, as well as the output of
> > running ping with XORP and with manual static routes.
> > The routes themselves are different (4002 vs 4001) which is also
> 
> add.
> 
> 
> Probably a wrong destination network added to the routing table?
> 
> FYI, the "S" vs "1" flag (i.e., "UGS" vs "UG1") is normal.
> >
> > Also, could you run "route -n monitor" before starting XORP, and
> > send the output of the messages until after XORP is started.
> >
> > Thanks,
> > Pavlin
> >
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin at icir.org  Wed Nov  7 12:31:49 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 07 Nov 2007 12:31:49 -0800
Subject: [Xorp-users] IPv6 intermittent connectivity
In-Reply-To: Message from Pavlin Radoslavov <pavlin@icir.org> of "Wed,
	07 Nov 2007 11:48:08 PST."
	<200711071948.lA7Jm8CC048840@possum.icir.org> 
Message-ID: <200711072031.lA7KVn19052369@possum.icir.org>

> There was an IPv6-related bug in the FEA which added bogus
> forwarding entries to the kernel. I just committed fix to the XORP
> CVS:
> 
> Revision  Changes                               Path
> 1.15      +4 -21;  commitid: 4e7a473213d87ea6;  xorp/fea/data_plane/fibconfig/fibconfig_entry_set_routing_socket.cc
> 
> Interestingly, the kernel didn't catch the bogus entries, and
> the FreeBSD-6.2 netstat(1) command didn't handle the error when
> decoding those entries. The side effect of this was the weird
> looking 2001:ec1:4001:10af::/64/64 entry.

Forgot to ask: were you using 64-bit machine?
I believe the above bug will show only on 64-bit system running
*BSD, so I just want to make sure it has been cornered properly.

Thanks,
Pavlin


From hantongs at gmail.com  Wed Nov  7 18:13:43 2007
From: hantongs at gmail.com (Hansi)
Date: Thu, 8 Nov 2007 10:13:43 +0800
Subject: [Xorp-users] IPv6 intermittent connectivity
In-Reply-To: <200711072031.lA7KVn19052369@possum.icir.org>
References: <pavlin@icir.org> <200711071948.lA7Jm8CC048840@possum.icir.org>
	<200711072031.lA7KVn19052369@possum.icir.org>
Message-ID: <2f9e317b0711071813r4eed6056qba94c5293b7b890c@mail.gmail.com>

Thank you Pavlin for accomodating this concern. :) Yes, I am using
64bit machines running XORP. Will download the recent source in CVS.

Regards,
Hansi

On Nov 8, 2007 4:31 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > There was an IPv6-related bug in the FEA which added bogus
> > forwarding entries to the kernel. I just committed fix to the XORP
> > CVS:
> >
> > Revision  Changes                               Path
> > 1.15      +4 -21;  commitid: 4e7a473213d87ea6;  xorp/fea/data_plane/fibconfig/fibconfig_entry_set_routing_socket.cc
> >
> > Interestingly, the kernel didn't catch the bogus entries, and
> > the FreeBSD-6.2 netstat(1) command didn't handle the error when
> > decoding those entries. The side effect of this was the weird
> > looking 2001:ec1:4001:10af::/64/64 entry.
>
> Forgot to ask: were you using 64-bit machine?
> I believe the above bug will show only on 64-bit system running
> *BSD, so I just want to make sure it has been cornered properly.
>
> Thanks,
> Pavlin
>


From brucew44 at gmail.com  Thu Nov  8 14:12:51 2007
From: brucew44 at gmail.com (Bruce Wilson)
Date: Thu, 8 Nov 2007 17:12:51 -0500
Subject: [Xorp-users] Modifying route preference
In-Reply-To: <862b10810711081204m28018c33yb28702139c973854@mail.gmail.com>
References: <862b10810711081204m28018c33yb28702139c973854@mail.gmail.com>
Message-ID: <862b10810711081412v366d0ed8j6d6377db2a8ed63b@mail.gmail.com>

Hi,

Is it possible to change the route preference values in XORP?

Route preferences are generally used to define the order of preference
between routing protocols
(http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-routing/html/protocols-overview4.html)

I am trying to change the route preference of
BGP(http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-routing/html/bgp-summary37.html#1015065)
but cannot find the corresponding command.

Thank you for your help!


From yueli.m at gmail.com  Thu Nov  8 20:22:57 2007
From: yueli.m at gmail.com (Yue Li)
Date: Thu, 8 Nov 2007 23:22:57 -0500
Subject: [Xorp-users] Can not set BGP peer-port other than 179
Message-ID: <49567c360711082022m70d7228dyb6c9a3a345e7e57c@mail.gmail.com>

Hi, I am new to XORP.
I want to set BGP peer-port other than 179, say 3001.
But when I start xorp_rtrmgr, some errors occur, as follows:

INFO xorp_rtrmgr:13811 RTRMGR +96 module_manager.cc execute ]
Executing module: bgp (bgp/xorp_bgp)
[ 2007/11/08 22:55:52  WARNING xorp_bgp:13821 XrlBgpTarget +591
bgp_base.cc handle_bgp_0_2_change_local_ip ] Handling method for
bgp/0.2/change_local_ip failed: XrlCmdError 102 Command failed
[ 2007/11/08 22:55:52  ERROR xorp_rtrmgr:13811 RTRMGR +675
master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command
failed
[ 2007/11/08 22:55:52  ERROR xorp_rtrmgr:13811 RTRMGR +251
master_conf_tree.cc config_done ] Configuration failed: 102 Command
failed
...

Can you give me some advices? Thanks a lot!


From atanu at ICSI.Berkeley.EDU  Fri Nov  9 00:59:42 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Fri, 09 Nov 2007 00:59:42 -0800
Subject: [Xorp-users] Can not set BGP peer-port other than 179
In-Reply-To: Message from "Yue Li" <yueli.m@gmail.com> of "Thu,
	08 Nov 2007 23:22:57 EST."
	<49567c360711082022m70d7228dyb6c9a3a345e7e57c@mail.gmail.com> 
Message-ID: <31589.1194598782@tigger.icir.org>

Hi,

We had tried to disable the setting of the peer-port as this feature has
been temporaily disabled. Having said that what may work is to set the
peer-port from the xorpsh after BGP has started.

    Atanu.

>>>>> "Yue" == Yue Li <yueli.m at gmail.com> writes:

    Yue> Hi, I am new to XORP.
    Yue> I want to set BGP peer-port other than 179, say 3001.
    Yue> But when I start xorp_rtrmgr, some errors occur, as follows:

    Yue> INFO xorp_rtrmgr:13811 RTRMGR +96 module_manager.cc execute ]
    Yue> Executing module: bgp (bgp/xorp_bgp)
    Yue> [ 2007/11/08 22:55:52  WARNING xorp_bgp:13821 XrlBgpTarget +591
    Yue> bgp_base.cc handle_bgp_0_2_change_local_ip ] Handling method for
    Yue> bgp/0.2/change_local_ip failed: XrlCmdError 102 Command failed
    Yue> [ 2007/11/08 22:55:52  ERROR xorp_rtrmgr:13811 RTRMGR +675
    Yue> master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command
    Yue> failed
    Yue> [ 2007/11/08 22:55:52  ERROR xorp_rtrmgr:13811 RTRMGR +251
    Yue> master_conf_tree.cc config_done ] Configuration failed: 102 Command
    Yue> failed
    Yue> ...

    Yue> Can you give me some advices? Thanks a lot!

    Yue> _______________________________________________
    Yue> Xorp-users mailing list
    Yue> Xorp-users at xorp.org
    Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin at icir.org  Fri Nov  9 01:44:58 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 09 Nov 2007 01:44:58 -0800
Subject: [Xorp-users] Modifying route preference
In-Reply-To: Message from "Bruce Wilson" <brucew44@gmail.com> of "Thu,
	08 Nov 2007 17:12:51 EST."
	<862b10810711081412v366d0ed8j6d6377db2a8ed63b@mail.gmail.com> 
Message-ID: <200711090944.lA99iwmR069988@possum.icir.org>

Bruce Wilson <brucew44 at gmail.com> wrote:

> Hi,
> 
> Is it possible to change the route preference values in XORP?

Not yet. We are aware that this functionality is missing and needs
to be addressed:

http://www.xorp.org/bugzilla/show_bug.cgi?id=536

For the time-being one ugly hack would be to modify the hard-coded
admin distance values inside rib/rib.cc. E.g., see the RIB<A>::RIB)
constructor for the list of hard-coded values and modify some 
of the desired values.

Regards,
Pavlin

> Route preferences are generally used to define the order of preference
> between routing protocols
> (http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-routing/html/protocols-overview4.html)
> 
> I am trying to change the route preference of
> BGP(http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-routing/html/bgp-summary37.html#1015065)
> but cannot find the corresponding command.
> 
> Thank you for your help!
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From brucew44 at gmail.com  Fri Nov  9 07:00:55 2007
From: brucew44 at gmail.com (Bruce Wilson)
Date: Fri, 9 Nov 2007 10:00:55 -0500
Subject: [Xorp-users] Modifying route preference
In-Reply-To: <200711090944.lA99iwmR069988@possum.icir.org>
References: <brucew44@gmail.com>
	<862b10810711081412v366d0ed8j6d6377db2a8ed63b@mail.gmail.com>
	<200711090944.lA99iwmR069988@possum.icir.org>
Message-ID: <862b10810711090700p5c1a9ad8if156d2110b2e1f23@mail.gmail.com>

Thank you for the clarification and for the hack!

Bruce

On Nov 9, 2007 4:44 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> Bruce Wilson <brucew44 at gmail.com> wrote:
>
> > Hi,
> >
> > Is it possible to change the route preference values in XORP?
>
> Not yet. We are aware that this functionality is missing and needs
> to be addressed:
>
> http://www.xorp.org/bugzilla/show_bug.cgi?id=536
>
> For the time-being one ugly hack would be to modify the hard-coded
> admin distance values inside rib/rib.cc. E.g., see the RIB<A>::RIB)
> constructor for the list of hard-coded values and modify some
> of the desired values.
>
> Regards,
> Pavlin
>
> > Route preferences are generally used to define the order of preference
> > between routing protocols
> > (http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-routing/html/protocols-overview4.html)
> >
> > I am trying to change the route preference of
> > BGP(http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-routing/html/bgp-summary37.html#1015065)
> > but cannot find the corresponding command.
> >
> > Thank you for your help!
> >
> > _______________________________________________
> > Xorp-users mailing list
> > Xorp-users at xorp.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>


From jeandro at larces.uece.br  Sat Nov 10 10:49:09 2007
From: jeandro at larces.uece.br (Jeandro de M. Bezerra)
Date: Sat, 10 Nov 2007 15:49:09 -0300
Subject: [Xorp-users] waiting for pimreg
Message-ID: <5efcb8aa0711101049y26c80fc0l5312a93427038c69@mail.gmail.com>

I started the rtrmg_xorp and is OK. But when crtl C for stop the xorp my
network configuration enter a loop.

The message is unregister_netdevice: waiting for pimreg to become free.

Once this happens it can't be stopped. I had to manually poweroff.

What is this all about?

thanks



-- 
Jeandro de Mesquita Bezerra, MSc
Professor Substituto - Universidade Estadual do Cear? (UECE)
Professor Auxiliar - UNICE-Ensino Superior
jeandro(arroba/at)larces.uece.br
LARCES-Laborat?rio de Redes de Comunica??o e Seguran?a da Informa??o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071110/1f8425aa/attachment.html 

From pavlin at icir.org  Sat Nov 10 11:05:32 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 10 Nov 2007 11:05:32 -0800
Subject: [Xorp-users] waiting for pimreg
In-Reply-To: Message from "Jeandro de M. Bezerra" <jeandro@larces.uece.br> 
	of "Sat, 10 Nov 2007 15:49:09 -0300."
	<5efcb8aa0711101049y26c80fc0l5312a93427038c69@mail.gmail.com> 
Message-ID: <200711101905.lAAJ5WGQ089626@possum.icir.org>

Jeandro de M. Bezerra <jeandro at larces.uece.br> wrote:

> I started the rtrmg_xorp and is OK. But when crtl C for stop the xorp my
> network configuration enter a loop.
> 
> The message is unregister_netdevice: waiting for pimreg to become free.

This doesn't look like a XORP message. Did it come from the kernel?
Please copy it exactly as it is.

> Once this happens it can't be stopped. I had to manually poweroff.

Can you open another terminal and "kill -9" the xorp_rtrmgr process?
If no and if the system was completely blocked, it sounds like a
problem in the kernel.
What OS and kernel version are you using?

Regards,
Pavlin

> What is this all about?
> 
> thanks
> 
> 
> 
> -- 
> Jeandro de Mesquita Bezerra, MSc
> Professor Substituto - Universidade Estadual do Cear? (UECE)
> Professor Auxiliar - UNICE-Ensino Superior
> jeandro(arroba/at)larces.uece.br
> LARCES-Laborat?rio de Redes de Comunica??o e Seguran?a da Informa??o.
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From greearb at candelatech.com  Sat Nov 10 11:07:45 2007
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 10 Nov 2007 11:07:45 -0800
Subject: [Xorp-users] waiting for pimreg
In-Reply-To: <5efcb8aa0711101049y26c80fc0l5312a93427038c69@mail.gmail.com>
References: <5efcb8aa0711101049y26c80fc0l5312a93427038c69@mail.gmail.com>
Message-ID: <47360181.6060506@candelatech.com>

Jeandro de M. Bezerra wrote:
> I started the rtrmg_xorp and is OK. But when crtl C for stop the xorp 
> my network configuration enter a loop.
>
> The message is unregister_netdevice: waiting for pimreg to become free.
> Once this happens it can't be stopped. I had to manually poweroff.
That looks like a kernel bug.  What linux kernel are you using?

Ben


-- 
Ben Greear <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com



From jeandro at larces.uece.br  Sat Nov 10 11:35:33 2007
From: jeandro at larces.uece.br (Jeandro de M. Bezerra)
Date: Sat, 10 Nov 2007 16:35:33 -0300
Subject: [Xorp-users] Fwd:  waiting for pimreg
In-Reply-To: <5efcb8aa0711101133oe64ad57q97103061e0e4f8cb@mail.gmail.com>
References: <jeandro@larces.uece.br>
	<5efcb8aa0711101049y26c80fc0l5312a93427038c69@mail.gmail.com>
	<200711101905.lAAJ5WGQ089626@possum.icir.org>
	<5efcb8aa0711101133oe64ad57q97103061e0e4f8cb@mail.gmail.com>
Message-ID: <5efcb8aa0711101135j6a268079o9433aa09b633e060@mail.gmail.com>

---------- Forwarded message ----------
From: Jeandro Bezerra <jeandro at gmail.com>
Date: 10/11/2007 16:33
Subject: Re: [Xorp-users] waiting for pimreg
To: Pavlin Radoslavov <pavlin at icir.org>

Slackware. Kernel  2.6.22. Is there  a apropriatte Kernel ?

thanks

2007/11/10, Pavlin Radoslavov <pavlin at icir.org>:
>
> Jeandro de M. Bezerra <jeandro at larces.uece.br> wrote:
>
> > I started the rtrmg_xorp and is OK. But when crtl C for stop the xorp my
> > network configuration enter a loop.
> >
> > The message is unregister_netdevice: waiting for pimreg to become free.
>
> This doesn't look like a XORP message. Did it come from the kernel?
> Please copy it exactly as it is.
>
> > Once this happens it can't be stopped. I had to manually poweroff.
>
> Can you open another terminal and "kill -9" the xorp_rtrmgr process?
> If no and if the system was completely blocked, it sounds like a
> problem in the kernel.
> What OS and kernel version are you using?
>
> Regards,
> Pavlin
>
> > What is this all about?
> >
> > thanks
> >
> >
> >
> > --
> > Jeandro de Mesquita Bezerra, MSc
> > Professor Substituto - Universidade Estadual do Cear? (UECE)
> > Professor Auxiliar - UNICE-Ensino Superior
> > jeandro(arroba/at)larces.uece.br
> > LARCES-Laborat?rio de Redes de Comunica??o e Seguran?a da Informa??o.
> > _______________________________________________
> > Xorp-users mailing list
> > Xorp-users at xorp.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>



-- 
Jeandro de Mesquita Bezerra, MSc
Professor Substituto - Universidade Estadual do Cear? (UECE)
Professor Auxiliar - UNICE-Ensino Superior
jeandro(arroba/at)larces.uece.br
LARCES-Laborat?rio de Redes de Comunica??o e Seguran?a da Informa??o.


-- 
Jeandro de Mesquita Bezerra, MSc
Professor Substituto - Universidade Estadual do Cear? (UECE)
Professor Auxiliar - UNICE-Ensino Superior
jeandro(arroba/at)larces.uece.br
LARCES-Laborat?rio de Redes de Comunica??o e Seguran?a da Informa??o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071110/3b0be8c3/attachment.html 

From pavlin at icir.org  Sat Nov 10 12:15:33 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 10 Nov 2007 12:15:33 -0800
Subject: [Xorp-users] waiting for pimreg
In-Reply-To: Message from "Jeandro de M. Bezerra" <jeandro@larces.uece.br> 
	of "Sat, 10 Nov 2007 16:35:33 -0300."
	<5efcb8aa0711101135j6a268079o9433aa09b633e060@mail.gmail.com> 
Message-ID: <200711102015.lAAKFXHm090311@possum.icir.org>

I haven't tried 2.6.22 so I don't know whether it should work.
Please try, say, 2.6.20.1 and see whether it will work for you.

Regards,
Pavlin

Jeandro de M. Bezerra <jeandro at larces.uece.br> wrote:

> ---------- Forwarded message ----------
> From: Jeandro Bezerra <jeandro at gmail.com>
> Date: 10/11/2007 16:33
> Subject: Re: [Xorp-users] waiting for pimreg
> To: Pavlin Radoslavov <pavlin at icir.org>
> 
> Slackware. Kernel  2.6.22. Is there  a apropriatte Kernel ?
> 
> thanks
> 
> 2007/11/10, Pavlin Radoslavov <pavlin at icir.org>:
> >
> > Jeandro de M. Bezerra <jeandro at larces.uece.br> wrote:
> >
> > > I started the rtrmg_xorp and is OK. But when crtl C for stop the xorp my
> > > network configuration enter a loop.
> > >
> > > The message is unregister_netdevice: waiting for pimreg to become free.
> >
> > This doesn't look like a XORP message. Did it come from the kernel?
> > Please copy it exactly as it is.
> >
> > > Once this happens it can't be stopped. I had to manually poweroff.
> >
> > Can you open another terminal and "kill -9" the xorp_rtrmgr process?
> > If no and if the system was completely blocked, it sounds like a
> > problem in the kernel.
> > What OS and kernel version are you using?
> >
> > Regards,
> > Pavlin
> >
> > > What is this all about?
> > >
> > > thanks
> > >
> > >
> > >
> > > --
> > > Jeandro de Mesquita Bezerra, MSc
> > > Professor Substituto - Universidade Estadual do Cear? (UECE)
> > > Professor Auxiliar - UNICE-Ensino Superior
> > > jeandro(arroba/at)larces.uece.br
> > > LARCES-Laborat?rio de Redes de Comunica??o e Seguran?a da Informa??o.
> > > _______________________________________________
> > > Xorp-users mailing list
> > > Xorp-users at xorp.org
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> >
> 
> 
> 
> -- 
> Jeandro de Mesquita Bezerra, MSc
> Professor Substituto - Universidade Estadual do Cear? (UECE)
> Professor Auxiliar - UNICE-Ensino Superior
> jeandro(arroba/at)larces.uece.br
> LARCES-Laborat?rio de Redes de Comunica??o e Seguran?a da Informa??o.
> 
> 
> -- 
> Jeandro de Mesquita Bezerra, MSc
> Professor Substituto - Universidade Estadual do Cear? (UECE)
> Professor Auxiliar - UNICE-Ensino Superior
> jeandro(arroba/at)larces.uece.br
> LARCES-Laborat?rio de Redes de Comunica??o e Seguran?a da Informa??o.
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From greearb at candelatech.com  Sat Nov 10 16:36:26 2007
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 10 Nov 2007 16:36:26 -0800
Subject: [Xorp-users] waiting for pimreg
In-Reply-To: <200711101905.lAAJ5WGQ089626@possum.icir.org>
References: <200711101905.lAAJ5WGQ089626@possum.icir.org>
Message-ID: <47364E8A.5010009@candelatech.com>

Pavlin Radoslavov wrote:
> Jeandro de M. Bezerra <jeandro at larces.uece.br> wrote:
>
>   
>> I started the rtrmg_xorp and is OK. But when crtl C for stop the xorp my
>> network configuration enter a loop.
>>
>> The message is unregister_netdevice: waiting for pimreg to become free.
>>     
>
> This doesn't look like a XORP message. Did it come from the kernel?
> Please copy it exactly as it is.

This happens because something in the kernel has a reference on a 
netdevice and is not properly
listening for netdev unregister events in the kernel or is not properly 
releasing the reference
when it gets the event.

Do you have a network device called pimreg or something like that?  What 
type of
device is it (some special virtual interface?)

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com



From pavlin at icir.org  Sat Nov 10 18:13:22 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 10 Nov 2007 18:13:22 -0800
Subject: [Xorp-users] waiting for pimreg
In-Reply-To: Message from Ben Greear <greearb@candelatech.com> 
	of "Sat, 10 Nov 2007 16:36:26 PST." <47364E8A.5010009@candelatech.com> 
Message-ID: <200711110213.lAB2DMGh092734@possum.icir.org>

> >> I started the rtrmg_xorp and is OK. But when crtl C for stop the xorp my
> >> network configuration enter a loop.
> >>
> >> The message is unregister_netdevice: waiting for pimreg to become free.
> >>     
> >
> > This doesn't look like a XORP message. Did it come from the kernel?
> > Please copy it exactly as it is.
> 
> This happens because something in the kernel has a reference on a 
> netdevice and is not properly
> listening for netdev unregister events in the kernel or is not properly 
> releasing the reference
> when it gets the event.
> 
> Do you have a network device called pimreg or something like that?  What 
> type of
> device is it (some special virtual interface?)

"pimreg" is the special (virtual) network interface created inside
the Linux kernel when PIM-SM is the multicast routing protocol.
When the userland multicast routing process is killed, the kernel
will detect it because the special multicast routing socket
(MRT_INIT) is closed, and then it should cleanup all related state
including pimreg.

Lets see whether the slightly older kernel will work for Jeandro.
This will tell us whether something got broken in the newer Linux
kernel.

Regards,
Pavlin


From hantongs at gmail.com  Mon Nov 12 01:11:36 2007
From: hantongs at gmail.com (Hansi)
Date: Mon, 12 Nov 2007 17:11:36 +0800
Subject: [Xorp-users] xorp RIPng
Message-ID: <2f9e317b0711120111k1aa7118fqa04d7a2d3202d222@mail.gmail.com>

Hello All,

I am currently trying to enable RIPNG on XORP and my network topology
is looks like this:
http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-November/002184.html
So far so good as I was able to configure RIPng on both XORP machines.
However, after "committing" the policy statement in order for networks
to be announced. I happen to encounter these logs messages.

[ 2007/11/12 02:49:57  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
run_task ] No more tasks to run
[ 2007/11/12 02:51:48  INFO xorp_rtrmgr:981 RTRMGR +96
module_manager.cc execute ] Executing module: rib (rib/xorp_rib)
[ 2007/11/12 02:51:50  INFO xorp_rtrmgr:981 RTRMGR +96
module_manager.cc execute ] Executing module: policy
(policy/xorp_policy)
[ 2007/11/12 02:51:52  INFO xorp_rtrmgr:981 RTRMGR +96
module_manager.cc execute ] Executing module: ripng (rip/xorp_ripng)
[ 2007/11/12 02:51:54 WARNING xorp_fea XrlFeaTarget ] Handling method
for socket6/0.1/set_socket_option failed: XrlCmdError 102 Command
failed Unknown socket option: multicast_hops
[ 2007/11/12 02:51:54 WARNING xorp_ripng XifSocket6 ] Failed to set
ttl/hops to 1
[ 2007/11/12 02:51:54  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
run_task ] No more tasks to run
[ 2007/11/12 03:08:22  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
run_task ] No more tasks to run
[ 2007/11/12 03:08:50  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
run_task ] No more tasks to run
[ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
failed Xrl does not resolve:
finder://ripng/policy_redist4/0.1/add_route4
[ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
add_route4 for ripng route: Dst: 172.16.0.0/16 Vif: sk0 NextHop:
NH:172.16.0.1 Metric: 0 Protocol: connected PolicyTags: 0
[ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
failed Xrl does not resolve:
finder://ripng/policy_redist4/0.1/add_route4
[ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
add_route4 for ripng route: Dst: 200.10.0.0/24 Vif: vr0 NextHop:
NH:200.10.0.1 Metric: 0 Protocol: connected PolicyTags: 0
[ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
failed Xrl does not resolve:
finder://ripng/policy_redist4/0.1/add_route4
[ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
add_route4 for ripng route: Dst: 172.16.0.0/16 Vif: sk0 NextHop:
NH:172.16.0.1 Metric: 0 Protocol: connected PolicyTags: 0
[ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
failed Xrl does not resolve:
finder://ripng/policy_redist4/0.1/add_route4
[ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
add_route4 for ripng route: Dst: 200.10.0.0/24 Vif: vr0 NextHop:
NH:200.10.0.1 Metric: 0 Protocol: connected PolicyTags: 0

Furthermore, I'm unable to ping pc1 to pc2 and vice versa. No routes
were also added to the kernel routing table using netstat despite the
configuration being committed already.
Is there something I have overlooked in my configuration? appreciate
the assistance.

Thanks.

Attached is the configuration file.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorpcfg.txt
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071112/fc9bd717/attachment.txt 

From pavlin at icir.org  Mon Nov 12 14:03:25 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 12 Nov 2007 14:03:25 -0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Mon,
	12 Nov 2007 17:11:36 +0800."
	<2f9e317b0711120111k1aa7118fqa04d7a2d3202d222@mail.gmail.com> 
Message-ID: <200711122203.lACM3PVd053860@possum.icir.org>

Hansi <hantongs at gmail.com> wrote:

> Hello All,
> 
> I am currently trying to enable RIPNG on XORP and my network topology
> is looks like this:
> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-November/002184.html
> So far so good as I was able to configure RIPng on both XORP machines.
> However, after "committing" the policy statement in order for networks
> to be announced. I happen to encounter these logs messages.
> 
> [ 2007/11/12 02:49:57  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
> run_task ] No more tasks to run
> [ 2007/11/12 02:51:48  INFO xorp_rtrmgr:981 RTRMGR +96
> module_manager.cc execute ] Executing module: rib (rib/xorp_rib)
> [ 2007/11/12 02:51:50  INFO xorp_rtrmgr:981 RTRMGR +96
> module_manager.cc execute ] Executing module: policy
> (policy/xorp_policy)
> [ 2007/11/12 02:51:52  INFO xorp_rtrmgr:981 RTRMGR +96
> module_manager.cc execute ] Executing module: ripng (rip/xorp_ripng)
> [ 2007/11/12 02:51:54 WARNING xorp_fea XrlFeaTarget ] Handling method
> for socket6/0.1/set_socket_option failed: XrlCmdError 102 Command
> failed Unknown socket option: multicast_hops

This was because of a bug which is now fixed in CVS.
Please get the latest code from anon CVS and try again.
Also, I applied few more fixes so now you can run the "show ripng"
xorpsh operational commands.

> [ 2007/11/12 02:51:54 WARNING xorp_ripng XifSocket6 ] Failed to set
> ttl/hops to 1
> [ 2007/11/12 02:51:54  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
> run_task ] No more tasks to run
> [ 2007/11/12 03:08:22  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
> run_task ] No more tasks to run
> [ 2007/11/12 03:08:50  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
> run_task ] No more tasks to run
> [ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> failed Xrl does not resolve:
> finder://ripng/policy_redist4/0.1/add_route4

Those warnings gets triggered because the RIB tries to export the IPv4
connected routes to RIPng (which is IPv6-only protocol).
In this particular case they should be harmless and can be ignored.
Please try the following export statement to get rid of them:

        term export {
            from {
                protocol: "connected"
                network6 <= ::/0
            }
        }

> [ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
> add_route4 for ripng route: Dst: 172.16.0.0/16 Vif: sk0 NextHop:
> NH:172.16.0.1 Metric: 0 Protocol: connected PolicyTags: 0
> [ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> failed Xrl does not resolve:
> finder://ripng/policy_redist4/0.1/add_route4
> [ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
> add_route4 for ripng route: Dst: 200.10.0.0/24 Vif: vr0 NextHop:
> NH:200.10.0.1 Metric: 0 Protocol: connected PolicyTags: 0
> [ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> failed Xrl does not resolve:
> finder://ripng/policy_redist4/0.1/add_route4
> [ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
> add_route4 for ripng route: Dst: 172.16.0.0/16 Vif: sk0 NextHop:
> NH:172.16.0.1 Metric: 0 Protocol: connected PolicyTags: 0
> [ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> failed Xrl does not resolve:
> finder://ripng/policy_redist4/0.1/add_route4
> [ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
> add_route4 for ripng route: Dst: 200.10.0.0/24 Vif: vr0 NextHop:
> NH:200.10.0.1 Metric: 0 Protocol: connected PolicyTags: 0
> 
> Furthermore, I'm unable to ping pc1 to pc2 and vice versa. No routes
> were also added to the kernel routing table using netstat despite the
> configuration being committed already.
> Is there something I have overlooked in my configuration? appreciate
> the assistance.

Have in mind that in case of RIP/RIPng if you configure some policy
you might need to wait some amount of time (e.g., 30 seconds) until
the routes are (re)transmit.

You need to start debuging the problem by using the "show route" and
"show ripng" commands, and by running tcpdump. The tcpdump output
will tell you what is exchanged on the wire. If you see the IPv6
routes being exchanged properly, then the "show ripng" and "show
route" commands will tell you how far they got inside XORP.

BTW, you can get rid of the "fib2mrib" and "plumbing/mfea6"
configuration statements, because they are needed only for multicast
routing.

Regards,
Pavlin


From hantongs at gmail.com  Tue Nov 13 01:25:21 2007
From: hantongs at gmail.com (Hansi)
Date: Tue, 13 Nov 2007 17:25:21 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <200711122203.lACM3PVd053860@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711120111k1aa7118fqa04d7a2d3202d222@mail.gmail.com>
	<200711122203.lACM3PVd053860@possum.icir.org>
Message-ID: <2f9e317b0711130125j49845bfqcfbc97f22171c252@mail.gmail.com>

Hello Pavlin,

See iniine responses.

On Nov 13, 2007 6:03 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> Hansi <hantongs at gmail.com> wrote:
>
> > Hello All,
> >
> > I am currently trying to enable RIPNG on XORP and my network topology
> > is looks like this:
> > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-November/002184.html
> > So far so good as I was able to configure RIPng on both XORP machines.
> > However, after "committing" the policy statement in order for networks
> > to be announced. I happen to encounter these logs messages.
> >
> > [ 2007/11/12 02:49:57  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
> > run_task ] No more tasks to run
> > [ 2007/11/12 02:51:48  INFO xorp_rtrmgr:981 RTRMGR +96
> > module_manager.cc execute ] Executing module: rib (rib/xorp_rib)
> > [ 2007/11/12 02:51:50  INFO xorp_rtrmgr:981 RTRMGR +96
> > module_manager.cc execute ] Executing module: policy
> > (policy/xorp_policy)
> > [ 2007/11/12 02:51:52  INFO xorp_rtrmgr:981 RTRMGR +96
> > module_manager.cc execute ] Executing module: ripng (rip/xorp_ripng)
> > [ 2007/11/12 02:51:54 WARNING xorp_fea XrlFeaTarget ] Handling method
> > for socket6/0.1/set_socket_option failed: XrlCmdError 102 Command
> > failed Unknown socket option: multicast_hops
>
> This was because of a bug which is now fixed in CVS.
> Please get the latest code from anon CVS and try again.
> Also, I applied few more fixes so now you can run the "show ripng"
> xorpsh operational commands.

Yes, as of the current version downloaded from CVS. The output error
shown above is no longer present.

>
> > [ 2007/11/12 02:51:54 WARNING xorp_ripng XifSocket6 ] Failed to set
> > ttl/hops to 1
> > [ 2007/11/12 02:51:54  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
> > run_task ] No more tasks to run
> > [ 2007/11/12 03:08:22  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
> > run_task ] No more tasks to run
> > [ 2007/11/12 03:08:50  INFO xorp_rtrmgr:981 RTRMGR +2228 task.cc
> > run_task ] No more tasks to run
> > [ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
> > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> > failed Xrl does not resolve:
> > finder://ripng/policy_redist4/0.1/add_route4
>
> Those warnings gets triggered because the RIB tries to export the IPv4
> connected routes to RIPng (which is IPv6-only protocol).
> In this particular case they should be harmless and can be ignored.
> Please try the following export statement to get rid of them:
>
>         term export {
>             from {
>                 protocol: "connected"
>                 network6 <= ::/0
>
>             }
>         }
>
> > [ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
> > add_route4 for ripng route: Dst: 172.16.0.0/16 Vif: sk0 NextHop:
> > NH:172.16.0.1 Metric: 0 Protocol: connected PolicyTags: 0
> > [ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
> > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> > failed Xrl does not resolve:
> > finder://ripng/policy_redist4/0.1/add_route4
> > [ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
> > add_route4 for ripng route: Dst: 200.10.0.0/24 Vif: vr0 NextHop:
> > NH:200.10.0.1 Metric: 0 Protocol: connected PolicyTags: 0
> > [ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
> > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> > failed Xrl does not resolve:
> > finder://ripng/policy_redist4/0.1/add_route4
> > [ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
> > add_route4 for ripng route: Dst: 172.16.0.0/16 Vif: sk0 NextHop:
> > NH:172.16.0.1 Metric: 0 Protocol: connected PolicyTags: 0
> > [ 2007/11/12 03:08:54  WARNING xorp_rtrmgr:981 XrlFinderTarget +406
> > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> > failed Xrl does not resolve:
> > finder://ripng/policy_redist4/0.1/add_route4
> > [ 2007/11/12 03:08:54 WARNING xorp_rib RIB ] Unable to complete XRL:
> > add_route4 for ripng route: Dst: 200.10.0.0/24 Vif: vr0 NextHop:
> > NH:200.10.0.1 Metric: 0 Protocol: connected PolicyTags: 0
> >
> > Furthermore, I'm unable to ping pc1 to pc2 and vice versa. No routes
> > were also added to the kernel routing table using netstat despite the
> > configuration being committed already.
> > Is there something I have overlooked in my configuration? appreciate
> > the assistance.
>
> Have in mind that in case of RIP/RIPng if you configure some policy
> you might need to wait some amount of time (e.g., 30 seconds) until
> the routes are (re)transmit.

Yes. RIP takes 30 seconds to transmit a packet to a multicast ipv6
address. The problem though here is that XORP seems to transmit
forever without any peering established. :( All I am seeing are RIP
request packets being transmitted by both XORP machines. Correct me if
I'm wrong but isn't it supposed to be that if a RIP peering is
established, the dump from the network would show an exchange of RIP
request and response messages? I'm not seeing any response messages in
this case even when RIPng is already enabled in both XORP machines..

Shown below is the tcpdump output:

05:05:26.395302 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:05:29.755473 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:05:56.394739 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:05:59.754388 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:06:26.394571 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:06:29.754415 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:06:56.394412 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:06:59.752328 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:07:26.394248 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:07:29.752277 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:07:56.394024 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:07:59.751233 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:08:26.394908 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:08:29.750188 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:08:56.394702 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:08:59.749315 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
05:09:26.394538 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
dump


The XORP box seems to listen on port 521 though:

$ sockstat -6l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     xorp_fea   43829 20 udp6   *:*                   *:*
root     xorp_fea   43829 39 udp6   *:521                 *:*
root     sshd       790   3  tcp6   *:22                  *:*
root     syslogd    640   6  udp6   *:514                 *:*

Issuing "show ripng peer statistics all" would yield:

admin at demo_rtr.infoweapons.com> show ripng peer statistics all
There are no known peers.

Could I have overlooked something in this configuration? I'm certain
that this is also the procedures I took on how I was able to enable
RIPv2 and everything worked fine. Hope you could shed some light on
this matter.

Regards,
Hansi
>
> You need to start debuging the problem by using the "show route" and
> "show ripng" commands, and by running tcpdump. The tcpdump output
> will tell you what is exchanged on the wire. If you see the IPv6
> routes being exchanged properly, then the "show ripng" and "show
> route" commands will tell you how far they got inside XORP.
>
> BTW, you can get rid of the "fib2mrib" and "plumbing/mfea6"
> configuration statements, because they are needed only for multicast
> routing.
>
> Regards,
> Pavlin
>


From pavlin at icir.org  Tue Nov 13 07:44:52 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 13 Nov 2007 07:44:52 -0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Tue,
	13 Nov 2007 17:25:21 +0800."
	<2f9e317b0711130125j49845bfqcfbc97f22171c252@mail.gmail.com> 
Message-ID: <200711131544.lADFiqGC074230@possum.icir.org>

> Yes. RIP takes 30 seconds to transmit a packet to a multicast ipv6
> address. The problem though here is that XORP seems to transmit
> forever without any peering established. :( All I am seeing are RIP
> request packets being transmitted by both XORP machines. Correct me if
> I'm wrong but isn't it supposed to be that if a RIP peering is
> established, the dump from the network would show an exchange of RIP
> request and response messages? I'm not seeing any response messages in
> this case even when RIPng is already enabled in both XORP machines..
> 
> Shown below is the tcpdump output:
> 
> 05:05:26.395302 IP6 (hlim 1, next-header: UDP (17), length: 32)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
> dump
> 05:05:29.755473 IP6 (hlim 1, next-header: UDP (17), length: 32)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
> dump
> 05:05:56.394739 IP6 (hlim 1, next-header: UDP (17), length: 32)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-req
> dump
> 05:05:59.754388 IP6 (hlim 1, next-header: UDP (17), length: 32)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
> dump

<DEL>

> 
> The XORP box seems to listen on port 521 though:
> 
> $ sockstat -6l
> USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
> root     xorp_fea   43829 20 udp6   *:*                   *:*
> root     xorp_fea   43829 39 udp6   *:521                 *:*
> root     sshd       790   3  tcp6   *:22                  *:*
> root     syslogd    640   6  udp6   *:514                 *:*
> 
> Issuing "show ripng peer statistics all" would yield:
> 
> admin at demo_rtr.infoweapons.com> show ripng peer statistics all
> There are no known peers.
> 
> Could I have overlooked something in this configuration? I'm certain
> that this is also the procedures I took on how I was able to enable
> RIPv2 and everything worked fine. Hope you could shed some light on
> this matter.

The only thing that comes to mind is to try to use the interface's
IPv6 link-local address instead of the global address (inside the
RIPng config).

If this has no impact, then enable the XRLTRACE environmental
variable before starting XORP and save the terminal output to a
file. E.g., in csh/tcsh:

setenv XRLTRACE yes
script
./xorp_rtrmgr -b config.boot
...
Ctrl-C
exit

This will save the output in file named "typescript".
Check inside that file for "socket6_user" XRLs from the FEA to
RIPng. This will tell you whether the FEA actually received the
RIPng packets and sent them to the RIPng.
Also, if you saw any warning/error messages from RIPng itself this
could be useful.

Regards,
Pavlin


From hantongs at gmail.com  Wed Nov 14 00:44:30 2007
From: hantongs at gmail.com (Hansi)
Date: Wed, 14 Nov 2007 16:44:30 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <200711131544.lADFiqGC074230@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711130125j49845bfqcfbc97f22171c252@mail.gmail.com>
	<200711131544.lADFiqGC074230@possum.icir.org>
Message-ID: <2f9e317b0711140044u7e3613dfp4116326d929c3c4c@mail.gmail.com>

Hello Pavlin,

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 at 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
[ 2007/11/14 02:28:57 INFO xorp_fea XRL ] Sending
stcp://127.0.0.1:49674/socket6_user/0.1/recv_event-10be5b2055e768a3?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
[ 2007/11/14 02:28:57 INFO xorp_ripng IPC ] dispatch_xrl (valid)
socket6_user/0.1/recv_event
[ 2007/11/14 02:29:27 INFO xorp_fea XRL ] Resolving
xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 at 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
[ 2007/11/14 02:29:27 INFO xorp_fea XRL ] Sending
stcp://127.0.0.1:49674/socket6_user/0.1/recv_event-10be5b2055e768a3?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
[ 2007/11/14 02:29:27 INFO xorp_ripng IPC ] dispatch_xrl (valid)
socket6_user/0.1/recv_event
[ 2007/11/14 02:29:57 INFO xorp_fea XRL ] Resolving
xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 at 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
[ 2007/11/14 02:29:57 INFO xorp_fea XRL ] Sending
stcp://127.0.0.1:49674/socket6_user/0.1/recv_event-10be5b2055e768a3?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
[ 2007/11/14 02:29:57 INFO xorp_ripng IPC ] dispatch_xrl (valid)
socket6_user/0.1/recv_event
[ 2007/11/14 02:30:27 INFO xorp_fea XRL ] Resolving
xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 at 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
[ 2007/11/14 02:30:27 INFO xorp_fea XRL ] Sending
stcp://127.0.0.1:49674/socket6_user/0.1/recv_event-10be5b2055e768a3?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
[ 2007/11/14 02:30:27 INFO xorp_ripng IPC ] dispatch_xrl (valid)
socket6_user/0.1/recv_event
[ 2007/11/14 02:30:57 INFO xorp_fea XRL ] Resolving
xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 at 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
[ 2007/11/14 02:30:57 INFO xorp_fea XRL ] Sending
stcp://127.0.0.1:49674/socket6_user/0.1/recv_event-10be5b2055e768a3?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
[ 2007/11/14 02:30:57 INFO xorp_ripng IPC ] dispatch_xrl (valid)
socket6_user/0.1/recv_event
[ 2007/11/14 02:31:27 INFO xorp_fea XRL ] Resolving
xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 at 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
[ 2007/11/14 02:31:27 INFO xorp_fea XRL ] Sending
stcp://127.0.0.1:49674/socket6_user/0.1/recv_event-10be5b2055e768a3?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
[ 2007/11/14 02:31:27 INFO xorp_ripng IPC ] dispatch_xrl (valid)
socket6_user/0.1/recv_event
[ 2007/11/14 02:31:57 INFO xorp_fea XRL ] Resolving
xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 at 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
[ 2007/11/14 02:31:57 INFO xorp_fea XRL ] Sending
stcp://127.0.0.1:49674/socket6_user/0.1/recv_event-10be5b2055e768a3?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
[ 2007/11/14 02:31:57 INFO xorp_ripng IPC ] dispatch_xrl (valid)
socket6_user/0.1/recv_event
[ 2007/11/14 02:32:27 INFO xorp_fea XRL ] Resolving
xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 at 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
[ 2007/11/14 02:32:27 INFO xorp_fea XRL ] Sending
stcp://127.0.0.1:49674/socket6_user/0.1/recv_event-10be5b2055e768a3?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