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%00%00%00%00%00%00%00%00%00%00%10
[ 2007/11/14 02:32:27 INFO xorp_ripng IPC ] dispatch_xrl (valid)
socket6_user/0.1/recv_event
[ 2007/11/14 02:32: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:32: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:32:57 INFO xorp_ripng IPC ] dispatch_xrl (valid)
socket6_user/0.1/recv_event
(2:33:27<root at demo_rtr :/usr/local/xorp/bin>)#

I don't know how to interpret these log messages. Perhaps you could help. :)

I did a ping to the all-ripv6 routers multicast address ff02::9 just
to double check:

$ ping6 -I vr0 ff02::9
PING6(56=40+8+8 bytes) fe80::213:d4ff:fed8:6808%vr0 --> ff02::9
16 bytes from fe80::213:d4ff:fed8:6808%vr0, icmp_seq=0 hlim=64 time=0.192 ms
16 bytes from fe80::215:f2ff:fe3d:ac91%vr0, icmp_seq=0 hlim=64
time=0.254 ms(DUP!)
16 bytes from fe80::213:d4ff:fed8:6808%vr0, icmp_seq=1 hlim=64 time=0.112 ms
16 bytes from fe80::215:f2ff:fe3d:ac91%vr0, icmp_seq=1 hlim=64
time=0.232 ms(DUP!)
16 bytes from fe80::213:d4ff:fed8:6808%vr0, icmp_seq=2 hlim=64 time=0.107 ms
16 bytes from fe80::215:f2ff:fe3d:ac91%vr0, icmp_seq=2 hlim=64
time=0.228 ms(DUP!)
16 bytes from fe80::213:d4ff:fed8:6808%vr0, icmp_seq=3 hlim=64 time=0.122 ms
16 bytes from fe80::215:f2ff:fe3d:ac91%vr0, icmp_seq=3 hlim=64
time=0.252 ms(DUP!)
16 bytes from fe80::213:d4ff:fed8:6808%vr0, icmp_seq=4 hlim=64 time=0.105 ms
16 bytes from fe80::215:f2ff:fe3d:ac91%vr0, icmp_seq=4 hlim=64
time=0.226 ms(DUP!)
16 bytes from fe80::213:d4ff:fed8:6808%vr0, icmp_seq=5 hlim=64 time=0.105 ms
16 bytes from fe80::215:f2ff:fe3d:ac91%vr0, icmp_seq=5 hlim=64
time=0.219 ms(DUP!)

Attached is my xorp config file.

Regards,
Hansi

On Nov 13, 2007 11:44 PM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > 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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: "
Type: application/octet-stream
Size: 3280 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071114/1556188a/attachment.obj 

From pavlin at icir.org  Wed Nov 14 09:52:05 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 14 Nov 2007 09:52:05 -0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Wed,
	14 Nov 2007 16:44:30 +0800."
	<2f9e317b0711140044u7e3613dfp4116326d929c3c4c@mail.gmail.com> 
Message-ID: <200711141752.lAEHq5k7006261@possum.icir.org>

> 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

OK, the above indicates that the FEA has received and forwarded the
UDP packet to the RIPng module.

After you started using the link-local addresses in your
configuration what is the output of "show ripng peer statistics all"
xorpsh command? It should show something like:

user at hostname> show ripng peer statistics all 

* RIP statistics for peer fe80::xxxx:xxxx on rl0 rl0 fe80::yyyy:yyyy

  Last Active at Wed Nov 14 09:40:37 2007

  Counter                                     Value
  -------------------------------- ----------------
  Total Packets Received                          6
  Request Packets Received                        1
  Update Packets Received                         5
  Bad Packets Received                            0
  Bad Routes Received                             5
  Routes Active                                   0


> Attached is my xorp config file.

There was one problem in your config file. Inside the policy
statement you need to replace

                network6: ::/0

with

                network6 <= ::/0

This could explain why the connected routes weren't exported.


Regards,
Pavlin

P.S. For reference purpose this is my config file. Obviously, you
need to replace the link-local address inside the ripng block with
your own link-local address.

====================================================
interfaces {
    interface rl0 {
	default-system-config
    }
}

fea {
    unicast-forwarding6 {
	disable: false
    }
}

policy {
    policy-statement export_connected {
        term static {
            from {
                protocol: "connected"
		network6 <= ::/0
            }
        }
    }
}

protocols {
    ripng {
	export: "export_connected"
	interface rl0 {
	    vif rl0 {
		address fe80::xxxx:xxxx {
		}
	    }
	}
    }
}
====================================================


From hantongs at gmail.com  Wed Nov 14 17:11:09 2007
From: hantongs at gmail.com (Hansi)
Date: Thu, 15 Nov 2007 09:11:09 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <200711141752.lAEHq5k7006261@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711140044u7e3613dfp4116326d929c3c4c@mail.gmail.com>
	<200711141752.lAEHq5k7006261@possum.icir.org>
Message-ID: <2f9e317b0711141711u1c734e56k69c2bce3ae7ee445@mail.gmail.com>

On Nov 15, 2007 1:52 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > Replacing the global address with the link-local IPv6 address provides
> > the same results. No peerings between two XORP machines w/ RIPng
> > enabled are established. Attached is the configuration file used.
> >
> > Also, I managed to do a trace as you instructed to:
> >
> > 2:33:20<root at demo_rtr :/usr/local/xorp/bin>)#less typescript | grep
> > "socket6_user"
> > "typescript" may be a binary file.  See it anyway? y
> >
> > [ 2007/11/14 02:28:57 INFO xorp_fea XRL ] Resolving
> > xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 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
>
> OK, the above indicates that the FEA has received and forwarded the
> UDP packet to the RIPng module.
>
> After you started using the link-local addresses in your
> configuration what is the output of "show ripng peer statistics all"
> xorpsh command? It should show something like:
>

Yes, I did. But it displays "There are no peers" or something like
that which indicates that no peerings has been established.

> user at hostname> show ripng peer statistics all
>
> * RIP statistics for peer fe80::xxxx:xxxx on rl0 rl0 fe80::yyyy:yyyy
>
>   Last Active at Wed Nov 14 09:40:37 2007
>
>   Counter                                     Value
>   -------------------------------- ----------------
>   Total Packets Received                          6
>   Request Packets Received                        1
>   Update Packets Received                         5
>   Bad Packets Received                            0
>   Bad Routes Received                             5
>   Routes Active                                   0
>
>
> > Attached is my xorp config file.
>
> There was one problem in your config file. Inside the policy
> statement you need to replace
>
>                 network6: ::/0
>
> with
>
>                 network6 <= ::/0
>
> This could explain why the connected routes weren't exported.
>

Ok. Thanks for pointing that out. Will try this out. I'll give you
feedback on the outcome of this.

Thanks,
Hansi
>
> Regards,
> Pavlin
>
> P.S. For reference purpose this is my config file. Obviously, you
> need to replace the link-local address inside the ripng block with
> your own link-local address.
>
> ====================================================
> interfaces {
>     interface rl0 {
>         default-system-config
>     }
> }
>
> fea {
>     unicast-forwarding6 {
>         disable: false
>     }
> }
>
> policy {
>     policy-statement export_connected {
>         term static {
>             from {
>                 protocol: "connected"
>                 network6 <= ::/0
>             }
>         }
>     }
> }
>
> protocols {
>     ripng {
>         export: "export_connected"
>         interface rl0 {
>             vif rl0 {
>                 address fe80::xxxx:xxxx {
>                 }
>             }
>         }
>     }
> }
> ====================================================
>


From pavlin at icir.org  Wed Nov 14 17:23:49 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 14 Nov 2007 17:23:49 -0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Thu,
	15 Nov 2007 09:11:09 +0800."
	<2f9e317b0711141711u1c734e56k69c2bce3ae7ee445@mail.gmail.com> 
Message-ID: <200711150123.lAF1Nn8q021909@possum.icir.org>

Hansi <hantongs at gmail.com> wrote:

> On Nov 15, 2007 1:52 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > > Replacing the global address with the link-local IPv6 address provides
> > > the same results. No peerings between two XORP machines w/ RIPng
> > > enabled are established. Attached is the configuration file used.
> > >
> > > Also, I managed to do a trace as you instructed to:
> > >
> > > 2:33:20<root at demo_rtr :/usr/local/xorp/bin>)#less typescript | grep
> > > "socket6_user"
> > > "typescript" may be a binary file.  See it anyway? y
> > >
> > > [ 2007/11/14 02:28:57 INFO xorp_fea XRL ] Resolving
> > > xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 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
> >
> > OK, the above indicates that the FEA has received and forwarded the
> > UDP packet to the RIPng module.
> >
> > After you started using the link-local addresses in your
> > configuration what is the output of "show ripng peer statistics all"
> > xorpsh command? It should show something like:
> >
> 
> Yes, I did. But it displays "There are no peers" or something like
> that which indicates that no peerings has been established.

That's odd.
What FreeBSD version are you using?

It worked for me between FreeBSD-6.2 (amd64) and FreeBSD-4.10.
If it still doesn't work for you, start with my configuration I sent
in the previous email, but double-check that the local IPv6 address
inside your ripng configuration indeed matches the link-local
address on each host.

This is a show-stopper and if they don't peer then the rest won't
work.

Pavlin

> > user at hostname> show ripng peer statistics all
> >
> > * RIP statistics for peer fe80::xxxx:xxxx on rl0 rl0 fe80::yyyy:yyyy
> >
> >   Last Active at Wed Nov 14 09:40:37 2007
> >
> >   Counter                                     Value
> >   -------------------------------- ----------------
> >   Total Packets Received                          6
> >   Request Packets Received                        1
> >   Update Packets Received                         5
> >   Bad Packets Received                            0
> >   Bad Routes Received                             5
> >   Routes Active                                   0


From hantongs at gmail.com  Wed Nov 14 17:49:43 2007
From: hantongs at gmail.com (Hansi)
Date: Thu, 15 Nov 2007 09:49:43 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <200711150123.lAF1Nn8q021909@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711141711u1c734e56k69c2bce3ae7ee445@mail.gmail.com>
	<200711150123.lAF1Nn8q021909@possum.icir.org>
Message-ID: <2f9e317b0711141749g6b9faf7byc9abe9c69058d646@mail.gmail.com>

On Nov 15, 2007 9:23 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> Hansi <hantongs at gmail.com> wrote:
>
> > On Nov 15, 2007 1:52 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > > > Replacing the global address with the link-local IPv6 address provides
> > > > the same results. No peerings between two XORP machines w/ RIPng
> > > > enabled are established. Attached is the configuration file used.
> > > >
> > > > Also, I managed to do a trace as you instructed to:
> > > >
> > > > 2:33:20<root at demo_rtr :/usr/local/xorp/bin>)#less typescript | grep
> > > > "socket6_user"
> > > > "typescript" may be a binary file.  See it anyway? y
> > > >
> > > > [ 2007/11/14 02:28:57 INFO xorp_fea XRL ] Resolving
> > > > xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 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
> > >
> > > OK, the above indicates that the FEA has received and forwarded the
> > > UDP packet to the RIPng module.
> > >
> > > After you started using the link-local addresses in your
> > > configuration what is the output of "show ripng peer statistics all"
> > > xorpsh command? It should show something like:
> > >
> >
> > Yes, I did. But it displays "There are no peers" or something like
> > that which indicates that no peerings has been established.
>
> That's odd.
> What FreeBSD version are you using?

I'm also using FreeBSD-6.2 on an amd64 architecture.
>
> It worked for me between FreeBSD-6.2 (amd64) and FreeBSD-4.10.
> If it still doesn't work for you, start with my configuration I sent
> in the previous email, but double-check that the local IPv6 address
> inside your ripng configuration indeed matches the link-local
> address on each host.
>
> This is a show-stopper and if they don't peer then the rest won't
> work.
>

Yes, indeed. The reason why I can't move forward. Nevertheless, I'll
keep you posted. :)

Thanks,
Hansi

> Pavlin
>
>
> > > user at hostname> show ripng peer statistics all
> > >
> > > * RIP statistics for peer fe80::xxxx:xxxx on rl0 rl0 fe80::yyyy:yyyy
> > >
> > >   Last Active at Wed Nov 14 09:40:37 2007
> > >
> > >   Counter                                     Value
> > >   -------------------------------- ----------------
> > >   Total Packets Received                          6
> > >   Request Packets Received                        1
> > >   Update Packets Received                         5
> > >   Bad Packets Received                            0
> > >   Bad Routes Received                             5
> > >   Routes Active                                   0
>


From hantongs at gmail.com  Thu Nov 15 03:01:16 2007
From: hantongs at gmail.com (Hansi)
Date: Thu, 15 Nov 2007 19:01:16 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <2f9e317b0711141749g6b9faf7byc9abe9c69058d646@mail.gmail.com>
References: <hantongs@gmail.com>
	<2f9e317b0711141711u1c734e56k69c2bce3ae7ee445@mail.gmail.com>
	<200711150123.lAF1Nn8q021909@possum.icir.org>
	<2f9e317b0711141749g6b9faf7byc9abe9c69058d646@mail.gmail.com>
Message-ID: <2f9e317b0711150301pd1a946l96a9f8c33b802f8e@mail.gmail.com>

Hello Pavlin,

Finally, I was able to establish a peering between two RIPng routers.
:) However, I noticed something odd. Shouldn't it be that RIP peerings
will be established even though no policy on connected/static routes
have been exported yet? During my exploration, I have observed that
upon enabling RIPng on both XORP machines, only the XORP router which
was enabled first would display that a peering has been established
through invoking "show ripng peer statistics all". The other router,
upon invoking the same command, displays "There are no known peers".
However, when policies are exported to the RIPng protocol, both would
now display that a peering has been established.

When configuring RIPng and the network has converged, should the next
hop address be the link-local address of the next-hop router or the
global unicast address? Because from what I'm seeing upon invoking
netstat -rna, this is returned:

Internet6:
Destination                       Gateway                       Flags      Netif
 Expire
::/96                             ::1                           UGRS        lo0
::1                               ::1                           UHL         lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
2001:ec0:4000:beef::/64           link#2                        UC          vr0
2001:ec0:4000:beef::1             00:13:d4:d8:68:08             UHL         lo0
2001:ec0:4000:beef::2             00:15:f2:3d:ac:91             UHLW        vr0
2001:ec1:4001:10af::/64           link#1                        UC          sk0
2001:ec1:4001:10af::1             00:19:5b:85:cf:c7             UHL         lo0
2001:ec1:4001:10af:219:5bff:fe2f:1468 00:19:5b:2f:14:68             UHLW
sk0
2001:ec2:4002:fa11::/64           fe80::215:f2ff:fe3d:ac91%sk0  UG1         sk0

The destination network is 2001:ec2:4002:fa11::/64 and the next hop
router address happens to be fe80::215:f2ff:fe3d:ac91%sk0. Please
refer to this link for the network topology as well as the interface
assignments.

http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-November/002176.html

I'm just confused of fe80::215:f2ff:fe3d:ac91%sk0. This happens to be
the link local address of the next hop router w/c is router two. The
interface should be vr0 and not sk0.

Looking further, I found this:

admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
2001:ec0:4000:beef::/64 [rip(120)/1]
                > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0
2001:ec2:4002:fa11::/64 [rip(120)/1]
                > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0

These results were take from router 1 indicating that in order to get
to network 2001:ec2:4002:fa11::/64, the next hop address should be
fe80::215:f2ff:fe3d:ac91. But how come it is via sk0? sk0 happens to
be the interface facing the client. Shouldn't it be vr0 instead? This
behavior is also inherent in router 2.

I can confirm that RIPng is now working because of these logs:

05:41:28.005579 IP6 (hlim 1, next-header: UDP (17), length: 92)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
4:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64
        fe80::/64
05:41:31.059524 IP6 (hlim 1, next-header: UDP (17), length: 52)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
2:
        ::/0 (255)
        2001:ec1:4001:10af::/64 (16)
05:41:32.942289 IP6 (hlim 1, next-header: UDP (17), length: 112)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
5:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64
        2001:ec2:4002:fa11::/64 (16)
        fe80::/64
05:41:35.686314 IP6 (hlim 1, next-header: UDP (17), length: 112)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
5:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64 (16)
        2001:ec2:4002:fa11::/64
        fe80::/64
05:42:01.260164 IP6 (hlim 1, next-header: UDP (17), length: 112)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
5:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64
        2001:ec2:4002:fa11::/64 (16)
        fe80::/64
05:42:08.229241 IP6 (hlim 1, next-header: UDP (17), length: 112)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
5:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64 (16)
        2001:ec2:4002:fa11::/64
        fe80::/64
05:42:32.784957 IP6 (hlim 1, next-header: UDP (17), length: 112)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
5:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64
        2001:ec2:4002:fa11::/64 (16)
        fe80::/64
05:42:38.688112 IP6 (hlim 1, next-header: UDP (17), length: 112)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
5:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64 (16)
        2001:ec2:4002:fa11::/64
        fe80::/64
05:43:00.533865 IP6 (hlim 1, next-header: UDP (17), length: 112)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
5:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64
        2001:ec2:4002:fa11::/64 (16)
        fe80::/64
05:43:08.615122 IP6 (hlim 1, next-header: UDP (17), length: 112)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
5:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64 (16)
        2001:ec2:4002:fa11::/64
        fe80::/64
05:43:31.085701 IP6 (hlim 1, next-header: UDP (17), length: 112)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
5:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64
        2001:ec2:4002:fa11::/64 (16)
        fe80::/64

However I'm also seeing these messages from stdout:

[ 2007/11/15 05:45:14 INFO xorp_ripng RIP ] RIP port
vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
fe80::215:f2ff:fe3d:ac91:521 - linklocal route
[ 2007/11/15 05:45:49 INFO xorp_ripng RIP ] RIP port
vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
fe80::215:f2ff:fe3d:ac91:521 - linklocal route
[ 2007/11/15 05:46:18 INFO xorp_ripng RIP ] RIP port
vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
fe80::215:f2ff:fe3d:ac91:521 - linklocal route
[ 2007/11/15 05:46:51 INFO xorp_ripng RIP ] RIP port
vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
fe80::215:f2ff:fe3d:ac91:521 - linklocal route
[ 2007/11/15 05:47:19 INFO xorp_ripng RIP ] RIP port
vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
fe80::215:f2ff:fe3d:ac91:521 - linklocal route

Hope you could shed some light on this.

Thanks,
Hansi

On Nov 15, 2007 9:49 AM, Hansi <hantongs at gmail.com> wrote:
> On Nov 15, 2007 9:23 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > Hansi <hantongs at gmail.com> wrote:
> >
> > > On Nov 15, 2007 1:52 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > > > > Replacing the global address with the link-local IPv6 address provides
> > > > > the same results. No peerings between two XORP machines w/ RIPng
> > > > > enabled are established. Attached is the configuration file used.
> > > > >
> > > > > Also, I managed to do a trace as you instructed to:
> > > > >
> > > > > 2:33:20<root at demo_rtr :/usr/local/xorp/bin>)#less typescript | grep
> > > > > "socket6_user"
> > > > > "typescript" may be a binary file.  See it anyway? y
> > > > >
> > > > > [ 2007/11/14 02:28:57 INFO xorp_fea XRL ] Resolving
> > > > > xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 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
> > > >
> > > > OK, the above indicates that the FEA has received and forwarded the
> > > > UDP packet to the RIPng module.
> > > >
> > > > After you started using the link-local addresses in your
> > > > configuration what is the output of "show ripng peer statistics all"
> > > > xorpsh command? It should show something like:
> > > >
> > >
> > > Yes, I did. But it displays "There are no peers" or something like
> > > that which indicates that no peerings has been established.
> >
> > That's odd.
> > What FreeBSD version are you using?
>
> I'm also using FreeBSD-6.2 on an amd64 architecture.
> >
> > It worked for me between FreeBSD-6.2 (amd64) and FreeBSD-4.10.
> > If it still doesn't work for you, start with my configuration I sent
> > in the previous email, but double-check that the local IPv6 address
> > inside your ripng configuration indeed matches the link-local
> > address on each host.
> >
> > This is a show-stopper and if they don't peer then the rest won't
> > work.
> >
>
> Yes, indeed. The reason why I can't move forward. Nevertheless, I'll
> keep you posted. :)
>
> Thanks,
> Hansi
>
>
> > Pavlin
> >
> >
> > > > user at hostname> show ripng peer statistics all
> > > >
> > > > * RIP statistics for peer fe80::xxxx:xxxx on rl0 rl0 fe80::yyyy:yyyy
> > > >
> > > >   Last Active at Wed Nov 14 09:40:37 2007
> > > >
> > > >   Counter                                     Value
> > > >   -------------------------------- ----------------
> > > >   Total Packets Received                          6
> > > >   Request Packets Received                        1
> > > >   Update Packets Received                         5
> > > >   Bad Packets Received                            0
> > > >   Bad Routes Received                             5
> > > >   Routes Active                                   0
> >
>


From hantongs at gmail.com  Thu Nov 15 23:03:57 2007
From: hantongs at gmail.com (Hansi)
Date: Fri, 16 Nov 2007 15:03:57 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <2f9e317b0711150301pd1a946l96a9f8c33b802f8e@mail.gmail.com>
References: <hantongs@gmail.com>
	<2f9e317b0711141711u1c734e56k69c2bce3ae7ee445@mail.gmail.com>
	<200711150123.lAF1Nn8q021909@possum.icir.org>
	<2f9e317b0711141749g6b9faf7byc9abe9c69058d646@mail.gmail.com>
	<2f9e317b0711150301pd1a946l96a9f8c33b802f8e@mail.gmail.com>
Message-ID: <2f9e317b0711152303r58326ed4pc58c3efa60fcc1cc@mail.gmail.com>

Hello Pavlin,

Just to be sure that I'm not mistaken on the problem that I reported,
I disabled XORP then ran route6d. (this is just for comparative
purposes)
Here are the details by the way:

ROUTER 1

$ ifconfig -a | more
sk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        inet6 fe80::219:5bff:fe85:cfc7%sk0 prefixlen 64 scopeid 0x1
        inet 172.16.0.1 netmask 0xffff0000 broadcast 172.16.255.255
        inet6 2001:ec1:4001:10af::1 prefixlen 64
        ether 00:19:5b:85:cf:c7
        media: Ethernet autoselect (1000baseTX <full-duplex,flag0,flag1>)
        status: active
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::213:d4ff:fed8:6808%vr0 prefixlen 64 scopeid 0x2
        inet 200.10.0.1 netmask 0xffffff00 broadcast 200.10.0.255
        inet6 2001:ec0:4000:beef::1 prefixlen 64
        ether 00:13:d4:d8:68:08
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
plip0: flags=108851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,NEEDSGIANT> mtu 15
00
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet 127.0.0.1 netmask 0xff000000


$netstat -rna | more
Internet6:
Destination                       Gateway                       Flags      Neti
f Expire
::/96                             ::1                           UGRS        lo0
::1                               ::1                           UHL         lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
2001:ec0:4000:beef::/64           link#2                        UC          vr0
2001:ec0:4000:beef::1             00:13:d4:d8:68:08             UHL         lo0
2001:ec1:4001:10af::/64           link#1                        UC          sk0
2001:ec1:4001:10af::1             00:19:5b:85:cf:c7             UHL         lo0
2001:ec1:4001:10af:219:5bff:fe2f:1468 00:19:5b:2f:14:68             UHLW
 sk0
2001:ec2:4002:fa11::/64           fe80::215:f2ff:fe3d:ac91%vr0  UG          vr0


ROUTER 2

$ ifconfig -a | more
sk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        inet6 fe80::219:5bff:fe2f:146a%sk0 prefixlen 64 scopeid 0x1
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
        inet6 2001:ec2:4002:fa11::1 prefixlen 64
        ether 00:19:5b:2f:14:6a
        media: Ethernet autoselect (100baseTX <full-duplex,flag0,flag1>)
        status: active
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::215:f2ff:fe3d:ac91%vr0 prefixlen 64 scopeid 0x2
        inet 200.10.0.2 netmask 0xffffff00 broadcast 200.10.0.255
        inet6 2001:ec0:4000:beef::2 prefixlen 64
        ether 00:15:f2:3d:ac:91
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
plip0: flags=108851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,NEEDSGIANT> mtu 150
0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet 127.0.0.1 netmask 0xff000000

$netstat -rna | more
Route Table:
Internet6:
Destination                       Gateway                       Flags      Netif
 Expire
::/96                             ::1                           UGRS        lo0
::1                               ::1                           UHL         lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
2001:ec0:4000:beef::/64           link#2                        UC          vr0
2001:ec0:4000:beef::2             00:15:f2:3d:ac:91             UHL         lo0
2001:ec1:4001:10af::/64           fe80::213:d4ff:fed8:6808%vr0  UG          vr0
2001:ec2:4002:fa11::/64           link#1                        UC          sk0


Routing Table entry when running route6d:
2001:ec2:4002:fa11::/64           fe80::215:f2ff:fe3d:ac91%vr0  UG          vr0

Routing Table entry when running XORP RIPng:
2001:ec2:4002:fa11::/64           fe80::215:f2ff:fe3d:ac91%sk0  UG1         sk0


There's a significant difference in the interfaces. Using route6d, I
was able to ping from pc to pc. And I believe that vr0 should be the
correct interface. :) No wonder why the advertised networks exhibit a
metric of 16. Here's a tcpdump when running route6d:

03:06:12.254810 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
1: 2001:ec2:4002:fa11::/64 (1)
03:06:13.916513 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
1: 2001:ec1:4001:10af::/64 (1)
03:06:37.918085 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
1: 2001:ec1:4001:10af::/64 (1)
03:06:49.255609 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
1: 2001:ec2:4002:fa11::/64 (1)
03:07:10.919883 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
1: 2001:ec1:4001:10af::/64 (1)
03:07:33.256372 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
1: 2001:ec2:4002:fa11::/64 (1)
03:07:47.921761 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
1: 2001:ec1:4001:10af::/64 (1)
03:07:58.257233 IP6 (hlim 255, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
1: 2001:ec2:4002:fa11::/64 (1)

Appreciate your assistance on this problem.

Regards,
Hansi

On Nov 15, 2007 7:01 PM, Hansi <hantongs at gmail.com> wrote:
> Hello Pavlin,
>
> Finally, I was able to establish a peering between two RIPng routers.
> :) However, I noticed something odd. Shouldn't it be that RIP peerings
> will be established even though no policy on connected/static routes
> have been exported yet? During my exploration, I have observed that
> upon enabling RIPng on both XORP machines, only the XORP router which
> was enabled first would display that a peering has been established
> through invoking "show ripng peer statistics all". The other router,
> upon invoking the same command, displays "There are no known peers".
> However, when policies are exported to the RIPng protocol, both would
> now display that a peering has been established.
>
> When configuring RIPng and the network has converged, should the next
> hop address be the link-local address of the next-hop router or the
> global unicast address? Because from what I'm seeing upon invoking
> netstat -rna, this is returned:
>
> Internet6:
> Destination                       Gateway                       Flags      Netif
>  Expire
> ::/96                             ::1                           UGRS        lo0
> ::1                               ::1                           UHL         lo0
> ::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
> 2001:ec0:4000:beef::/64           link#2                        UC          vr0
> 2001:ec0:4000:beef::1             00:13:d4:d8:68:08             UHL         lo0
> 2001:ec0:4000:beef::2             00:15:f2:3d:ac:91             UHLW        vr0
> 2001:ec1:4001:10af::/64           link#1                        UC          sk0
> 2001:ec1:4001:10af::1             00:19:5b:85:cf:c7             UHL         lo0
> 2001:ec1:4001:10af:219:5bff:fe2f:1468 00:19:5b:2f:14:68             UHLW
> sk0
> 2001:ec2:4002:fa11::/64           fe80::215:f2ff:fe3d:ac91%sk0  UG1         sk0
>
> The destination network is 2001:ec2:4002:fa11::/64 and the next hop
> router address happens to be fe80::215:f2ff:fe3d:ac91%sk0. Please
> refer to this link for the network topology as well as the interface
> assignments.
>
> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-November/002176.html
>
> I'm just confused of fe80::215:f2ff:fe3d:ac91%sk0. This happens to be
> the link local address of the next hop router w/c is router two. The
> interface should be vr0 and not sk0.
>
> Looking further, I found this:
>
> admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
> 2001:ec0:4000:beef::/64 [rip(120)/1]
>                 > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0
> 2001:ec2:4002:fa11::/64 [rip(120)/1]
>                 > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0
>
> These results were take from router 1 indicating that in order to get
> to network 2001:ec2:4002:fa11::/64, the next hop address should be
> fe80::215:f2ff:fe3d:ac91. But how come it is via sk0? sk0 happens to
> be the interface facing the client. Shouldn't it be vr0 instead? This
> behavior is also inherent in router 2.
>
> I can confirm that RIPng is now working because of these logs:
>
> 05:41:28.005579 IP6 (hlim 1, next-header: UDP (17), length: 92)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 4:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64
>         fe80::/64
> 05:41:31.059524 IP6 (hlim 1, next-header: UDP (17), length: 52)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 2:
>         ::/0 (255)
>         2001:ec1:4001:10af::/64 (16)
> 05:41:32.942289 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 5:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64
>         2001:ec2:4002:fa11::/64 (16)
>         fe80::/64
> 05:41:35.686314 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 5:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64 (16)
>         2001:ec2:4002:fa11::/64
>         fe80::/64
> 05:42:01.260164 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 5:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64
>         2001:ec2:4002:fa11::/64 (16)
>         fe80::/64
> 05:42:08.229241 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 5:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64 (16)
>         2001:ec2:4002:fa11::/64
>         fe80::/64
> 05:42:32.784957 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 5:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64
>         2001:ec2:4002:fa11::/64 (16)
>         fe80::/64
> 05:42:38.688112 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 5:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64 (16)
>         2001:ec2:4002:fa11::/64
>         fe80::/64
> 05:43:00.533865 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 5:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64
>         2001:ec2:4002:fa11::/64 (16)
>         fe80::/64
> 05:43:08.615122 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 5:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64 (16)
>         2001:ec2:4002:fa11::/64
>         fe80::/64
> 05:43:31.085701 IP6 (hlim 1, next-header: UDP (17), length: 112)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 5:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64
>         2001:ec2:4002:fa11::/64 (16)
>         fe80::/64
>
> However I'm also seeing these messages from stdout:
>
> [ 2007/11/15 05:45:14 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> [ 2007/11/15 05:45:49 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> [ 2007/11/15 05:46:18 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> [ 2007/11/15 05:46:51 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> [ 2007/11/15 05:47:19 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route
>
> Hope you could shed some light on this.
>
> Thanks,
> Hansi
>
>
> On Nov 15, 2007 9:49 AM, Hansi <hantongs at gmail.com> wrote:
> > On Nov 15, 2007 9:23 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > > Hansi <hantongs at gmail.com> wrote:
> > >
> > > > On Nov 15, 2007 1:52 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > > > > > Replacing the global address with the link-local IPv6 address provides
> > > > > > the same results. No peerings between two XORP machines w/ RIPng
> > > > > > enabled are established. Attached is the configuration file used.
> > > > > >
> > > > > > Also, I managed to do a trace as you instructed to:
> > > > > >
> > > > > > 2:33:20<root at demo_rtr :/usr/local/xorp/bin>)#less typescript | grep
> > > > > > "socket6_user"
> > > > > > "typescript" may be a binary file.  See it anyway? y
> > > > > >
> > > > > > [ 2007/11/14 02:28:57 INFO xorp_fea XRL ] Resolving
> > > > > > xrl:finder://ripng-775637ed507ee002ab82dd3f24333ee1 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
> > > > >
> > > > > OK, the above indicates that the FEA has received and forwarded the
> > > > > UDP packet to the RIPng module.
> > > > >
> > > > > After you started using the link-local addresses in your
> > > > > configuration what is the output of "show ripng peer statistics all"
> > > > > xorpsh command? It should show something like:
> > > > >
> > > >
> > > > Yes, I did. But it displays "There are no peers" or something like
> > > > that which indicates that no peerings has been established.
> > >
> > > That's odd.
> > > What FreeBSD version are you using?
> >
> > I'm also using FreeBSD-6.2 on an amd64 architecture.
> > >
> > > It worked for me between FreeBSD-6.2 (amd64) and FreeBSD-4.10.
> > > If it still doesn't work for you, start with my configuration I sent
> > > in the previous email, but double-check that the local IPv6 address
> > > inside your ripng configuration indeed matches the link-local
> > > address on each host.
> > >
> > > This is a show-stopper and if they don't peer then the rest won't
> > > work.
> > >
> >
> > Yes, indeed. The reason why I can't move forward. Nevertheless, I'll
> > keep you posted. :)
> >
> > Thanks,
> > Hansi
> >
> >
> > > Pavlin
> > >
> > >
> > > > > user at hostname> show ripng peer statistics all
> > > > >
> > > > > * RIP statistics for peer fe80::xxxx:xxxx on rl0 rl0 fe80::yyyy:yyyy
> > > > >
> > > > >   Last Active at Wed Nov 14 09:40:37 2007
> > > > >
> > > > >   Counter                                     Value
> > > > >   -------------------------------- ----------------
> > > > >   Total Packets Received                          6
> > > > >   Request Packets Received                        1
> > > > >   Update Packets Received                         5
> > > > >   Bad Packets Received                            0
> > > > >   Bad Routes Received                             5
> > > > >   Routes Active                                   0
> > >
> >
>


From pavlin at icir.org  Fri Nov 16 21:56:09 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 16 Nov 2007 21:56:09 -0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Thu,
	15 Nov 2007 19:01:16 +0800."
	<2f9e317b0711150301pd1a946l96a9f8c33b802f8e@mail.gmail.com> 
Message-ID: <200711170556.lAH5u9pr073683@possum.icir.org>

> Finally, I was able to establish a peering between two RIPng routers.
> :) However, I noticed something odd. Shouldn't it be that RIP peerings
> will be established even though no policy on connected/static routes
> have been exported yet? During my exploration, I have observed that
> upon enabling RIPng on both XORP machines, only the XORP router which
> was enabled first would display that a peering has been established
> through invoking "show ripng peer statistics all". The other router,
> upon invoking the same command, displays "There are no known peers".
> However, when policies are exported to the RIPng protocol, both would
> now display that a peering has been established.

This is an artifact of how the "Request" packets are transmitted in
the XORP implementation: the request packets are transmitted
periodically only if there is no neighbor (e.g., see rip/port.hh and
rip/port.cc and search for "request_table").

I quickly looked into the spec (RFC 2080) and the spec doesn't say
that the "Request" packets have to be transmitted periodically
(i.e., the "Request" packets do not have the function of Hello
packets that are usually seen in other protocols).

Hence, what you see is an interesting (though slightly confusing)
corner case that shouldn't break anything.

Once you start exporting some routes (e.g., "connected") then there
should be no more confusion.

> When configuring RIPng and the network has converged, should the next
> hop address be the link-local address of the next-hop router or the
> global unicast address? Because from what I'm seeing upon invoking
> netstat -rna, this is returned:
> 
> Internet6:
> Destination                       Gateway                       Flags      Netif
>  Expire
> ::/96                             ::1                           UGRS        lo0
> ::1                               ::1                           UHL         lo0
> ::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
> 2001:ec0:4000:beef::/64           link#2                        UC          vr0
> 2001:ec0:4000:beef::1             00:13:d4:d8:68:08             UHL         lo0
> 2001:ec0:4000:beef::2             00:15:f2:3d:ac:91             UHLW        vr0
> 2001:ec1:4001:10af::/64           link#1                        UC          sk0
> 2001:ec1:4001:10af::1             00:19:5b:85:cf:c7             UHL         lo0
> 2001:ec1:4001:10af:219:5bff:fe2f:1468 00:19:5b:2f:14:68             UHLW
> sk0
> 2001:ec2:4002:fa11::/64           fe80::215:f2ff:fe3d:ac91%sk0  UG1         sk0
> 
> The destination network is 2001:ec2:4002:fa11::/64 and the next hop
> router address happens to be fe80::215:f2ff:fe3d:ac91%sk0. Please
> refer to this link for the network topology as well as the interface
> assignments.
> 
> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-November/002176.html
> 
> I'm just confused of fe80::215:f2ff:fe3d:ac91%sk0. This happens to be
> the link local address of the next hop router w/c is router two. The
> interface should be vr0 and not sk0.

The nexthop should be the link-local address of the neighbor (on the
connected interface).
However, there was a bug the way the incoming interface was
calculated for IPv6 so that's why probably are seeing the wrong
interface. I just committed a fix, hence please try the latest code
from CVS.

> Looking further, I found this:
> 
> admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
> 2001:ec0:4000:beef::/64 [rip(120)/1]
>                 > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0
> 2001:ec2:4002:fa11::/64 [rip(120)/1]
>                 > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0
> 
> These results were take from router 1 indicating that in order to get
> to network 2001:ec2:4002:fa11::/64, the next hop address should be
> fe80::215:f2ff:fe3d:ac91. But how come it is via sk0? sk0 happens to
> be the interface facing the client. Shouldn't it be vr0 instead? This
> behavior is also inherent in router 2.
> 
> I can confirm that RIPng is now working because of these logs:
> 
> 05:41:28.005579 IP6 (hlim 1, next-header: UDP (17), length: 92)
> fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
> 4:
>         ::/0 (255)
>         2001:ec0:4000:beef::/64
>         2001:ec1:4001:10af::/64
>         fe80::/64

<DEL>

> However I'm also seeing these messages from stdout:
> 
> [ 2007/11/15 05:45:14 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> [ 2007/11/15 05:45:49 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> [ 2007/11/15 05:46:18 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> [ 2007/11/15 05:46:51 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route
> [ 2007/11/15 05:47:19 INFO xorp_ripng RIP ] RIP port
> vr0/vr0/fe80::213:d4ff:fed8:6808 received bad route from
> fe80::215:f2ff:fe3d:ac91:521 - linklocal route

Those can be safely ignored.
Anyway I committed another fix so now they should be gone.

Please let me know whether the latest CVS code works for you.

Regards,
Pavlin


From hantongs at gmail.com  Sun Nov 18 21:56:29 2007
From: hantongs at gmail.com (Hansi)
Date: Mon, 19 Nov 2007 13:56:29 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <200711170556.lAH5u9pr073683@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711150301pd1a946l96a9f8c33b802f8e@mail.gmail.com>
	<200711170556.lAH5u9pr073683@possum.icir.org>
Message-ID: <2f9e317b0711182156v360e6789m69c9882a22ebdb23@mail.gmail.com>

Hello Pavlin,

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

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

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

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

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


From pavlin at icir.org  Sun Nov 18 22:16:11 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sun, 18 Nov 2007 22:16:11 -0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Mon,
	19 Nov 2007 13:56:29 +0800."
	<2f9e317b0711182156v360e6789m69c9882a22ebdb23@mail.gmail.com> 
Message-ID: <200711190616.lAJ6GBkY098908@possum.icir.org>

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

Please enable again the XRLTRACE environmental variable and send me
the log output. This will help finding whether the problem is in
the FEA or RIP.

Also, please run tcpdump on both interface to double-check that the
RIPng packet is indeed coming on the expected interface.

Thanks,
Pavlin


From hantongs at gmail.com  Sun Nov 18 23:36:47 2007
From: hantongs at gmail.com (Hansi)
Date: Mon, 19 Nov 2007 15:36:47 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <200711190616.lAJ6GBkY098908@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711182156v360e6789m69c9882a22ebdb23@mail.gmail.com>
	<200711190616.lAJ6GBkY098908@possum.icir.org>
Message-ID: <2f9e317b0711182336r5ee30e8akc4a38c4fc543299e@mail.gmail.com>

Hello Pavlin,

Here's the output taken from tcpdump:

e3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req dump
07:31:50.929298 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
07:32:20.929740 IP6 (hlim 1, next-header: UDP (17), length: 32)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-req
dump
07:32:29.944286 IP6 (hlim 1, next-header: UDP (17), length: 72)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
3:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64
07:32:31.871290 IP6 (hlim 1, next-header: UDP (17), length: 92)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
4:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec2:4002:fa11::/64
        2001:ec1:4001:10af::/64 (16)
07:32:32.122065 IP6 (hlim 1, next-header: UDP (17), length: 52)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
2:
        ::/0 (255)
        2001:ec2:4002:fa11::/64 (16)
07:32:50.496254 IP6 (hlim 1, next-header: UDP (17), length: 92)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
4:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64 (16)
        2001:ec2:4002:fa11::/64
07:33:21.618279 IP6 (hlim 1, next-header: UDP (17), length: 92)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
4:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64
        2001:ec2:4002:fa11::/64 (16)
07:33:24.255844 IP6 (hlim 1, next-header: UDP (17), length: 92)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
4:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64 (16)
        2001:ec2:4002:fa11::/64
07:33:50.167961 IP6 (hlim 1, next-header: UDP (17), length: 92)
fe80::213:d4ff:fed8:6808.521 > ff02::9.521: [udp sum ok]  ripng-resp
4:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64
        2001:ec2:4002:fa11::/64 (16)
07:33:52.804191 IP6 (hlim 1, next-header: UDP (17), length: 92)
fe80::215:f2ff:fe3d:ac91.521 > ff02::9.521: [udp sum ok]  ripng-resp
4:
        ::/0 (255)
        2001:ec0:4000:beef::/64
        2001:ec1:4001:10af::/64 (16)
        2001:ec2:4002:fa11::/64

Appears though that the correct interface is sending out the ripng
packets. Although I am seeing a metric of 16 here which should not be
the case since its a connected network.

I'm attaching a file of the output of the trace since its quite long
to paste here.

Thanks,
Hansi



On Nov 19, 2007 2:16 PM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> >    The CVS code downloaded from the XORP CVS repository still exhibits
> > the same bug issue. The wrong interface is still being used as the
> > incoming interface as seen using netstat.
>
> Please enable again the XRLTRACE environmental variable and send me
> the log output. This will help finding whether the problem is in
> the FEA or RIP.
>
> Also, please run tcpdump on both interface to double-check that the
> RIPng packet is indeed coming on the expected interface.
>
> Thanks,
> Pavlin
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xrltrace.txt
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071119/3fd1fd13/attachment-0001.txt 

From pavlin at icir.org  Mon Nov 19 11:09:04 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 19 Nov 2007 11:09:04 -0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Mon,
	19 Nov 2007 15:36:47 +0800."
	<2f9e317b0711182336r5ee30e8akc4a38c4fc543299e@mail.gmail.com> 
Message-ID: <200711191909.lAJJ94qk006093@possum.icir.org>

<DEL>

> Appears though that the correct interface is sending out the ripng
> packets. Although I am seeing a metric of 16 here which should not be
> the case since its a connected network.
> 
> I'm attaching a file of the output of the trace since its quite long
> to paste here.

The trace output shows that the FEA has correctly identified vr0 as
the incoming interface for the RIPng packets:

[ 2007/11/19 03:33:55 INFO xorp_fea XRL ] Resolving xrl:finder://ripng-77422bcc5c4f8cc6087ec1f71328cb21 at 127.0.0.1/socket6_user/0.1/recv_event?sockid:txt=00000\000-0000058a-0004a5e5-03c70000&if_name:txt=vr0&vif_name:txt=vr0&src_host:ipv6=fe80::215:f2ff:fe3d:ac91&src_port:u32=521&data:binary=%02%01%00%00%00%00%00%00%0\0%00%00%00%00%00%00%00%00%00%00%00%00%00%00%FF+%01%0E%C0@%00%BE%EF%00%00%00%00%00%00%00%00%00%00@%00+%01%0E%C1@%01%10%AF%00%00%00%00%00%00%00%00%00%00@%10+%01\%0E%C2@%02%FA%11%00%00%00%00%00%00%00%00%00%00@%00

What is the output of the "show route table ipv6 unicast ripng"
xorpsh command?

I believe I have found the problem (RIPng doesn't send the interface
information along with the route it sends to the RIB so the RIB
mis-calculates the outgoing interface), but I'd like to cross-check
this with the "show route" output.

Thanks,
Pavlin




From eneas.hunguana at gmail.com  Mon Nov 19 14:47:57 2007
From: eneas.hunguana at gmail.com (Eneas Hunguana)
Date: Mon, 19 Nov 2007 23:47:57 +0100
Subject: [Xorp-users] INFO xorp_rib RIB Received death event for protocol
	bgp shutting down
Message-ID: <13F8F8A1-49A2-4938-881B-9A55069929FD@gmail.com>

Dear All,

I've been trying to configure XORP to assign a local preference to BGP  
routes received from a specific neighbor. I've done that by setting up  
the following import policy:

policy {
     policy-statement LP {
         term rule1 {
             from {
                 neighbor: 172.16.2.12..172.16.2.12
             }
             then {
                 localpref: 300
             }
         }
     }


It works fine, BUT, when I use an export policy so that the router  
injects static routes into BGP in order to announce it to its peers,  
XORP BGP module crashes with the following message: [the same problem  
occurs if I inject "connected" routes into BGP]

================= Logs ======================
[ 2007/11/13 11:03:04  ERROR xorp_rtrmgr:2784 RTRMGR +747  
module_manager.cc done_cb ] Command "/usr/local/src/xorp-1.4/bgp/ 
xorp_bgp": terminated with signal 11.
[ 2007/11/13 11:03:04  INFO xorp_rtrmgr:2784 RTRMGR +294  
module_manager.cc module_exited ] Module abnormally killed: bgp
[ 2007/11/13 11:03:04 INFO xorp_rib RIB ] Received death event for  
protocol bgp shutting down -------
OriginTable: ebgp
EGP
next table = Merged:(ebgp)+(ibgp)
[ 2007/11/13 11:03:04 INFO xorp_rib RIB ] Received death event for  
protocol bgp shutting down -------
OriginTable: ebgp
EGP
next table = Merged:(ebgp)+(ibgp)
[ 2007/11/13 11:03:04 INFO xorp_rib RIB ] Received death event for  
protocol bgp shutting down -------
OriginTable: ebgp
EGP
next table = Merged:(ebgp)+(ibgp)
[ 2007/11/13 11:03:04 INFO xorp_rib RIB ] Received death event for  
protocol bgp shutting down -------
OriginTable: ebgp
EGP
next table = Merged:(ebgp)+(ibgp)
=============================================

This is the export policy I am using:

  policy-statement "static-to-bgp" {
         term rule1 {
             from {
                 protocol: "static"
             }
             to {
                 neighbor: 172.16.2.12..172.16.2.12
             }
             then {
                 accept {
                 }
             }
         }
     }

Did any of you ever experience a similar problem?! What could the  
reason behind this behavior be?

Than You in advance

Regards

/Eneas

P.S: Below is my XORP configuration file


=============== config.boot =================
/*XORP Configuration File, v1.0*/
protocols {
     bgp {
         bgp-id: 10.1.1.1
         local-as: 10
         peer "172.16.2.12" {
             peer-port: 179
             local-port: 179
             local-ip: "172.16.2.11"
             as: 20
             next-hop: 172.16.2.11
             holdtime: 90
             delay-open-time: 0
             client: false
             confederation-member: false
             disable: false
             ipv4-unicast: true
             ipv4-multicast: false
             ipv6-unicast: false
             ipv6-multicast: false
         }
         peer "172.16.5.14" {
             peer-port: 179
             local-port: 179
             local-ip: "172.16.5.11"
             as: 10
             next-hop: 172.16.5.11
             holdtime: 90
             delay-open-time: 0
             client: false
             confederation-member: false
             disable: false
             ipv4-unicast: true
             ipv4-multicast: false
             ipv6-unicast: false
             ipv6-multicast: false
         }

	import: "LP"
	export: "static-to-bgp"
     }
     static {
         disable: false
         route 100.1.1.0/24 {
             next-hop: 172.16.141.1
             metric: 1
         }
     }
}
policy {
     policy-statement LP {
         term rule1 {
             from {
                 neighbor: 172.16.2.12..172.16.2.12
             }
             then {
                 localpref: 300
             }
         }
     }
     policy-statement "static-to-bgp" {
         term rule1 {
             from {
                 protocol: "static"
             }
             to {
                 neighbor: 172.16.2.12..172.16.2.12
             }
             then {
                 accept {
                 }
             }
         }
     }
}
fea {
     unicast-forwarding4 {
         disable: false
     }
}
interfaces {
     restore-original-config-on-shutdown: false
     interface eth1 {
         disable: false
         discard: false
         description: "data interface"
         vif eth1 {
             disable: false
             address 172.16.2.11 {
                 prefix-length: 24
                 disable: false
             }
         }
     }
     interface eth2 {
         disable: false
         discard: false
         description: ""
         vif eth2 {
             disable: false
             address 172.16.5.11 {
                 prefix-length: 24
                 disable: false
             }
         }
     }
     interface eth3 {
         disable: false
         discard: false
         description: ""
         vif eth3 {
             disable: false
             address 172.16.141.200 {
                 prefix-length: 24
                 disable: false
             }
         }
     }
}


=========================================



From hantongs at gmail.com  Mon Nov 19 17:46:18 2007
From: hantongs at gmail.com (Hansi)
Date: Tue, 20 Nov 2007 09:46:18 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <200711191909.lAJJ94qk006093@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711182336r5ee30e8akc4a38c4fc543299e@mail.gmail.com>
	<200711191909.lAJJ94qk006093@possum.icir.org>
Message-ID: <2f9e317b0711191746h2f6f5d02r7fed65a929fc7ee@mail.gmail.com>

Hello Pavlin,

See inline response on your query.

On Nov 20, 2007 3:09 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> <DEL>
>
> > Appears though that the correct interface is sending out the ripng
> > packets. Although I am seeing a metric of 16 here which should not be
> > the case since its a connected network.
> >
> > I'm attaching a file of the output of the trace since its quite long
> > to paste here.
>
> The trace output shows that the FEA has correctly identified vr0 as
> the incoming interface for the RIPng packets:
>
> [ 2007/11/19 03:33:55 INFO xorp_fea XRL ] Resolving xrl:finder://ripng-77422bcc5c4f8cc6087ec1f71328cb21 at 127.0.0.1/socket6_user/0.1/recv_event?sockid:txt=00000\000-0000058a-0004a5e5-03c70000&if_name:txt=vr0&vif_name:txt=vr0&src_host:ipv6=fe80::215:f2ff:fe3d:ac91&src_port:u32=521&data:binary=%02%01%00%00%00%00%00%00%0\0%00%00%00%00%00%00%00%00%00%00%00%00%00%00%FF+%01%0E%C0@%00%BE%EF%00%00%00%00%00%00%00%00%00%00@%00+%01%0E%C1@%01%10%AF%00%00%00%00%00%00%00%00%00%00@%10+%01\%0E%C2@%02%FA%11%00%00%00%00%00%00%00%00%00%00@%00
>
> What is the output of the "show route table ipv6 unicast ripng"
> xorpsh command?


admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
2001:ec0:4000:beef::/64 [rip(120)/1]
                > to fe80::213:d4ff:fed8:6808 via sk0/sk0
2001:ec1:4001:10af::/64 [rip(120)/1]
                > to fe80::213:d4ff:fed8:6808 via sk0/sk0

This status output was taken from Router 2. Link-local address
fe80::213:d4ff:fed8:6808 is the vr0 interface of Router1. So I believe
it should be vr0 instead of the one shown above.

Output of show route table ipv6 unicast ripng from Router 1:

admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
2001:ec2:4002:fa11::/64 [rip(120)/1]
                > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0


Thanks,
Hansi
>
> I believe I have found the problem (RIPng doesn't send the interface
> information along with the route it sends to the RIB so the RIB
> mis-calculates the outgoing interface), but I'd like to cross-check
> this with the "show route" output.
>
> Thanks,
> Pavlin
>
>
>
>


From pavlin at icir.org  Wed Nov 21 02:40:04 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 21 Nov 2007 02:40:04 -0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Tue,
	20 Nov 2007 09:46:18 +0800."
	<2f9e317b0711191746h2f6f5d02r7fed65a929fc7ee@mail.gmail.com> 
Message-ID: <200711211040.lALAe4oJ050030@possum.icir.org>

> > What is the output of the "show route table ipv6 unicast ripng"
> > xorpsh command?
> 
> 
> admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
> 2001:ec0:4000:beef::/64 [rip(120)/1]
>                 > to fe80::213:d4ff:fed8:6808 via sk0/sk0
> 2001:ec1:4001:10af::/64 [rip(120)/1]
>                 > to fe80::213:d4ff:fed8:6808 via sk0/sk0
> 
> This status output was taken from Router 2. Link-local address
> fe80::213:d4ff:fed8:6808 is the vr0 interface of Router1. So I believe
> it should be vr0 instead of the one shown above.
> 
> Output of show route table ipv6 unicast ripng from Router 1:
> 
> admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
> 2001:ec2:4002:fa11::/64 [rip(120)/1]
>                 > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0
> 
> 
> Thanks,
> Hansi
> >
> > I believe I have found the problem (RIPng doesn't send the interface
> > information along with the route it sends to the RIB so the RIB
> > mis-calculates the outgoing interface), but I'd like to cross-check
> > this with the "show route" output.

Thank you for the info.
I just committed a fix to CVS. Please let me know whether the latest
code fixes the problem for you.

Thanks,
Pavlin


From hantongs at gmail.com  Wed Nov 21 22:31:43 2007
From: hantongs at gmail.com (Hansi)
Date: Thu, 22 Nov 2007 14:31:43 +0800
Subject: [Xorp-users] xorp RIPng
In-Reply-To: <200711211040.lALAe4oJ050030@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0711191746h2f6f5d02r7fed65a929fc7ee@mail.gmail.com>
	<200711211040.lALAe4oJ050030@possum.icir.org>
Message-ID: <2f9e317b0711212231k73aa248cg968b42b8948b1c24@mail.gmail.com>

Hello Pavlin,

Thank you for the fix and accomodating this concern. :) Everything's
working smoothly now.

Regards,
Hansi
On Nov 21, 2007 6:40 PM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > > What is the output of the "show route table ipv6 unicast ripng"
> > > xorpsh command?
> >
> >
> > admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
> > 2001:ec0:4000:beef::/64 [rip(120)/1]
> >                 > to fe80::213:d4ff:fed8:6808 via sk0/sk0
> > 2001:ec1:4001:10af::/64 [rip(120)/1]
> >                 > to fe80::213:d4ff:fed8:6808 via sk0/sk0
> >
> > This status output was taken from Router 2. Link-local address
> > fe80::213:d4ff:fed8:6808 is the vr0 interface of Router1. So I believe
> > it should be vr0 instead of the one shown above.
> >
> > Output of show route table ipv6 unicast ripng from Router 1:
> >
> > admin at demo_rtr.infoweapons.com> show route table ipv6 unicast ripng
> > 2001:ec2:4002:fa11::/64 [rip(120)/1]
> >                 > to fe80::215:f2ff:fe3d:ac91 via sk0/sk0
> >
> >
> > Thanks,
> > Hansi
> > >
> > > I believe I have found the problem (RIPng doesn't send the interface
> > > information along with the route it sends to the RIB so the RIB
> > > mis-calculates the outgoing interface), but I'd like to cross-check
> > > this with the "show route" output.
>
> Thank you for the info.
> I just committed a fix to CVS. Please let me know whether the latest
> code fixes the problem for you.
>
> Thanks,
> Pavlin
>


From fd2 at cs.rice.edu  Sun Nov 25 13:55:05 2007
From: fd2 at cs.rice.edu (Florin Dinu)
Date: Sun, 25 Nov 2007 15:55:05 -0600
Subject: [Xorp-users] Updates Received: 0,  Updates Sent: 0
Message-ID: <4749EF39.5010905@cs.rice.edu>

HI

I started using XORP a few days ago.
I installed it on a few machines and i would like to get them to 
communicate with each other.

For:  "show bgp peers detail" i get something like

 Peer ID: 10.1.1.3
  Peer State: ESTABLISHED
  Admin State: START
  Negotiated BGP Version: 4
  Peer AS Number: 65002
  Updates Received: 0,  Updates Sent: 0
  Messages Received: 49,  Messages Sent: 49
  Time since last received update: n/a
  Number of transitions to ESTABLISHED: 3
  Time since last entering ESTABLISHED state: 1247 seconds
  Retry Interval: 120 seconds
  Hold Time: 90 seconds,  Keep Alive Time: 30 seconds
  Configured Hold Time: 90 seconds,  Configured Keep Alive Time: 30 seconds
  Minimum AS Origination Interval: 0 seconds
  Minimum Route Advertisement Interval: 0 seconds
for each of them.

and when i type show bgp routes i don't get anything.
It seems the peers are not advertising anything although in the .boot 
files i have something like
        network4 10.1.12.0/24 {
            next-hop: 10.1.12.2
            unicast: true
            multicast: true
        }
and all peers are successfully connected.

What would be the cause of this?
Thank you
Florin


From fd2 at cs.rice.edu  Sun Nov 25 19:34:25 2007
From: fd2 at cs.rice.edu (Florin Dinu)
Date: Sun, 25 Nov 2007 21:34:25 -0600
Subject: [Xorp-users] Updates Received: 0,  Updates Sent: 0
In-Reply-To: <2FD3D323-9936-41D6-ADB3-29D5A785CE46@gmail.com>
References: <4749EF39.5010905@cs.rice.edu>
	<2FD3D323-9936-41D6-ADB3-29D5A785CE46@gmail.com>
Message-ID: <474A3EC1.5030608@cs.rice.edu>

Me bothering again :(

it still does not work..after changing some stuff stuff
So, basically there are no updates sent.I cannot see any of them with 
either tcpdump or traceoptions.Only keep alives are sent.
With show bgp peers detail i can see that all sessions are ESTABLISHED

In my boot file i have

        bgp-id: 10.1.6.2
        local-as: 65001

        peer 10.1.6.3 { 
            local-ip: 10.1.6.2
            as: 65003
            next-hop: 10.1.6.2
        }
        peer 10.1.3.3 {
            local-ip: 10.1.3.2      //another of this router's ips
            as: 65002
            next-hop: 10.1.3.2
        }
        network4 10.1.5.0/24 {
            next-hop: 10.1.5.2
            unicast: true
            multicast: true
        }
        network4 10.1.8.0/24 {
            next-hop: 10.1.8.3
            unicast: true
            multicast: true
        }

10.1.5.2 and 10.1.8.3 are both reachable (respond to pings ok)
Typing route i get
10.1.8.0        *               255.255.255.0   U     0      0        0 eth3
10.1.5.0        *               255.255.255.0   U     0      0        0 eth2
10.1.6.0        *               255.255.255.0   U     0      0        0 eth4
10.1.6.0        *               255.255.255.0   U     0      0        0 eth3
10.1.3.0        *               255.255.255.0   U     0      0        0 eth5
so here you can also see that those next-hops are connected.

I also wrote two policies ( one for import one for export) that only 
have a then clause that says accept.
It seems this way all routes received are matched.

Any ideas what am i missing?
Thank you
Florin


From atanu at ICSI.Berkeley.EDU  Mon Nov 26 10:57:46 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 26 Nov 2007 10:57:46 -0800
Subject: [Xorp-users] Updates Received: 0, Updates Sent: 0
In-Reply-To: Message from Florin Dinu <fd2@cs.rice.edu> 
	of "Sun, 25 Nov 2007 21:34:25 CST." <474A3EC1.5030608@cs.rice.edu> 
Message-ID: <40699.1196103466@tigger.icir.org>

Hi,

The network4 syntax was deprecated in release 1.2 when policy was introduced. 

The way to introduce a route is to configure static routes and then
export them to bgp, you will find information on how this should be done
in the policy section of the user manual.

   Atanu.

>>>>> "Florin" == Florin Dinu <fd2 at cs.rice.edu> writes:

    Florin> Me bothering again :(
    Florin> it still does not work..after changing some stuff stuff
    Florin> So, basically there are no updates sent.I cannot see any of them with 
    Florin> either tcpdump or traceoptions.Only keep alives are sent.
    Florin> With show bgp peers detail i can see that all sessions are ESTABLISHED

    Florin> In my boot file i have

    Florin> bgp-id: 10.1.6.2
    Florin> local-as: 65001

    Florin> peer 10.1.6.3 { 
    Florin> local-ip: 10.1.6.2
    Florin> as: 65003
    Florin> next-hop: 10.1.6.2
    Florin> }
    Florin> peer 10.1.3.3 {
    Florin> local-ip: 10.1.3.2      //another of this router's ips
    Florin> as: 65002
    Florin> next-hop: 10.1.3.2
    Florin> }
    Florin> network4 10.1.5.0/24 {
    Florin> next-hop: 10.1.5.2
    Florin> unicast: true
    Florin> multicast: true
    Florin> }
    Florin> network4 10.1.8.0/24 {
    Florin> next-hop: 10.1.8.3
    Florin> unicast: true
    Florin> multicast: true
    Florin> }

    Florin> 10.1.5.2 and 10.1.8.3 are both reachable (respond to pings ok)
    Florin> Typing route i get
    Florin> 10.1.8.0        *               255.255.255.0   U     0      0        0 eth3
    Florin> 10.1.5.0        *               255.255.255.0   U     0      0        0 eth2
    Florin> 10.1.6.0        *               255.255.255.0   U     0      0        0 eth4
    Florin> 10.1.6.0        *               255.255.255.0   U     0      0        0 eth3
    Florin> 10.1.3.0        *               255.255.255.0   U     0      0        0 eth5
    Florin> so here you can also see that those next-hops are connected.

    Florin> I also wrote two policies ( one for import one for export) that only 
    Florin> have a then clause that says accept.
    Florin> It seems this way all routes received are matched.

    Florin> Any ideas what am i missing?
    Florin> Thank you
    Florin> Florin

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


From rsuk at ucsc.edu  Mon Nov 26 20:01:38 2007
From: rsuk at ucsc.edu (Robert Joseph Suk)
Date: Mon, 26 Nov 2007 20:01:38 -0800
Subject: [Xorp-users] rip troubles
Message-ID: <web-11577454@email-prod-be-1.ucsc.edu>

Hello,
I'm new to xorp, and I'm trying to get a basic router up 
and running RIP, but I keep getting the following error:

[ 2007/11/26 19:23:44 WARNING xorp_fea 
XrlSocketServerTarget ] Handling method for 
socket4/0.1/send_from_multicast_if failed: XrlCmdError 102 
Command failed Network is unreachable
[ 2007/11/26 19:23:44  ERROR xorp_rip:1264 RIP +552 
port.cc port_io_send_completion ] Send failed

My boot config is below, and I'm running freebsd 6.2

interfaces{
         restore-original-config-on-shutdown: false
         interface xl0 {
                 description: "from 10.0.2"
                 disable: false
                 vif xl0 {
                         disable: false
                         address 10.0.2.33 {
                                 prefix-length: 24
                                 broadcast: 10.0.2.255
                                 disable: false
                         }
                 }
         }
         interface xl1 {
                 description: "to 10.0.3"
                 disable: false
                 vif xl1 {
                         disable: false
                         address 10.0.3.33 {
                                 prefix-length: 24
                                 broadcast: 10.0.3.255
                                 disable: false
                         }
                 }
         }
} /* </interfaces> */

fea{
         unicast-forwarding4 {
                 disable: false
         }

         unicast-forwarding6 {
                 disable: true
         }

         click {
                 disable: true  /*just for now*/
         }

} /* </fea> */
plumbing{
         mfea4 {
                 disable: true
         }
         mfea6{
                 disable: true
         }
}
policy {
         /*Describe connected routes for redistribution*/
         policy-statement connected {
                 term export {
                         from {
                                 protocol: "connected"
                         }
                 }
         }
}

protocols {
         rip {
                 export: "connected"

                 /*run on both interfaces*/
                 interface xl0 {
                         vif xl0 {
                                 address 10.0.2.33 {
                                         disable: false
                                 }
                         }
                 }
                 interface xl1 {
                         vif xl1 {
                                 address 10.0.3.33 {
                                         disable: false
                                 }
                         }
                 }
         } /* </rip> */
} /* </protocols>*/

No updates are being received at the neigoboring nodes. 
 any ideas where I went wrong?

-Robbie


From pavlin at icir.org  Tue Nov 27 12:43:17 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 27 Nov 2007 12:43:17 -0800
Subject: [Xorp-users] rip troubles
In-Reply-To: Message from "Robert Joseph Suk" <rsuk@ucsc.edu> of "Mon,
	26 Nov 2007 20:01:38 PST." <web-11577454@email-prod-be-1.ucsc.edu> 
Message-ID: <200711272043.lARKhH05051623@possum.icir.org>

Robert Joseph Suk <rsuk at ucsc.edu> wrote:

> Hello,
> I'm new to xorp, and I'm trying to get a basic router up 
> and running RIP, but I keep getting the following error:

What OS are you using? I guess it is FreeBSD.

Some (all?) FreeBSD versions have the questionable requirement that
you must have an entry in the unicast forwarding table that covers
the multicast address space if you want to transmit any multicast
packets. It doesn't matter what the entry is, it has to be there.

The simplest solution is to add a default 0.0.0.0/0 entry to the
kernel that points to somewhere. You could do it either by hand
before starting XORP, or as a static route inside XORP.

The alternative solution is to add by hand a 224.0.0.0/4 route
before starting XORP. E.g.:

route add 224.0.0.0/4 10.10.10.10

where 10.10.10.10 is an IP address that belongs to the same subnet
as one of your interfaces.

Hope that helps,
Pavlin

> [ 2007/11/26 19:23:44 WARNING xorp_fea 
> XrlSocketServerTarget ] Handling method for 
> socket4/0.1/send_from_multicast_if failed: XrlCmdError 102 
> Command failed Network is unreachable
> [ 2007/11/26 19:23:44  ERROR xorp_rip:1264 RIP +552 
> port.cc port_io_send_completion ] Send failed
> 
> My boot config is below, and I'm running freebsd 6.2
> 
> interfaces{
>          restore-original-config-on-shutdown: false
>          interface xl0 {
>                  description: "from 10.0.2"
>                  disable: false
>                  vif xl0 {
>                          disable: false
>                          address 10.0.2.33 {
>                                  prefix-length: 24
>                                  broadcast: 10.0.2.255
>                                  disable: false
>                          }
>                  }
>          }
>          interface xl1 {
>                  description: "to 10.0.3"
>                  disable: false
>                  vif xl1 {
>                          disable: false
>                          address 10.0.3.33 {
>                                  prefix-length: 24
>                                  broadcast: 10.0.3.255
>                                  disable: false
>                          }
>                  }
>          }
> } /* </interfaces> */
> 
> fea{
>          unicast-forwarding4 {
>                  disable: false
>          }
> 
>          unicast-forwarding6 {
>                  disable: true
>          }
> 
>          click {
>                  disable: true  /*just for now*/
>          }
> 
> } /* </fea> */
> plumbing{
>          mfea4 {
>                  disable: true
>          }
>          mfea6{
>                  disable: true
>          }
> }
> policy {
>          /*Describe connected routes for redistribution*/
>          policy-statement connected {
>                  term export {
>                          from {
>                                  protocol: "connected"
>                          }
>                  }
>          }
> }
> 
> protocols {
>          rip {
>                  export: "connected"
> 
>                  /*run on both interfaces*/
>                  interface xl0 {
>                          vif xl0 {
>                                  address 10.0.2.33 {
>                                          disable: false
>                                  }
>                          }
>                  }
>                  interface xl1 {
>                          vif xl1 {
>                                  address 10.0.3.33 {
>                                          disable: false
>                                  }
>                          }
>                  }
>          } /* </rip> */
> } /* </protocols>*/
> 
> No updates are being received at the neigoboring nodes. 
>  any ideas where I went wrong?
> 
> -Robbie
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From acarballeda at nextel.es  Wed Nov 28 03:25:23 2007
From: acarballeda at nextel.es (Angel CArballeda)
Date: Wed, 28 Nov 2007 12:25:23 +0100
Subject: [Xorp-users] Maximum number of interfaces
Message-ID: <00b201c831b1$5e4064f0$1ac12ed0$@es>

Hello,

 

We are using Xorp to provide multicast routing. All works fine with 10
interfaces (vif), but if we add a new interface this new interface doesn?t
work with multicast. The Xorp version is old (1.0)but before change the
version we want to know if there is a restriction in the maximum number of
interfaces?

 

Thanks

 

Angel Carballeda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071128/027d7299/attachment.html 

From a.greenhalgh at cs.ucl.ac.uk  Wed Nov 28 03:29:43 2007
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Wed, 28 Nov 2007 11:29:43 +0000
Subject: [Xorp-users] Maximum number of interfaces
In-Reply-To: <00b201c831b1$5e4064f0$1ac12ed0$@es>
References: <00b201c831b1$5e4064f0$1ac12ed0$@es>
Message-ID: <4769af410711280329y5a61bef9q72b9d8ca41d58a65@mail.gmail.com>

No, I don't think so. But you could easily try the livecd for the 1.4
release with the same config file but on a floppy. The cvs version
does include a number of enhancements though so you might want to try
that.

Adam

On 28/11/2007, Angel CArballeda <acarballeda at nextel.es> wrote:
>
>
>
>
> Hello,
>
>
>
> We are using Xorp to provide multicast routing. All works fine with 10
> interfaces (vif), but if we add a new interface this new interface doesn?t
> work with multicast. The Xorp version is old (1.0)but before change the
> version we want to know if there is a restriction in the maximum number of
> interfaces?
>
>
>
> Thanks
>
>
>
> Angel Carballeda
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>


From msrinivas at ceeyes.com  Wed Nov 28 03:38:25 2007
From: msrinivas at ceeyes.com (`Srinivasrao)
Date: Wed, 28 Nov 2007 17:08:25 +0530
Subject: [Xorp-users] compiling in vx works
Message-ID: <200711281150.lASBo7Q4012819@pork.ICSI.Berkeley.EDU>

Hell sirs,
 
can i compile xorp router in vxworks.
please suggest me.
 
with regards,
srinivas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071128/e11ff7c6/attachment.html 

From greearb at candelatech.com  Wed Nov 28 08:13:59 2007
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 28 Nov 2007 08:13:59 -0800
Subject: [Xorp-users] Maximum number of interfaces
In-Reply-To: <4769af410711280329y5a61bef9q72b9d8ca41d58a65@mail.gmail.com>
References: <00b201c831b1$5e4064f0$1ac12ed0$@es>
	<4769af410711280329y5a61bef9q72b9d8ca41d58a65@mail.gmail.com>
Message-ID: <474D93C7.6000802@candelatech.com>

Adam Greenhalgh wrote:
> No, I don't think so. But you could easily try the livecd for the 1.4
> release with the same config file but on a floppy. The cvs version
> does include a number of enhancements though so you might want to try
> that.
>   
Try this:

echo 2000 > /proc/sys/net/ipv4/igmp_max_msf
echo 2000 > /proc/sys/net/ipv4/igmp_max_memberships

Thanks,
Ben

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



From pavlin at icir.org  Wed Nov 28 10:47:15 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 28 Nov 2007 10:47:15 -0800
Subject: [Xorp-users] Maximum number of interfaces
In-Reply-To: Message from Ben Greear <greearb@candelatech.com> 
	of "Wed, 28 Nov 2007 08:13:59 PST." <474D93C7.6000802@candelatech.com> 
Message-ID: <200711281847.lASIlFnQ015610@possum.icir.org>

Ben Greear <greearb at candelatech.com> wrote:

> Adam Greenhalgh wrote:
> > No, I don't think so. But you could easily try the livecd for the 1.4
> > release with the same config file but on a floppy. The cvs version
> > does include a number of enhancements though so you might want to try
> > that.
> >   
> Try this:
> 
> echo 2000 > /proc/sys/net/ipv4/igmp_max_msf
> echo 2000 > /proc/sys/net/ipv4/igmp_max_memberships

The original question didn't specify the OS, so I should clarify
that the above commands are for Linux.

I believe that igmp_max_msf is the max. number of source filters (i.e.,
if you use source-specific multicast with IGMPv3) and is per
interface, hence it shouldn't have impact on the max. number of
interfaces.

The second limit however (igmp_max_memberships) is global (the
max. number of joined groups across all interfaces) and is the
primary reason that by default you can't start XORP on more than 10
interfaces. Its default value is 20, and the XORP multicast modules
will join 2-3 multicast groups per interface.

There are few more limiting factors that have impact on the
max. number of interfaces you can use. See the IGMP/MLD and PIM-SM
sections in the latest version of the XORP ERRATA document for
details:

http://xorpc.icir.org/cgi-bin/cvsweb.cgi/xorp/ERRATA

Regards,
Pavlin

P.S. I believe all *BSDs also have similar limits for the
max. number of joined multicast group. E.g., FreeBSD has
defined IP_MAX_MEMBERSHIPS (max. 20) per socket, but in the next
7.0 release it can be scaled dynamically (thanks to Bruce M. Simpson).


From dscher at mitre.org  Wed Nov 28 13:22:48 2007
From: dscher at mitre.org (Scher, Dave)
Date: Wed, 28 Nov 2007 16:22:48 -0500
Subject: [Xorp-users] Cross-Compilation PPC Architecture patches
Message-ID: <9472CDDE9370AF4C871D40FD2ADB92BC023B2D6C@IMCSRV1.MITRE.ORG>

I am trying to cross-compile xorp for a ppc platform.  The build notes
indicate that there may be a patch required to successfully
cross-compile; but I cannot find the patch in the release 1.4 archive.

 
Also without using the patch I received the following error when
building the CLI:
 
ld: normal_obj/getline.o: Relocations in generic ELF (EM:  20)
normal_obj/getline.o: could not read symbols: File in wrong format
 
I configured xorp using the following: 
./configure --host=powerpc-linux  --prefix=$CROSS_LOCATION/usr/include
--with-openssl=$CROSS_LOCATION/usr
 
The issue, I believe, is linking of cross arch. and native specific
objects.  Not sure if anyone has run into this specific issue.  Since I
have not yet applied the patch, I was wondering if this error is patch
specific.  
 
Any clues?
 
Thanks.
Dave Scher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071128/8541cf4b/attachment.html 

From fd2 at cs.rice.edu  Wed Nov 28 13:40:49 2007
From: fd2 at cs.rice.edu (Florin Dinu)
Date: Wed, 28 Nov 2007 15:40:49 -0600
Subject: [Xorp-users] configuration
Message-ID: <474DE061.5040907@cs.rice.edu>

Hello

Is it possible to do something like :
./xorpsh -c "configure delete interfaces interface eth2" ?
I want to do this from a java program.
The option there is to call exec with a string as a parameter so i need 
to do this in one shot.
However if I use the command above then xorpsh enters configure mode and 
then does nothing.It just awaits input.
Can this be done?

Thank you
Florin


From pavlin at icir.org  Wed Nov 28 13:41:49 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 28 Nov 2007 13:41:49 -0800
Subject: [Xorp-users] Cross-Compilation PPC Architecture patches
In-Reply-To: Message from "Scher, Dave" <dscher@mitre.org> of "Wed,
	28 Nov 2007 16:22:48 EST."
	<9472CDDE9370AF4C871D40FD2ADB92BC023B2D6C@IMCSRV1.MITRE.ORG> 
Message-ID: <200711282141.lASLfncw017743@possum.icir.org>

Scher, Dave <dscher at mitre.org> wrote:

> I am trying to cross-compile xorp for a ppc platform.  The build notes
> indicate that there may be a patch required to successfully
> cross-compile; but I cannot find the patch in the release 1.4 archive.
> 
>  
> Also without using the patch I received the following error when
> building the CLI:
>  
> ld: normal_obj/getline.o: Relocations in generic ELF (EM:  20)
> normal_obj/getline.o: could not read symbols: File in wrong format
>  
> I configured xorp using the following: 
> ./configure --host=powerpc-linux  --prefix=$CROSS_LOCATION/usr/include
> --with-openssl=$CROSS_LOCATION/usr
>  
> The issue, I believe, is linking of cross arch. and native specific
> objects.  Not sure if anyone has run into this specific issue.  Since I
> have not yet applied the patch, I was wondering if this error is patch
> specific.  
>  
> Any clues?

It looks like that the cli/libtecla library wasn't compiled with the
right compiler (or most likely the linker itself is the wrong one).

There are several environmental variables that should be set before
running ./configure. See file BUILD_NOTES (in the XORP top-level
directory), Section "3.8. Cross-compilation". Pay special attention
to step h) which describes the XORP cross-compilation environment.
Setting variable "LD" for example is needed to point to the right
cross-compilation linker.

Please let me know how it goes.

Regards,
Pavlin

P.S. Option "--prefix=..." when running ./configure is used to
specify the directory to install XORP. I doubt you want to install
it in the "$CROSS_LOCATION/usr/include" header directory.

P.P.S. Which cross-compilation patch are you referring to?
All patches mentioned in the "Cross-compilation" section refer to
installing the cross-compilation environment, and each patch itself
is included inline.


From pavlin at icir.org  Wed Nov 28 13:53:23 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 28 Nov 2007 13:53:23 -0800
Subject: [Xorp-users] configuration
In-Reply-To: Message from Florin Dinu <fd2@cs.rice.edu> 
	of "Wed, 28 Nov 2007 15:40:49 CST." <474DE061.5040907@cs.rice.edu> 
Message-ID: <200711282153.lASLrOrL017860@possum.icir.org>

Florin Dinu <fd2 at cs.rice.edu> wrote:

> Hello
> 
> Is it possible to do something like :
> ./xorpsh -c "configure delete interfaces interface eth2" ?
> I want to do this from a java program.
> The option there is to call exec with a string as a parameter so i need 
> to do this in one shot.
> However if I use the command above then xorpsh enters configure mode and 
> then does nothing.It just awaits input.
> Can this be done?

You need to specify each new command separately with another
-c "command". E.g.,

./xorpsh -c "configure" -c "delete interfaces interface eth2" -c "commit"

The alternative would be to have a file with those commands (one
command per new line), and then pipe it into xorpsh:
cat commands.txt | ./xorpsh

For testing purpuse try it first by hand from the command line and
once you get it working then run it inside your Java program.

Regards,
Pavlin


From greearb at candelatech.com  Wed Nov 28 14:08:08 2007
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 28 Nov 2007 14:08:08 -0800
Subject: [Xorp-users] configuration
In-Reply-To: <474DE061.5040907@cs.rice.edu>
References: <474DE061.5040907@cs.rice.edu>
Message-ID: <474DE6C8.8050705@candelatech.com>

Florin Dinu wrote:
> Hello
> 
> Is it possible to do something like :
> ./xorpsh -c "configure delete interfaces interface eth2" ?
> I want to do this from a java program.
> The option there is to call exec with a string as a parameter so i need 
> to do this in one shot.
> However if I use the command above then xorpsh enters configure mode and 
> then does nothing.It just awaits input.
> Can this be done?

In the latest code you can use -c multiple times to do multiple commands.
I'd try adding more cmds to do a commit and exit.

Ben


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


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


From pavlin at icir.org  Wed Nov 28 14:37:25 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 28 Nov 2007 14:37:25 -0800
Subject: [Xorp-users] configuration
In-Reply-To: Message from Ben Greear <greearb@candelatech.com> 
	of "Wed, 28 Nov 2007 14:08:08 PST." <474DE6C8.8050705@candelatech.com> 
Message-ID: <200711282237.lASMbPmL018268@possum.icir.org>

Ben Greear <greearb at candelatech.com> wrote:

> Florin Dinu wrote:
> > Hello
> > 
> > Is it possible to do something like :
> > ./xorpsh -c "configure delete interfaces interface eth2" ?
> > I want to do this from a java program.
> > The option there is to call exec with a string as a parameter so i need 
> > to do this in one shot.
> > However if I use the command above then xorpsh enters configure mode and 
> > then does nothing.It just awaits input.
> > Can this be done?
> 
> In the latest code you can use -c multiple times to do multiple commands.
> I'd try adding more cmds to do a commit and exit.

Ah, right, in my previous email on the subject I forgot to mention
that the multiple -c support is in the latest code in CVS, but is
not in Release 1.4:

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

Pavlin


From fd2 at cs.rice.edu  Wed Nov 28 15:17:12 2007
From: fd2 at cs.rice.edu (Florin Dinu)
Date: Wed, 28 Nov 2007 17:17:12 -0600
Subject: [Xorp-users] configuration
In-Reply-To: <200711282237.lASMbPmL018268@possum.icir.org>
References: <200711282237.lASMbPmL018268@possum.icir.org>
Message-ID: <474DF6F8.1050709@cs.rice.edu>

Thank you

I have downloaded the latest version.
But....how do i compile only the protocols i need?
For example I only need to use static routes and bgp.
Compilation takes 1 hour normally and uses a lot of disk space.
However, i have to do this remotely, on a machine that i cannot fully 
control.
It would be great if i could compile only the modules that i need.

Thank you
Florin

Pavlin Radoslavov wrote:
> Ben Greear <greearb at candelatech.com> wrote:
>
>   
>> Florin Dinu wrote:
>>     
>>> Hello
>>>
>>> Is it possible to do something like :
>>> ./xorpsh -c "configure delete interfaces interface eth2" ?
>>> I want to do this from a java program.
>>> The option there is to call exec with a string as a parameter so i need 
>>> to do this in one shot.
>>> However if I use the command above then xorpsh enters configure mode and 
>>> then does nothing.It just awaits input.
>>> Can this be done?
>>>       
>> In the latest code you can use -c multiple times to do multiple commands.
>> I'd try adding more cmds to do a commit and exit.
>>     
>
> Ah, right, in my previous email on the subject I forgot to mention
> that the multiple -c support is in the latest code in CVS, but is
> not in Release 1.4:
>
> http://www.xorp.org/cvs.html
>
> Pavlin
>
>   


From pavlin at icir.org  Wed Nov 28 15:32:50 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 28 Nov 2007 15:32:50 -0800
Subject: [Xorp-users] configuration
In-Reply-To: Message from Florin Dinu <fd2@cs.rice.edu> 
	of "Wed, 28 Nov 2007 17:17:12 CST." <474DF6F8.1050709@cs.rice.edu> 
Message-ID: <200711282332.lASNWodU018830@possum.icir.org>

> I have downloaded the latest version.
> But....how do i compile only the protocols i need?
> For example I only need to use static routes and bgp.
> Compilation takes 1 hour normally and uses a lot of disk space.
> However, i have to do this remotely, on a machine that i cannot fully 
> control.
> It would be great if i could compile only the modules that i need.

You have to do it by hand (a sort of).

First run ./configure as usual. After that have a look in the top
level Makefile.am file. It lists all directories and the order they
are visited. The first two sets (up to and including "rib") are
needed by practically all protocols (with few minor exceptions), so
they should always be compiled.
The rest of the directories contain various protocols and you can
select any of them without having to compile the rest (with the
exception of the rtrmgr which should always be compiled).

Hence, you need to write a script that does something like:

cd libxorp
gmake
cd ..
cd libcomm
gmake
cd ..
<more compilations>
cd bgp
gmake
cd ..


Below is a sample script that will compile the first three
directories. All you need to do is to change the value of DIRS to
include the rest of the directories that should be compiled:

#!/bin/sh

DIRS="libxorp libcomm libxipc"

for d in ${DIRS} ; do
    echo "Compiling ${d} ..."
    cd "${d}"
    gmake
    cd ..
done


Hope that helps,
Pavlin


From dscher at mitre.org  Thu Nov 29 08:01:59 2007
From: dscher at mitre.org (Scher, Dave)
Date: Thu, 29 Nov 2007 11:01:59 -0500
Subject: [Xorp-users] Cross-Compilation PPC Architecture patches
In-Reply-To: <200711282141.lASLfncw017743@possum.icir.org>
References: Message from "Scher, Dave" <dscher@mitre.org>    of "Wed,
	28 Nov 2007 16:22:48 EST."
	<9472CDDE9370AF4C871D40FD2ADB92BC023B2D6C@IMCSRV1.MITRE.ORG>
	<200711282141.lASLfncw017743@possum.icir.org>
Message-ID: <9472CDDE9370AF4C871D40FD2ADB92BC023B2E5F@IMCSRV1.MITRE.ORG>

Thanks for the heads up.  I rechecked out the --prefix and yes it means
something different than what I had previously thought.  I have removed
the --prefix incantation from the configure command line which now
looks something like this: 

./configure --host=$CROSS_ARCH
--with-openssl=/opt/embedded/tools/ppc_85xx/usr

I read section H and did the following.  I am not familiar with the
subtle differences between *export and *setenv, but for some reason the
setenv binary was not present on my system so I used the following:

Export CROSS_ARCH=powerpc-linux
Export CROSS_ROOT=/opt/embedded/tools/ppc_85xx/usr
Export CROSS_LINUX_ROOT=$CROSS_ROOT/$CROSS_ARCH
Export CC=$CROSS_ROOT/bin/$CROSS_ARCH-gcc
Export CXX=$CROSS_ROOT/bin/$CROSS_ARCH-g++
Export LD=$CROSS_ROOT/bin/$CROSS_ARCH-ld
Export RANLIB=$CROSS_ROOT/bin/$CROSS_ARCH-ranlib
Export NM=$CROSS_ROOT/bin/$CROSS_ARCH-nm

Getting farther into compilation, but I now have the following error:

Cc1plus: warnings being treated as errors
Yacc.yy_policy_backend_parser.cc:3 warning: 'yyrcsid' defined but not
used.

Perhaps there is a compiler flag that is only allowing for strict
compilation. 
I seem to have completed compilation of the cli/libtecla library; so
that's a plus.
When I checked the configuration script, it seemed to find the correct
tools without setting env. Var.
But after setting them, the libtecla library compiled.  

Any clue on the next error?

Thanks a lot.
Dave


-----Original Message-----
From: Pavlin Radoslavov [mailto:pavlin at icir.org] 
Sent: Wednesday, November 28, 2007 4:42 PM
To: Scher, Dave
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] Cross-Compilation PPC Architecture patches 

Scher, Dave <dscher at mitre.org> wrote:

> I am trying to cross-compile xorp for a ppc platform.  The build
notes
> indicate that there may be a patch required to successfully
> cross-compile; but I cannot find the patch in the release 1.4
archive.
> 
>  
> Also without using the patch I received the following error when
> building the CLI:
>  
> ld: normal_obj/getline.o: Relocations in generic ELF (EM:  20)
> normal_obj/getline.o: could not read symbols: File in wrong format
>  
> I configured xorp using the following: 
> ./configure --host=powerpc-linux
--prefix=$CROSS_LOCATION/usr/include
> --with-openssl=$CROSS_LOCATION/usr
>  
> The issue, I believe, is linking of cross arch. and native specific
> objects.  Not sure if anyone has run into this specific issue.  Since
I
> have not yet applied the patch, I was wondering if this error is
patch
> specific.  
>  
> Any clues?

It looks like that the cli/libtecla library wasn't compiled with the
right compiler (or most likely the linker itself is the wrong one).

There are several environmental variables that should be set before
running ./configure. See file BUILD_NOTES (in the XORP top-level
directory), Section "3.8. Cross-compilation". Pay special attention
to step h) which describes the XORP cross-compilation environment.
Setting variable "LD" for example is needed to point to the right
cross-compilation linker.

Please let me know how it goes.

Regards,
Pavlin

P.S. Option "--prefix=..." when running ./configure is used to
specify the directory to install XORP. I doubt you want to install
it in the "$CROSS_LOCATION/usr/include" header directory.

P.P.S. Which cross-compilation patch are you referring to?
All patches mentioned in the "Cross-compilation" section refer to
installing the cross-compilation environment, and each patch itself
is included inline.


From pavlin at icir.org  Thu Nov 29 09:19:45 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 29 Nov 2007 09:19:45 -0800
Subject: [Xorp-users] Cross-Compilation PPC Architecture patches
In-Reply-To: Message from "Scher, Dave" <dscher@mitre.org> of "Thu,
	29 Nov 2007 11:01:59 EST."
	<9472CDDE9370AF4C871D40FD2ADB92BC023B2E5F@IMCSRV1.MITRE.ORG> 
Message-ID: <200711291719.lATHJjnc058633@possum.icir.org>

Scher, Dave <dscher at mitre.org> wrote:

> Thanks for the heads up.  I rechecked out the --prefix and yes it means
> something different than what I had previously thought.  I have removed
> the --prefix incantation from the configure command line which now
> looks something like this: 
> 
> ./configure --host=$CROSS_ARCH
> --with-openssl=/opt/embedded/tools/ppc_85xx/usr
> 
> I read section H and did the following.  I am not familiar with the
> subtle differences between *export and *setenv, but for some reason the
> setenv binary was not present on my system so I used the following:
> 
> Export CROSS_ARCH=powerpc-linux
> Export CROSS_ROOT=/opt/embedded/tools/ppc_85xx/usr
> Export CROSS_LINUX_ROOT=$CROSS_ROOT/$CROSS_ARCH
> Export CC=$CROSS_ROOT/bin/$CROSS_ARCH-gcc
> Export CXX=$CROSS_ROOT/bin/$CROSS_ARCH-g++
> Export LD=$CROSS_ROOT/bin/$CROSS_ARCH-ld
> Export RANLIB=$CROSS_ROOT/bin/$CROSS_ARCH-ranlib
> Export NM=$CROSS_ROOT/bin/$CROSS_ARCH-nm

"setenv" is used in csh/tcsh to set environmental variable.

> Getting farther into compilation, but I now have the following error:
> 
> Cc1plus: warnings being treated as errors
> Yacc.yy_policy_backend_parser.cc:3 warning: 'yyrcsid' defined but not
> used.

Interesting. What cross-compiler (incl. version) are you using?
We are using a variety of gcc compilers, but none of them generates
warning on this particular line. Anyway, you can fix this by just
commenting-out this particular line. E.g., the first 4 lines in file
policy/yacc.yy_policy_parser.cc are:

#ifndef lint
static char const
yyrcsid[] = "$FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.28.2.1 2001/07/19 05:46:39 peter Exp $";
#endif

Just change the first line "#ifndef lint" to "#if 0".
If there are similar errors in some of the other yacc auto-generated
files, then use same solution for all of them.

> Perhaps there is a compiler flag that is only allowing for strict
> compilation.

Yes, there is such flag which is explicitly enabled in configure.in
(and the auto-generated configure and Makefiles), but removing it
there is going to be much more complicated for you: you need to
install the right version of the autotools/etc.

> I seem to have completed compilation of the cli/libtecla library; so
> that's a plus.
> When I checked the configuration script, it seemed to find the correct
> tools without setting env. Var.
> But after setting them, the libtecla library compiled.  
> 
> Any clue on the next error?

See above.

Thanks,
Pavlin


From MANJON at terra.es  Fri Nov 30 03:36:08 2007
From: MANJON at terra.es (MANJON at terra.es)
Date: Fri, 30 Nov 2007 12:36:08 +0100 (MET)
Subject: [Xorp-users] Performance test
Message-ID: <26442461.1196422568673.JavaMail.root@cps9>


Hi Pavlin

Is there any performance test running over xorp? what is the throughput of xorp? Have you got any specifications about it?

thanks in advance

Chema

 

 
		 TERRA 

-->

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071130/98f68f61/attachment.html 

From pavlin at icir.org  Fri Nov 30 10:23:19 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 30 Nov 2007 10:23:19 -0800
Subject: [Xorp-users] Performance test
In-Reply-To: Message from "MANJON@terra.es" <MANJON@terra.es> of "Fri,
	30 Nov 2007 12:36:08 +0100."
	<26442461.1196422568673.JavaMail.root@cps9> 
Message-ID: <200711301823.lAUINJ1K073629@possum.icir.org>

> Is there any performance test running over xorp? what is the throughput of xorp? Have you got any specifications about it?
> 
> thanks in advance
> 
> Chema

Chema,

Please clarify what kind of performance.
If you have forwarding performance in mind, this is defined by the
underlying system, because XORP is only the control plane.

Regards,
Pavlin


From greearb at candelatech.com  Fri Nov 30 10:46:49 2007
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 30 Nov 2007 10:46:49 -0800
Subject: [Xorp-users] Performance test
In-Reply-To: <26442461.1196422568673.JavaMail.root@cps9>
References: <26442461.1196422568673.JavaMail.root@cps9>
Message-ID: <47505A99.60405@candelatech.com>

MANJON at terra.es wrote:
> Hi Pavlin
> 
> Is there any performance test running over xorp? what is the throughput 
> of xorp? Have you got any specifications about it?

Xorp doesn't actually route packets..the OS does that, so the limitations
will be in the OS.  On Linux, at least, you can reach full 1Gbps traffic
with a small number of routes.  Huge numbers of routes may slow you down
a bit.

Ben

> 
> thanks in advance
> 
> Chema
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


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