From manjon at terra.es  Sat Dec  1 13:40:52 2007
From: manjon at terra.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Mart=EDn?=)
Date: Sat, 01 Dec 2007 22:40:52 +0100
Subject: [Xorp-users] Performance test
In-Reply-To: <200711301823.lAUINJ1K073629@possum.icir.org>
References: <200711301823.lAUINJ1K073629@possum.icir.org>
Message-ID: <4751D4E4.8020301@terra.es>

First al all, thank you for the answers

I am goint to do a data charge in a lab environment. The data will be 
multicast an unicast data flow.
Xorp is running on a Linux 2.4.25 kernel
I have different scenarios:
1. Static routing with xorp routing multicast (Pim-SM) being RP and not 
being RP. In the last case I will use bootstrap mechanism against two 
Nortel/Cisco routers.
2. OSPF routing (not xorp) and the same multicast environment.

My hardware is intel xeon 2.8 ghz 1 gb ram and a gigabit ethernet 
network card. This server is running a checkpoint firewall too.
In the first attempt the system crash ( crash = the source packets 
didn?t reach the destination machine) with 100.000 multicast packets 
flow. I am using 1.0 xorp version.

Be run grateful for your opinions and ideas

thanks in advance

Chema


Pavlin Radoslavov escribi?:
>> 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
>
> _______________________________________________
> 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 Dec  2 00:47:29 2007
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Sun, 2 Dec 2007 08:47:29 +0000
Subject: [Xorp-users] Performance test
In-Reply-To: <4751D4E4.8020301@terra.es>
References: <200711301823.lAUINJ1K073629@possum.icir.org>
	<4751D4E4.8020301@terra.es>
Message-ID: <4769af410712020047l7b1ebc7fn7779738fb8746b9a@mail.gmail.com>

I would recommend you upgrade your kernel version to one of the new
2.6 kernels as there have been improvements in the kernel since 2.4.25
.

adam

On 01/12/2007, Jos? Mar?a Mart?n <manjon at terra.es> wrote:
> First al all, thank you for the answers
>
> I am goint to do a data charge in a lab environment. The data will be
> multicast an unicast data flow.
> Xorp is running on a Linux 2.4.25 kernel
> I have different scenarios:
> 1. Static routing with xorp routing multicast (Pim-SM) being RP and not
> being RP. In the last case I will use bootstrap mechanism against two
> Nortel/Cisco routers.
> 2. OSPF routing (not xorp) and the same multicast environment.
>
> My hardware is intel xeon 2.8 ghz 1 gb ram and a gigabit ethernet
> network card. This server is running a checkpoint firewall too.
> In the first attempt the system crash ( crash = the source packets
> didn?t reach the destination machine) with 100.000 multicast packets
> flow. I am using 1.0 xorp version.
>
> Be run grateful for your opinions and ideas
>
> thanks in advance
>
> Chema
>
>
> Pavlin Radoslavov escribi?:
> >> 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
> >
> > _______________________________________________
> > 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 manjon at terra.es  Sun Dec  2 02:37:25 2007
From: manjon at terra.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Mart=EDn?=)
Date: Sun, 02 Dec 2007 11:37:25 +0100
Subject: [Xorp-users] Performance test
In-Reply-To: <4769af410712020047l7b1ebc7fn7779738fb8746b9a@mail.gmail.com>
References: <200711301823.lAUINJ1K073629@possum.icir.org>	
	<4751D4E4.8020301@terra.es>
	<4769af410712020047l7b1ebc7fn7779738fb8746b9a@mail.gmail.com>
Message-ID: <47528AE5.7040504@terra.es>

Adam, I know that but at this momment I can?t change my kernel version. 
I am using a commercial secured OS
based in Linux and the manufacturer has not update to 2.6 yet.

thanks a lot Adam

Chema


Adam Greenhalgh escribi?:
> I would recommend you upgrade your kernel version to one of the new
> 2.6 kernels as there have been improvements in the kernel since 2.4.25
> .
>
> adam
>
> On 01/12/2007, Jos? Mar?a Mart?n <manjon at terra.es> wrote:
>   
>> First al all, thank you for the answers
>>
>> I am goint to do a data charge in a lab environment. The data will be
>> multicast an unicast data flow.
>> Xorp is running on a Linux 2.4.25 kernel
>> I have different scenarios:
>> 1. Static routing with xorp routing multicast (Pim-SM) being RP and not
>> being RP. In the last case I will use bootstrap mechanism against two
>> Nortel/Cisco routers.
>> 2. OSPF routing (not xorp) and the same multicast environment.
>>
>> My hardware is intel xeon 2.8 ghz 1 gb ram and a gigabit ethernet
>> network card. This server is running a checkpoint firewall too.
>> In the first attempt the system crash ( crash = the source packets
>> didn?t reach the destination machine) with 100.000 multicast packets
>> flow. I am using 1.0 xorp version.
>>
>> Be run grateful for your opinions and ideas
>>
>> thanks in advance
>>
>> Chema
>>
>>
>> Pavlin Radoslavov escribi?:
>>     
>>>> 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
>>>
>>> _______________________________________________
>>> 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 pavlin at icir.org  Sun Dec  2 10:56:19 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sun, 02 Dec 2007 10:56:19 -0800
Subject: [Xorp-users] Performance test
In-Reply-To: Message from =?ISO-8859-1?Q?Jos=E9_Mar=EDa_Mart=EDn?=
	<manjon@terra.es> 
	of "Sun, 02 Dec 2007 11:37:25 +0100." <47528AE5.7040504@terra.es> 
Message-ID: <200712021856.lB2IuJY2029410@possum.icir.org>

Jos? Mar?a Mart?n <manjon at terra.es> wrote:

> Adam, I know that but at this momment I can?t change my kernel version. 
> I am using a commercial secured OS
> based in Linux and the manufacturer has not update to 2.6 yet.

You should try at least to upgrade XORP, because 1.0 is quite old.
The current version is 1.4, but you might want to use even the
latest code from CVS, because it contains a number of bug fixes:

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

>From your email it wasn't clear to me whether multicast worked for
low bandwidth data. If it didn't then probably there is some setup
problem that needs to be fixed first.
If it worked for low bandwidth, did you have 100% losses for high
bandwidth?
One thing you should be aware is that the PIM-SM DR (Designated
Router) on the sender side might be using PIM-SM Register
encapsulation to unicast the data to the RP (where it is
decapsulated to native multicast). This adds more processing
overhead, and could explain the losses. Though, the threshold for
switching to native multicast is configurable (at the RP and the
last-hop PIM-SM routers on the receiver side) so this is one thing
to check in your configuration.

In any case, before you start playing with the XORP configuration
I'd highly recommend that you update its version.

Regards,
Pavlin


> thanks a lot Adam
> 
> Chema
> 
> 
> Adam Greenhalgh escribi?:
> > I would recommend you upgrade your kernel version to one of the new
> > 2.6 kernels as there have been improvements in the kernel since 2.4.25
> > .
> >
> > adam
> >
> > On 01/12/2007, Jos? Mar?a Mart?n <manjon at terra.es> wrote:
> >   
> >> First al all, thank you for the answers
> >>
> >> I am goint to do a data charge in a lab environment. The data will be
> >> multicast an unicast data flow.
> >> Xorp is running on a Linux 2.4.25 kernel
> >> I have different scenarios:
> >> 1. Static routing with xorp routing multicast (Pim-SM) being RP and not
> >> being RP. In the last case I will use bootstrap mechanism against two
> >> Nortel/Cisco routers.
> >> 2. OSPF routing (not xorp) and the same multicast environment.
> >>
> >> My hardware is intel xeon 2.8 ghz 1 gb ram and a gigabit ethernet
> >> network card. This server is running a checkpoint firewall too.
> >> In the first attempt the system crash ( crash = the source packets
> >> didn?t reach the destination machine) with 100.000 multicast packets
> >> flow. I am using 1.0 xorp version.
> >>
> >> Be run grateful for your opinions and ideas
> >>
> >> thanks in advance
> >>
> >> Chema
> >>
> >>
> >> Pavlin Radoslavov escribi?:
> >>     
> >>>> 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
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >>     
> >
> >   
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From bbb999 at zerodistance.fi  Mon Dec  3 02:21:00 2007
From: bbb999 at zerodistance.fi (Arsi Antila)
Date: Mon, 3 Dec 2007 12:21:00 +0200
Subject: [Xorp-users] BGP crash
Message-ID: <20071203102100.GA12449@zerodistance.fi>

Is the following a known problem in XORP?

Note: this was shown to me by someone else. I didn't test this myself,
so some of the details may be incorrect.

XORP crashes when the same set of BGP routes is advertised from two
different routers connected to the same interface and the winning route
changes. Tested with VLANs, if-aliases and plain interfaces. Results do
not vary.


For example, configuration of the network is as follows:

- device under test (Linux/Debian, XORP) and five simulated routers 

- AS 1 is advertised to ports eth1 and eth2 

- AS 2 is advertised to ports eth1 and eth2 

- AS 3 is advertised to port eth3

- Policy rules so that AS 2 routes are not advertised to AS 1

BGP process dies when one of the routers in AS 2 goes down and then up
so that the primary route in AS 2 changes.


Regards,
A.A.


From atanu at ICSI.Berkeley.EDU  Mon Dec  3 09:24:31 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 03 Dec 2007 09:24:31 -0800
Subject: [Xorp-users] BGP crash
In-Reply-To: Message from bbb999@zerodistance.fi (Arsi Antila) of "Mon,
	03 Dec 2007 12:21:00 +0200." <20071203102100.GA12449@zerodistance.fi> 
Message-ID: <16495.1196702671@tigger.icir.org>

Hi,

We were not aware of this issue, which verison of XORP are you using?

   Atanu.

>>>>> "Arsi" == Arsi Antila <bbb999 at zerodistance.fi> writes:

    Arsi> Is the following a known problem in XORP?  Note: this was
    Arsi> shown to me by someone else. I didn't test this myself, so
    Arsi> some of the details may be incorrect.

    Arsi> XORP crashes when the same set of BGP routes is advertised
    Arsi> from two different routers connected to the same interface and
    Arsi> the winning route changes. Tested with VLANs, if-aliases and
    Arsi> plain interfaces. Results do not vary.

    Arsi> For example, configuration of the network is as follows:

    Arsi> - device under test (Linux/Debian, XORP) and five simulated
    Arsi> routers

    Arsi> - AS 1 is advertised to ports eth1 and eth2

    Arsi> - AS 2 is advertised to ports eth1 and eth2

    Arsi> - AS 3 is advertised to port eth3

    Arsi> - Policy rules so that AS 2 routes are not advertised to AS 1

    Arsi> BGP process dies when one of the routers in AS 2 goes down and
    Arsi> then up so that the primary route in AS 2 changes.

    Arsi> Regards, A.A.

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


From M.Handley at cs.ucl.ac.uk  Mon Dec  3 09:43:49 2007
From: M.Handley at cs.ucl.ac.uk (Mark Handley)
Date: Mon, 3 Dec 2007 17:43:49 +0000
Subject: [Xorp-users] BGP crash
In-Reply-To: <20071203102100.GA12449@zerodistance.fi>
References: <20071203102100.GA12449@zerodistance.fi>
Message-ID: <84a612dd0712030943h7e49dab3u6970b29ef1d19e91@mail.gmail.com>

Xorp should not crash; I don't think this is a known issue.  Can you
clarify - which Xorp process crashes?  The subject implies BGP, but I
just want to be sure.

Also I'm not clear on the scenario - BGP doesn't advertise ASs to
interfaces - it advertises them via BGP connections which are only
loosely connected to interfaces (if you choose an interface IP address
for the connection endpoint).  Do you mean the BGP has peering
configured using the local IP addresses of the three ethernets in your
scenario?

Which AS is the router that crashes in?

Your text says 5 routers, but I'm not sure where the 5th one is - the
minimum needed to implement something like you describe is 4 (One each
for AS1, AS2, AS3 and the router that crashes).  Where's the 5th one?

Also could you send the policy config you used to prevent route redistribution?

If we understood the scenario, we can build a test suite to tickle
this problem, but right now I don't really know how to do this.

 - Mark

On Dec 3, 2007 10:21 AM, Arsi Antila <bbb999 at zerodistance.fi> wrote:
> Is the following a known problem in XORP?
>
> Note: this was shown to me by someone else. I didn't test this myself,
> so some of the details may be incorrect.
>
> XORP crashes when the same set of BGP routes is advertised from two
> different routers connected to the same interface and the winning route
> changes. Tested with VLANs, if-aliases and plain interfaces. Results do
> not vary.
>
>
> For example, configuration of the network is as follows:
>
> - device under test (Linux/Debian, XORP) and five simulated routers
>
> - AS 1 is advertised to ports eth1 and eth2
>
> - AS 2 is advertised to ports eth1 and eth2
>
> - AS 3 is advertised to port eth3
>
> - Policy rules so that AS 2 routes are not advertised to AS 1
>
> BGP process dies when one of the routers in AS 2 goes down and then up
> so that the primary route in AS 2 changes.
>
>
> Regards,
> A.A.
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>


From bbb999 at zerodistance.fi  Mon Dec  3 23:37:00 2007
From: bbb999 at zerodistance.fi (Arsi Antila)
Date: Tue, 4 Dec 2007 09:37:00 +0200
Subject: [Xorp-users] BGP crash
In-Reply-To: <16495.1196702671@tigger.icir.org>
References: <20071203102100.GA12449@zerodistance.fi>
	<16495.1196702671@tigger.icir.org>
Message-ID: <20071204073700.GA16903@zerodistance.fi>

XORP version is 1.4.

Regards,
Arsi


On Mon, Dec 03, 2007 at 09:24:31AM -0800, Atanu Ghosh wrote:
> Hi,
> 
> We were not aware of this issue, which verison of XORP are you using?
> 
>    Atanu.
> 
> >>>>> "Arsi" == Arsi Antila <bbb999 at zerodistance.fi> writes:
> 
>     Arsi> Is the following a known problem in XORP?  Note: this was
>     Arsi> shown to me by someone else. I didn't test this myself, so
>     Arsi> some of the details may be incorrect.
> 
>     Arsi> XORP crashes when the same set of BGP routes is advertised
>     Arsi> from two different routers connected to the same interface and
>     Arsi> the winning route changes. Tested with VLANs, if-aliases and
>     Arsi> plain interfaces. Results do not vary.
> 
>     Arsi> For example, configuration of the network is as follows:
> 
>     Arsi> - device under test (Linux/Debian, XORP) and five simulated
>     Arsi> routers
> 
>     Arsi> - AS 1 is advertised to ports eth1 and eth2
> 
>     Arsi> - AS 2 is advertised to ports eth1 and eth2
> 
>     Arsi> - AS 3 is advertised to port eth3
> 
>     Arsi> - Policy rules so that AS 2 routes are not advertised to AS 1
> 
>     Arsi> BGP process dies when one of the routers in AS 2 goes down and
>     Arsi> then up so that the primary route in AS 2 changes.
> 
>     Arsi> Regards, A.A.
> 
>     Arsi> _______________________________________________ Xorp-users
>     Arsi> mailing list Xorp-users at xorp.org
>     Arsi> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From hantongs at gmail.com  Tue Dec  4 00:09:58 2007
From: hantongs at gmail.com (Hansi)
Date: Tue, 4 Dec 2007 16:09:58 +0800
Subject: [Xorp-users] Problem in IPv6 SSM Multicast
Message-ID: <2f9e317b0712040009s4f376c30t97f893955746fb11@mail.gmail.com>

Hello All,

I'm currently exploring ipv6 multicast specifically pim-ssm. The network
topology setup I have is shown below:

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



Details:

Source
OS: FreeBSD 6.2
Streaming Server: vlc-0.8.6_c
sis1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet6 fe80::200:24ff:fec4:3235%sis1 prefixlen 64 scopeid 0x2
        inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
        inet6 2001:ec2:4002:fa11:200:24ff:fec4:3235 prefixlen 64 autoconf
        ether 00:00:24:c4:32:35
        media: Ethernet autoselect (100baseTX <full-duplex>)

Router 1
OS: FreeBSD 6.2
sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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

Router 2
OS: FreeBSD 6.2
sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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

Client
OS: Linux Ubuntu Fiesty Fawn 7.04  2.6.20-16-generic
Streaming Client: vlc-0.8.6_c
eth0      Link encap:Ethernet  HWaddr 00:19:5B:2F:14:68
          inet addr:172.16.0.2  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: 2001:ec1:4001:10af:219:5bff:fe2f:1468/64 Scope:Global
          inet6 addr: fe80::219:5bff:fe2f:1468/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:71141 errors:0 dropped:0 overruns:0 frame:0
          TX packets:103425 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6304908 (6.0 MiB)  TX bytes:137947821 (131.5 MiB)
          Interrupt:17


The problem is that I can't seem to recieve multicast streams from the
streaming server. :( I haven't encountered issues w/ regards to ipv4 ssm
multicast. The syntax used for the vlc streaming server is: vlc -vvv
video.xyz - -ipv6 - -sout udp:[ff3e::1234] - -ttl 12. I also tried placing a
backslash (\) character before each bracket but to no avail.  I configured
the client through vlc's graphical interface with
udp://[2001:ec2:4002:fa11:200:24ff:fec4:3235]@[ff3e::1234].
What I came to notice though is that there are no "Join" messages sent out
from the client side to indicate that it intends to join a channel, in this
case (2001:ec2:4002:fa11:200:24ff:fec4:3235, ff3e::1234). I suspect that the
it could be the client not initiating any "join" activity to a multicast
group although I can't also rule out that I overlooked something in my XORP
configuration file. I would appreciate if someone could lend me a hand here.

Attached is my xorp config file.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071204/a4b7c284/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorpcfg.txt
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071204/a4b7c284/attachment.txt 

From pavlin at icir.org  Tue Dec  4 01:00:46 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 04 Dec 2007 01:00:46 -0800
Subject: [Xorp-users] Problem in IPv6 SSM Multicast
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Tue,
	04 Dec 2007 16:09:58 +0800."
	<2f9e317b0712040009s4f376c30t97f893955746fb11@mail.gmail.com> 
Message-ID: <200712040900.lB490k9p050955@possum.icir.org>

Router 1 is missing the "mld" configuration.

After you add it, please send the output of the following commands
when running them on the router directly connected to the receiver:

show mld interface
show mld interface address
show mld group

Also, what do you mean by:
"there are no "Join" messages sent out from the client side"

Do you mean that the client/receiver host didn't send MLDv2 Join, or
that the Router connected to it didn't send PIM-SSM Join toward the
sender?

Regards,
Pavlin

Hansi <hantongs at gmail.com> wrote:

> Hello All,
> 
> I'm currently exploring ipv6 multicast specifically pim-ssm. The network
> topology setup I have is shown below:
> 
>             +----------+                     +----------+
>             | Source/  +---------------------+          |
>             | Sender   |                sk0  | Router 1 |
>             +----------+                     +-----+----+
>                                                    | vr0
>                                                    |
>                                                    |
>                                                    |
>                                                    |
>                                                    |
>                                                    | vr0
>             +----------+                     +-----+----+
>             | Client/  +---------------------+          |
>             | Receiver |                sk0  | Router 2 |
>             +----------+                     +----------+
> 
> 
> 
> Details:
> 
> Source
> OS: FreeBSD 6.2
> Streaming Server: vlc-0.8.6_c
> sis1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         options=8<VLAN_MTU>
>         inet6 fe80::200:24ff:fec4:3235%sis1 prefixlen 64 scopeid 0x2
>         inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
>         inet6 2001:ec2:4002:fa11:200:24ff:fec4:3235 prefixlen 64 autoconf
>         ether 00:00:24:c4:32:35
>         media: Ethernet autoselect (100baseTX <full-duplex>)
> 
> Router 1
> OS: FreeBSD 6.2
> sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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
> 
> Router 2
> OS: FreeBSD 6.2
> sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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
> 
> Client
> OS: Linux Ubuntu Fiesty Fawn 7.04  2.6.20-16-generic
> Streaming Client: vlc-0.8.6_c
> eth0      Link encap:Ethernet  HWaddr 00:19:5B:2F:14:68
>           inet addr:172.16.0.2  Bcast:172.16.255.255  Mask:255.255.0.0
>           inet6 addr: 2001:ec1:4001:10af:219:5bff:fe2f:1468/64 Scope:Global
>           inet6 addr: fe80::219:5bff:fe2f:1468/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:71141 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:103425 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:6304908 (6.0 MiB)  TX bytes:137947821 (131.5 MiB)
>           Interrupt:17
> 
> 
> The problem is that I can't seem to recieve multicast streams from the
> streaming server. :( I haven't encountered issues w/ regards to ipv4 ssm
> multicast. The syntax used for the vlc streaming server is: vlc -vvv
> video.xyz - -ipv6 - -sout udp:[ff3e::1234] - -ttl 12. I also tried placing a
> backslash (\) character before each bracket but to no avail.  I configured
> the client through vlc's graphical interface with
> udp://[2001:ec2:4002:fa11:200:24ff:fec4:3235]@[ff3e::1234].
> What I came to notice though is that there are no "Join" messages sent out
> from the client side to indicate that it intends to join a channel, in this
> case (2001:ec2:4002:fa11:200:24ff:fec4:3235, ff3e::1234). I suspect that the
> it could be the client not initiating any "join" activity to a multicast
> group although I can't also rule out that I overlooked something in my XORP
> configuration file. I would appreciate if someone could lend me a hand here.
> 
> Attached is my xorp config file.
> 
> Thanks.
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From hantongs at gmail.com  Tue Dec  4 01:37:14 2007
From: hantongs at gmail.com (Hansi)
Date: Tue, 4 Dec 2007 17:37:14 +0800
Subject: [Xorp-users] Fwd:  Problem in IPv6 SSM Multicast
In-Reply-To: <2f9e317b0712040130w30f1a1bck498d8dcc2e59f29c@mail.gmail.com>
References: <hantongs@gmail.com>
	<2f9e317b0712040009s4f376c30t97f893955746fb11@mail.gmail.com>
	<200712040900.lB490k9p050955@possum.icir.org>
	<2f9e317b0712040130w30f1a1bck498d8dcc2e59f29c@mail.gmail.com>
Message-ID: <2f9e317b0712040137t1dad7c59v6f456127b6ed3ad7@mail.gmail.com>

copying the mail list. :)

Hello Pavlin,

Thank you for the quick response. I intentionally did not add the mld
configuration in Router 1 specifically because my understanding on the MLD
as well as the IGMP protocol is that both are only intended for multicast
routers to  receivers communication. Please don't hesitate to correct me if
I'm wrong.

After adding MLD to the router1 xorp configuration:

admin at demo_rtr1> show mld interface
Interface    State    Querier         Timeout Version Groups
sk0          UP       fe80::219:5bff:fe2f:146a    None       2      8
vr0          DISABLED fe80::215:f2ff:fe3d:ac91    None       1      0

Furthermore, I also happen to see these logs in stdout:

[ 2007/12/04 05:26:47 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
packet from ::1 to ::1 pif_index 4: no vif found
[ 2007/12/04 05:26:47 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
packet from ::1 to ::1 pif_index 4: no vif found
[ 2007/12/04 05:26:47 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
packet from ::1 to ::1 pif_index 4: no vif found
[ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
packet from ::1 to ::1 pif_index 4: no vif found
[ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
packet from ::1 to ::1 pif_index 4: no vif found
[ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
packet from ::1 to ::1 pif_index 4: no vif found
[ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
packet from ::1 to ::1 pif_index 4: no vif found
[ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
packet from ::1 to ::1 pif_index 4: no vif found
[ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
packet from ::1 to ::1 pif_index 4: no vif found

On Dec 4, 2007 5:00 PM, Pavlin Radoslavov <pavlin at icir.org> wrote:

> Router 1 is missing the "mld" configuration.
>
> After you add it, please send the output of the following commands
> when running them on the router directly connected to the receiver:
>
> show mld interface


Interface    State    Querier         Timeout Version Groups
sk0          UP       fe80::219:5bff:fe85:cfc7    None       2      7
vr0          DISABLED fe80::213:d4ff:fed8:6808    None       1      0

>
> show mld interface address


Interface    PrimaryAddr     SecondaryAddr
sk0          fe80::219:5bff:fe85:cfc7 2001:ec1:4001:10af::1
vr0          fe80::213:d4ff:fed8:6808 2001:ec0:4000:beef::1

>
> show mld group


Interface    Group           Source          LastReported Timeout V State
sk0          ff02::2         ::              fe80::219:5bff:fe85:cfc7
243 1     E
sk0          ff02::d         ::              fe80::219:5bff:fe85:cfc7
243 1     E
sk0          ff02::16        ::              fe80::219:5bff:fe85:cfc7
243 1     E
sk0          ff02::1:ff00:1  ::              fe80::219:5bff:fe85:cfc7
243 1     E
sk0          ff02::1:ff2f:1468 ::              fe80::219:5bff:fe2f:1468
248 2     E
sk0          ff02::1:ff85:cfc7 ::              fe80::219:5bff:fe85:cfc7
243 1     E
sk0          ff02::2:15ba:6cf7 ::              fe80::219:5bff:fe85:cfc7
243 1     E

>
>
> Also, what do you mean by:
> "there are no "Join" messages sent out from the client side"
>
> Do you mean that the client/receiver host didn't send MLDv2 Join, or
> that the Router connected to it didn't send PIM-SSM Join toward the
> sender?
>

I was referring to the client/receiver host not sending an MLDv2 Join (upon
entering the (S,G) parameters and pressing OK) to the upstream router
connected to it.

>
> Regards,
> Pavlin
>
> Hansi < hantongs at gmail.com> wrote:
>
> > Hello All,
> >
> > I'm currently exploring ipv6 multicast specifically pim-ssm. The network
> > topology setup I have is shown below:
> >
> >             +----------+                     +----------+
> >             | Source/  +---------------------+          |
> >             | Sender   |                sk0  | Router 1 |
> >             +----------+                     +-----+----+
> >                                                    | vr0
> >                                                    |
> >                                                    |
> >                                                    |
> >                                                    |
> >                                                    |
> >                                                    | vr0
> >             +----------+                     +-----+----+
> >             | Client/  +---------------------+          |
> >             | Receiver |                sk0  | Router 2 |
> >             +----------+                     +----------+
> >
> >
> >
> > Details:
> >
> > Source
> > OS: FreeBSD 6.2
> > Streaming Server: vlc-0.8.6_c
> > sis1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >         options=8<VLAN_MTU>
> >         inet6 fe80::200:24ff:fec4:3235%sis1 prefixlen 64 scopeid 0x2
> >         inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
> >         inet6 2001:ec2:4002:fa11:200:24ff:fec4:3235 prefixlen 64
> autoconf
> >         ether 00:00:24:c4:32:35
> >         media: Ethernet autoselect (100baseTX <full-duplex>)
> >
> > Router 1
> > OS: FreeBSD 6.2
> > sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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
> >
> > Router 2
> > OS: FreeBSD 6.2
> > sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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
> >
> > Client
> > OS: Linux Ubuntu Fiesty Fawn 7.04  2.6.20-16-generic
> > Streaming Client: vlc-0.8.6_c
> > eth0      Link encap:Ethernet  HWaddr 00:19:5B:2F:14:68
> >           inet addr:172.16.0.2  Bcast:172.16.255.255  Mask:255.255.0.0
> >           inet6 addr: 2001:ec1:4001:10af:219:5bff:fe2f:1468/64
> Scope:Global
> >           inet6 addr: fe80::219:5bff:fe2f:1468/64 Scope:Link
> >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >           RX packets:71141 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:103425 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:1000
> >           RX bytes:6304908 ( 6.0 MiB)  TX bytes:137947821 (131.5 MiB)
> >           Interrupt:17
> >
> >
> > The problem is that I can't seem to recieve multicast streams from the
> > streaming server. :( I haven't encountered issues w/ regards to ipv4 ssm
>
> > multicast. The syntax used for the vlc streaming server is: vlc -vvv
> > video.xyz - -ipv6 - -sout udp:[ff3e::1234] - -ttl 12. I also tried
> placing a
> > backslash (\) character before each bracket but to no avail.  I
> configured
> > the client through vlc's graphical interface with
> > udp://[2001:ec2:4002:fa11:200:24ff:fec4:3235]@[ff3e::1234].
> > What I came to notice though is that there are no "Join" messages sent
> out
> > from the client side to indicate that it intends to join a channel, in
> this
> > case (2001:ec2:4002:fa11:200:24ff:fec4:3235, ff3e::1234). I suspect that
> the
> > it could be the client not initiating any "join" activity to a multicast
>
> > group although I can't also rule out that I overlooked something in my
> XORP
> > configuration file. I would appreciate if someone could lend me a hand
> here.
> >
> > Attached is my xorp config file.
> >
> > Thanks.
> > _______________________________________________
> > Xorp-users mailing list
> > Xorp-users at xorp.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071204/312e5079/attachment.html 

From pavlin at icir.org  Tue Dec  4 02:05:08 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 04 Dec 2007 02:05:08 -0800
Subject: [Xorp-users] Fwd: Problem in IPv6 SSM Multicast
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Tue,
	04 Dec 2007 17:37:14 +0800."
	<2f9e317b0712040137t1dad7c59v6f456127b6ed3ad7@mail.gmail.com> 
Message-ID: <200712041005.lB4A58XI051653@possum.icir.org>

> Thank you for the quick response. I intentionally did not add the mld
> configuration in Router 1 specifically because my understanding on the MLD
> as well as the IGMP protocol is that both are only intended for multicast
> routers to  receivers communication. Please don't hesitate to correct me if
> I'm wrong.

Yes, you are correct that IGMP and MLD are needed only on the router
with directly connected receivers.
I mentioned the missing mld just to make sure that you are aware of
it.

> After adding MLD to the router1 xorp configuration:
> 
> admin at demo_rtr1> show mld interface
> Interface    State    Querier         Timeout Version Groups
> sk0          UP       fe80::219:5bff:fe2f:146a    None       2      8
> vr0          DISABLED fe80::215:f2ff:fe3d:ac91    None       1      0

Looks good.

> Furthermore, I also happen to see these logs in stdout:
> 
> [ 2007/12/04 05:26:47 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
> packet from ::1 to ::1 pif_index 4: no vif found
> [ 2007/12/04 05:26:47 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
> packet from ::1 to ::1 pif_index 4: no vif found
> [ 2007/12/04 05:26:47 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
> packet from ::1 to ::1 pif_index 4: no vif found
> [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
> packet from ::1 to ::1 pif_index 4: no vif found
> [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
> packet from ::1 to ::1 pif_index 4: no vif found
> [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
> packet from ::1 to ::1 pif_index 4: no vif found
> [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
> packet from ::1 to ::1 pif_index 4: no vif found
> [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
> packet from ::1 to ::1 pif_index 4: no vif found
> [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed: RX
> packet from ::1 to ::1 pif_index 4: no vif found

That's interesting. It looks like some IPv6 traffic is received on the
loopback interface. This might be harmless, but it could be a side
effect of some other problem. If you run tcpdump on the lo0
interface, can you figure out what kind of traffic is that.

> On Dec 4, 2007 5:00 PM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> 
> > Router 1 is missing the "mld" configuration.
> >
> > After you add it, please send the output of the following commands
> > when running them on the router directly connected to the receiver:
> >
> > show mld interface
> 
> 
> Interface    State    Querier         Timeout Version Groups
> sk0          UP       fe80::219:5bff:fe85:cfc7    None       2      7
> vr0          DISABLED fe80::213:d4ff:fed8:6808    None       1      0

Looks good.

> >
> > show mld interface address
> 
> 
> Interface    PrimaryAddr     SecondaryAddr
> sk0          fe80::219:5bff:fe85:cfc7 2001:ec1:4001:10af::1
> vr0          fe80::213:d4ff:fed8:6808 2001:ec0:4000:beef::1

Looks good.

> >
> > show mld group
> 
> 
> Interface    Group           Source          LastReported Timeout V State
> sk0          ff02::2         ::              fe80::219:5bff:fe85:cfc7
> 243 1     E
> sk0          ff02::d         ::              fe80::219:5bff:fe85:cfc7
> 243 1     E
> sk0          ff02::16        ::              fe80::219:5bff:fe85:cfc7
> 243 1     E
> sk0          ff02::1:ff00:1  ::              fe80::219:5bff:fe85:cfc7
> 243 1     E
> sk0          ff02::1:ff2f:1468 ::              fe80::219:5bff:fe2f:1468
> 248 2     E
> sk0          ff02::1:ff85:cfc7 ::              fe80::219:5bff:fe85:cfc7
> 243 1     E
> sk0          ff02::2:15ba:6cf7 ::              fe80::219:5bff:fe85:cfc7
> 243 1     E

It doesn't seem that the client/receiver with IPv6 address
2001:ec2:4002:fa11:200:24ff:fec4:3235 has joined group ff3e::1234.
So your guess in your original email is correct: there is something
wrong with the receiver so it hasn't joined the multicast group.
Could you run tcpdump to capture all ICMPv6 (incl. MLD) traffic and
confirm that XORP is sending the periodic query messages, but the
receiver itself never sends MLDv2 Join messages.

BTW, what about MLDv1 Join messages? If you configure the client to
join some (*,G) multicast group does it initiate MLDv1 Join?

In any case, please make sure you don't have firewall rules that
stop ICMPv6 (the protocol number used by MLD).
You should check both the receiver and the router connected to it.

Regards,
Pavlin


> >
> >
> > Also, what do you mean by:
> > "there are no "Join" messages sent out from the client side"
> >
> > Do you mean that the client/receiver host didn't send MLDv2 Join, or
> > that the Router connected to it didn't send PIM-SSM Join toward the
> > sender?
> >
> 
> I was referring to the client/receiver host not sending an MLDv2 Join (upon
> entering the (S,G) parameters and pressing OK) to the upstream router
> connected to it.
> 
> >
> > Regards,
> > Pavlin
> >
> > Hansi < hantongs at gmail.com> wrote:
> >
> > > Hello All,
> > >
> > > I'm currently exploring ipv6 multicast specifically pim-ssm. The network
> > > topology setup I have is shown below:
> > >
> > >             +----------+                     +----------+
> > >             | Source/  +---------------------+          |
> > >             | Sender   |                sk0  | Router 1 |
> > >             +----------+                     +-----+----+
> > >                                                    | vr0
> > >                                                    |
> > >                                                    |
> > >                                                    |
> > >                                                    |
> > >                                                    |
> > >                                                    | vr0
> > >             +----------+                     +-----+----+
> > >             | Client/  +---------------------+          |
> > >             | Receiver |                sk0  | Router 2 |
> > >             +----------+                     +----------+
> > >
> > >
> > >
> > > Details:
> > >
> > > Source
> > > OS: FreeBSD 6.2
> > > Streaming Server: vlc-0.8.6_c
> > > sis1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > >         options=8<VLAN_MTU>
> > >         inet6 fe80::200:24ff:fec4:3235%sis1 prefixlen 64 scopeid 0x2
> > >         inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
> > >         inet6 2001:ec2:4002:fa11:200:24ff:fec4:3235 prefixlen 64
> > autoconf
> > >         ether 00:00:24:c4:32:35
> > >         media: Ethernet autoselect (100baseTX <full-duplex>)
> > >
> > > Router 1
> > > OS: FreeBSD 6.2
> > > sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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
> > >
> > > Router 2
> > > OS: FreeBSD 6.2
> > > sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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
> > >
> > > Client
> > > OS: Linux Ubuntu Fiesty Fawn 7.04  2.6.20-16-generic
> > > Streaming Client: vlc-0.8.6_c
> > > eth0      Link encap:Ethernet  HWaddr 00:19:5B:2F:14:68
> > >           inet addr:172.16.0.2  Bcast:172.16.255.255  Mask:255.255.0.0
> > >           inet6 addr: 2001:ec1:4001:10af:219:5bff:fe2f:1468/64
> > Scope:Global
> > >           inet6 addr: fe80::219:5bff:fe2f:1468/64 Scope:Link
> > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> > >           RX packets:71141 errors:0 dropped:0 overruns:0 frame:0
> > >           TX packets:103425 errors:0 dropped:0 overruns:0 carrier:0
> > >           collisions:0 txqueuelen:1000
> > >           RX bytes:6304908 ( 6.0 MiB)  TX bytes:137947821 (131.5 MiB)
> > >           Interrupt:17
> > >
> > >
> > > The problem is that I can't seem to recieve multicast streams from the
> > > streaming server. :( I haven't encountered issues w/ regards to ipv4 ssm
> >
> > > multicast. The syntax used for the vlc streaming server is: vlc -vvv
> > > video.xyz - -ipv6 - -sout udp:[ff3e::1234] - -ttl 12. I also tried
> > placing a
> > > backslash (\) character before each bracket but to no avail.  I
> > configured
> > > the client through vlc's graphical interface with
> > > udp://[2001:ec2:4002:fa11:200:24ff:fec4:3235]@[ff3e::1234].
> > > What I came to notice though is that there are no "Join" messages sent
> > out
> > > from the client side to indicate that it intends to join a channel, in
> > this
> > > case (2001:ec2:4002:fa11:200:24ff:fec4:3235, ff3e::1234). I suspect that
> > the
> > > it could be the client not initiating any "join" activity to a multicast
> >
> > > group although I can't also rule out that I overlooked something in my
> > XORP
> > > configuration file. I would appreciate if someone could lend me a hand
> > here.
> > >
> > > Attached is my xorp config file.
> > >
> > > Thanks.
> > > _______________________________________________
> > > 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 awalton at wires3.net  Tue Dec  4 05:22:40 2007
From: awalton at wires3.net (Aidan Walton)
Date: Tue, 04 Dec 2007 13:22:40 +0000
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
Message-ID: <1196774560.3967.36.camel@bass.wires3.net>

Hi All,
I am using xorp in a production environment, admittedly a small one. I
operate a local WISP and xorp is running on my wireless nodes. I have a
very simple configuration and really I could probably get away with
static routing throughout the entire network, but I wanted to try xorp
and see just how stable it was. However as I expand the network I am
having second thoughts. It is not good at all when a network goes up in
smoke and I can't explain why or predict when and what the causes are.

The network has been in operation 24x7 for around 9 months. I am running
on a Linux kernel 2.6.18-4 and for the vast majority of the time I have
no issues. However now for the fourth time I see the same problem:

Suddenly the Linux kernel and the xorp rib become detached. Normally all
routes in the kernel match those that xorp is generating, receiving and
electing as active. I am running OSPF and the neighbour states remain
'full' throughout but if I am not mistaken I see ospf hellos only in one
direction (i.e nothing being transmitted from the router I suspect). The
lsdb of OSPF on the suspect and adjacent routers contain all the routes
but they are aging out slowly on the adjacent router. When I look at the
kernel routes those from OSPF have already vanished.

I can see the ospf process running on the offending router? and again I
can see the ospf lsdb intact and correct. When I restart xorp the system
recovers and the routes appear in the kernel again. I suspect a problem
with ospf. I tried enabling traceoptions on the ospf process, but in
fact I needed to restart all the xorp processes before this actually
became active. I now have this running so if/when it happens again I
might be able to offer some more information.

Does anyone have any experience of ospf begin unstable? any suggestions
how I might more effectively capture some logs from this event. I do not
see any options for logging the fea process. Is there anything I can
enable to help diagnose the issue?

Many thanks, and of course cheers for the code in the first place.
Aidan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071204/167fff1a/attachment.html 

From hantongs at gmail.com  Tue Dec  4 04:38:33 2007
From: hantongs at gmail.com (Hansi)
Date: Tue, 4 Dec 2007 20:38:33 +0800
Subject: [Xorp-users] Fwd:  Fwd: Problem in IPv6 SSM Multicast
In-Reply-To: <2f9e317b0712040438h637634fk2914a2c318212d93@mail.gmail.com>
References: <hantongs@gmail.com>
	<2f9e317b0712040137t1dad7c59v6f456127b6ed3ad7@mail.gmail.com>
	<200712041005.lB4A58XI051653@possum.icir.org>
	<2f9e317b0712040438h637634fk2914a2c318212d93@mail.gmail.com>
Message-ID: <2f9e317b0712040438r492183fxe0926d026aa55c90@mail.gmail.com>

cc'ng the mailing list.



On Dec 4, 2007 6:05 PM, Pavlin Radoslavov <pavlin at icir.org> wrote:

> > Thank you for the quick response. I intentionally did not add the mld
> > configuration in Router 1 specifically because my understanding on the
> MLD
> > as well as the IGMP protocol is that both are only intended for
> multicast
> > routers to  receivers communication. Please don't hesitate to correct me
> if
> > I'm wrong.
>
> Yes, you are correct that IGMP and MLD are needed only on the router
> with directly connected receivers.
> I mentioned the missing mld just to make sure that you are aware of
> it.
>
> > After adding MLD to the router1 xorp configuration:
> >
> > admin at demo_rtr1> show mld interface
> > Interface    State    Querier         Timeout Version Groups
> > sk0          UP       fe80::219:5bff:fe2f:146a    None       2      8
> > vr0          DISABLED fe80::215:f2ff:fe3d:ac91    None       1      0
>
> Looks good.
>
> > Furthermore, I also happen to see these logs in stdout:
> >
> > [ 2007/12/04 05:26:47 WARNING xorp_fea FEA ] proto_socket_read() failed:
> RX
> > packet from ::1 to ::1 pif_index 4: no vif found
> > [ 2007/12/04 05:26:47 WARNING xorp_fea FEA ] proto_socket_read() failed:
> RX
> > packet from ::1 to ::1 pif_index 4: no vif found
> > [ 2007/12/04 05:26:47 WARNING xorp_fea FEA ] proto_socket_read() failed:
> RX
> > packet from ::1 to ::1 pif_index 4: no vif found
> > [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed:
> RX
> > packet from ::1 to ::1 pif_index 4: no vif found
> > [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed:
> RX
> > packet from ::1 to ::1 pif_index 4: no vif found
> > [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed:
> RX
> > packet from ::1 to ::1 pif_index 4: no vif found
> > [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed:
> RX
> > packet from ::1 to ::1 pif_index 4: no vif found
> > [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed:
> RX
> > packet from ::1 to ::1 pif_index 4: no vif found
> > [ 2007/12/04 05:28:39 WARNING xorp_fea FEA ] proto_socket_read() failed:
> RX
> > packet from ::1 to ::1 pif_index 4: no vif found
>
> That's interesting. It looks like some IPv6 traffic is received on the
> loopback interface. This might be harmless, but it could be a side
> effect of some other problem. If you run tcpdump on the lo0
> interface, can you figure out what kind of traffic is that.


 Yes, I concur. These are just harmless messages displayed by stdout and
generated everytime a process is opened. (I noticed that these messages are
logged by stdout everytime I open a terminal console or text editor etc.)

>
>
> > On Dec 4, 2007 5:00 PM, Pavlin Radoslavov < pavlin at icir.org> wrote:
> >
> > > Router 1 is missing the "mld" configuration.
> > >
> > > After you add it, please send the output of the following commands
> > > when running them on the router directly connected to the receiver:
> > >
> > > show mld interface
> >
> >
> > Interface    State    Querier         Timeout Version Groups
> > sk0          UP       fe80::219:5bff:fe85:cfc7    None       2      7
> > vr0          DISABLED fe80::213:d4ff:fed8:6808    None       1      0
>
> Looks good.
>
> > >
> > > show mld interface address
> >
> >
> > Interface    PrimaryAddr     SecondaryAddr
> > sk0          fe80::219:5bff:fe85:cfc7 2001:ec1:4001:10af::1
> > vr0          fe80::213:d4ff:fed8:6808 2001:ec0:4000:beef::1
>
> Looks good.
>
> > >
> > > show mld group
> >
> >
> > Interface    Group           Source          LastReported Timeout V
> State
> > sk0          ff02::2         ::              fe80::219:5bff:fe85:cfc7
> > 243 1     E
> > sk0          ff02::d         ::              fe80::219:5bff:fe85:cfc7
> > 243 1     E
> > sk0          ff02::16        ::              fe80::219:5bff:fe85:cfc7
> > 243 1     E
> > sk0          ff02::1:ff00:1  ::              fe80::219:5bff:fe85:cfc7
> > 243 1     E
> > sk0          ff02::1:ff2f:1468 ::              fe80::219:5bff:fe2f:1468
> > 248 2     E
> > sk0          ff02::1:ff85:cfc7 ::              fe80::219:5bff:fe85:cfc7
> > 243 1     E
> > sk0          ff02::2:15ba:6cf7 ::              fe80::219:5bff:fe85:cfc7
> > 243 1     E
>
> It doesn't seem that the client/receiver with IPv6 address
> 2001:ec2:4002:fa11:200:24ff:fec4:3235 has joined group ff3e::1234.


The ipv6 address 2001:ec2:4002:fa11:200:24ff
>
> :fec4:3235 is the address of the streaming server. :)
>

> So your guess in your original email is correct: there is something
> wrong with the receiver so it hasn't joined the multicast group.
> Could you run tcpdump to capture all ICMPv6 (incl. MLD) traffic and
> confirm that XORP is sending the periodic query messages, but the
> receiver itself never sends MLDv2 Join messages.


Here are the logs from tcpdump taken on the LAN side of the router (router
----- receiver)

20:23:17.081711 IP6 (hlim 1, next-header: PIM (103), length: 56)
fe80::219:5bff:fe85:cfc7 > ff02::d: PIMv2, length 56
        Hello, cksum 0x1028 (correct)
          Hold Time Option (1), length 2, Value: 1m45s
            0x0000:  0069
          LAN Prune Delay Option (2), length 4, Value:
            T-bit=0, LAN delay 500ms, Override interval 2500ms
            0x0000:  01f4 09c4
          DR Priority Option (19), length 4, Value: 1
            0x0000:  0000 0001
          Generation ID Option (20), length 4, Value: 0x7c4b9afe
            0x0000:  7c4b 9afe[|pim]

20:23:47.075081 IP6 (hlim 1, next-header: PIM (103), length: 56)
fe80::219:5bff:fe85:cfc7 > ff02::d: PIMv2, length 56
        Hello, cksum 0x1028 (correct)
          Hold Time Option (1), length 2, Value: 1m45s
            0x0000:  0069
          LAN Prune Delay Option (2), length 4, Value:
            T-bit=0, LAN delay 500ms, Override interval 2500ms
            0x0000:  01f4 09c4
          DR Priority Option (19), length 4, Value: 1
            0x0000:  0000 0001
          Generation ID Option (20), length 4, Value: 0x7c4b9afe
            0x0000:  7c4b 9afe[|pim]
20:24:17.076424 IP6 (hlim 1, next-header: PIM (103), length: 56)
fe80::219:5bff:fe85:cfc7 > ff02::d: PIMv2, length 56
        Hello, cksum 0x1028 (correct)
          Hold Time Option (1), length 2, Value: 1m45s
            0x0000:  0069
          LAN Prune Delay Option (2), length 4, Value:
            T-bit=0, LAN delay 500ms, Override interval 2500ms
            0x0000:  01f4 09c4
          DR Priority Option (19), length 4, Value: 1
            0x0000:  0000 0001
          Generation ID Option (20), length 4, Value: 0x7c4b9afe
            0x0000:  7c4b 9afe[|pim]
20:24:32.872230 IP6 (hlim 1, next-header: Options (0), length: 36)
fe80::219:5bff:fe85:cfc7 > ip6-allnodes: HBH (rtalert: 0x0000) (padn)[icmp6
sum ok] ICMP6, multicast listener query, length 28v2  [max resp delay=10000]
[gaddr :: robustness=2 qqi=125]
20:24:32.876596 IP6 (hlim 1, next-header: Options (0), length: 32)
fe80::219:5bff:fe85:cfc7 > ff02::16: HBH (padn)(rtalert: 0x0000) [icmp6 sum
ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
ff02::16
20:24:32.892588 IP6 (hlim 1, next-header: Options (0), length: 32)
fe80::219:5bff:fe85:cfc7 > ip6-allrouters: HBH (padn)(rtalert: 0x0000)
[icmp6 sum ok] ICMP6, multicast listener report, length 24max resp delay: 0
addr: ip6-allrouters
20:24:32.906594 IP6 (hlim 1, next-header: Options (0), length: 32)
fe80::219:5bff:fe85:cfc7 > ff02::d: HBH (padn)(rtalert: 0x0000) [icmp6 sum
ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
ff02::d
20:24:32.906613 IP6 (hlim 1, next-header: Options (0), length: 32)
fe80::219:5bff:fe85:cfc7 > ff02::1:ff00:1: HBH (padn)(rtalert: 0x0000)
[icmp6 sum ok] ICMP6, multicast listener report, length 24max resp delay: 0
addr: ff02::1:ff00:1
20:24:32.906634 IP6 (hlim 1, next-header: Options (0), length: 32)
fe80::219:5bff:fe85:cfc7 > ff02::2:15ba:6cf7: HBH (padn)(rtalert: 0x0000)
[icmp6 sum ok] ICMP6, multicast listener report, length 24max resp delay: 0
addr: ff02::2:15ba:6cf7
20:24:32.910605 IP6 (hlim 1, next-header: Options (0), length: 32)
fe80::219:5bff:fe85:cfc7 > ff02::1:ff85:cfc7: HBH (padn)(rtalert: 0x0000)
[icmp6 sum ok] ICMP6, multicast listener report, length 24max resp delay: 0
addr: ff02::1:ff85:cfc7
20:24:37.389295 IP6 (hlim 1, next-header: Options (0), length: 36)
fe80::219:5bff:fe2f:1468 > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum
ok] ICMP6, multicast listener report v2, length 28, 1 group record(s) [gaddr
ff02::1:ff2f:1468 is_ex { }]

Back when I was exploring ipv4 ssm, everytime I click either on the play or
stop button of the vlc client, I always see an IGMP join or prune message.
Shouldn't  it that it also applies to MLDv2? However, I'm not seeing any
here.


>
> BTW, what about MLDv1 Join messages? If you configure the client to
> join some (*,G) multicast group does it initiate MLDv1 Join?
>
My current setup is intended for PIM-SSM traffic. Can it also apply to PIM
SM considering the setup consist of only two routers?

>
> In any case, please make sure you don't have firewall rules that
> stop ICMPv6 (the protocol number used by MLD).
> You should check both the receiver and the router connected to it.


Yes, no firewall  process es are running  in the both router boxes. :)

>
>
> Regards,
> Pavlin
>


Thank you,
Hansi

>
>
> > >
> > >
> > > Also, what do you mean by:
> > > "there are no "Join" messages sent out from the client side"
> > >
> > > Do you mean that the client/receiver host didn't send MLDv2 Join, or
> > > that the Router connected to it didn't send PIM-SSM Join toward the
> > > sender?
> > >
> >
> > I was referring to the client/receiver host not sending an MLDv2 Join
> (upon
> > entering the (S,G) parameters and pressing OK) to the upstream router
> > connected to it.
> >
> > >
> > > Regards,
> > > Pavlin
> > >
> > > Hansi < hantongs at gmail.com> wrote:
> > >
> > > > Hello All,
> > > >
> > > > I'm currently exploring ipv6 multicast specifically pim-ssm. The
> network
> > > > topology setup I have is shown below:
> > > >
> > > >             +----------+                     +----------+
> > > >             | Source/  +---------------------+          |
> > > >             | Sender   |                sk0  | Router 1 |
> > > >             +----------+                     +-----+----+
> > > >                                                    | vr0
> > > >                                                    |
> > > >                                                    |
> > > >                                                    |
> > > >                                                    |
> > > >                                                    |
> > > >                                                    | vr0
> > > >             +----------+                     +-----+----+
> > > >             | Client/  +---------------------+          |
> > > >             | Receiver |                sk0  | Router 2 |
> > > >             +----------+                     +----------+
> > > >
> > > >
> > > >
> > > > Details:
> > > >
> > > > Source
> > > > OS: FreeBSD 6.2
> > > > Streaming Server: vlc-0.8.6_c
> > > > sis1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > > >         options=8<VLAN_MTU>
> > > >         inet6 fe80::200:24ff:fec4:3235%sis1 prefixlen 64 scopeid 0x2
>
> > > >         inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
> > > >         inet6 2001:ec2:4002:fa11:200:24ff:fec4:3235 prefixlen 64
> > > autoconf
> > > >         ether 00:00:24:c4:32:35
> > > >         media: Ethernet autoselect (100baseTX <full-duplex>)
> > > >
> > > > Router 1
> > > > OS: FreeBSD 6.2
> > > > sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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
> > > >
> > > > Router 2
> > > > OS: FreeBSD 6.2
> > > > sk0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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=8a43<UP,BROADCAST,RUNNING,ALLMULTI,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
> > > >
> > > > Client
> > > > OS: Linux Ubuntu Fiesty Fawn 7.04  2.6.20-16-generic
> > > > Streaming Client: vlc-0.8.6_c
> > > > eth0      Link encap:Ethernet  HWaddr 00:19:5B:2F:14:68
> > > >           inet addr:172.16.0.2  Bcast:172.16.255.255  Mask:255.255.0.0
> > > >           inet6 addr: 2001:ec1:4001:10af:219:5bff:fe2f:1468/64
> > > Scope:Global
> > > >           inet6 addr: fe80::219:5bff:fe2f:1468/64 Scope:Link
> > > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> > > >           RX packets:71141 errors:0 dropped:0 overruns:0 frame:0
> > > >           TX packets:103425 errors:0 dropped:0 overruns:0 carrier:0
> > > >           collisions:0 txqueuelen:1000
> > > >           RX bytes:6304908 ( 6.0 MiB)  TX bytes:137947821 (131.5MiB)
> > > >           Interrupt:17
> > > >
> > > >
> > > > The problem is that I can't seem to recieve multicast streams from
> the
> > > > streaming server. :( I haven't encountered issues w/ regards to ipv4
> ssm
> > >
> > > > multicast. The syntax used for the vlc streaming server is: vlc -vvv
> > > > video.xyz - -ipv6 - -sout udp:[ff3e::1234] - -ttl 12. I also tried
> > > placing a
> > > > backslash (\) character before each bracket but to no avail.  I
> > > configured
> > > > the client through vlc's graphical interface with
> > > > udp://[2001:ec2:4002:fa11:200:24ff:fec4:3235]@[ff3e::1234].
> > > > What I came to notice though is that there are no "Join" messages
> sent
> > > out
> > > > from the client side to indicate that it intends to join a channel,
> in
> > > this
> > > > case (2001:ec2:4002:fa11:200:24ff:fec4:3235, ff3e::1234). I suspect
> that
> > > the
> > > > it could be the client not initiating any "join" activity to a
> multicast
> > >
> > > > group although I can't also rule out that I overlooked something in
> my
> > > XORP
> > > > configuration file. I would appreciate if someone could lend me a
> hand
> > > here.
> > > >
> > > > Attached is my xorp config file.
> > > >
> > > > Thanks.
> > > > _______________________________________________
> > > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071204/84db390a/attachment-0001.html 

From bbb999 at zerodistance.fi  Tue Dec  4 10:32:06 2007
From: bbb999 at zerodistance.fi (Arsi Antila)
Date: Tue, 4 Dec 2007 20:32:06 +0200
Subject: [Xorp-users] BGP crash
In-Reply-To: <84a612dd0712030943h7e49dab3u6970b29ef1d19e91@mail.gmail.com>
References: <20071203102100.GA12449@zerodistance.fi>
	<84a612dd0712030943h7e49dab3u6970b29ef1d19e91@mail.gmail.com>
Message-ID: <20071204183206.GA2903@zerodistance.fi>

I'll try to get more information about the situation where the crash
happens. My understanding is that it is only the BGP process which dies,
and it happens when the winning route seen by XORP changes, and the new
winning route is on the same interface as the old winning route.

I would guess that BGP had peering configured using the local IP
addresses of the three ethernets. 


Regards,
Arsi


On Mon, Dec 03, 2007 at 05:43:49PM +0000, Mark Handley wrote:
> Xorp should not crash; I don't think this is a known issue.  Can you
> clarify - which Xorp process crashes?  The subject implies BGP, but I
> just want to be sure.
> 
> Also I'm not clear on the scenario - BGP doesn't advertise ASs to
> interfaces - it advertises them via BGP connections which are only
> loosely connected to interfaces (if you choose an interface IP address
> for the connection endpoint).  Do you mean the BGP has peering
> configured using the local IP addresses of the three ethernets in your
> scenario?
> 
> Which AS is the router that crashes in?
> 
> Your text says 5 routers, but I'm not sure where the 5th one is - the
> minimum needed to implement something like you describe is 4 (One each
> for AS1, AS2, AS3 and the router that crashes).  Where's the 5th one?
> 
> Also could you send the policy config you used to prevent route redistribution?
> 
> If we understood the scenario, we can build a test suite to tickle
> this problem, but right now I don't really know how to do this.
> 
>  - Mark
> 
> On Dec 3, 2007 10:21 AM, Arsi Antila <bbb999 at zerodistance.fi> wrote:
> > Is the following a known problem in XORP?
> >
> > Note: this was shown to me by someone else. I didn't test this myself,
> > so some of the details may be incorrect.
> >
> > XORP crashes when the same set of BGP routes is advertised from two
> > different routers connected to the same interface and the winning route
> > changes. Tested with VLANs, if-aliases and plain interfaces. Results do
> > not vary.
> >
> >
> > For example, configuration of the network is as follows:
> >
> > - device under test (Linux/Debian, XORP) and five simulated routers
> >
> > - AS 1 is advertised to ports eth1 and eth2
> >
> > - AS 2 is advertised to ports eth1 and eth2
> >
> > - AS 3 is advertised to port eth3
> >
> > - Policy rules so that AS 2 routes are not advertised to AS 1
> >
> > BGP process dies when one of the routers in AS 2 goes down and then up
> > so that the primary route in AS 2 changes.
> >
> >
> > Regards,
> > A.A.
> >
> > _______________________________________________
> > Xorp-users mailing list
> > Xorp-users at xorp.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> >


From pavlin at icir.org  Tue Dec  4 10:46:41 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 04 Dec 2007 10:46:41 -0800
Subject: [Xorp-users] Fwd: Fwd: Problem in IPv6 SSM Multicast
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Tue,
	04 Dec 2007 20:38:33 +0800."
	<2f9e317b0712040438r492183fxe0926d026aa55c90@mail.gmail.com> 
Message-ID: <200712041846.lB4IkfWN055887@possum.icir.org>

> > > > show mld group
> > >
> > >
> > > Interface    Group           Source          LastReported Timeout V
> > State
> > > sk0          ff02::2         ::              fe80::219:5bff:fe85:cfc7
> > > 243 1     E
> > > sk0          ff02::d         ::              fe80::219:5bff:fe85:cfc7
> > > 243 1     E
> > > sk0          ff02::16        ::              fe80::219:5bff:fe85:cfc7
> > > 243 1     E
> > > sk0          ff02::1:ff00:1  ::              fe80::219:5bff:fe85:cfc7
> > > 243 1     E
> > > sk0          ff02::1:ff2f:1468 ::              fe80::219:5bff:fe2f:1468
> > > 248 2     E
> > > sk0          ff02::1:ff85:cfc7 ::              fe80::219:5bff:fe85:cfc7
> > > 243 1     E
> > > sk0          ff02::2:15ba:6cf7 ::              fe80::219:5bff:fe85:cfc7
> > > 243 1     E
> >
> > It doesn't seem that the client/receiver with IPv6 address
> > 2001:ec2:4002:fa11:200:24ff:fec4:3235 has joined group ff3e::1234.
> 
> 
> The ipv6 address 2001:ec2:4002:fa11:200:24ff
> >
> > :fec4:3235 is the address of the streaming server. :)
> >
> 
> > So your guess in your original email is correct: there is something
> > wrong with the receiver so it hasn't joined the multicast group.
> > Could you run tcpdump to capture all ICMPv6 (incl. MLD) traffic and
> > confirm that XORP is sending the periodic query messages, but the
> > receiver itself never sends MLDv2 Join messages.
> 
> 
> Here are the logs from tcpdump taken on the LAN side of the router (router
> ----- receiver)
> 20:24:32.872230 IP6 (hlim 1, next-header: Options (0), length: 36)
> fe80::219:5bff:fe85:cfc7 > ip6-allnodes: HBH (rtalert: 0x0000) (padn)[icmp6
> sum ok] ICMP6, multicast listener query, length 28v2  [max resp delay=10000]
> [gaddr :: robustness=2 qqi=125]

OK: the router sends the Query

> 20:24:32.876596 IP6 (hlim 1, next-header: Options (0), length: 32)
> fe80::219:5bff:fe85:cfc7 > ff02::16: HBH (padn)(rtalert: 0x0000) [icmp6 sum
> ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
> ff02::16

OK: MLDv1 Report from the router itself that it is a member of group
ff02::16

> 20:24:32.892588 IP6 (hlim 1, next-header: Options (0), length: 32)
> fe80::219:5bff:fe85:cfc7 > ip6-allrouters: HBH (padn)(rtalert: 0x0000)
> [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp delay: 0
> addr: ip6-allrouters

OK: MLDv1 Report from the router itself that it is a member of group
ip6-allrouters

> 20:24:32.906594 IP6 (hlim 1, next-header: Options (0), length: 32)
> fe80::219:5bff:fe85:cfc7 > ff02::d: HBH (padn)(rtalert: 0x0000) [icmp6 sum
> ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
> ff02::d

OK: MLDv1 Report from the router itself that it is a member of group
ff02::d

> 20:24:32.906613 IP6 (hlim 1, next-header: Options (0), length: 32)
> fe80::219:5bff:fe85:cfc7 > ff02::1:ff00:1: HBH (padn)(rtalert: 0x0000)
> [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp delay: 0
> addr: ff02::1:ff00:1

OK: MLDv1 Report from the router itself that it is a member of group
ff02::1:ff00:1

> 20:24:32.906634 IP6 (hlim 1, next-header: Options (0), length: 32)
> fe80::219:5bff:fe85:cfc7 > ff02::2:15ba:6cf7: HBH (padn)(rtalert: 0x0000)
> [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp delay: 0
> addr: ff02::2:15ba:6cf7

OK: MLDv1 Report from the router itself that it is a member of group
ff02::2:15ba:6cf7

> 20:24:32.910605 IP6 (hlim 1, next-header: Options (0), length: 32)
> fe80::219:5bff:fe85:cfc7 > ff02::1:ff85:cfc7: HBH (padn)(rtalert: 0x0000)
> [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp delay: 0
> addr: ff02::1:ff85:cfc7

OK: MLDv1 Report from the router itself that it is a member of group
ff02::1:ff85:cfc7

> 20:24:37.389295 IP6 (hlim 1, next-header: Options (0), length: 36)
> fe80::219:5bff:fe2f:1468 > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum
> ok] ICMP6, multicast listener report v2, length 28, 1 group record(s) [gaddr
> ff02::1:ff2f:1468 is_ex { }]

OK: MLDv2 Report from the client that it is a member of group
ff02::1:ff2f:1468 for all sources.

It appears that the MLDv2 join mechanism between the client and the
router is working for group ff02::1:ff2f:1468 (which is the group
automatically joined by the kernel on the client's interface).

However, I don't seen any join for the multicast group from the
client's application.

> Back when I was exploring ipv4 ssm, everytime I click either on the play or
> stop button of the vlc client, I always see an IGMP join or prune message.
> Shouldn't  it that it also applies to MLDv2? However, I'm not seeing any
> here.

I am not familiar with vlc, but what you say is the logically
expected behavior.
You might want to contact the vlc author(s) about that.

> > BTW, what about MLDv1 Join messages? If you configure the client to
> > join some (*,G) multicast group does it initiate MLDv1 Join?
> >
> My current setup is intended for PIM-SSM traffic. Can it also apply to PIM
> SM considering the setup consist of only two routers?

Yes, you can, but then you must configure one of the routers as the
RP. For testing purpose you could just try without any
RP. Obviously, multicast routing won't work, but the "show mld
group" output will tell us whether MLDv1 Join works for the
application (and whether the router will record that).

Regards,
Pavlin


From greearb at candelatech.com  Tue Dec  4 11:01:58 2007
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 04 Dec 2007 11:01:58 -0800
Subject: [Xorp-users] BGP crash
In-Reply-To: <20071204183206.GA2903@zerodistance.fi>
References: <20071203102100.GA12449@zerodistance.fi>	<84a612dd0712030943h7e49dab3u6970b29ef1d19e91@mail.gmail.com>
	<20071204183206.GA2903@zerodistance.fi>
Message-ID: <4755A426.7000900@candelatech.com>

Arsi Antila wrote:
> I'll try to get more information about the situation where the crash
> happens. My understanding is that it is only the BGP process which dies,
> and it happens when the winning route seen by XORP changes, and the new
> winning route is on the same interface as the old winning route.
>
> I would guess that BGP had peering configured using the local IP
> addresses of the three ethernets. 
>   
If you have a core file, you can likely get a backtrace using gdb that would
be very helpful in figuring out where the problem lies...

If you have no core files, try running this before starting xorp:

ulimit -a unlimited

(Assuming you are on Linux).

Ben


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



From dscher at mitre.org  Tue Dec  4 11:29:49 2007
From: dscher at mitre.org (Scher, Dave)
Date: Tue, 4 Dec 2007 14:29:49 -0500
Subject: [Xorp-users] Quiet Death
In-Reply-To: <200711291719.lATHJjnc058633@possum.icir.org>
References: Message from "Scher, Dave" <dscher@mitre.org>    of "Thu,
	29 Nov 2007 11:01:59 EST."
	<9472CDDE9370AF4C871D40FD2ADB92BC023B2E5F@IMCSRV1.MITRE.ORG>
	<200711291719.lATHJjnc058633@possum.icir.org>
Message-ID: <9472CDDE9370AF4C871D40FD2ADB92BC0241C20B@IMCSRV1.MITRE.ORG>

 
All,
	I am trying to figure out how to make xorp (XORP Router
Manager) die a louder death.  I have cross-compiled xorp for a powerpc
platform.  I try to start the router manager with a very simple
config.boot and this executable dies very quickly and with no messages
to STDERR.  Anyone have any ideas to make it die louder or a location
for log files?  

Thanks.
Dave S. 


From dscher at mitre.org  Tue Dec  4 11:35:32 2007
From: dscher at mitre.org (Scher, Dave)
Date: Tue, 4 Dec 2007 14:35:32 -0500
Subject: [Xorp-users] Quiet Death
Message-ID: <9472CDDE9370AF4C871D40FD2ADB92BC0241C215@IMCSRV1.MITRE.ORG>

Oh and the verbose option doesn't help.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071204/d5773115/attachment.html 

From pavlin at icir.org  Tue Dec  4 11:56:07 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 04 Dec 2007 11:56:07 -0800
Subject: [Xorp-users] Quiet Death
In-Reply-To: Message from "Scher, Dave" <dscher@mitre.org> of "Tue,
	04 Dec 2007 14:29:49 EST."
	<9472CDDE9370AF4C871D40FD2ADB92BC0241C20B@IMCSRV1.MITRE.ORG> 
Message-ID: <200712041956.lB4Ju7cf056641@possum.icir.org>

> All,
> 	I am trying to figure out how to make xorp (XORP Router
> Manager) die a louder death.  I have cross-compiled xorp for a powerpc
> platform.  I try to start the router manager with a very simple
> config.boot and this executable dies very quickly and with no messages
> to STDERR.  Anyone have any ideas to make it die louder or a location
> for log files?  

If you run "./xorp_rtrmgr -h" does it print the help information?

If yes, then probably the XORP log mechanism is not working.
FYI, it tries to open the following three device files (in this
order):
/dev/stderr
/dev/console
/dev/stdout

The first device that it successfully opens for writing will be used
to output the log messages.
Do you have any of those devices on your platform and are they
writable (as root)?
FYI, the above list is hard-coded inside xorp/xlog.c so you could 
modify it if the output device name is different.
In any case, please let us know how it goes, so we can fix the
code (if the problem is in the XORP code).

Thanks,
Pavlin


From atanu at ICSI.Berkeley.EDU  Tue Dec  4 12:19:20 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Tue, 04 Dec 2007 12:19:20 -0800
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: Message from Aidan Walton <awalton@wires3.net> of "Tue,
	04 Dec 2007 13:22:40 GMT." <1196774560.3967.36.camel@bass.wires3.net> 
Message-ID: <6448.1196799560@tigger.icir.org>

Hi,

The scenario that you describe would be perfectly normal if the
connectivity between the "suspect" router and the "adjacent" router is
lost. Although I would expect the "show ospf4 neighbor" to show the
state of the adjacency to be "Down" not "Full". When an OSPF router
loses its adjancencies the LSA database will slowly timeout, however,
the routes will be withdrawn as soon as the adjacencies are lost.

We will require more information to diagnose the problem next time the
problem occurs the output of "show interfaces" and "show ospf4 neighbor"
would be very useful.

XORP tracks the state of interfaces in particular the carrier state. If
OSPF believes that the Ethernet has been disconnected it will stop
attempting to send hello packets. Is it possible that there is a problem
with an interface or cable between the two routers?

	   Atanu.

>>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:

    Aidan>    Hi All, I am using xorp in a production environment,
    Aidan> admittedly a small one. I operate a local WISP and xorp is
    Aidan> running on my wireless nodes. I have a very simple
    Aidan> configuration and really I could probably get away with
    Aidan> static routing throughout the entire network, but I wanted to
    Aidan> try xorp and see just how stable it was. However as I expand
    Aidan> the network I am having second thoughts. It is not good at
    Aidan> all when a network goes up in smoke and I can't explain why
    Aidan> or predict when and what the causes are.  The network has
    Aidan> been in operation 24x7 for around 9 months. I am running on a
    Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
    Aidan> have no issues. However now for the fourth time I see the
    Aidan> same problem: Suddenly the Linux kernel and the xorp rib
    Aidan> become detached. Normally all routes in the kernel match
    Aidan> those that xorp is generating, receiving and electing as
    Aidan> active. I am running OSPF and the neighbour states remain
    Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
    Aidan> only in one direction (i.e nothing being transmitted from the
    Aidan> router I suspect). The lsdb of OSPF on the suspect and
    Aidan> adjacent routers contain all the routes but they are aging
    Aidan> out slowly on the adjacent router. When I look at the kernel
    Aidan> routes those from OSPF have already vanished.  I can see the
    Aidan> ospf process running on the offending router? and again I can
    Aidan> see the ospf lsdb intact and correct. When I restart xorp the
    Aidan> system recovers and the routes appear in the kernel again. I
    Aidan> suspect a problem with ospf. I tried enabling traceoptions on
    Aidan> the ospf process, but in fact I needed to restart all the
    Aidan> xorp processes before this actually became active. I now have
    Aidan> this running so if/when it happens again I might be able to
    Aidan> offer some more information.  Does anyone have any experience
    Aidan> of ospf begin unstable? any suggestions how I might more
    Aidan> effectively capture some logs from this event. I do not see
    Aidan> any options for logging the fea process. Is there anything I
    Aidan> can enable to help diagnose the issue?  Many thanks, and of
    Aidan> course cheers for the code in the first place.  Aidan
    Aidan> _______________________________________________ Xorp-users
    Aidan> mailing list Xorp-users at xorp.org
    Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From dscher at mitre.org  Tue Dec  4 13:35:02 2007
From: dscher at mitre.org (Scher, Dave)
Date: Tue, 4 Dec 2007 16:35:02 -0500
Subject: [Xorp-users] Quiet Death
In-Reply-To: <200712041956.lB4Ju7cf056641@possum.icir.org>
References: Message from "Scher, Dave" <dscher@mitre.org>    of "Tue,
	04 Dec 2007 14:29:49 EST."
	<9472CDDE9370AF4C871D40FD2ADB92BC0241C20B@IMCSRV1.MITRE.ORG>
	<200712041956.lB4Ju7cf056641@possum.icir.org>
Message-ID: <9472CDDE9370AF4C871D40FD2ADB92BC0241C255@IMCSRV1.MITRE.ORG>

> If you run "./xorp_rtrmgr -h" does it print the help information?

Yes the help information prints to the console output.

>If yes, then probably the XORP log mechanism is not working.
>FYI, it tries to open the following three device files (in this
>order):
>/dev/stderr
>/dev/console
>/dev/stdout

>Do you have any of those devices on your platform and are they
>writable (as root)?

Yes.

/dev/console
/dev/stderr

Both exist and are both writable as root.  Tried a hello world and it
does indeed output to the console.

Thanks.

Dave  




From awalton at wires3.net  Tue Dec  4 14:54:36 2007
From: awalton at wires3.net (Aidan Walton)
Date: Tue, 04 Dec 2007 22:54:36 +0000
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: <6448.1196799560@tigger.icir.org>
References: <6448.1196799560@tigger.icir.org>
Message-ID: <1196808876.3967.109.camel@bass.wires3.net>

Hi,
The adjacency runs over a wireless link between the routers. It can,
very possibly, drop in and out, but as far as I can see this did not
happen and to be honest in the 9 months I have had this system up I have
never seen the wireless link drop, but packet corruption could be a
possibility and this may be less easy to diagnose. It is a high power
5.8GHz connection, here in the UK this is a licensed band (and yes I
have a license). So I don't think interference is the likely cause,
though I wouldn't rule this out. If I look at the logs from the same
period I seen nothing to indicate the interface flapped, I would see the
wireless dis-associate and re-associate and cypher exchange and this did
not happen. But as I say there could be a period of high BER on the
links. I thought ospf would handle this reasonably gracefully? I have to
say heavy BER was not evident when I came to repair the network, or at
least I didn't detect it and in the past I have run ospf over another
one of my wireless links with stations 10km apart with the wireless link
almost non-functional, dropping packets left right and centre and
re-associating over and over, but xorp's ospf never complained!

I was beginning to suspect that this was related to my adsl link on the
suspect router, as this is a dynamic interface and I have this defined
independently of xorp. If this interface flaps then the default route
associated with the adsl ppp session is withdrawn. The default from the
adsl line is not propagated into ospf though, instead I use a static
default with a higher metric pointed at the loopback and inject this
into ospf instead. Then the flaps of the adsl line do not cause churn in
the ospf domain. I was starting to think that the addition and removal
of the default from the adsl line was affecting the kernel table and
this was upsetting xorp's ospf. However this morning when this happened
the adsl line was stable. As far as my logs look it suddenly decided to
stop functioning with no correlated events from other system processes.
The only things in the logs at the same time is iptables dropping DOS
attacks, but this in normal, unfortunately far to normal.

show ospf4 neighbour simply stated 'full' there is only one neighbour
defined on this router. I didn't look this time at show interfaces, but
from memory of the last time this happened this also was normal.

The problem is that these routers are mounted 10m high up telegraph
poles. If I loose connectivity it requires a ladder and a climbing
harness to get at them, this is not to mention my upset customers who,
as is normal with customers, do not delay in telling me they have lost
their Internet links.

I suppose what I'm trying to understand is how to be best prepared for
next time, logging, processes and checks during the failure period to
grab as much useful info before I am forced to restart xorp and get my
customers up and running again. This is a very short period I have to
say. I have a small group of business units supported on this router and
all hell breaks loose if this happens during working hours.

How can I get the maximum logging info from the xorp processes?

Anything I can do in order that you can help me, will be dutifully
carried out. What next, any suggestions?
Thanks
Aidan


I will On Tue, 2007-12-04 at 12:19 -0800, Atanu Ghosh wrote:

> Hi,
> 
> The scenario that you describe would be perfectly normal if the
> connectivity between the "suspect" router and the "adjacent" router is
> lost. Although I would expect the "show ospf4 neighbor" to show the
> state of the adjacency to be "Down" not "Full". When an OSPF router
> loses its adjancencies the LSA database will slowly timeout, however,
> the routes will be withdrawn as soon as the adjacencies are lost.
> 
> We will require more information to diagnose the problem next time the
> problem occurs the output of "show interfaces" and "show ospf4 neighbor"
> would be very useful.
> 
> XORP tracks the state of interfaces in particular the carrier state. If
> OSPF believes that the Ethernet has been disconnected it will stop
> attempting to send hello packets. Is it possible that there is a problem
> with an interface or cable between the two routers?
> 
> 	   Atanu.
> 
> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
> 
>     Aidan>    Hi All, I am using xorp in a production environment,
>     Aidan> admittedly a small one. I operate a local WISP and xorp is
>     Aidan> running on my wireless nodes. I have a very simple
>     Aidan> configuration and really I could probably get away with
>     Aidan> static routing throughout the entire network, but I wanted to
>     Aidan> try xorp and see just how stable it was. However as I expand
>     Aidan> the network I am having second thoughts. It is not good at
>     Aidan> all when a network goes up in smoke and I can't explain why
>     Aidan> or predict when and what the causes are.  The network has
>     Aidan> been in operation 24x7 for around 9 months. I am running on a
>     Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
>     Aidan> have no issues. However now for the fourth time I see the
>     Aidan> same problem: Suddenly the Linux kernel and the xorp rib
>     Aidan> become detached. Normally all routes in the kernel match
>     Aidan> those that xorp is generating, receiving and electing as
>     Aidan> active. I am running OSPF and the neighbour states remain
>     Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
>     Aidan> only in one direction (i.e nothing being transmitted from the
>     Aidan> router I suspect). The lsdb of OSPF on the suspect and
>     Aidan> adjacent routers contain all the routes but they are aging
>     Aidan> out slowly on the adjacent router. When I look at the kernel
>     Aidan> routes those from OSPF have already vanished.  I can see the
>     Aidan> ospf process running on the offending router? and again I can
>     Aidan> see the ospf lsdb intact and correct. When I restart xorp the
>     Aidan> system recovers and the routes appear in the kernel again. I
>     Aidan> suspect a problem with ospf. I tried enabling traceoptions on
>     Aidan> the ospf process, but in fact I needed to restart all the
>     Aidan> xorp processes before this actually became active. I now have
>     Aidan> this running so if/when it happens again I might be able to
>     Aidan> offer some more information.  Does anyone have any experience
>     Aidan> of ospf begin unstable? any suggestions how I might more
>     Aidan> effectively capture some logs from this event. I do not see
>     Aidan> any options for logging the fea process. Is there anything I
>     Aidan> can enable to help diagnose the issue?  Many thanks, and of
>     Aidan> course cheers for the code in the first place.  Aidan
>     Aidan> _______________________________________________ Xorp-users
>     Aidan> mailing list Xorp-users at xorp.org
>     Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071204/c3c9d070/attachment.html 

From yueli.m at gmail.com  Tue Dec  4 18:51:52 2007
From: yueli.m at gmail.com (Yue Li)
Date: Tue, 4 Dec 2007 21:51:52 -0500
Subject: [Xorp-users] [xorp-users] Experimental scenarios
Message-ID: <49567c360712041851s52057712h3a7db688887c9e1b@mail.gmail.com>

Hi, all
Does xorp have some scenarios for conducting large-scale experiments?
If I want to run hundreds of xorp the realistic configurations of xorp is a
problem.

- Yue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071204/2a14ee23/attachment.html 

From pavlin at icir.org  Tue Dec  4 21:12:19 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 04 Dec 2007 21:12:19 -0800
Subject: [Xorp-users] Quiet Death
In-Reply-To: Message from "Scher, Dave" <dscher@mitre.org> of "Tue,
	04 Dec 2007 16:35:02 EST."
	<9472CDDE9370AF4C871D40FD2ADB92BC0241C255@IMCSRV1.MITRE.ORG> 
Message-ID: <200712050512.lB55CJOr060659@possum.icir.org>

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

> > If you run "./xorp_rtrmgr -h" does it print the help information?
> 
> Yes the help information prints to the console output.
> 
> >If yes, then probably the XORP log mechanism is not working.
> >FYI, it tries to open the following three device files (in this
> >order):
> >/dev/stderr
> >/dev/console
> >/dev/stdout
> 
> >Do you have any of those devices on your platform and are they
> >writable (as root)?
> 
> Yes.
> 
> /dev/console
> /dev/stderr
> 
> Both exist and are both writable as root.  Tried a hello world and it
> does indeed output to the console.

Interesting.
Chasing the problem might take several rounds of email exchange so
lets take it off the list.
I will send you an email with some initial suggestions.

Thanks,
Pavlin


From atanu at ICSI.Berkeley.EDU  Wed Dec  5 01:00:53 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 05 Dec 2007 01:00:53 -0800
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: Message from Aidan Walton <awalton@wires3.net> of "Tue,
	04 Dec 2007 22:54:36 GMT." <1196808876.3967.109.camel@bass.wires3.net> 
Message-ID: <3876.1196845253@tigger.icir.org>

Hi,

The output that it would be good to see before and after the problem
occurs.
1) $ netstat -nr
2) Xorp> show interfaces
3) Xorp> show route table ipv4 unicast final
4) Xorp> show ospf4 neighbor detail
5) Xorp> show ospf4 database detail
6) $ print_lsas -S save.lsas
The print_lsas program can be found in ospf/tools directory. The program
stores the LSA database in a form that can be replayed.

You can also enable tracing in ospf:
        traceoptions {
            flag {
                all {
                    disable: false
                }
            }
        }

Which should show routes being added and deleted.

The latest code in CVS has a "clear ospf4 database" command, it would be
interesting to know if once the problem occurs if this solves the
problem.

It might also be interesting to keep the "ip mon" command running to
track routes being added and deleted.

Would it be possible at some off peak time to flap the ADSL link to see
if this replicates the problem. I know that you have stated that there
were no ADSL issues when the problem occurred, but I do wonder if we are
seeing some issue related to dynamic interfaces.

       Atanu.

>>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:

    Aidan>    Hi, The adjacency runs over a wireless link between the
    Aidan> routers. It can, very possibly, drop in and out, but as far
    Aidan> as I can see this did not happen and to be honest in the 9
    Aidan> months I have had this system up I have never seen the
    Aidan> wireless link drop, but packet corruption could be a
    Aidan> possibility and this may be less easy to diagnose. It is a
    Aidan> high power 5.8GHz connection, here in the UK this is a
    Aidan> licensed band (and yes I have a license). So I don't think
    Aidan> interference is the likely cause, though I wouldn't rule this
    Aidan> out. If I look at the logs from the same period I seen
    Aidan> nothing to indicate the interface flapped, I would see the
    Aidan> wireless dis-associate and re-associate and cypher exchange
    Aidan> and this did not happen. But as I say there could be a period
    Aidan> of high BER on the links. I thought ospf would handle this
    Aidan> reasonably gracefully? I have to say heavy BER was not
    Aidan> evident when I came to repair the network, or at least I
    Aidan> didn't detect it and in the past I have run ospf over another
    Aidan> one of my wireless links with stations 10km apart with the
    Aidan> wireless link almost non-functional, dropping packets left
    Aidan> right and centre and re-associating over and over, but xorp's
    Aidan> ospf never complained!  I was beginning to suspect that this
    Aidan> was related to my adsl link on the suspect router, as this is
    Aidan> a dynamic interface and I have this defined independently of
    Aidan> xorp. If this interface flaps then the default route
    Aidan> associated with the adsl ppp session is withdrawn. The
    Aidan> default from the adsl line is not propagated into ospf
    Aidan> though, instead I use a static default with a higher metric
    Aidan> pointed at the loopback and inject this into ospf
    Aidan> instead. Then the flaps of the adsl line do not cause churn
    Aidan> in the ospf domain. I was starting to think that the addition
    Aidan> and removal of the default from the adsl line was affecting
    Aidan> the kernel table and this was upsetting xorp's ospf. However
    Aidan> this morning when this happened the adsl line was stable. As
    Aidan> far as my logs look it suddenly decided to stop functioning
    Aidan> with no correlated events from other system processes. The
    Aidan> only things in the logs at the same time is iptables dropping
    Aidan> DOS attacks, but this in normal, unfortunately far to normal.
    Aidan> show ospf4 neighbour simply stated 'full' there is only one
    Aidan> neighbour defined on this router. I didn't look this time at
    Aidan> show interfaces, but from memory of the last time this
    Aidan> happened this also was normal.  The problem is that these
    Aidan> routers are mounted 10m high up telegraph poles. If I loose
    Aidan> connectivity it requires a ladder and a climbing harness to
    Aidan> get at them, this is not to mention my upset customers who,
    Aidan> as is normal with customers, do not delay in telling me they
    Aidan> have lost their Internet links.  I suppose what I'm trying to
    Aidan> understand is how to be best prepared for next time, logging,
    Aidan> processes and checks during the failure period to grab as
    Aidan> much useful info before I am forced to restart xorp and get
    Aidan> my customers up and running again. This is a very short
    Aidan> period I have to say. I have a small group of business units
    Aidan> supported on this router and all hell breaks loose if this
    Aidan> happens during working hours.  How can I get the maximum
    Aidan> logging info from the xorp processes?  Anything I can do in
    Aidan> order that you can help me, will be dutifully carried
    Aidan> out. What next, any suggestions?  Thanks Aidan I will On Tue,
    Aidan> 2007-12-04 at 12:19 -0800, Atanu Ghosh wrote:

    Atanu> Hi,

    Atanu> The scenario that you describe would be perfectly normal if
    Atanu> the connectivity between the "suspect" router and the
    Atanu> "adjacent" router is lost. Although I would expect the "show
    Atanu> ospf4 neighbor" to show the state of the adjacency to be
    Atanu> "Down" not "Full". When an OSPF router loses its adjancencies
    Atanu> the LSA database will slowly timeout, however, the routes
    Atanu> will be withdrawn as soon as the adjacencies are lost.

    Atanu> We will require more information to diagnose the problem next
    Atanu> time the problem occurs the output of "show interfaces" and
    Atanu> "show ospf4 neighbor" would be very useful.

    Atanu> XORP tracks the state of interfaces in particular the carrier
    Atanu> state. If OSPF believes that the Ethernet has been
    Atanu> disconnected it will stop attempting to send hello
    Atanu> packets. Is it possible that there is a problem with an
    Atanu> interface or cable between the two routers?

    Atanu> Atanu.

>>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:

    Aidan> Hi All, I am using xorp in a production environment,
    Aidan> admittedly a small one. I operate a local WISP and xorp is
    Aidan> running on my wireless nodes. I have a very simple
    Aidan> configuration and really I could probably get away with
    Aidan> static routing throughout the entire network, but I wanted to
    Aidan> try xorp and see just how stable it was. However as I expand
    Aidan> the network I am having second thoughts. It is not good at
    Aidan> all when a network goes up in smoke and I can't explain why
    Aidan> or predict when and what the causes are.  The network has
    Aidan> been in operation 24x7 for around 9 months. I am running on a
    Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
    Aidan> have no issues. However now for the fourth time I see the
    Aidan> same problem: Suddenly the Linux kernel and the xorp rib
    Aidan> become detached. Normally all routes in the kernel match
    Aidan> those that xorp is generating, receiving and electing as
    Aidan> active. I am running OSPF and the neighbour states remain
    Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
    Aidan> only in one direction (i.e nothing being transmitted from the
    Aidan> router I suspect). The lsdb of OSPF on the suspect and
    Aidan> adjacent routers contain all the routes but they are aging
    Aidan> out slowly on the adjacent router. When I look at the kernel
    Aidan> routes those from OSPF have already vanished.  I can see the
    Aidan> ospf process running on the offending router? and again I can
    Aidan> see the ospf lsdb intact and correct. When I restart xorp the
    Aidan> system recovers and the routes appear in the kernel again. I
    Aidan> suspect a problem with ospf. I tried enabling traceoptions on
    Aidan> the ospf process, but in fact I needed to restart all the
    Aidan> xorp processes before this actually became active. I now have
    Aidan> this running so if/when it happens again I might be able to
    Aidan> offer some more information.  Does anyone have any experience
    Aidan> of ospf begin unstable? any suggestions how I might more
    Aidan> effectively capture some logs from this event. I do not see
    Aidan> any options for logging the fea process. Is there anything I
    Aidan> can enable to help diagnose the issue?  Many thanks, and of
    Aidan> course cheers for the code in the first place.  Aidan
    Aidan> _______________________________________________ Xorp-users
    Aidan> mailing list Xorp-users at xorp.org
    Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From hantongs at gmail.com  Wed Dec  5 05:40:05 2007
From: hantongs at gmail.com (Hansi)
Date: Wed, 5 Dec 2007 21:40:05 +0800
Subject: [Xorp-users] Fwd: Fwd: Problem in IPv6 SSM Multicast
In-Reply-To: <200712041846.lB4IkfWN055887@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0712040438r492183fxe0926d026aa55c90@mail.gmail.com>
	<200712041846.lB4IkfWN055887@possum.icir.org>
Message-ID: <2f9e317b0712050540m3a6571dcq83488b0dbc5913e@mail.gmail.com>

Hello Pavlin,

I've consulted w/ the VLC authors and everything appears to be alright w/
the VLC player according to them. Weird... anyway, I'll review my setup. I
might have overlooked something though..

Thanks for your assistance.

Hansi
On Dec 5, 2007 2:46 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:

> > > > > show mld group
> > > >
> > > >
> > > > Interface    Group           Source          LastReported Timeout V
> > > State
> > > > sk0          ff02::2         ::
>  fe80::219:5bff:fe85:cfc7
> > > > 243 1     E
> > > > sk0          ff02::d         ::
>  fe80::219:5bff:fe85:cfc7
> > > > 243 1     E
> > > > sk0          ff02::16        ::
>  fe80::219:5bff:fe85:cfc7
> > > > 243 1     E
> > > > sk0          ff02::1:ff00:1  ::
>  fe80::219:5bff:fe85:cfc7
> > > > 243 1     E
> > > > sk0          ff02::1:ff2f:1468 ::
>  fe80::219:5bff:fe2f:1468
> > > > 248 2     E
> > > > sk0          ff02::1:ff85:cfc7 ::
>  fe80::219:5bff:fe85:cfc7
> > > > 243 1     E
> > > > sk0          ff02::2:15ba:6cf7 ::
>  fe80::219:5bff:fe85:cfc7
> > > > 243 1     E
> > >
> > > It doesn't seem that the client/receiver with IPv6 address
> > > 2001:ec2:4002:fa11:200:24ff:fec4:3235 has joined group ff3e::1234.
> >
> >
> > The ipv6 address 2001:ec2:4002:fa11:200:24ff
> > >
> > > :fec4:3235 is the address of the streaming server. :)
> > >
> >
> > > So your guess in your original email is correct: there is something
> > > wrong with the receiver so it hasn't joined the multicast group.
> > > Could you run tcpdump to capture all ICMPv6 (incl. MLD) traffic and
> > > confirm that XORP is sending the periodic query messages, but the
> > > receiver itself never sends MLDv2 Join messages.
> >
> >
> > Here are the logs from tcpdump taken on the LAN side of the router
> (router
> > ----- receiver)
> > 20:24:32.872230 IP6 (hlim 1, next-header: Options (0), length: 36)
> > fe80::219:5bff:fe85:cfc7 > ip6-allnodes: HBH (rtalert: 0x0000)
> (padn)[icmp6
> > sum ok] ICMP6, multicast listener query, length 28v2  [max resp
> delay=10000]
> > [gaddr :: robustness=2 qqi=125]
>
> OK: the router sends the Query
>
> > 20:24:32.876596 IP6 (hlim 1, next-header: Options (0), length: 32)
> > fe80::219:5bff:fe85:cfc7 > ff02::16: HBH (padn)(rtalert: 0x0000) [icmp6
> sum
> > ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
> > ff02::16
>
> OK: MLDv1 Report from the router itself that it is a member of group
> ff02::16
>
> > 20:24:32.892588 IP6 (hlim 1, next-header: Options (0), length: 32)
> > fe80::219:5bff:fe85:cfc7 > ip6-allrouters: HBH (padn)(rtalert: 0x0000)
> > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> delay: 0
> > addr: ip6-allrouters
>
> OK: MLDv1 Report from the router itself that it is a member of group
> ip6-allrouters
>
> > 20:24:32.906594 IP6 (hlim 1, next-header: Options (0), length: 32)
> > fe80::219:5bff:fe85:cfc7 > ff02::d: HBH (padn)(rtalert: 0x0000) [icmp6
> sum
> > ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
> > ff02::d
>
> OK: MLDv1 Report from the router itself that it is a member of group
> ff02::d
>
> > 20:24:32.906613 IP6 (hlim 1, next-header: Options (0), length: 32)
> > fe80::219:5bff:fe85:cfc7 > ff02::1:ff00:1: HBH (padn)(rtalert: 0x0000)
> > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> delay: 0
> > addr: ff02::1:ff00:1
>
> OK: MLDv1 Report from the router itself that it is a member of group
> ff02::1:ff00:1
>
> > 20:24:32.906634 IP6 (hlim 1, next-header: Options (0), length: 32)
> > fe80::219:5bff:fe85:cfc7 > ff02::2:15ba:6cf7: HBH (padn)(rtalert:
> 0x0000)
> > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> delay: 0
> > addr: ff02::2:15ba:6cf7
>
> OK: MLDv1 Report from the router itself that it is a member of group
> ff02::2:15ba:6cf7
>
> > 20:24:32.910605 IP6 (hlim 1, next-header: Options (0), length: 32)
> > fe80::219:5bff:fe85:cfc7 > ff02::1:ff85:cfc7: HBH (padn)(rtalert:
> 0x0000)
> > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> delay: 0
> > addr: ff02::1:ff85:cfc7
>
> OK: MLDv1 Report from the router itself that it is a member of group
> ff02::1:ff85:cfc7
>
> > 20:24:37.389295 IP6 (hlim 1, next-header: Options (0), length: 36)
> > fe80::219:5bff:fe2f:1468 > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6
> sum
> > ok] ICMP6, multicast listener report v2, length 28, 1 group record(s)
> [gaddr
> > ff02::1:ff2f:1468 is_ex { }]
>
> OK: MLDv2 Report from the client that it is a member of group
> ff02::1:ff2f:1468 for all sources.
>
> It appears that the MLDv2 join mechanism between the client and the
> router is working for group ff02::1:ff2f:1468 (which is the group
> automatically joined by the kernel on the client's interface).
>
> However, I don't seen any join for the multicast group from the
> client's application.
>
> > Back when I was exploring ipv4 ssm, everytime I click either on the play
> or
> > stop button of the vlc client, I always see an IGMP join or prune
> message.
> > Shouldn't  it that it also applies to MLDv2? However, I'm not seeing any
> > here.
>
> I am not familiar with vlc, but what you say is the logically
> expected behavior.
> You might want to contact the vlc author(s) about that.
>
> > > BTW, what about MLDv1 Join messages? If you configure the client to
> > > join some (*,G) multicast group does it initiate MLDv1 Join?
> > >
> > My current setup is intended for PIM-SSM traffic. Can it also apply to
> PIM
> > SM considering the setup consist of only two routers?
>
> Yes, you can, but then you must configure one of the routers as the
> RP. For testing purpose you could just try without any
> RP. Obviously, multicast routing won't work, but the "show mld
> group" output will tell us whether MLDv1 Join works for the
> application (and whether the router will record that).
>
> Regards,
> Pavlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071205/b0775ebd/attachment.html 

From awalton at wires3.net  Wed Dec  5 10:24:14 2007
From: awalton at wires3.net (Aidan Walton)
Date: Wed, 05 Dec 2007 18:24:14 +0000
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: <3876.1196845253@tigger.icir.org>
References: <3876.1196845253@tigger.icir.org>
Message-ID: <1196879055.3790.32.camel@bass.wires3.net>

Hi Atanu,
We didn't have to wait too long. It just happened again, this time on a
different router altogether.  I would love to give you logs, but its
broken. It seems that when logrotate does its job in the early hours,
after it has rotated the active log file, xorp stops writing anything
into the log file. This seems to happen on all the routers. I have no
idea why, maybe you do. As soon as you restart xorp the log output
beings to appear in the log file. On the routers where I have not
restarted xorp, yesterdays logs are intact in the rotated file up to
when cron runs logrotate but the new log file is empty a big fat zero
and unless I restart the xorp processes it seems to stay this way!

Inline is the output from the commands you wanted me to run and the
replay file attached. I hope this helps.

All the best
Aidan

lodgefarm:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
89.248.141.239  *               255.255.255.255 UH    0      0        0
ppp13
89.248.141.238  *               255.255.255.255 UH    0      0        0
ppp25
89.248.141.254  *               255.255.255.255 UH    0      0        0
ppp27
89.248.141.237  *               255.255.255.255 UH    0      0        0
ppp23
89.248.141.253  *               255.255.255.255 UH    0      0        0
ppp15
89.248.141.252  *               255.255.255.255 UH    0      0        0
ppp11
89.248.141.236  *               255.255.255.255 UH    0      0        0
ppp7
89.248.141.235  *               255.255.255.255 UH    0      0        0
ppp0
89.248.141.251  *               255.255.255.255 UH    0      0        0
ppp3
89.248.141.234  *               255.255.255.255 UH    0      0        0
ppp16
89.248.141.250  *               255.255.255.255 UH    0      0        0
ppp22
89.248.141.233  *               255.255.255.255 UH    0      0        0
ppp14
89.248.141.249  *               255.255.255.255 UH    0      0        0
ppp1
89.248.141.232  *               255.255.255.255 UH    0      0        0
ppp12
89.248.141.248  *               255.255.255.255 UH    0      0        0
ppp10
89.248.141.231  *               255.255.255.255 UH    0      0        0
ppp26
89.248.141.247  *               255.255.255.255 UH    0      0        0
ppp4
89.248.141.230  *               255.255.255.255 UH    0      0        0
ppp19
89.248.141.246  *               255.255.255.255 UH    0      0        0
ppp17
89.248.141.229  *               255.255.255.255 UH    0      0        0
ppp18
89.248.141.245  *               255.255.255.255 UH    0      0        0
ppp5
89.248.141.244  *               255.255.255.255 UH    0      0        0
ppp6
89.248.141.228  *               255.255.255.255 UH    0      0        0
ppp2
89.248.141.227  *               255.255.255.255 UH    0      0        0
ppp24
89.248.141.243  *               255.255.255.255 UH    0      0        0
ppp21
89.248.141.242  *               255.255.255.255 UH    0      0        0
ppp8
89.248.141.241  *               255.255.255.255 UH    0      0        0
ppp20
89.248.141.196  *               255.255.255.252 U     0      0        0
ath0
89.248.142.128  89.248.141.221  255.255.255.248 UG    10     0        0
lo
89.248.141.224  *               255.255.255.224 U     0      0        0
ath1
10.20.30.0      *               255.255.255.0   U     0      0        0
eth0


lodgefarm:~# xorpsh
Welcome to XORP on lodgefarm
root at lodgefarm> show ospf4 neighbor
  Address         Interface             State      ID              Pri
Dead
89.248.141.197   ath0/ath0              Full      89.248.141.222   128
34


root at lodgefarm> show ospf4 database
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
Len
Router  *89.248.141.221   89.248.141.221   0x80000807   409  0x2  0x9516
48
ASExt-2 *89.248.141.224   89.248.141.221   0x8000003a   645  0x2  0x7903
36
Router   89.248.141.222   89.248.141.222   0x800008f0   405  0x2  0x77f5
60
Network  89.248.141.197   89.248.141.222   0x8000003b   409  0x2  0xaf92
32
Router   89.248.141.223   89.248.141.223   0x80000fc5  1690  0x2  0xa048
48
Network  89.248.141.194   89.248.141.222   0x8000003c  1701  0x2  0xe75a
32
ASExt-2 *89.248.142.128   89.248.141.221   0x8000003a   645  0x2  0x2792
36
ASExt-2  0.0.0.0          89.248.141.223   0x80000f82  1700  0x2  0xfdba
36
Network *89.248.141.198   89.248.141.221   0x80000001   409  0x2  0x2458
32
root at lodgefarm> show route table ipv4 unicast final
89.248.141.224/27       [connected(0)/0]
                > via ath1/ath1
89.248.142.128/29       [static(1)/10]
                > to 89.248.141.221 via lo/lo
89.248.141.196/30       [connected(0)/0]
                > via ath0/ath0
89.248.141.221/32       [connected(0)/0]
                > via lo/lo


root at lodgefarm> show interfaces
ath0/ath0: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500
        inet 89.248.141.198 subnet 89.248.141.196/30 broadcast
89.248.141.199
        physical index 7
        ether 0:15:6d:53:25:5c
ath1/ath1: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500
        inet 89.248.141.225 subnet 89.248.141.224/27 broadcast
89.248.141.255
        physical index 8
        ether 0:15:6d:54:31:b2
lo/lo: Flags:<ENABLED,LOOPBACK> mtu 16436
        inet 89.248.141.221 subnet 89.248.141.221/32
        physical index 1
root at lodgefarm> show route table ipv4 unicast final
89.248.141.224/27       [connected(0)/0]
                > via ath1/ath1
89.248.142.128/29       [static(1)/10]
                > to 89.248.141.221 via lo/lo
89.248.141.196/30       [connected(0)/0]
                > via ath0/ath0
89.248.141.221/32       [connected(0)/0]
                > via lo/lo
root at lodgefarm> show ospf4 neighbor detail
  Address         Interface             State      ID              Pri
Dead
89.248.141.197   ath0/ath0              Full      89.248.141.222   128
36
  Area 0.0.0.0, opt 0x2, DR 89.248.141.197, BDR 0.0.0.0
  Up 28:58:12, adjacent 00:08:32
root at lodgefarm> show ospf4 database detail
   OSPF link state database, Area 0.0.0.0
Router-LSA:
LS age  528 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.221 Advertising Router 89.248.141.221 LS sequence
number 0x80000807 LS checksum 0x9516 length 48
        bit Nt false
        bit V false
        bit E true
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.198 Routers interface address 89.248.141.198 Metric 1
        Type 3 Stub network Subnet number 89.248.141.221 Mask
255.255.255.255 Metric 1
As-External-LSA:
LS age  764 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 89.248.141.224 Advertising Router 89.248.141.221 LS sequence
number 0x8000003a LS checksum 0x7903 length 36
        Network Mask 0xffffffe0
        bit E true
        Metric 0 0
        Forwarding address 89.248.141.221
        External Route Tag 0
Router-LSA:
LS age  524 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.222 Advertising Router 89.248.141.222 LS sequence
number 0x800008f0 LS checksum 0x77f5 length 60
        bit Nt false
        bit V false
        bit E false
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.194 Routers interface address 89.248.141.194 Metric 1
        Type 3 Stub network Subnet number 89.248.141.222 Mask
255.255.255.255 Metric 1
        Type 2 Transit network IP address of Designated router
89.248.141.197 Routers interface address 89.248.141.197 Metric 1
Network-LSA:
LS age  528 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.197 Advertising Router 89.248.141.222 LS sequence
number 0x8000003b LS checksum 0xaf92 length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.222
        Attached Router 89.248.141.221
Router-LSA:
LS age   10 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.223 Advertising Router 89.248.141.223 LS sequence
number 0x80000fc6 LS checksum 0x9e49 length 48
        bit Nt false
        bit V false
        bit E true
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.194 Routers interface address 89.248.141.193 Metric 1
        Type 3 Stub network Subnet number 89.248.141.223 Mask
255.255.255.255 Metric 1
Network-LSA:
LS age   20 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.194 Advertising Router 89.248.141.222 LS sequence
number 0x8000003d LS checksum 0xe55b length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.222
        Attached Router 89.248.141.223
As-External-LSA:
LS age  764 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 89.248.142.128 Advertising Router 89.248.141.221 LS sequence
number 0x8000003a LS checksum 0x2792 length 36
        Network Mask 0xfffffff8
        bit E true
        Metric 10 0xa
        Forwarding address 89.248.141.221
        External Route Tag 0
Network-LSA:
LS age  529 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.198 Advertising Router 89.248.141.221 LS sequence
number 0x80000001 LS checksum 0x2458 length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.221
        Attached Router 89.248.141.222
As-External-LSA:
LS age   19 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 0.0.0.0 Advertising Router 89.248.141.223 LS sequence number
0x80000f83 LS checksum 0xfbbb length 36
        Network Mask 0
        bit E true
        Metric 10 0xa
        Forwarding address 89.248.141.223
        External Route Tag 0
root at lodgefarm> exit


lodgefarm:/usr/local/xorp/ospf/tools# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
89.248.141.239  *               255.255.255.255 UH    0      0        0
ppp13
89.248.141.254  *               255.255.255.255 UH    0      0        0
ppp27
89.248.141.237  *               255.255.255.255 UH    0      0        0
ppp23
89.248.141.253  *               255.255.255.255 UH    0      0        0
ppp15
89.248.141.252  *               255.255.255.255 UH    0      0        0
ppp11
89.248.141.236  *               255.255.255.255 UH    0      0        0
ppp7
89.248.141.251  *               255.255.255.255 UH    0      0        0
ppp3
89.248.141.234  *               255.255.255.255 UH    0      0        0
ppp16
89.248.141.250  *               255.255.255.255 UH    0      0        0
ppp22
89.248.141.233  *               255.255.255.255 UH    0      0        0
ppp14
89.248.141.249  *               255.255.255.255 UH    0      0        0
ppp1
89.248.141.232  *               255.255.255.255 UH    0      0        0
ppp12
89.248.141.248  *               255.255.255.255 UH    0      0        0
ppp10
89.248.141.231  *               255.255.255.255 UH    0      0        0
ppp26
89.248.141.247  *               255.255.255.255 UH    0      0        0
ppp4
89.248.141.230  *               255.255.255.255 UH    0      0        0
ppp19
89.248.141.246  *               255.255.255.255 UH    0      0        0
ppp17
89.248.141.229  *               255.255.255.255 UH    0      0        0
ppp18
89.248.141.245  *               255.255.255.255 UH    0      0        0
ppp5
89.248.141.244  *               255.255.255.255 UH    0      0        0
ppp6
89.248.141.228  *               255.255.255.255 UH    0      0        0
ppp2
89.248.141.227  *               255.255.255.255 UH    0      0        0
ppp24
89.248.141.243  *               255.255.255.255 UH    0      0        0
ppp21
89.248.141.242  *               255.255.255.255 UH    0      0        0
ppp8
89.248.141.241  *               255.255.255.255 UH    0      0        0
ppp20
89.248.141.196  *               255.255.255.252 U     0      0        0
ath0
89.248.142.128  89.248.141.221  255.255.255.248 UG    10     0        0
lo
89.248.141.224  *               255.255.255.224 U     0      0        0
ath1
10.20.30.0      *               255.255.255.0   U     0      0        0
eth0
lodgefarm:/usr/local/xorp/ospf/tools# xorpsh
Welcome to XORP on lodgefarm
root at lodgefarm> show  ospf4 database
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
Len
Router  *89.248.141.221   89.248.141.221   0x80000807   723  0x2  0x9516
48
ASExt-2 *89.248.141.224   89.248.141.221   0x8000003a   959  0x2  0x7903
36
Router   89.248.141.222   89.248.141.222   0x800008f0   719  0x2  0x77f5
60
Network  89.248.141.197   89.248.141.222   0x8000003b   723  0x2  0xaf92
32
Router   89.248.141.223   89.248.141.223   0x80000fc6   204  0x2  0x9e49
48
Network  89.248.141.194   89.248.141.222   0x8000003d   215  0x2  0xe55b
32
ASExt-2 *89.248.142.128   89.248.141.221   0x8000003a   959  0x2  0x2792
36
Network *89.248.141.198   89.248.141.221   0x80000001   723  0x2  0x2458
32
ASExt-2  0.0.0.0          89.248.141.223   0x80000f83   214  0x2  0xfbbb
36
root at lodgefarm> show  ospf4 database
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
Len
Router  *89.248.141.221   89.248.141.221   0x80000807   742  0x2  0x9516
48
ASExt-2 *89.248.141.224   89.248.141.221   0x8000003a   978  0x2  0x7903
36
Router   89.248.141.222   89.248.141.222   0x800008f0   738  0x2  0x77f5
60
Network  89.248.141.197   89.248.141.222   0x8000003b   742  0x2  0xaf92
32
Router   89.248.141.223   89.248.141.223   0x80000fc6   224  0x2  0x9e49
48
Network  89.248.141.194   89.248.141.222   0x8000003d   234  0x2  0xe55b
32
ASExt-2 *89.248.142.128   89.248.141.221   0x8000003a   978  0x2  0x2792
36
Network *89.248.141.198   89.248.141.221   0x80000001   743  0x2  0x2458
32
ASExt-2  0.0.0.0          89.248.141.223   0x80000f83   233  0x2  0xfbbb
36


root at lodgefarm> exit
lodgefarm:/usr/local/xorp/ospf/tools# tcpdump -i ath0 proto ospf
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
17:03:17.694436 IP 89.248.141.198 > 224.0.0.5: OSPFv2, Hello, length: 48
17:03:21.899777 IP 89.248.141.197 > 224.0.0.5: OSPFv2, Hello, length: 48
17:03:27.786449 IP 89.248.141.198 > 224.0.0.5: OSPFv2, Hello, length: 48
17:03:31.896206 IP 89.248.141.197 > 224.0.0.5: OSPFv2, Hello, length: 48
17:03:37.694828 IP 89.248.141.198 > 224.0.0.5: OSPFv2, Hello, length: 48
17:03:41.896639 IP 89.248.141.197 > 224.0.0.5: OSPFv2, Hello, length: 48

6 packets captured
6 packets received by filter
0 packets dropped by kernel
lodgefarm:/usr/local/xorp/ospf/tools# xorpsh
Welcome to XORP on lodgefarm
root at lodgefarm> show ospf4 database
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
Len
Router  *89.248.141.221   89.248.141.221   0x80000807   813  0x2  0x9516
48
ASExt-2 *89.248.141.224   89.248.141.221   0x8000003a  1049  0x2  0x7903
36
Router   89.248.141.222   89.248.141.222   0x800008f0   809  0x2  0x77f5
60
Network  89.248.141.197   89.248.141.222   0x8000003b   813  0x2  0xaf92
32
Router   89.248.141.223   89.248.141.223   0x80000fc6   294  0x2  0x9e49
48
Network  89.248.141.194   89.248.141.222   0x8000003d   305  0x2  0xe55b
32
ASExt-2 *89.248.142.128   89.248.141.221   0x8000003a  1049  0x2  0x2792
36
Network *89.248.141.198   89.248.141.221   0x80000001   813  0x2  0x2458
32
ASExt-2  0.0.0.0          89.248.141.223   0x80000f83   304  0x2  0xfbbb
36
root at lodgefarm> show ospf4 database detail
   OSPF link state database, Area 0.0.0.0
Router-LSA:
LS age  828 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.221 Advertising Router 89.248.141.221 LS sequence
number 0x80000807 LS checksum 0x9516 length 48
        bit Nt false
        bit V false
        bit E true
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.198 Routers interface address 89.248.141.198 Metric 1
        Type 3 Stub network Subnet number 89.248.141.221 Mask
255.255.255.255 Metric 1
As-External-LSA:
LS age 1064 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 89.248.141.224 Advertising Router 89.248.141.221 LS sequence
number 0x8000003a LS checksum 0x7903 length 36
        Network Mask 0xffffffe0
        bit E true
        Metric 0 0
        Forwarding address 89.248.141.221
        External Route Tag 0
Router-LSA:
LS age  824 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.222 Advertising Router 89.248.141.222 LS sequence
number 0x800008f0 LS checksum 0x77f5 length 60
        bit Nt false
        bit V false
        bit E false
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.194 Routers interface address 89.248.141.194 Metric 1
        Type 3 Stub network Subnet number 89.248.141.222 Mask
255.255.255.255 Metric 1
        Type 2 Transit network IP address of Designated router
89.248.141.197 Routers interface address 89.248.141.197 Metric 1
Network-LSA:
LS age  828 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.197 Advertising Router 89.248.141.222 LS sequence
number 0x8000003b LS checksum 0xaf92 length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.222
        Attached Router 89.248.141.221
Router-LSA:
LS age  309 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.223 Advertising Router 89.248.141.223 LS sequence
number 0x80000fc6 LS checksum 0x9e49 length 48
        bit Nt false
        bit V false
        bit E true
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.194 Routers interface address 89.248.141.193 Metric 1
        Type 3 Stub network Subnet number 89.248.141.223 Mask
255.255.255.255 Metric 1
Network-LSA:
LS age  320 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.194 Advertising Router 89.248.141.222 LS sequence
number 0x8000003d LS checksum 0xe55b length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.222
        Attached Router 89.248.141.223
As-External-LSA:
LS age 1064 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 89.248.142.128 Advertising Router 89.248.141.221 LS sequence
number 0x8000003a LS checksum 0x2792 length 36
        Network Mask 0xfffffff8
root at lodgefarm> /etc/init.d/xorp restart
                ^
unknown command.
root at lodgefarm> exit
lodgefarm:/usr/local/xorp/ospf/tools# /etc/init.d/xorp restart
Stopping xorp: Stopping xorp

Starting xorp: Starting xorp

lodgefarm:/usr/local/xorp/ospf/tools# xorpsh
Welcome to XORP on lodgefarm
root at lodgefarm> show ospf4 database
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
Len
Router  *89.248.141.221   89.248.141.221   0x80000001     4  0x2  0xf86b
48
ASExt-2 *89.248.141.224   89.248.141.221   0x80000001     4  0x2  0xebc9
36
ASExt-2 *89.248.142.128   89.248.141.221   0x80000001     4  0x2  0x9959
36
Router   89.248.141.222   89.248.141.222   0x800008f2     4  0x2  0x73f7
60
Network  89.248.141.197   89.248.141.222   0x80000001     4  0x2  0x2458
32
root at lodgefarm> show ospf4 database
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
Len
Router  *89.248.141.221   89.248.141.221   0x80000809     1  0x2  0x8723
48
ASExt-2 *89.248.141.224   89.248.141.221   0x8000003b     8  0x2  0x7704
36
ASExt-2 *89.248.142.128   89.248.141.221   0x8000003b     8  0x2  0x2593
36
Router   89.248.141.222   89.248.141.222   0x800008f2     7  0x2  0x73f7
60
Network  89.248.141.197   89.248.141.222   0x80000001     7  0x2  0x2458
32
Router   89.248.141.223   89.248.141.223   0x80000fc6   396  0x2  0x9e49
48
Network  89.248.141.194   89.248.141.222   0x8000003d   406  0x2  0xe55b
32
ASExt-2  0.0.0.0          89.248.141.223   0x80000f83   405  0x2  0xfbbb
36
root at lodgefarm> show ospf4 database
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
Len
Router  *89.248.141.221   89.248.141.221   0x80000809     5  0x2  0x8723
48
ASExt-2 *89.248.141.224   89.248.141.221   0x8000003b    12  0x2  0x7704
36
ASExt-2 *89.248.142.128   89.248.141.221   0x8000003b    12  0x2  0x2593
36
Router   89.248.141.222   89.248.141.222   0x800008f2    11  0x2  0x73f7
60
Network  89.248.141.197   89.248.141.222   0x80000001    11  0x2  0x2458
32
Router   89.248.141.223   89.248.141.223   0x80000fc6   400  0x2  0x9e49
48
Network  89.248.141.194   89.248.141.222   0x8000003d   410  0x2  0xe55b
32
ASExt-2  0.0.0.0          89.248.141.223   0x80000f83   409  0x2  0xfbbb
36
root at lodgefarm> show ospf4 database detail
   OSPF link state database, Area 0.0.0.0
Router-LSA:
LS age   18 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.221 Advertising Router 89.248.141.221 LS sequence
number 0x80000809 LS checksum 0x8723 length 48
        bit Nt false
        bit V false
        bit E true
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.197 Routers interface address 89.248.141.198 Metric 1
        Type 3 Stub network Subnet number 89.248.141.221 Mask
255.255.255.255 Metric 1
As-External-LSA:
LS age   25 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 89.248.141.224 Advertising Router 89.248.141.221 LS sequence
number 0x8000003b LS checksum 0x7704 length 36
        Network Mask 0xffffffe0
        bit E true
        Metric 0 0
        Forwarding address 89.248.141.221
        External Route Tag 0
As-External-LSA:
LS age   25 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 89.248.142.128 Advertising Router 89.248.141.221 LS sequence
number 0x8000003b LS checksum 0x2593 length 36
        Network Mask 0xfffffff8
        bit E true
        Metric 10 0xa
        Forwarding address 89.248.141.221
        External Route Tag 0
Router-LSA:
LS age   25 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.222 Advertising Router 89.248.141.222 LS sequence
number 0x800008f2 LS checksum 0x73f7 length 60
        bit Nt false
        bit V false
        bit E false
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.194 Routers interface address 89.248.141.194 Metric 1
        Type 3 Stub network Subnet number 89.248.141.222 Mask
255.255.255.255 Metric 1
        Type 2 Transit network IP address of Designated router
89.248.141.197 Routers interface address 89.248.141.197 Metric 1
Network-LSA:
LS age   25 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.197 Advertising Router 89.248.141.222 LS sequence
number 0x80000001 LS checksum 0x2458 length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.222
        Attached Router 89.248.141.221
Router-LSA:
LS age  414 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.223 Advertising Router 89.248.141.223 LS sequence
number 0x80000fc6 LS checksum 0x9e49 length 48
        bit Nt false
        bit V false
        bit E true
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.194 Routers interface address 89.248.141.193 Metric 1
        Type 3 Stub network Subnet number 89.248.141.223 Mask
255.255.255.255 Metric 1
Network-LSA:
LS age  424 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.194 Advertising Router 89.248.141.222 LS sequence
number 0x8000003d LS checksum 0xe55b length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.222
        Attached Router 89.248.141.223
As-External-LSA:
LS age  423 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 0.0.0.0 Advertising Router 89.248.141.223 LS sequence number
0x80000f83 LS checksum 0xfbbb length 36
        Network Mask 0
        bit E true
        Metric 10 0xa
        Forwarding address 89.248.141.223
        External Route Tag 0
root at lodgefarm> show ospf4 neighbor det
Possible completions:
  <neighbor>           Show Neighbors
  detail               Show Neighbors
root at lodgefarm> show ospf4 neighbor detail
  Address         Interface             State      ID              Pri
Dead
89.248.141.197   ath0/ath0              Full      89.248.141.222   128
33
  Area 0.0.0.0, opt 0x2, DR 89.248.141.197, BDR 89.248.141.198
  Up 00:00:36, adjacent 00:00:31
root at lodgefarm> exit
lodgefarm:/usr/local/xorp/ospf/tools# xorpsh
shWelcome to XORP on lodgefarm
root at lodgefarm> show interfaces
ath0/ath0: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500
        inet 89.248.141.198 subnet 89.248.141.196/30 broadcast
89.248.141.199
        physical index 7
        ether 0:15:6d:53:25:5c
ath1/ath1: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500
        inet 89.248.141.225 subnet 89.248.141.224/27 broadcast
89.248.141.255
        physical index 8
        ether 0:15:6d:54:31:b2
lo/lo: Flags:<ENABLED,LOOPBACK> mtu 16436
        inet 89.248.141.221 subnet 89.248.141.221/32
        physical index 1
root at lodgefarm> exit
lodgefarm:/usr/local/xorp/ospf/tools# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
89.248.141.222  89.248.141.197  255.255.255.255 UGH   2      0        0
ath0
89.248.141.239  *               255.255.255.255 UH    0      0        0
ppp13
89.248.141.238  *               255.255.255.255 UH    0      0        0
ppp25
89.248.141.223  89.248.141.197  255.255.255.255 UGH   3      0        0
ath0
89.248.141.254  *               255.255.255.255 UH    0      0        0
ppp27
89.248.141.237  *               255.255.255.255 UH    0      0        0
ppp23
89.248.141.253  *               255.255.255.255 UH    0      0        0
ppp15
89.248.141.252  *               255.255.255.255 UH    0      0        0
ppp11
89.248.141.236  *               255.255.255.255 UH    0      0        0
ppp7
89.248.141.235  *               255.255.255.255 UH    0      0        0
ppp9
89.248.141.251  *               255.255.255.255 UH    0      0        0
ppp3
89.248.141.234  *               255.255.255.255 UH    0      0        0
ppp16
89.248.141.250  *               255.255.255.255 UH    0      0        0
ppp22
89.248.141.233  *               255.255.255.255 UH    0      0        0
ppp14
89.248.141.249  *               255.255.255.255 UH    0      0        0
ppp1
89.248.141.232  *               255.255.255.255 UH    0      0        0
ppp12
89.248.141.248  *               255.255.255.255 UH    0      0        0
ppp10
89.248.141.231  *               255.255.255.255 UH    0      0        0
ppp26
89.248.141.247  *               255.255.255.255 UH    0      0        0
ppp4
89.248.141.230  *               255.255.255.255 UH    0      0        0
ppp19
89.248.141.246  *               255.255.255.255 UH    0      0        0
ppp17
89.248.141.229  *               255.255.255.255 UH    0      0        0
ppp18
89.248.141.245  *               255.255.255.255 UH    0      0        0
ppp5
89.248.141.244  *               255.255.255.255 UH    0      0        0
ppp6
89.248.141.228  *               255.255.255.255 UH    0      0        0
ppp2
89.248.141.227  *               255.255.255.255 UH    0      0        0
ppp24
89.248.141.243  *               255.255.255.255 UH    0      0        0
ppp21
89.248.141.242  *               255.255.255.255 UH    0      0        0
ppp8
89.248.141.241  *               255.255.255.255 UH    0      0        0
ppp20
89.248.141.240  *               255.255.255.255 UH    0      0        0
ppp0
89.248.141.196  *               255.255.255.252 U     0      0        0
ath0
89.248.141.192  89.248.141.197  255.255.255.252 UG    2      0        0
ath0
89.248.142.128  89.248.141.221  255.255.255.248 UG    10     0        0
lo
89.248.141.224  *               255.255.255.224 U     0      0        0
ath1
10.20.30.0      *               255.255.255.0   U     0      0        0
eth0
default         89.248.141.197  0.0.0.0         UG    3      0        0
ath0
lodgefarm:/usr/local/xorp/ospf/tools#

On Wed, 2007-12-05 at 01:00 -0800, Atanu Ghosh wrote:
> Hi,
> 
> The output that it would be good to see before and after the problem
> occurs.
> 1) $ netstat -nr
> 2) Xorp> show interfaces
> 3) Xorp> show route table ipv4 unicast final
> 4) Xorp> show ospf4 neighbor detail
> 5) Xorp> show ospf4 database detail
> 6) $ print_lsas -S save.lsas
> The print_lsas program can be found in ospf/tools directory. The program
> stores the LSA database in a form that can be replayed.
> 
> You can also enable tracing in ospf:
>         traceoptions {
>             flag {
>                 all {
>                     disable: false
>                 }
>             }
>         }
> 
> Which should show routes being added and deleted.
> 
> The latest code in CVS has a "clear ospf4 database" command, it would be
> interesting to know if once the problem occurs if this solves the
> problem.
> 
> It might also be interesting to keep the "ip mon" command running to
> track routes being added and deleted.
> 
> Would it be possible at some off peak time to flap the ADSL link to see
> if this replicates the problem. I know that you have stated that there
> were no ADSL issues when the problem occurred, but I do wonder if we are
> seeing some issue related to dynamic interfaces.
> 
>        Atanu.
> 
> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
> 
>     Aidan>    Hi, The adjacency runs over a wireless link between the
>     Aidan> routers. It can, very possibly, drop in and out, but as far
>     Aidan> as I can see this did not happen and to be honest in the 9
>     Aidan> months I have had this system up I have never seen the
>     Aidan> wireless link drop, but packet corruption could be a
>     Aidan> possibility and this may be less easy to diagnose. It is a
>     Aidan> high power 5.8GHz connection, here in the UK this is a
>     Aidan> licensed band (and yes I have a license). So I don't think
>     Aidan> interference is the likely cause, though I wouldn't rule this
>     Aidan> out. If I look at the logs from the same period I seen
>     Aidan> nothing to indicate the interface flapped, I would see the
>     Aidan> wireless dis-associate and re-associate and cypher exchange
>     Aidan> and this did not happen. But as I say there could be a period
>     Aidan> of high BER on the links. I thought ospf would handle this
>     Aidan> reasonably gracefully? I have to say heavy BER was not
>     Aidan> evident when I came to repair the network, or at least I
>     Aidan> didn't detect it and in the past I have run ospf over another
>     Aidan> one of my wireless links with stations 10km apart with the
>     Aidan> wireless link almost non-functional, dropping packets left
>     Aidan> right and centre and re-associating over and over, but xorp's
>     Aidan> ospf never complained!  I was beginning to suspect that this
>     Aidan> was related to my adsl link on the suspect router, as this is
>     Aidan> a dynamic interface and I have this defined independently of
>     Aidan> xorp. If this interface flaps then the default route
>     Aidan> associated with the adsl ppp session is withdrawn. The
>     Aidan> default from the adsl line is not propagated into ospf
>     Aidan> though, instead I use a static default with a higher metric
>     Aidan> pointed at the loopback and inject this into ospf
>     Aidan> instead. Then the flaps of the adsl line do not cause churn
>     Aidan> in the ospf domain. I was starting to think that the addition
>     Aidan> and removal of the default from the adsl line was affecting
>     Aidan> the kernel table and this was upsetting xorp's ospf. However
>     Aidan> this morning when this happened the adsl line was stable. As
>     Aidan> far as my logs look it suddenly decided to stop functioning
>     Aidan> with no correlated events from other system processes. The
>     Aidan> only things in the logs at the same time is iptables dropping
>     Aidan> DOS attacks, but this in normal, unfortunately far to normal.
>     Aidan> show ospf4 neighbour simply stated 'full' there is only one
>     Aidan> neighbour defined on this router. I didn't look this time at
>     Aidan> show interfaces, but from memory of the last time this
>     Aidan> happened this also was normal.  The problem is that these
>     Aidan> routers are mounted 10m high up telegraph poles. If I loose
>     Aidan> connectivity it requires a ladder and a climbing harness to
>     Aidan> get at them, this is not to mention my upset customers who,
>     Aidan> as is normal with customers, do not delay in telling me they
>     Aidan> have lost their Internet links.  I suppose what I'm trying to
>     Aidan> understand is how to be best prepared for next time, logging,
>     Aidan> processes and checks during the failure period to grab as
>     Aidan> much useful info before I am forced to restart xorp and get
>     Aidan> my customers up and running again. This is a very short
>     Aidan> period I have to say. I have a small group of business units
>     Aidan> supported on this router and all hell breaks loose if this
>     Aidan> happens during working hours.  How can I get the maximum
>     Aidan> logging info from the xorp processes?  Anything I can do in
>     Aidan> order that you can help me, will be dutifully carried
>     Aidan> out. What next, any suggestions?  Thanks Aidan I will On Tue,
>     Aidan> 2007-12-04 at 12:19 -0800, Atanu Ghosh wrote:
> 
>     Atanu> Hi,
> 
>     Atanu> The scenario that you describe would be perfectly normal if
>     Atanu> the connectivity between the "suspect" router and the
>     Atanu> "adjacent" router is lost. Although I would expect the "show
>     Atanu> ospf4 neighbor" to show the state of the adjacency to be
>     Atanu> "Down" not "Full". When an OSPF router loses its adjancencies
>     Atanu> the LSA database will slowly timeout, however, the routes
>     Atanu> will be withdrawn as soon as the adjacencies are lost.
> 
>     Atanu> We will require more information to diagnose the problem next
>     Atanu> time the problem occurs the output of "show interfaces" and
>     Atanu> "show ospf4 neighbor" would be very useful.
> 
>     Atanu> XORP tracks the state of interfaces in particular the carrier
>     Atanu> state. If OSPF believes that the Ethernet has been
>     Atanu> disconnected it will stop attempting to send hello
>     Atanu> packets. Is it possible that there is a problem with an
>     Atanu> interface or cable between the two routers?
> 
>     Atanu> Atanu.
> 
> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
> 
>     Aidan> Hi All, I am using xorp in a production environment,
>     Aidan> admittedly a small one. I operate a local WISP and xorp is
>     Aidan> running on my wireless nodes. I have a very simple
>     Aidan> configuration and really I could probably get away with
>     Aidan> static routing throughout the entire network, but I wanted to
>     Aidan> try xorp and see just how stable it was. However as I expand
>     Aidan> the network I am having second thoughts. It is not good at
>     Aidan> all when a network goes up in smoke and I can't explain why
>     Aidan> or predict when and what the causes are.  The network has
>     Aidan> been in operation 24x7 for around 9 months. I am running on a
>     Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
>     Aidan> have no issues. However now for the fourth time I see the
>     Aidan> same problem: Suddenly the Linux kernel and the xorp rib
>     Aidan> become detached. Normally all routes in the kernel match
>     Aidan> those that xorp is generating, receiving and electing as
>     Aidan> active. I am running OSPF and the neighbour states remain
>     Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
>     Aidan> only in one direction (i.e nothing being transmitted from the
>     Aidan> router I suspect). The lsdb of OSPF on the suspect and
>     Aidan> adjacent routers contain all the routes but they are aging
>     Aidan> out slowly on the adjacent router. When I look at the kernel
>     Aidan> routes those from OSPF have already vanished.  I can see the
>     Aidan> ospf process running on the offending router? and again I can
>     Aidan> see the ospf lsdb intact and correct. When I restart xorp the
>     Aidan> system recovers and the routes appear in the kernel again. I
>     Aidan> suspect a problem with ospf. I tried enabling traceoptions on
>     Aidan> the ospf process, but in fact I needed to restart all the
>     Aidan> xorp processes before this actually became active. I now have
>     Aidan> this running so if/when it happens again I might be able to
>     Aidan> offer some more information.  Does anyone have any experience
>     Aidan> of ospf begin unstable? any suggestions how I might more
>     Aidan> effectively capture some logs from this event. I do not see
>     Aidan> any options for logging the fea process. Is there anything I
>     Aidan> can enable to help diagnose the issue?  Many thanks, and of
>     Aidan> course cheers for the code in the first place.  Aidan
>     Aidan> _______________________________________________ Xorp-users
>     Aidan> mailing list Xorp-users at xorp.org
>     Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: save.lsas.lodgefarm-5-12-07
Type: application/octet-stream
Size: 481 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071205/7185b20d/attachment-0001.obj 

From awalton at wires3.net  Wed Dec  5 10:54:04 2007
From: awalton at wires3.net (Aidan Walton)
Date: Wed, 05 Dec 2007 18:54:04 +0000
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: <3876.1196845253@tigger.icir.org>
References: <3876.1196845253@tigger.icir.org>
Message-ID: <1196880844.3790.41.camel@bass.wires3.net>

Hi Atanu,
Now that I'm over the panic of collecting the data and recovering the
network. I can see that the neighbour seems to have been up for 29hrs
but adjacent for only 8mins. Clearly the adjacency has been dropped and
even though it has recovered it no longer imports the routes from the
database. Unfortunately because I do not have the logs, as explained in
the last email, I have no trace of the failure :( Note the tcpdump of
the hellos in both directions. I thought if the adjacency failed a
database update would be forced when it is re-established.

Oh BTW I checked my logs on the interfaces and the physicals have been
up all the time.

What's up with ospf?
Aidan

On Wed, 2007-12-05 at 01:00 -0800, Atanu Ghosh wrote:
> Hi,
> 
> The output that it would be good to see before and after the problem
> occurs.
> 1) $ netstat -nr
> 2) Xorp> show interfaces
> 3) Xorp> show route table ipv4 unicast final
> 4) Xorp> show ospf4 neighbor detail
> 5) Xorp> show ospf4 database detail
> 6) $ print_lsas -S save.lsas
> The print_lsas program can be found in ospf/tools directory. The program
> stores the LSA database in a form that can be replayed.
> 
> You can also enable tracing in ospf:
>         traceoptions {
>             flag {
>                 all {
>                     disable: false
>                 }
>             }
>         }
> 
> Which should show routes being added and deleted.
> 
> The latest code in CVS has a "clear ospf4 database" command, it would be
> interesting to know if once the problem occurs if this solves the
> problem.
> 
> It might also be interesting to keep the "ip mon" command running to
> track routes being added and deleted.
> 
> Would it be possible at some off peak time to flap the ADSL link to see
> if this replicates the problem. I know that you have stated that there
> were no ADSL issues when the problem occurred, but I do wonder if we are
> seeing some issue related to dynamic interfaces.
> 
>        Atanu.
> 
> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
> 
>     Aidan>    Hi, The adjacency runs over a wireless link between the
>     Aidan> routers. It can, very possibly, drop in and out, but as far
>     Aidan> as I can see this did not happen and to be honest in the 9
>     Aidan> months I have had this system up I have never seen the
>     Aidan> wireless link drop, but packet corruption could be a
>     Aidan> possibility and this may be less easy to diagnose. It is a
>     Aidan> high power 5.8GHz connection, here in the UK this is a
>     Aidan> licensed band (and yes I have a license). So I don't think
>     Aidan> interference is the likely cause, though I wouldn't rule this
>     Aidan> out. If I look at the logs from the same period I seen
>     Aidan> nothing to indicate the interface flapped, I would see the
>     Aidan> wireless dis-associate and re-associate and cypher exchange
>     Aidan> and this did not happen. But as I say there could be a period
>     Aidan> of high BER on the links. I thought ospf would handle this
>     Aidan> reasonably gracefully? I have to say heavy BER was not
>     Aidan> evident when I came to repair the network, or at least I
>     Aidan> didn't detect it and in the past I have run ospf over another
>     Aidan> one of my wireless links with stations 10km apart with the
>     Aidan> wireless link almost non-functional, dropping packets left
>     Aidan> right and centre and re-associating over and over, but xorp's
>     Aidan> ospf never complained!  I was beginning to suspect that this
>     Aidan> was related to my adsl link on the suspect router, as this is
>     Aidan> a dynamic interface and I have this defined independently of
>     Aidan> xorp. If this interface flaps then the default route
>     Aidan> associated with the adsl ppp session is withdrawn. The
>     Aidan> default from the adsl line is not propagated into ospf
>     Aidan> though, instead I use a static default with a higher metric
>     Aidan> pointed at the loopback and inject this into ospf
>     Aidan> instead. Then the flaps of the adsl line do not cause churn
>     Aidan> in the ospf domain. I was starting to think that the addition
>     Aidan> and removal of the default from the adsl line was affecting
>     Aidan> the kernel table and this was upsetting xorp's ospf. However
>     Aidan> this morning when this happened the adsl line was stable. As
>     Aidan> far as my logs look it suddenly decided to stop functioning
>     Aidan> with no correlated events from other system processes. The
>     Aidan> only things in the logs at the same time is iptables dropping
>     Aidan> DOS attacks, but this in normal, unfortunately far to normal.
>     Aidan> show ospf4 neighbour simply stated 'full' there is only one
>     Aidan> neighbour defined on this router. I didn't look this time at
>     Aidan> show interfaces, but from memory of the last time this
>     Aidan> happened this also was normal.  The problem is that these
>     Aidan> routers are mounted 10m high up telegraph poles. If I loose
>     Aidan> connectivity it requires a ladder and a climbing harness to
>     Aidan> get at them, this is not to mention my upset customers who,
>     Aidan> as is normal with customers, do not delay in telling me they
>     Aidan> have lost their Internet links.  I suppose what I'm trying to
>     Aidan> understand is how to be best prepared for next time, logging,
>     Aidan> processes and checks during the failure period to grab as
>     Aidan> much useful info before I am forced to restart xorp and get
>     Aidan> my customers up and running again. This is a very short
>     Aidan> period I have to say. I have a small group of business units
>     Aidan> supported on this router and all hell breaks loose if this
>     Aidan> happens during working hours.  How can I get the maximum
>     Aidan> logging info from the xorp processes?  Anything I can do in
>     Aidan> order that you can help me, will be dutifully carried
>     Aidan> out. What next, any suggestions?  Thanks Aidan I will On Tue,
>     Aidan> 2007-12-04 at 12:19 -0800, Atanu Ghosh wrote:
> 
>     Atanu> Hi,
> 
>     Atanu> The scenario that you describe would be perfectly normal if
>     Atanu> the connectivity between the "suspect" router and the
>     Atanu> "adjacent" router is lost. Although I would expect the "show
>     Atanu> ospf4 neighbor" to show the state of the adjacency to be
>     Atanu> "Down" not "Full". When an OSPF router loses its adjancencies
>     Atanu> the LSA database will slowly timeout, however, the routes
>     Atanu> will be withdrawn as soon as the adjacencies are lost.
> 
>     Atanu> We will require more information to diagnose the problem next
>     Atanu> time the problem occurs the output of "show interfaces" and
>     Atanu> "show ospf4 neighbor" would be very useful.
> 
>     Atanu> XORP tracks the state of interfaces in particular the carrier
>     Atanu> state. If OSPF believes that the Ethernet has been
>     Atanu> disconnected it will stop attempting to send hello
>     Atanu> packets. Is it possible that there is a problem with an
>     Atanu> interface or cable between the two routers?
> 
>     Atanu> Atanu.
> 
> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
> 
>     Aidan> Hi All, I am using xorp in a production environment,
>     Aidan> admittedly a small one. I operate a local WISP and xorp is
>     Aidan> running on my wireless nodes. I have a very simple
>     Aidan> configuration and really I could probably get away with
>     Aidan> static routing throughout the entire network, but I wanted to
>     Aidan> try xorp and see just how stable it was. However as I expand
>     Aidan> the network I am having second thoughts. It is not good at
>     Aidan> all when a network goes up in smoke and I can't explain why
>     Aidan> or predict when and what the causes are.  The network has
>     Aidan> been in operation 24x7 for around 9 months. I am running on a
>     Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
>     Aidan> have no issues. However now for the fourth time I see the
>     Aidan> same problem: Suddenly the Linux kernel and the xorp rib
>     Aidan> become detached. Normally all routes in the kernel match
>     Aidan> those that xorp is generating, receiving and electing as
>     Aidan> active. I am running OSPF and the neighbour states remain
>     Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
>     Aidan> only in one direction (i.e nothing being transmitted from the
>     Aidan> router I suspect). The lsdb of OSPF on the suspect and
>     Aidan> adjacent routers contain all the routes but they are aging
>     Aidan> out slowly on the adjacent router. When I look at the kernel
>     Aidan> routes those from OSPF have already vanished.  I can see the
>     Aidan> ospf process running on the offending router? and again I can
>     Aidan> see the ospf lsdb intact and correct. When I restart xorp the
>     Aidan> system recovers and the routes appear in the kernel again. I
>     Aidan> suspect a problem with ospf. I tried enabling traceoptions on
>     Aidan> the ospf process, but in fact I needed to restart all the
>     Aidan> xorp processes before this actually became active. I now have
>     Aidan> this running so if/when it happens again I might be able to
>     Aidan> offer some more information.  Does anyone have any experience
>     Aidan> of ospf begin unstable? any suggestions how I might more
>     Aidan> effectively capture some logs from this event. I do not see
>     Aidan> any options for logging the fea process. Is there anything I
>     Aidan> can enable to help diagnose the issue?  Many thanks, and of
>     Aidan> course cheers for the code in the first place.  Aidan
>     Aidan> _______________________________________________ Xorp-users
>     Aidan> mailing list Xorp-users at xorp.org
>     Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From greearb at candelatech.com  Wed Dec  5 11:26:39 2007
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 05 Dec 2007 11:26:39 -0800
Subject: [Xorp-users] Example config files for connecting different OSPF
	areas?
Message-ID: <4756FB6F.2070007@candelatech.com>


Hello!

I am trying to understand how OSPF areas work and are configured in
Xorp.

To start with, would this be a valid scenario:

Router1,Area-0.0.0.0   -- ethernet -- Router1,Area-1.1.1.1

I assume that if I can get these talking, I can easily add more routers to
each of the areas connected to one of the routers above...

Does anyone have a set of example Xorp configs for this scenario?

Thanks,
Ben

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


From rsuk at ucsc.edu  Wed Dec  5 12:54:35 2007
From: rsuk at ucsc.edu (Robert Joseph Suk)
Date: Wed, 05 Dec 2007 12:54:35 -0800
Subject: [Xorp-users] xorp with click and RIP
Message-ID: <web-13360335@email-prod-be-1.ucsc.edu>

Hello,
  I'm trying to set up a xorp/click configuration which 
runs RIP. I have RIP working with xorp, but when I enable 
the user click forwarding path, I get strange behavior. If 
I 'duplicate-routes-to-kernel' everything works fine. 
However, when I don't duplicate routes-to-kernel, the 
routes still show up in xorpsh (show route table ipv4 
unicast rip/final), but if I ping any of those addresses, 
I get 'no route to host'. Xorp also cannot send RIP 
updates, getting the send_from_multicast_if failed.

The reason I want to turn 'duplicate-routes-to-kernel' 
off, is so that I can check that the click forwarding path 
is working.

I already added a static route 0.0.0.0/0 to an attached 
interface, and put "multicast_host="YES"" in my rc.conf.
I'm running BSD6.2, and my xorp config is below. The click 
config I'm running is simply the one generated by 
'make-ip-conf.pl' which is a basic IP router
Any ideas why xorp sees the routes in xorpsh but can't use 
them?


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: true
         }

         unicast-forwarding6 {
                 disable: true
         }

         click {
                 disable: false  /*run autogenerated 
config from /conf/make-ip-conf.pl*/
                 duplicate-routes-to-kernel: true

                 kernel-click{
                         disable: true
                 }

                 user-click{
                         disable: false
                         command-file: 
"/usr/local/bin/click"
                         command-extra-arguments: "-R"
                         command-execute-on-startup: true
                         startup-config-file: 
"/usr/local/xorp/iprouter_auto.click"
                         user-click-config-generator-file: 
"/usr/local/fea/xorp_fea_click_config_generator"
                 }
         }
} /* </fea> */
plumbing{
         mfea4 {
                 disable: true
         }
         mfea6{
                 disable: true
         }
}
policy {
         /*Describe connected routes for redistribution*/
         policy-statement connected {
                 term export {
                         from {
                                 protocol: "connected"
                         }
                 }
         }
}

protocols {
         static{
                 route 0.0.0.0/0{
                         next-hop: 10.0.2.22
                         metric: 1
                 }
         }
         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>*/



-Robbie


From kristian at spritelink.net  Wed Dec  5 14:19:07 2007
From: kristian at spritelink.net (Kristian Larsson)
Date: Wed, 5 Dec 2007 23:19:07 +0100
Subject: [Xorp-users] Example config files for connecting different	OSPF
	areas?
In-Reply-To: <4756FB6F.2070007@candelatech.com>
References: <4756FB6F.2070007@candelatech.com>
Message-ID: <20071205221906.GA32997@spritelink.se>

On Wed, Dec 05, 2007 at 11:26:39AM -0800, Ben Greear wrote:
> 
> Hello!
> 
> I am trying to understand how OSPF areas work and are configured in
> Xorp.
> 
> To start with, would this be a valid scenario:
> 
> Router1,Area-0.0.0.0   -- ethernet -- Router1,Area-1.1.1.1

Yes, having one interface in one area and another
interface in another area makes this router an ABR = Area Border
Router. OSPF will by default (and unlike IS-IS) redistribute
routes between areas (with a few exceptions).

 
> I assume that if I can get these talking, I can easily add more routers to
> each of the areas connected to one of the routers above...
> 
> Does anyone have a set of example Xorp configs for this scenario?

It's basically the same as with only one area..
with the exception that you have more than one
area ;)
Have you run into any problems?

  Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
Network Engineer & Peering Coordinator      SpriteLink [AS39525]
+46 704 910401			              kll at spritelink.net


From greearb at candelatech.com  Wed Dec  5 14:29:52 2007
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 05 Dec 2007 14:29:52 -0800
Subject: [Xorp-users] Example config files for connecting different	OSPF
 areas?
In-Reply-To: <20071205221906.GA32997@spritelink.se>
References: <4756FB6F.2070007@candelatech.com>
	<20071205221906.GA32997@spritelink.se>
Message-ID: <47572660.2060500@candelatech.com>

Kristian Larsson wrote:

>> I assume that if I can get these talking, I can easily add more routers to
>> each of the areas connected to one of the routers above...
>>
>> Does anyone have a set of example Xorp configs for this scenario?
> 
> It's basically the same as with only one area..
> with the exception that you have more than one
> area ;)
> Have you run into any problems?

I was having conceptual issues..didn't realize area pertained to interfaces
as opposed to the entire ospf configuration.  I also got lost trying to figure
out normal, stub, and nssa modes..but it seems I can ignore that for now and
just use normal.

Working on setting it up as you propose now...

Thanks,
Ben

> 
>   Kristian.
> 


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


From greearb at candelatech.com  Wed Dec  5 16:21:38 2007
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 05 Dec 2007 16:21:38 -0800
Subject: [Xorp-users] Example config files for connecting different	OSPF
 areas?
In-Reply-To: <20071205221906.GA32997@spritelink.se>
References: <4756FB6F.2070007@candelatech.com>
	<20071205221906.GA32997@spritelink.se>
Message-ID: <47574092.7090705@candelatech.com>

Kristian Larsson wrote:

> It's basically the same as with only one area..
> with the exception that you have more than one
> area ;)
> Have you run into any problems?

Ok, this is probably another basic misunderstanding of OSPF on my part:

I have router 1, with 2 interfaces: 10.3.0.1/24, 10.3.1.5/24 and area 0.0.0.1
A third interface is in area 0.0.0.0
That interface connects to router 2, which in turn connects to
router 3.  All interfaces in R2, R3 are area 0.0.0.0

I was hoping that the routing table for R2 would
show something like:

10.3.0.0/16 via 10.0.0.1 dev rddVR1  proto xorp  metric 2 notify

(ie, consolidate the two 10.3 subnets into a single route).

Instead, I see:

10.3.0.0/24 via 10.0.0.1 dev rddVR1  proto xorp  metric 2 notify
10.3.1.0/24 via 10.0.0.1 dev rddVR1  proto xorp  metric 2 notify


Now, after a bit more thinking..this sounds like it couldn't really
work since there may be other 10.3.x.x subnets elsewhere.  But, is there
a way to somehow tell it that we have all 10.3.x.x/24 subnets on or
behind R1 so that only the 10.3.0.0/16 route is propagated to the
rest of the OSPF network?

My config for R1 is below, if that helps.

Thanks,
Ben


     protocols {
         ospf4 {
             router-id: 127.1.0.2
             traceoptions {
                 flag {
                     all {
                     }
                 }
             }
             area 0.0.0.0 {
                 interface rddVR0 {
                     vif rddVR0 {
                         address 10.0.0.1 {
                         }
                     }
                 }
             }
             area 0.0.0.1 {
                 interface rddVR3 {
                     vif rddVR3 {
                         address 10.3.1.5 {
                         }
                     }
                 }
                 interface br2 {
                     vif br2 {
                         address 10.3.0.1 {
                         }
                     }
                 }
             }
         }
         static {
             interface-route 0.0.0.0/0 {
                 next-hop-interface: "my_discard"
                 next-hop-vif: "my_discard"
             }
         }
     }
     fea {
         unicast-forwarding4 {
             table-id: 10002
         }
     }
     interfaces {
         interface "my_discard" {
             unreachable: true
             vif "my_discard" {
             }
         }
         interface rddVR0 {
             vif rddVR0 {
                 address 10.0.0.1 {
                     prefix-length: 24
                 }
             }
         }
         interface rddVR3 {
             vif rddVR3 {
                 address 10.3.1.5 {
                     prefix-length: 24
                 }
             }
         }
         interface br2 {
             vif br2 {
                 address 10.3.0.1 {
                     prefix-length: 24
                 }
             }
         }
     }

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


From hantongs at gmail.com  Thu Dec  6 03:19:43 2007
From: hantongs at gmail.com (Hansi)
Date: Thu, 6 Dec 2007 19:19:43 +0800
Subject: [Xorp-users] Fwd: Fwd: Problem in IPv6 SSM Multicast
In-Reply-To: <2f9e317b0712050540m3a6571dcq83488b0dbc5913e@mail.gmail.com>
References: <hantongs@gmail.com>
	<2f9e317b0712040438r492183fxe0926d026aa55c90@mail.gmail.com>
	<200712041846.lB4IkfWN055887@possum.icir.org>
	<2f9e317b0712050540m3a6571dcq83488b0dbc5913e@mail.gmail.com>
Message-ID: <2f9e317b0712060319m37ddce34tc1df221325c391f4@mail.gmail.com>

Hello Pavlin,

Finally, IPv6 PIM SSM is working. :) Here are the details:

admin at demo_rtr.infoweapons.com> show mld group
Interface    Group           Source          LastReported Timeout V State
sk0          ff02::2         ::              fe80::219:5bff:fe85:cfc7
159 1     E
sk0          ff02::d         ::              fe80::219:5bff:fe85:cfc7
159 1     E
sk0          ff02::16        ::              fe80::219:5bff:fe85:cfc7
159 1     E
sk0          ff02::1:ff00:1  ::              fe80::219:5bff:fe85:cfc7
159 1     E
sk0          ff02::1:ff2f:1468 ::              fe80::219:5bff:fe2f:1468
166 2     E
sk0          ff02::1:ff85:cfc7 ::              fe80::219:5bff:fe85:cfc7
159 1     E
sk0          ff02::2:15ba:6cf7 ::              fe80::219:5bff:fe85:cfc7
159 1     E
sk0          ff3e::1234      ::              fe80::219:5bff:fe2f:1468
0 2     I
sk0          ff3e::1234      2001:ec2:4002:fa11:200:24ff:fec4:3235
fe80::219:5bff:fe2f:1468     166 2     F

Visible in the Show MLD Group is the multicast address FF3E:1234 and the
source
2001:ec2:4002:fa11:200:24ff:fec4:3235 w/c indicates that xorp successfully
received a MLDv2 Join message from the client receiver application.

What's odd though is that I don't see any video displayed in the vlc
receiver application. I'm quite sure PIM-SSM is already working as I can see
these packets on the interface of the receiver connected to the upstream
router:

17:19:39.634155 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x9a8d7789:0|1232) 65336 > 1234: UDP, length 1316
17:19:39.646131 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x89a0d7d2:0|1232) 65336 > 1234: UDP, length 1316
17:19:39.659118 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x960ae0a2:0|1232) 65336 > 1234: UDP, length 1316
17:19:39.670100 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xaa68e0b2:0|1232) 65336 > 1234: UDP, length 1316
17:19:39.683136 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x856c81f0:0|1232) 65336 > 1234: UDP, length 1316
17:19:39.695087 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xd64fbf0f:0|1232) 65336 > 1234: UDP, length 1316
17:19:39.708045 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x99f7d97b:0|1232) 65336 > 1234: UDP, length 1316
17:19:39.720029 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xdc3a139d:0|1232) 65336 > 1234: UDP, length 1316
17:19:39.732111 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xa3688a13:0|1232) 65336 > 1234: UDP, length 1316
17:19:47.410658 IP6 (hlim 1, next-header: Options (0), length: 52)
fe80::219:5bff:fe2f:1468 > ff02::16: HBH (rtalert: 0x0000) (padn)ICMP6,
multicast listener report v2, length 44, 1 group record(s) [gaddr ff3e::1234
block {[|icmp6]

Is there something wrong with the packets arriving at the receiver's side?

Thanks,
Hansi

On Dec 5, 2007 9:40 PM, Hansi <hantongs at gmail.com> wrote:


> Hello Pavlin,
>
> I've consulted w/ the VLC authors and everything appears to be alright w/
> the VLC player according to them. Weird... anyway, I'll review my setup. I
> might have overlooked something though..
>
> Thanks for your assistance.
>
> Hansi
>
> On Dec 5, 2007 2:46 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > > > > > show mld group
> > > > >
> > > > >
> > > > > Interface    Group           Source          LastReported Timeout
> > V
> > > > State
> > > > > sk0          ff02::2         ::
> >  fe80::219:5bff:fe85:cfc7
> > > > > 243 1     E
> > > > > sk0          ff02::d         ::
> >  fe80::219:5bff:fe85:cfc7
> > > > > 243 1     E
> > > > > sk0          ff02::16        ::
> >  fe80::219:5bff:fe85:cfc7
> > > > > 243 1     E
> > > > > sk0          ff02::1:ff00:1  ::
> >  fe80::219:5bff:fe85:cfc7
> > > > > 243 1     E
> > > > > sk0          ff02::1:ff2f:1468 ::
> >  fe80::219:5bff:fe2f:1468
> > > > > 248 2     E
> > > > > sk0          ff02::1:ff85:cfc7 ::
> >  fe80::219:5bff:fe85:cfc7
> > > > > 243 1     E
> > > > > sk0          ff02::2:15ba:6cf7 ::
> >  fe80::219:5bff:fe85:cfc7
> > > > > 243 1     E
> > > >
> > > > It doesn't seem that the client/receiver with IPv6 address
> > > > 2001:ec2:4002:fa11:200:24ff:fec4:3235 has joined group ff3e::1234.
> > >
> > >
> > > The ipv6 address 2001:ec2:4002:fa11:200:24ff
> > > >
> > > > :fec4:3235 is the address of the streaming server. :)
> > > >
> > >
> > > > So your guess in your original email is correct: there is something
> > > > wrong with the receiver so it hasn't joined the multicast group.
> > > > Could you run tcpdump to capture all ICMPv6 (incl. MLD) traffic and
> > > > confirm that XORP is sending the periodic query messages, but the
> > > > receiver itself never sends MLDv2 Join messages.
> > >
> > >
> > > Here are the logs from tcpdump taken on the LAN side of the router
> > (router
> > > ----- receiver)
> > > 20:24:32.872230 IP6 (hlim 1, next-header: Options (0), length: 36)
> > > fe80::219:5bff:fe85:cfc7 > ip6-allnodes: HBH (rtalert: 0x0000)
> > (padn)[icmp6
> > > sum ok] ICMP6, multicast listener query, length 28v2  [max resp
> > delay=10000]
> > > [gaddr :: robustness=2 qqi=125]
> >
> > OK: the router sends the Query
> >
> > > 20:24:32.876596 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::16: HBH (padn)(rtalert: 0x0000)
> > [icmp6 sum
> > > ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
> >
> > > ff02::16
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::16
> >
> > > 20:24:32.892588 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ip6-allrouters: HBH (padn)(rtalert: 0x0000)
> >
> > > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> > delay: 0
> > > addr: ip6-allrouters
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ip6-allrouters
> >
> > > 20:24:32.906594 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::d: HBH (padn)(rtalert: 0x0000) [icmp6
> > sum
> > > ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
> >
> > > ff02::d
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::d
> >
> > > 20:24:32.906613 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::1:ff00:1: HBH (padn)(rtalert: 0x0000)
> >
> > > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> > delay: 0
> > > addr: ff02::1:ff00:1
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::1:ff00:1
> >
> > > 20:24:32.906634 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::2:15ba:6cf7: HBH (padn)(rtalert:
> > 0x0000)
> > > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> > delay: 0
> > > addr: ff02::2:15ba:6cf7
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::2:15ba:6cf7
> >
> > > 20:24:32.910605 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::1:ff85:cfc7: HBH (padn)(rtalert:
> > 0x0000)
> > > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> > delay: 0
> > > addr: ff02::1:ff85:cfc7
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::1:ff85:cfc7
> >
> > > 20:24:37.389295 IP6 (hlim 1, next-header: Options (0), length: 36)
> > > fe80::219:5bff:fe2f:1468 > ff02::16: HBH (rtalert: 0x0000)
> > (padn)[icmp6 sum
> > > ok] ICMP6, multicast listener report v2, length 28, 1 group record(s)
> > [gaddr
> > > ff02::1:ff2f:1468 is_ex { }]
> >
> > OK: MLDv2 Report from the client that it is a member of group
> > ff02::1:ff2f:1468 for all sources.
> >
> > It appears that the MLDv2 join mechanism between the client and the
> > router is working for group ff02::1:ff2f:1468 (which is the group
> > automatically joined by the kernel on the client's interface).
> >
> > However, I don't seen any join for the multicast group from the
> > client's application.
> >
> > > Back when I was exploring ipv4 ssm, everytime I click either on the
> > play or
> > > stop button of the vlc client, I always see an IGMP join or prune
> > message.
> > > Shouldn't  it that it also applies to MLDv2? However, I'm not seeing
> > any
> > > here.
> >
> > I am not familiar with vlc, but what you say is the logically
> > expected behavior.
> > You might want to contact the vlc author(s) about that.
> >
> > > > BTW, what about MLDv1 Join messages? If you configure the client to
> > > > join some (*,G) multicast group does it initiate MLDv1 Join?
> > > >
> > > My current setup is intended for PIM-SSM traffic. Can it also apply to
> > PIM
> > > SM considering the setup consist of only two routers?
> >
> > Yes, you can, but then you must configure one of the routers as the
> > RP. For testing purpose you could just try without any
> > RP. Obviously, multicast routing won't work, but the "show mld
> > group" output will tell us whether MLDv1 Join works for the
> > application (and whether the router will record that).
> >
> > Regards,
> > Pavlin
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071206/3c2c4be4/attachment-0001.html 

From bbb999 at zerodistance.fi  Thu Dec  6 03:22:26 2007
From: bbb999 at zerodistance.fi (Arsi Antila)
Date: Thu, 6 Dec 2007 13:22:26 +0200
Subject: [Xorp-users] BGP crash
In-Reply-To: <84a612dd0712030943h7e49dab3u6970b29ef1d19e91@mail.gmail.com>
References: <20071203102100.GA12449@zerodistance.fi>
	<84a612dd0712030943h7e49dab3u6970b29ef1d19e91@mail.gmail.com>
Message-ID: <20071206112226.GA29713@zerodistance.fi>

The BGP crash situation was tested using both Linux/CentOS/XORP 1.4 and
Linux/Debian/Debian XORP package 1.5~cvs.20070824-1, and it seems to occur in
both environments. The key to get BGP to crash seems to be a combination of a
policy rule (even a simple one), a network like the one described below (or
similar), and flapping BGP peers.

The test network has DUT (device under test, XORP) with eth1 connected to both
Router1 (AS 1) and Router2 (AS 2). DUT eth2 port is connected to Router3 (AS 1)
and Router4 (AS 2).

Test sequence to get XORP BGP to crash is: start routers 1-4, start XORP, make
Router2 go down, make Router2 go up. After this XORP crashes.

Here is XORP output for the crash:


[ 2007/12/05 13:31:18 INFO xorp_bgp BGP ] Peer-{10.10.20.20(179)
10.10.20.40(179)} in state ESTABLISHED(6) received Notification Packet:
Cease(6)
[ 2007/12/05 13:31:18 INFO xorp_bgp BGP ] Peer-{10.10.10.20(179)
10.10.10.30(179)} in state ESTABLISHED(6) received Notification Packet:
Cease(6)
[ 2007/12/05 13:31:19 INFO xorp_bgp BGP ] Peer-{10.10.10.20(179)
10.10.10.40(179)} in state ESTABLISHED(6) received Notification Packet:
Cease(6)
[ 2007/12/05 13:31:19 INFO xorp_bgp BGP ] Peer-{10.10.20.20(179)
10.10.20.30(179)} in state ESTABLISHED(6) received Notification Packet:
Cease(6)
[ 2007/12/05 13:31:34  FATAL xorp_bgp:10028 BGP +83 route_table_cache.cc
add_route ] Internal fatal error: unreachable code reached
[ 2007/12/05 13:31:34  ERROR xorp_rtrmgr:10024 RTRMGR +747
module_manager.cc done_cb ] Command "/usr/local/xorp/bgp/xorp_bgp":
terminated with signal 6.
[ 2007/12/05 13:31:34  INFO xorp_rtrmgr:10024 RTRMGR +294
module_manager.cc module_exited ] Module abnormally killed: bgp
[ 2007/12/05 13:31:34 INFO xorp_rib RIB ] Received death event for
protocol bgp shutting down -------
OriginTable: ebgp
EGP
next table = Merged:(ebgp)+(ibgp)
[ 2007/12/05 13:31:34 INFO xorp_rib RIB ] Received death event for
protocol bgp shutting down -------
OriginTable: ebgp
EGP
next table = Merged:(ebgp)+(ibgp)
[ 2007/12/05 13:31:34 INFO xorp_rib RIB ] Received death event for
protocol bgp shutting down -------
OriginTable: ebgp
EGP
next table = Merged:(ebgp)+(ibgp)
[ 2007/12/05 13:31:34 INFO xorp_rib RIB ] Received death event for
protocol bgp shutting down -------
OriginTable: ebgp
EGP
next table = Merged:(ebgp)+(ibgp)



Here is the configuration:

interfaces {
    restore-original-config-on-shutdown: false

    interface eth1 {
        description: "router interface"
        disable: false
        default-system-config
    }

    interface eth2 {
        description: "router interface"
        disable: false
        default-system-config
    }

}

fea {
    unicast-forwarding4 {
        disable: false
    }
}

policy {
    policy-statement block {
        term bgp_65400 {
            from {
                protocol: "bgp"
            }
            then {
                accept
            }
        }
    }
}

protocols {
    bgp {
        bgp-id: 10.100.100.2
        local-as: 65000
        peer 10.10.10.30 {
            local-ip: 10.10.10.20
            as: 65300
            next-hop: 10.10.10.20
        }
        peer 10.10.10.40 {
            local-ip: 10.10.10.20
            as: 65400
            next-hop: 10.10.10.20
        }
        peer 10.10.20.30 {
            local-ip: 10.10.20.20
            as: 65300
            next-hop: 10.10.20.20
        }
        peer 10.10.20.40 {
            local-ip: 10.10.20.20
            as: 65400
            next-hop: 10.10.20.20
        }
        export: "block"
    }
}



An example of 'show bgp peers' and 'show bgp routes' from another test, just
before a crash. All routes are marked as best.

root at ipca> show bgp peers
Peer 1: local 10.10.10.20/179 remote 10.10.10.30/179
Peer 2: local 10.10.10.20/179 remote 10.10.10.40/179
Peer 3: local 10.10.20.20/179 remote 10.10.20.30/179
Peer 4: local 10.10.20.20/179 remote 10.10.20.40/179
root at ipca> show bgp routes
Status Codes: * valid route, > best route
Origin Codes: i IGP, e EGP, ? incomplete

   Prefix                Nexthop                    Peer            AS 
Path
   ------                -------                    ----            
-------
*> 2.0.0.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 1.0.0.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 2.0.0.0/24            10.10.10.40                10.100.100.14  65400 
i
*> 1.0.0.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 1.0.1.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 1.0.2.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 1.0.3.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 1.0.4.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 1.0.5.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 1.0.6.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 1.0.7.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 1.0.8.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 1.0.9.0/24            10.10.10.30                10.100.100.13  65300 
i
*> 2.0.1.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 2.0.2.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 2.0.3.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 2.0.4.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 2.0.5.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 2.0.6.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 2.0.7.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 2.0.8.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 2.0.9.0/24            10.10.20.40                10.100.100.24  65400 
i
*> 1.0.1.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 1.0.2.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 1.0.3.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 1.0.4.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 1.0.5.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 1.0.6.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 1.0.7.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 1.0.8.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 1.0.9.0/24            10.10.20.30                10.100.100.23  65300 
i
*> 2.0.1.0/24            10.10.10.40                10.100.100.14  65400 
i
*> 2.0.2.0/24            10.10.10.40                10.100.100.14  65400 
i
*> 2.0.3.0/24            10.10.10.40                10.100.100.14  65400 
i
*> 2.0.4.0/24            10.10.10.40                10.100.100.14  65400 
i
*> 2.0.5.0/24            10.10.10.40                10.100.100.14  65400 
i
*> 2.0.6.0/24            10.10.10.40                10.100.100.14  65400 
i
*> 2.0.7.0/24            10.10.10.40                10.100.100.14  65400 
i
*> 2.0.8.0/24            10.10.10.40                10.100.100.14  65400 
i
*> 2.0.9.0/24            10.10.10.40                10.100.100.14  65400 
i



Regards,
Arsi

On Mon, Dec 03, 2007 at 05:43:49PM +0000, Mark Handley wrote:
> Xorp should not crash; I don't think this is a known issue.  Can you
> clarify - which Xorp process crashes?  The subject implies BGP, but I
> just want to be sure.
> 
> Also I'm not clear on the scenario - BGP doesn't advertise ASs to
> interfaces - it advertises them via BGP connections which are only
> loosely connected to interfaces (if you choose an interface IP address
> for the connection endpoint).  Do you mean the BGP has peering
> configured using the local IP addresses of the three ethernets in your
> scenario?
> 
> Which AS is the router that crashes in?
> 
> Your text says 5 routers, but I'm not sure where the 5th one is - the
> minimum needed to implement something like you describe is 4 (One each
> for AS1, AS2, AS3 and the router that crashes).  Where's the 5th one?
> 
> Also could you send the policy config you used to prevent route redistribution?
> 
> If we understood the scenario, we can build a test suite to tickle
> this problem, but right now I don't really know how to do this.
> 
>  - Mark
> 
> On Dec 3, 2007 10:21 AM, Arsi Antila <bbb999 at zerodistance.fi> wrote:
> > Is the following a known problem in XORP?
> >
> > Note: this was shown to me by someone else. I didn't test this myself,
> > so some of the details may be incorrect.
> >
> > XORP crashes when the same set of BGP routes is advertised from two
> > different routers connected to the same interface and the winning route
> > changes. Tested with VLANs, if-aliases and plain interfaces. Results do
> > not vary.
> >
> >
> > For example, configuration of the network is as follows:
> >
> > - device under test (Linux/Debian, XORP) and five simulated routers
> >
> > - AS 1 is advertised to ports eth1 and eth2
> >
> > - AS 2 is advertised to ports eth1 and eth2
> >
> > - AS 3 is advertised to port eth3
> >
> > - Policy rules so that AS 2 routes are not advertised to AS 1
> >
> > BGP process dies when one of the routers in AS 2 goes down and then up
> > so that the primary route in AS 2 changes.
> >
> >
> > Regards,
> > A.A.
> >
> > _______________________________________________
> > Xorp-users mailing list
> > Xorp-users at xorp.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> >


From kristian at spritelink.net  Thu Dec  6 04:05:10 2007
From: kristian at spritelink.net (Kristian Larsson)
Date: Thu, 6 Dec 2007 13:05:10 +0100
Subject: [Xorp-users] Example config files for connecting different	OSPF
	areas?
In-Reply-To: <47574092.7090705@candelatech.com>
References: <4756FB6F.2070007@candelatech.com>
	<20071205221906.GA32997@spritelink.se>
	<47574092.7090705@candelatech.com>
Message-ID: <20071206120510.GB32997@spritelink.se>

On Wed, Dec 05, 2007 at 04:21:38PM -0800, Ben Greear wrote:
> Kristian Larsson wrote:
> 
>> It's basically the same as with only one area..
>> with the exception that you have more than one
>> area ;)
>> Have you run into any problems?
> 
> Ok, this is probably another basic misunderstanding of OSPF on my part:
> 
> I have router 1, with 2 interfaces: 10.3.0.1/24, 10.3.1.5/24 and area 
> 0.0.0.1
> A third interface is in area 0.0.0.0
> That interface connects to router 2, which in turn connects to
> router 3.  All interfaces in R2, R3 are area 0.0.0.0
> 
> I was hoping that the routing table for R2 would
> show something like:
> 
> 10.3.0.0/16 via 10.0.0.1 dev rddVR1  proto xorp  metric 2 notify
> 
> (ie, consolidate the two 10.3 subnets into a single route).

Okey, yes, this is not how areas work. Areas are
simply to limit the scope of an SPF calculation.
Routes from one (normal) area to another (normal)
area is distributed as an external route.

I'm not certain about XORP, but Cisco provides
functionality to aggregate prefixes into larger
ones, but it's not completely automatic, you still
have to specify the aggregates by hand.

Stubby areas usually just contain a default from
the ABR(s).


> Instead, I see:
> 
> 10.3.0.0/24 via 10.0.0.1 dev rddVR1  proto xorp  metric 2 notify
> 10.3.1.0/24 via 10.0.0.1 dev rddVR1  proto xorp  metric 2 notify
> 
> 
> Now, after a bit more thinking..this sounds like it couldn't really
> work since there may be other 10.3.x.x subnets elsewhere.  But, is there
> a way to somehow tell it that we have all 10.3.x.x/24 subnets on or
> behind R1 so that only the 10.3.0.0/16 route is propagated to the
> rest of the OSPF network?

Dunno about XORP ;)

  -K

-- 
Kristian Larsson                                        KLL-RIPE
Network Engineer & Peering Coordinator      SpriteLink [AS39525]
+46 704 910401			              kll at spritelink.net


From joshihirenn at gmail.com  Thu Dec  6 01:30:30 2007
From: joshihirenn at gmail.com (hiren joshi)
Date: Thu, 6 Dec 2007 15:00:30 +0530
Subject: [Xorp-users] Session Announcement Protocol (SAP) and XORP
Message-ID: <29820bf40712060130u23b7cda1ofce03cf9a53a085f@mail.gmail.com>

Is there any configuration required for SAP packets?
Particularly how a multicast router will act against SAP packets (destined
to 224.2.127.254) received?

Thanks in advance.
-hiren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071206/dd631bca/attachment.html 

From pavlin at icir.org  Thu Dec  6 11:36:10 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 06 Dec 2007 11:36:10 -0800
Subject: [Xorp-users] Session Announcement Protocol (SAP) and XORP
In-Reply-To: Message from "hiren joshi" <joshihirenn@gmail.com> of "Thu,
	06 Dec 2007 15:00:30 +0530."
	<29820bf40712060130u23b7cda1ofce03cf9a53a085f@mail.gmail.com> 
Message-ID: <200712061936.lB6JaAmx098372@possum.icir.org>

> Is there any configuration required for SAP packets?
> Particularly how a multicast router will act against SAP packets (destined
> to 224.2.127.254) received?

The multicast routing protocol (PIM-SM) won't threat the SAP packets
any differently. It will just forward them as appropriate same as
any other multicast packet.
The only exception is the link-local multicast (224.0.0.0/24) which
are not forwarded beyond the local subnet, but the SAP address
doesn't fail into that range.

Regards,
Pavlin


From pavlin at icir.org  Thu Dec  6 12:00:42 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 06 Dec 2007 12:00:42 -0800
Subject: [Xorp-users] Fwd: Fwd: Problem in IPv6 SSM Multicast
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Thu,
	06 Dec 2007 19:19:43 +0800."
	<2f9e317b0712060319m37ddce34tc1df221325c391f4@mail.gmail.com> 
Message-ID: <200712062000.lB6K0ghj098659@possum.icir.org>

> Finally, IPv6 PIM SSM is working. :) Here are the details:

Good!
What was the source of the problem?

> What's odd though is that I don't see any video displayed in the vlc
> receiver application. I'm quite sure PIM-SSM is already working as I can see
> these packets on the interface of the receiver connected to the upstream
> router:
> 
> 17:19:39.634155 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x9a8d7789:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.646131 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x89a0d7d2:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.659118 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x960ae0a2:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.670100 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xaa68e0b2:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.683136 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x856c81f0:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.695087 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xd64fbf0f:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.708045 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x99f7d97b:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.720029 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xdc3a139d:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.732111 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xa3688a13:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:47.410658 IP6 (hlim 1, next-header: Options (0), length: 52)
> fe80::219:5bff:fe2f:1468 > ff02::16: HBH (rtalert: 0x0000) (padn)ICMP6,
> multicast listener report v2, length 44, 1 group record(s) [gaddr ff3e::1234
> block {[|icmp6]
> 
> Is there something wrong with the packets arriving at the receiver's side?

It looks like the IPv6 UDP packets that reach the receiver are
fragmented. Also, I could be wrong here, but it appears that only
the first fragment of each packet reaches the receiver, and the
second segment is missing. The way I interpretate the above log
messages is that the size of each original UDP packet is 1316, but
each of the above fragments contains only 1240 bytes.

FYI, the IPv6 fragmentation should happen at the sender so you need
to run tcpdump on the sender's segment to see whether it really
sends all fragments. You should be looking for the smaller fragments
with size of 76 or so.

Once you solve the above problem, you should also try to eliminate
the reason for the fragmentation. E.g., if the sender's application
allows you to control the transmitted packet size then you should
eventually reduce it to avoid the fragmentation penalty.
However, I'd strongly recommend that first you fix the problem with
the missing fragments. Otherwise, if you mask it by reducing the
packet size it will come and bite you at later stage :)

Regards,
Pavlin


From pavlin at icir.org  Thu Dec  6 12:39:47 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 06 Dec 2007 12:39:47 -0800
Subject: [Xorp-users] xorp with click and RIP
In-Reply-To: Message from "Robert Joseph Suk" <rsuk@ucsc.edu> of "Wed,
	05 Dec 2007 12:54:35 PST." <web-13360335@email-prod-be-1.ucsc.edu> 
Message-ID: <200712062039.lB6Kdlfr099040@possum.icir.org>

>   I'm trying to set up a xorp/click configuration which 
> runs RIP. I have RIP working with xorp, but when I enable 
> the user click forwarding path, I get strange behavior. If 
> I 'duplicate-routes-to-kernel' everything works fine. 
> However, when I don't duplicate routes-to-kernel, the 
> routes still show up in xorpsh (show route table ipv4 
> unicast rip/final), but if I ping any of those addresses, 
> I get 'no route to host'. Xorp also cannot send RIP 
> updates, getting the send_from_multicast_if failed.

First the (hopefully) easy part:
As you know already, FreeBSD requires to have a matching route
(e.g., 0.0.0.0/0) in the unicast forwarding table in the kernel to
be able to originate multicast packets. If you use XORP to configure
the 0.0.0.0/0 static route, and if "duplicate-routes-to-kernel" is
disabled, this route won't reach the kernel.
Hence, to get around this problem you should add 0.0.0.0/0 to the
kernel by hand before starting XORP.

> The reason I want to turn 'duplicate-routes-to-kernel' 
> off, is so that I can check that the click forwarding path 
> is working.
> 
> I already added a static route 0.0.0.0/0 to an attached 
> interface, and put "multicast_host="YES"" in my rc.conf.
> I'm running BSD6.2, and my xorp config is below. The click 
> config I'm running is simply the one generated by 
> 'make-ip-conf.pl' which is a basic IP router
> Any ideas why xorp sees the routes in xorpsh but can't use 
> them?

If you are to use your own static config with make-ip-conf.pl, it
will be safer if you also modify the sample
"/usr/local/fea/xorp_fea_click_config_generator" generator to
unconditionally return that configuration. FYI, the config generator
is automatically called by XORP whenenever something in the
interface configuration changes, so on startup it might actually be
overwriting your own static config.

Once you eliminate the config generation factor, then you need to
investigate whether userland Click itself is working as
expected. For that purpose I'd recommend to start userland Click by
hand (without XORP), and then manually configure it with your static
config (including the routes that should be generated by RIP).
Then do the ping test to see whether userland Click on its own is
fine.
One thing to have in mind is that the ping packets originated on the
router running Click might not actually be processed by Click: such
packets will lookup the unicast forwarding table in the kernel, and
therefore fail. Hence, you might want to run ping on a machine
directly connected to the router running Click.

Hopefully the above tests will narrow the problem.

Regards,
Pavlin

P.S. In your config you don't need the plumbing/mfea4 and mfea6
sections.


> 
> 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: true
>          }
> 
>          unicast-forwarding6 {
>                  disable: true
>          }
> 
>          click {
>                  disable: false  /*run autogenerated 
> config from /conf/make-ip-conf.pl*/
>                  duplicate-routes-to-kernel: true
> 
>                  kernel-click{
>                          disable: true
>                  }
> 
>                  user-click{
>                          disable: false
>                          command-file: 
> "/usr/local/bin/click"
>                          command-extra-arguments: "-R"
>                          command-execute-on-startup: true
>                          startup-config-file: 
> "/usr/local/xorp/iprouter_auto.click"
>                          user-click-config-generator-file: 
> "/usr/local/fea/xorp_fea_click_config_generator"
>                  }
>          }
> } /* </fea> */
> plumbing{
>          mfea4 {
>                  disable: true
>          }
>          mfea6{
>                  disable: true
>          }
> }
> policy {
>          /*Describe connected routes for redistribution*/
>          policy-statement connected {
>                  term export {
>                          from {
>                                  protocol: "connected"
>                          }
>                  }
>          }
> }
> 
> protocols {
>          static{
>                  route 0.0.0.0/0{
>                          next-hop: 10.0.2.22
>                          metric: 1
>                  }
>          }
>          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>*/
> 
> 
> 
> -Robbie
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From M.Handley at cs.ucl.ac.uk  Thu Dec  6 14:00:30 2007
From: M.Handley at cs.ucl.ac.uk (Mark Handley)
Date: Thu, 6 Dec 2007 22:00:30 +0000
Subject: [Xorp-users] BGP crash
In-Reply-To: <20071206112226.GA29713@zerodistance.fi>
References: <20071203102100.GA12449@zerodistance.fi>
	<84a612dd0712030943h7e49dab3u6970b29ef1d19e91@mail.gmail.com>
	<20071206112226.GA29713@zerodistance.fi>
Message-ID: <84a612dd0712061400v27f7eaddl5449a857d1f50985@mail.gmail.com>

Thanks - that should be sufficient to build a test suite case.

The crash is one where BGP is sending a route to a peer (not sure
which yet) and detects internally that it's already sent a version of
the same route without (internally) withdrawing that route first.
This triggers an internal sanity check because this should never
happen, and BGP aborts to preserve the evidence of the bug.  In
general these cases are hard to debug, but this one shouldn't be too
bad as you've given us a lot to go on.

Thank you!

 - Mark

On Dec 6, 2007 11:22 AM, Arsi Antila <bbb999 at zerodistance.fi> wrote:
> The BGP crash situation was tested using both Linux/CentOS/XORP 1.4 and
> Linux/Debian/Debian XORP package 1.5~cvs.20070824-1, and it seems to occur in
> both environments. The key to get BGP to crash seems to be a combination of a
> policy rule (even a simple one), a network like the one described below (or
> similar), and flapping BGP peers.
>
> The test network has DUT (device under test, XORP) with eth1 connected to both
> Router1 (AS 1) and Router2 (AS 2). DUT eth2 port is connected to Router3 (AS 1)
> and Router4 (AS 2).
>
> Test sequence to get XORP BGP to crash is: start routers 1-4, start XORP, make
> Router2 go down, make Router2 go up. After this XORP crashes.
>
> Here is XORP output for the crash:
>
>
> [ 2007/12/05 13:31:18 INFO xorp_bgp BGP ] Peer-{10.10.20.20(179)
> 10.10.20.40(179)} in state ESTABLISHED(6) received Notification Packet:
> Cease(6)
> [ 2007/12/05 13:31:18 INFO xorp_bgp BGP ] Peer-{10.10.10.20(179)
> 10.10.10.30(179)} in state ESTABLISHED(6) received Notification Packet:
> Cease(6)
> [ 2007/12/05 13:31:19 INFO xorp_bgp BGP ] Peer-{10.10.10.20(179)
> 10.10.10.40(179)} in state ESTABLISHED(6) received Notification Packet:
> Cease(6)
> [ 2007/12/05 13:31:19 INFO xorp_bgp BGP ] Peer-{10.10.20.20(179)
> 10.10.20.30(179)} in state ESTABLISHED(6) received Notification Packet:
> Cease(6)
> [ 2007/12/05 13:31:34  FATAL xorp_bgp:10028 BGP +83 route_table_cache.cc
> add_route ] Internal fatal error: unreachable code reached
> [ 2007/12/05 13:31:34  ERROR xorp_rtrmgr:10024 RTRMGR +747
> module_manager.cc done_cb ] Command "/usr/local/xorp/bgp/xorp_bgp":
> terminated with signal 6.
> [ 2007/12/05 13:31:34  INFO xorp_rtrmgr:10024 RTRMGR +294
> module_manager.cc module_exited ] Module abnormally killed: bgp
> [ 2007/12/05 13:31:34 INFO xorp_rib RIB ] Received death event for
> protocol bgp shutting down -------
> OriginTable: ebgp
> EGP
> next table = Merged:(ebgp)+(ibgp)
> [ 2007/12/05 13:31:34 INFO xorp_rib RIB ] Received death event for
> protocol bgp shutting down -------
> OriginTable: ebgp
> EGP
> next table = Merged:(ebgp)+(ibgp)
> [ 2007/12/05 13:31:34 INFO xorp_rib RIB ] Received death event for
> protocol bgp shutting down -------
> OriginTable: ebgp
> EGP
> next table = Merged:(ebgp)+(ibgp)
> [ 2007/12/05 13:31:34 INFO xorp_rib RIB ] Received death event for
> protocol bgp shutting down -------
> OriginTable: ebgp
> EGP
> next table = Merged:(ebgp)+(ibgp)
>
>
>
> Here is the configuration:
>
> interfaces {
>     restore-original-config-on-shutdown: false
>
>     interface eth1 {
>         description: "router interface"
>         disable: false
>         default-system-config
>     }
>
>     interface eth2 {
>         description: "router interface"
>         disable: false
>         default-system-config
>     }
>
> }
>
> fea {
>     unicast-forwarding4 {
>         disable: false
>     }
> }
>
> policy {
>     policy-statement block {
>         term bgp_65400 {
>             from {
>                 protocol: "bgp"
>             }
>             then {
>                 accept
>             }
>         }
>     }
> }
>
> protocols {
>     bgp {
>         bgp-id: 10.100.100.2
>         local-as: 65000
>         peer 10.10.10.30 {
>             local-ip: 10.10.10.20
>             as: 65300
>             next-hop: 10.10.10.20
>         }
>         peer 10.10.10.40 {
>             local-ip: 10.10.10.20
>             as: 65400
>             next-hop: 10.10.10.20
>         }
>         peer 10.10.20.30 {
>             local-ip: 10.10.20.20
>             as: 65300
>             next-hop: 10.10.20.20
>         }
>         peer 10.10.20.40 {
>             local-ip: 10.10.20.20
>             as: 65400
>             next-hop: 10.10.20.20
>         }
>         export: "block"
>     }
> }
>
>
>
> An example of 'show bgp peers' and 'show bgp routes' from another test, just
> before a crash. All routes are marked as best.
>
> root at ipca> show bgp peers
> Peer 1: local 10.10.10.20/179 remote 10.10.10.30/179
> Peer 2: local 10.10.10.20/179 remote 10.10.10.40/179
> Peer 3: local 10.10.20.20/179 remote 10.10.20.30/179
> Peer 4: local 10.10.20.20/179 remote 10.10.20.40/179
> root at ipca> show bgp routes
> Status Codes: * valid route, > best route
> Origin Codes: i IGP, e EGP, ? incomplete
>
>    Prefix                Nexthop                    Peer            AS
> Path
>    ------                -------                    ----
> -------
> *> 2.0.0.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 1.0.0.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 2.0.0.0/24            10.10.10.40                10.100.100.14  65400
> i
> *> 1.0.0.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 1.0.1.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 1.0.2.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 1.0.3.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 1.0.4.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 1.0.5.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 1.0.6.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 1.0.7.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 1.0.8.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 1.0.9.0/24            10.10.10.30                10.100.100.13  65300
> i
> *> 2.0.1.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 2.0.2.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 2.0.3.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 2.0.4.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 2.0.5.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 2.0.6.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 2.0.7.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 2.0.8.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 2.0.9.0/24            10.10.20.40                10.100.100.24  65400
> i
> *> 1.0.1.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 1.0.2.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 1.0.3.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 1.0.4.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 1.0.5.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 1.0.6.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 1.0.7.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 1.0.8.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 1.0.9.0/24            10.10.20.30                10.100.100.23  65300
> i
> *> 2.0.1.0/24            10.10.10.40                10.100.100.14  65400
> i
> *> 2.0.2.0/24            10.10.10.40                10.100.100.14  65400
> i
> *> 2.0.3.0/24            10.10.10.40                10.100.100.14  65400
> i
> *> 2.0.4.0/24            10.10.10.40                10.100.100.14  65400
> i
> *> 2.0.5.0/24            10.10.10.40                10.100.100.14  65400
> i
> *> 2.0.6.0/24            10.10.10.40                10.100.100.14  65400
> i
> *> 2.0.7.0/24            10.10.10.40                10.100.100.14  65400
> i
> *> 2.0.8.0/24            10.10.10.40                10.100.100.14  65400
> i
> *> 2.0.9.0/24            10.10.10.40                10.100.100.14  65400
> i
>
>
>
> Regards,
> Arsi
>
> On Mon, Dec 03, 2007 at 05:43:49PM +0000, Mark Handley wrote:
>
> > Xorp should not crash; I don't think this is a known issue.  Can you
> > clarify - which Xorp process crashes?  The subject implies BGP, but I
> > just want to be sure.
> >
> > Also I'm not clear on the scenario - BGP doesn't advertise ASs to
> > interfaces - it advertises them via BGP connections which are only
> > loosely connected to interfaces (if you choose an interface IP address
> > for the connection endpoint).  Do you mean the BGP has peering
> > configured using the local IP addresses of the three ethernets in your
> > scenario?
> >
> > Which AS is the router that crashes in?
> >
> > Your text says 5 routers, but I'm not sure where the 5th one is - the
> > minimum needed to implement something like you describe is 4 (One each
> > for AS1, AS2, AS3 and the router that crashes).  Where's the 5th one?
> >
> > Also could you send the policy config you used to prevent route redistribution?
> >
> > If we understood the scenario, we can build a test suite to tickle
> > this problem, but right now I don't really know how to do this.
> >
> >  - Mark
> >
> > On Dec 3, 2007 10:21 AM, Arsi Antila <bbb999 at zerodistance.fi> wrote:
> > > Is the following a known problem in XORP?
> > >
> > > Note: this was shown to me by someone else. I didn't test this myself,
> > > so some of the details may be incorrect.
> > >
> > > XORP crashes when the same set of BGP routes is advertised from two
> > > different routers connected to the same interface and the winning route
> > > changes. Tested with VLANs, if-aliases and plain interfaces. Results do
> > > not vary.
> > >
> > >
> > > For example, configuration of the network is as follows:
> > >
> > > - device under test (Linux/Debian, XORP) and five simulated routers
> > >
> > > - AS 1 is advertised to ports eth1 and eth2
> > >
> > > - AS 2 is advertised to ports eth1 and eth2
> > >
> > > - AS 3 is advertised to port eth3
> > >
> > > - Policy rules so that AS 2 routes are not advertised to AS 1
> > >
> > > BGP process dies when one of the routers in AS 2 goes down and then up
> > > so that the primary route in AS 2 changes.
> > >
> > >
> > > Regards,
> > > A.A.
> > >
> > > _______________________________________________
> > > Xorp-users mailing list
> > > Xorp-users at xorp.org
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> > >
>


From Dragos.Ciobanu at xerox.com  Thu Dec  6 16:52:52 2007
From: Dragos.Ciobanu at xerox.com (Ciobanu, Dragos O)
Date: Thu, 6 Dec 2007 16:52:52 -0800
Subject: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
	fticonfig_entry_set_netlink.cc add_entry ] Error checking
	netlink request
Message-ID: <9C245B9CF8CC6647B6BD9237D6C7EFA98085E8@USA7061MS04.na.xerox.net>


I'm trying to configure a xorp router with static routes for IPv6. In
xorpsh I can commit the static route, but the output for xorp_rtrmgr
gives me this error:

ERROR: xorp_fea:4361 FEA +324 fticonfig_entry_set_netlink.cc add_entry ]
Error checking netlink request: AF_NETLINK NLMSG_ERROR message: Invalid
argument. 

I'm using xorp 1.4. 

Has anyone else seen this and could help me?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071206/47e64a43/attachment-0001.html 

From pavlin at icir.org  Thu Dec  6 16:59:17 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 06 Dec 2007 16:59:17 -0800
Subject: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
	fticonfig_entry_set_netlink.cc add_entry ] Error checking
	netlink request
In-Reply-To: Message from "Ciobanu, Dragos O" <Dragos.Ciobanu@xerox.com> 
	of "Thu, 06 Dec 2007 16:52:52 PST."
	<9C245B9CF8CC6647B6BD9237D6C7EFA98085E8@USA7061MS04.na.xerox.net>
Message-ID: <200712070059.lB70xHuq007354@possum.icir.org>

Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:

> 
> I'm trying to configure a xorp router with static routes for IPv6. In
> xorpsh I can commit the static route, but the output for xorp_rtrmgr
> gives me this error:
> 
> ERROR: xorp_fea:4361 FEA +324 fticonfig_entry_set_netlink.cc add_entry ]
> Error checking netlink request: AF_NETLINK NLMSG_ERROR message: Invalid
> argument. 
> 
> I'm using xorp 1.4. 
> 
> Has anyone else seen this and could help me?

What OS and kernel version are you using?

Also, can you try the latest code from anon. CVS:
http://www.xorp.org/cvs.html
It contains various bug fixes, but no guarantee it contains the fix
for the error you see.

Regards,
Pavlin


From Dragos.Ciobanu at xerox.com  Thu Dec  6 17:13:20 2007
From: Dragos.Ciobanu at xerox.com (Ciobanu, Dragos O)
Date: Thu, 6 Dec 2007 17:13:20 -0800
Subject: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
	fticonfig_entry_set_netlink.cc add_entry ] Error checking
	netlink request
In-Reply-To: <200712070059.lB70xHuq007354@possum.icir.org>
References: Message from "Ciobanu,
	Dragos O" <Dragos.Ciobanu@xerox.com>    of "Thu,
	06 Dec 2007 16:52:52 PST."
	<9C245B9CF8CC6647B6BD9237D6C7EFA98085E8@USA7061MS04.na.xerox.net>
	<200712070059.lB70xHuq007354@possum.icir.org>
Message-ID: <9C245B9CF8CC6647B6BD9237D6C7EFA98085F8@USA7061MS04.na.xerox.net>

I'm using Ubuntu 7.10 Server. Kernel version is 2.6.22-14.
Thanks for the suggestion, I'll install the latest code from the cvs to
see what's going to happen. 

-----Original Message-----
From: Pavlin Radoslavov [mailto:pavlin at icir.org] 
Sent: Thursday, December 06, 2007 4:59 PM
To: Ciobanu, Dragos O
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
fticonfig_entry_set_netlink.cc add_entry ] Error checking netlink
request 

Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:

> 
> I'm trying to configure a xorp router with static routes for IPv6. In 
> xorpsh I can commit the static route, but the output for xorp_rtrmgr 
> gives me this error:
> 
> ERROR: xorp_fea:4361 FEA +324 fticonfig_entry_set_netlink.cc add_entry

> ] Error checking netlink request: AF_NETLINK NLMSG_ERROR message: 
> Invalid argument.
> 
> I'm using xorp 1.4. 
> 
> Has anyone else seen this and could help me?

What OS and kernel version are you using?

Also, can you try the latest code from anon. CVS:
http://www.xorp.org/cvs.html
It contains various bug fixes, but no guarantee it contains the fix for
the error you see.

Regards,
Pavlin


From rsuk at ucsc.edu  Thu Dec  6 17:43:05 2007
From: rsuk at ucsc.edu (Robert Joseph Suk)
Date: Thu, 06 Dec 2007 17:43:05 -0800
Subject: [Xorp-users] xorp with click and RIP
In-Reply-To: <200712062039.lB6Kdlfr099040@possum.icir.org>
References: <200712062039.lB6Kdlfr099040@possum.icir.org>
Message-ID: <web-13669118@email-prod-be-1.ucsc.edu>

Thanks for your reply, Pavlin.
I'm not exactly sure the best way to get the 
xorp_fea_click_config_generator to unconditionally return 
my static config, but I replaced the config_generator 
script with my config file, inside a printf("") and it 
seems to work.  I also made sure to rename my 
LinearIPlookup from "rt" to "_xorp_rt4" so xorp could 
handle it.  The router still receives updates from 
neighboring routers and updates the RIB, but now xorp 
throws an error:

[ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +71 
fti_transaction.cc operation_result ] FTI transaction 
commit failed on AddE
ntry4: net = 10.0.0.0/24 nexthop = 10.0.2.22 ifname = xl0 
vifname = xl0 metric = 2 admin_distance = 120 xorp_route = 
true is_d
eleted = false is_unresolved = false is_connected_route = 
false
[ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +301 
fticonfig_entry_set_click.cc add_entry ] Cannot find 
outgoing port number
for the Click forwarding table element to add entry net = 
10.0.1.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname = xl0 
metric =
1 admin_distance = 120 xorp_route = true is_deleted = 
false is_unresolved = false is_connected_route = false


and click still won't function.
When I run "click myconfig.click", pings across the router 
work fine, while pinging the router directly generates 
Duplicate replies (one from the kernel, and one from 
click).
As a debug, in my click config I added a Tee to the output 
of xl0 and copied all click-generated responses out to The 
other interface, xl1. Now when I ping the router, I can 
see the extra traffic on a TCPdump of xl1.  When I run 
xorp with my config and ping the router, I only get one 
response, and nothing on xl1, leading me to believe that 
either my click config isn't running, or it just isnt 
getting any traffic.


On Thu, 06 Dec 2007 12:39:47 -0800
  Pavlin Radoslavov <pavlin at icir.org> wrote:
>>   I'm trying to set up a xorp/click configuration which 
>> runs RIP. I have RIP working with xorp, but when I 
>>enable 
>> the user click forwarding path, I get strange behavior. 
>>If 
>> I 'duplicate-routes-to-kernel' everything works fine. 
>> However, when I don't duplicate routes-to-kernel, the 
>> routes still show up in xorpsh (show route table ipv4 
>> unicast rip/final), but if I ping any of those 
>>addresses, 
>> I get 'no route to host'. Xorp also cannot send RIP 
>> updates, getting the send_from_multicast_if failed.
> 
>First the (hopefully) easy part:
> As you know already, FreeBSD requires to have a matching 
>route
> (e.g., 0.0.0.0/0) in the unicast forwarding table in the 
>kernel to
> be able to originate multicast packets. If you use XORP 
>to configure
> the 0.0.0.0/0 static route, and if 
>"duplicate-routes-to-kernel" is
> disabled, this route won't reach the kernel.
> Hence, to get around this problem you should add 
>0.0.0.0/0 to the
> kernel by hand before starting XORP.
> 
>> The reason I want to turn 'duplicate-routes-to-kernel' 
>> off, is so that I can check that the click forwarding 
>>path 
>> is working.
>> 
>> I already added a static route 0.0.0.0/0 to an attached 
>> interface, and put "multicast_host="YES"" in my rc.conf.
>> I'm running BSD6.2, and my xorp config is below. The 
>>click 
>> config I'm running is simply the one generated by 
>> 'make-ip-conf.pl' which is a basic IP router
>> Any ideas why xorp sees the routes in xorpsh but can't 
>>use 
>> them?
> 
> If you are to use your own static config with 
>make-ip-conf.pl, it
> will be safer if you also modify the sample
> "/usr/local/fea/xorp_fea_click_config_generator" 
>generator to
> unconditionally return that configuration. FYI, the 
>config generator
> is automatically called by XORP whenenever something in 
>the
> interface configuration changes, so on startup it might 
>actually be
> overwriting your own static config.
> 
> Once you eliminate the config generation factor, then 
>you need to
> investigate whether userland Click itself is working as
> expected. For that purpose I'd recommend to start 
>userland Click by
> hand (without XORP), and then manually configure it with 
>your static
> config (including the routes that should be generated by 
>RIP).
> Then do the ping test to see whether userland Click on 
>its own is
> fine.
> One thing to have in mind is that the ping packets 
>originated on the
> router running Click might not actually be processed by 
>Click: such
> packets will lookup the unicast forwarding table in the 
>kernel, and
> therefore fail. Hence, you might want to run ping on a 
>machine
> directly connected to the router running Click.
> 
> Hopefully the above tests will narrow the problem.
> 
> Regards,
> Pavlin
> 
> P.S. In your config you don't need the plumbing/mfea4 
>and mfea6
> sections.
> 
> 
>> 
>> 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: true
>>          }
>> 
>>          unicast-forwarding6 {
>>                  disable: true
>>          }
>> 
>>          click {
>>                  disable: false  /*run autogenerated 
>> config from /conf/make-ip-conf.pl*/
>>                  duplicate-routes-to-kernel: true
>> 
>>                  kernel-click{
>>                          disable: true
>>                  }
>> 
>>                  user-click{
>>                          disable: false
>>                          command-file: 
>> "/usr/local/bin/click"
>>                          command-extra-arguments: "-R"
>>                          command-execute-on-startup: 
>>true
>>                          startup-config-file: 
>> "/usr/local/xorp/iprouter_auto.click"
>>                          user-click-config-generator-file: 
>> "/usr/local/fea/xorp_fea_click_config_generator"
>>                  }
>>          }
>> } /* </fea> */
>> plumbing{
>>          mfea4 {
>>                  disable: true
>>          }
>>          mfea6{
>>                  disable: true
>>          }
>> }
>> policy {
>>          /*Describe connected routes for 
>>redistribution*/
>>          policy-statement connected {
>>                  term export {
>>                          from {
>>                                  protocol: "connected"
>>                          }
>>                  }
>>          }
>> }
>> 
>> protocols {
>>          static{
>>                  route 0.0.0.0/0{
>>                          next-hop: 10.0.2.22
>>                          metric: 1
>>                  }
>>          }
>>          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>*/
>> 
>> 
>> 
>> -Robbie
>> 
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

-Robbie


From pavlin at icir.org  Thu Dec  6 18:01:55 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 06 Dec 2007 18:01:55 -0800
Subject: [Xorp-users] xorp with click and RIP
In-Reply-To: Message from "Robert Joseph Suk" <rsuk@ucsc.edu> of "Thu,
	06 Dec 2007 17:43:05 PST." <web-13669118@email-prod-be-1.ucsc.edu> 
Message-ID: <200712070201.lB721tDk008173@possum.icir.org>

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

> Thanks for your reply, Pavlin.
> I'm not exactly sure the best way to get the 
> xorp_fea_click_config_generator to unconditionally return 
> my static config, but I replaced the config_generator 
> script with my config file, inside a printf("") and it 
> seems to work.  I also made sure to rename my 
> LinearIPlookup from "rt" to "_xorp_rt4" so xorp could 
> handle it.  The router still receives updates from 

Yes, this hack should do it.

> neighboring routers and updates the RIB, but now xorp 
> throws an error:
> 
> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +71 
> fti_transaction.cc operation_result ] FTI transaction 
> commit failed on AddE
> ntry4: net = 10.0.0.0/24 nexthop = 10.0.2.22 ifname = xl0 
> vifname = xl0 metric = 2 admin_distance = 120 xorp_route = 
> true is_d
> eleted = false is_unresolved = false is_connected_route = 
> false
> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +301 
> fticonfig_entry_set_click.cc add_entry ] Cannot find 
> outgoing port number
> for the Click forwarding table element to add entry net = 
> 10.0.1.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname = xl0 
> metric =
> 1 admin_distance = 120 xorp_route = true is_deleted = 
> false is_unresolved = false is_connected_route = false

There seems to be some error with adding the routes to Click.
Could you update to the latest XORP from CVS.
The update might not fix the problem, but will make it easier to
debug it:

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

Please send me your latest XORP configuration as well as your
hacked xorp_fea_click_config_generator.
Also, please tell me the Click version you are using.

Thanks,
Pavlin

> 
> and click still won't function.
> When I run "click myconfig.click", pings across the router 
> work fine, while pinging the router directly generates 
> Duplicate replies (one from the kernel, and one from 
> click).
> As a debug, in my click config I added a Tee to the output 
> of xl0 and copied all click-generated responses out to The 
> other interface, xl1. Now when I ping the router, I can 
> see the extra traffic on a TCPdump of xl1.  When I run 
> xorp with my config and ping the router, I only get one 
> response, and nothing on xl1, leading me to believe that 
> either my click config isn't running, or it just isnt 
> getting any traffic.
> 
> 
> On Thu, 06 Dec 2007 12:39:47 -0800
>   Pavlin Radoslavov <pavlin at icir.org> wrote:
> >>   I'm trying to set up a xorp/click configuration which 
> >> runs RIP. I have RIP working with xorp, but when I 
> >>enable 
> >> the user click forwarding path, I get strange behavior. 
> >>If 
> >> I 'duplicate-routes-to-kernel' everything works fine. 
> >> However, when I don't duplicate routes-to-kernel, the 
> >> routes still show up in xorpsh (show route table ipv4 
> >> unicast rip/final), but if I ping any of those 
> >>addresses, 
> >> I get 'no route to host'. Xorp also cannot send RIP 
> >> updates, getting the send_from_multicast_if failed.
> > 
> >First the (hopefully) easy part:
> > As you know already, FreeBSD requires to have a matching 
> >route
> > (e.g., 0.0.0.0/0) in the unicast forwarding table in the 
> >kernel to
> > be able to originate multicast packets. If you use XORP 
> >to configure
> > the 0.0.0.0/0 static route, and if 
> >"duplicate-routes-to-kernel" is
> > disabled, this route won't reach the kernel.
> > Hence, to get around this problem you should add 
> >0.0.0.0/0 to the
> > kernel by hand before starting XORP.
> > 
> >> The reason I want to turn 'duplicate-routes-to-kernel' 
> >> off, is so that I can check that the click forwarding 
> >>path 
> >> is working.
> >> 
> >> I already added a static route 0.0.0.0/0 to an attached 
> >> interface, and put "multicast_host="YES"" in my rc.conf.
> >> I'm running BSD6.2, and my xorp config is below. The 
> >>click 
> >> config I'm running is simply the one generated by 
> >> 'make-ip-conf.pl' which is a basic IP router
> >> Any ideas why xorp sees the routes in xorpsh but can't 
> >>use 
> >> them?
> > 
> > If you are to use your own static config with 
> >make-ip-conf.pl, it
> > will be safer if you also modify the sample
> > "/usr/local/fea/xorp_fea_click_config_generator" 
> >generator to
> > unconditionally return that configuration. FYI, the 
> >config generator
> > is automatically called by XORP whenenever something in 
> >the
> > interface configuration changes, so on startup it might 
> >actually be
> > overwriting your own static config.
> > 
> > Once you eliminate the config generation factor, then 
> >you need to
> > investigate whether userland Click itself is working as
> > expected. For that purpose I'd recommend to start 
> >userland Click by
> > hand (without XORP), and then manually configure it with 
> >your static
> > config (including the routes that should be generated by 
> >RIP).
> > Then do the ping test to see whether userland Click on 
> >its own is
> > fine.
> > One thing to have in mind is that the ping packets 
> >originated on the
> > router running Click might not actually be processed by 
> >Click: such
> > packets will lookup the unicast forwarding table in the 
> >kernel, and
> > therefore fail. Hence, you might want to run ping on a 
> >machine
> > directly connected to the router running Click.
> > 
> > Hopefully the above tests will narrow the problem.
> > 
> > Regards,
> > Pavlin
> > 
> > P.S. In your config you don't need the plumbing/mfea4 
> >and mfea6
> > sections.
> > 
> > 
> >> 
> >> 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: true
> >>          }
> >> 
> >>          unicast-forwarding6 {
> >>                  disable: true
> >>          }
> >> 
> >>          click {
> >>                  disable: false  /*run autogenerated 
> >> config from /conf/make-ip-conf.pl*/
> >>                  duplicate-routes-to-kernel: true
> >> 
> >>                  kernel-click{
> >>                          disable: true
> >>                  }
> >> 
> >>                  user-click{
> >>                          disable: false
> >>                          command-file: 
> >> "/usr/local/bin/click"
> >>                          command-extra-arguments: "-R"
> >>                          command-execute-on-startup: 
> >>true
> >>                          startup-config-file: 
> >> "/usr/local/xorp/iprouter_auto.click"
> >>                          user-click-config-generator-file: 
> >> "/usr/local/fea/xorp_fea_click_config_generator"
> >>                  }
> >>          }
> >> } /* </fea> */
> >> plumbing{
> >>          mfea4 {
> >>                  disable: true
> >>          }
> >>          mfea6{
> >>                  disable: true
> >>          }
> >> }
> >> policy {
> >>          /*Describe connected routes for 
> >>redistribution*/
> >>          policy-statement connected {
> >>                  term export {
> >>                          from {
> >>                                  protocol: "connected"
> >>                          }
> >>                  }
> >>          }
> >> }
> >> 
> >> protocols {
> >>          static{
> >>                  route 0.0.0.0/0{
> >>                          next-hop: 10.0.2.22
> >>                          metric: 1
> >>                  }
> >>          }
> >>          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>*/
> >> 
> >> 
> >> 
> >> -Robbie
> >> 
> >> _______________________________________________
> >> Xorp-users mailing list
> >> Xorp-users at xorp.org
> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> 
> -Robbie
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From Dragos.Ciobanu at xerox.com  Thu Dec  6 18:10:06 2007
From: Dragos.Ciobanu at xerox.com (Ciobanu, Dragos O)
Date: Thu, 6 Dec 2007 18:10:06 -0800
Subject: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
	fticonfig_entry_set_netlink.cc add_entry ] Error checking
	netlink request
In-Reply-To: <200712070059.lB70xHuq007354@possum.icir.org>
References: Message from "Ciobanu,
	Dragos O" <Dragos.Ciobanu@xerox.com>    of "Thu,
	06 Dec 2007 16:52:52 PST."
	<9C245B9CF8CC6647B6BD9237D6C7EFA98085E8@USA7061MS04.na.xerox.net>
	<200712070059.lB70xHuq007354@possum.icir.org>
Message-ID: <9C245B9CF8CC6647B6BD9237D6C7EFA9808610@USA7061MS04.na.xerox.net>

Sorry Pavlin, 

But I couldn't log in to the CVS server. I tried leaving the password
blank and  it gives me this error: 
Cvs [login aborted]: end of file from server

Is the CVS server up?

-----Original Message-----
From: Pavlin Radoslavov [mailto:pavlin at icir.org] 
Sent: Thursday, December 06, 2007 4:59 PM
To: Ciobanu, Dragos O
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
fticonfig_entry_set_netlink.cc add_entry ] Error checking netlink
request 

Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:

> 
> I'm trying to configure a xorp router with static routes for IPv6. In 
> xorpsh I can commit the static route, but the output for xorp_rtrmgr 
> gives me this error:
> 
> ERROR: xorp_fea:4361 FEA +324 fticonfig_entry_set_netlink.cc add_entry

> ] Error checking netlink request: AF_NETLINK NLMSG_ERROR message: 
> Invalid argument.
> 
> I'm using xorp 1.4. 
> 
> Has anyone else seen this and could help me?

What OS and kernel version are you using?

Also, can you try the latest code from anon. CVS:
http://www.xorp.org/cvs.html
It contains various bug fixes, but no guarantee it contains the fix for
the error you see.

Regards,
Pavlin


From pavlin at icir.org  Thu Dec  6 18:19:10 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 06 Dec 2007 18:19:10 -0800
Subject: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
	fticonfig_entry_set_netlink.cc add_entry ] Error checking
	netlink request
In-Reply-To: Message from "Ciobanu, Dragos O" <Dragos.Ciobanu@xerox.com> 
	of "Thu, 06 Dec 2007 18:10:06 PST."
	<9C245B9CF8CC6647B6BD9237D6C7EFA9808610@USA7061MS04.na.xerox.net>
Message-ID: <200712070219.lB72JAQR008427@possum.icir.org>

Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:

> Sorry Pavlin, 
> 
> But I couldn't log in to the CVS server. I tried leaving the password
> blank and  it gives me this error: 
> Cvs [login aborted]: end of file from server
> 
> Is the CVS server up?

I just tried it and it works for me:

pavlin at xorp13[25] setenv CVSROOT :pserver:xorpcvs at anoncvs.xorp.org:/cvs
pavlin at xorp13[26] cvs login
Logging in to :pserver:xorpcvs at anoncvs.xorp.org:2401/cvs
CVS password: 
pavlin at xorp13[27] cvs checkout xorp
cvs checkout: Updating xorp
U xorp/.cvsignore
U xorp/BUGS
U xorp/BUILD_NOTES
U xorp/ERRATA
^Ccvs [checkout aborted]: received interrupt signal
Exit 1
pavlin at xorp13[28] 

Note that "setenv" is used by csh/tcsh; If your login shell is bash,
then replace the first line with
export CVSROOT=:pserver:xorpcvs at anoncvs.xorp.org:/cvs

Pavlin

> -----Original Message-----
> From: Pavlin Radoslavov [mailto:pavlin at icir.org] 
> Sent: Thursday, December 06, 2007 4:59 PM
> To: Ciobanu, Dragos O
> Cc: xorp-users at xorp.org
> Subject: Re: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
> fticonfig_entry_set_netlink.cc add_entry ] Error checking netlink
> request 
> 
> Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:
> 
> > 
> > I'm trying to configure a xorp router with static routes for IPv6. In 
> > xorpsh I can commit the static route, but the output for xorp_rtrmgr 
> > gives me this error:
> > 
> > ERROR: xorp_fea:4361 FEA +324 fticonfig_entry_set_netlink.cc add_entry
> 
> > ] Error checking netlink request: AF_NETLINK NLMSG_ERROR message: 
> > Invalid argument.
> > 
> > I'm using xorp 1.4. 
> > 
> > Has anyone else seen this and could help me?
> 
> What OS and kernel version are you using?
> 
> Also, can you try the latest code from anon. CVS:
> http://www.xorp.org/cvs.html
> It contains various bug fixes, but no guarantee it contains the fix for
> the error you see.
> 
> Regards,
> Pavlin
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From atanu at ICSI.Berkeley.EDU  Thu Dec  6 20:13:25 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Thu, 06 Dec 2007 20:13:25 -0800
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: Message from Aidan Walton <awalton@wires3.net> of "Wed,
	05 Dec 2007 18:54:04 GMT." <1196880844.3790.41.camel@bass.wires3.net> 
Message-ID: <61495.1197000805@tigger.icir.org>

Hi,

The problem that I see is that that both routers (89.248.141.221 and
89.248.141.222) are announcing a Network-LSA for the subnet
89.248.141.196/30. There should only be one Network-LSA per subnet, an 
unfortunate side effect of this behaviour is that from the perspective
of the LSA database routers 89.248.141.221 and 89.248.141.222 are not
connected, hence no routes.

Only the designated router (DR) for a subnet should be announcing a
Network-LSA from the output of "show ospf4 neighbor detail" router
89.248.141.221 doesn't consider itself to be the DR (router
89.248.141.222 is the DR, 89.248.141.197 is its interface address).

>From the sequence number and age of the Network-LSA generated by router
89.248.141.221 we can see that it was initially announced 6 mins 48
secs ago, which is similar to the 8 mins 32 secs the adjacency has
existed.

Router 89.248.141.221 is announcing a Network-LSA even though it is not
the DR. The odd part is that the Network-LSA was initially announced
after the adjacency was formed and a DR had already been selected.

Could you try running the latest code from CVS some DR election issues
have been fixed since the last release?

My guess would be that the problem only occurs after a loss of
adjacency. The default settings for hello-interval and
router-dead-interval are 10 and 40 seconds respectively. You could try
decreasing the hello-interval and increasing router-dead-interval until
we get to the bottom of this.

Next time you see a problem:
1) $ print_lsas -S save.lsas
2) show ospf4 neighbor detail (On the router in question and the neighbour)
Just to confirm the problem.

I will try and reproduce the problem.

	   Atanu.

   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Network  89.248.141.197   89.248.141.222   0x8000003b   409  0x2  0xaf92  32
Network *89.248.141.198   89.248.141.221   0x80000001   409  0x2  0x2458  32

>>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:

    Aidan> Hi Atanu, Now that I'm over the panic of collecting the data
    Aidan> and recovering the network. I can see that the neighbour
    Aidan> seems to have been up for 29hrs but adjacent for only
    Aidan> 8mins. Clearly the adjacency has been dropped and even though
    Aidan> it has recovered it no longer imports the routes from the
    Aidan> database. Unfortunately because I do not have the logs, as
    Aidan> explained in the last email, I have no trace of the failure
    Aidan> :( Note the tcpdump of the hellos in both directions. I
    Aidan> thought if the adjacency failed a database update would be
    Aidan> forced when it is re-established.

    Aidan> Oh BTW I checked my logs on the interfaces and the physicals
    Aidan> have been up all the time.

    Aidan> What's up with ospf?  Aidan

    Aidan> On Wed, 2007-12-05 at 01:00 -0800, Atanu Ghosh wrote:
    >> Hi,
    >> 
    >> The output that it would be good to see before and after the
    >> problem occurs.  1) $ netstat -nr 2) Xorp> show interfaces 3)
    >> Xorp> show route table ipv4 unicast final 4) Xorp> show ospf4
    >> neighbor detail 5) Xorp> show ospf4 database detail 6) $
    >> print_lsas -S save.lsas The print_lsas program can be found in
    >> ospf/tools directory. The program stores the LSA database in a
    >> form that can be replayed.
    >> 
    >> You can also enable tracing in ospf: traceoptions { flag { all {
    >> disable: false } } }
    >> 
    >> Which should show routes being added and deleted.
    >> 
    >> The latest code in CVS has a "clear ospf4 database" command, it
    >> would be interesting to know if once the problem occurs if this
    >> solves the problem.
    >> 
    >> It might also be interesting to keep the "ip mon" command running
    >> to track routes being added and deleted.
    >> 
    >> Would it be possible at some off peak time to flap the ADSL link
    >> to see if this replicates the problem. I know that you have
    >> stated that there were no ADSL issues when the problem occurred,
    >> but I do wonder if we are seeing some issue related to dynamic
    >> interfaces.
    >> 
    >> Atanu.
    >> 
    >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
    >> 
    Aidan> Hi, The adjacency runs over a wireless link between the
    Aidan> routers. It can, very possibly, drop in and out, but as far
    Aidan> as I can see this did not happen and to be honest in the 9
    Aidan> months I have had this system up I have never seen the
    Aidan> wireless link drop, but packet corruption could be a
    Aidan> possibility and this may be less easy to diagnose. It is a
    Aidan> high power 5.8GHz connection, here in the UK this is a
    Aidan> licensed band (and yes I have a license). So I don't think
    Aidan> interference is the likely cause, though I wouldn't rule this
    Aidan> out. If I look at the logs from the same period I seen
    Aidan> nothing to indicate the interface flapped, I would see the
    Aidan> wireless dis-associate and re-associate and cypher exchange
    Aidan> and this did not happen. But as I say there could be a period
    Aidan> of high BER on the links. I thought ospf would handle this
    Aidan> reasonably gracefully? I have to say heavy BER was not
    Aidan> evident when I came to repair the network, or at least I
    Aidan> didn't detect it and in the past I have run ospf over another
    Aidan> one of my wireless links with stations 10km apart with the
    Aidan> wireless link almost non-functional, dropping packets left
    Aidan> right and centre and re-associating over and over, but xorp's
    Aidan> ospf never complained!  I was beginning to suspect that this
    Aidan> was related to my adsl link on the suspect router, as this is
    Aidan> a dynamic interface and I have this defined independently of
    Aidan> xorp. If this interface flaps then the default route
    Aidan> associated with the adsl ppp session is withdrawn. The
    Aidan> default from the adsl line is not propagated into ospf
    Aidan> though, instead I use a static default with a higher metric
    Aidan> pointed at the loopback and inject this into ospf
    Aidan> instead. Then the flaps of the adsl line do not cause churn
    Aidan> in the ospf domain. I was starting to think that the addition
    Aidan> and removal of the default from the adsl line was affecting
    Aidan> the kernel table and this was upsetting xorp's ospf. However
    Aidan> this morning when this happened the adsl line was stable. As
    Aidan> far as my logs look it suddenly decided to stop functioning
    Aidan> with no correlated events from other system processes. The
    Aidan> only things in the logs at the same time is iptables dropping
    Aidan> DOS attacks, but this in normal, unfortunately far to normal.
    Aidan> show ospf4 neighbour simply stated 'full' there is only one
    Aidan> neighbour defined on this router. I didn't look this time at
    Aidan> show interfaces, but from memory of the last time this
    Aidan> happened this also was normal.  The problem is that these
    Aidan> routers are mounted 10m high up telegraph poles. If I loose
    Aidan> connectivity it requires a ladder and a climbing harness to
    Aidan> get at them, this is not to mention my upset customers who,
    Aidan> as is normal with customers, do not delay in telling me they
    Aidan> have lost their Internet links.  I suppose what I'm trying to
    Aidan> understand is how to be best prepared for next time, logging,
    Aidan> processes and checks during the failure period to grab as
    Aidan> much useful info before I am forced to restart xorp and get
    Aidan> my customers up and running again. This is a very short
    Aidan> period I have to say. I have a small group of business units
    Aidan> supported on this router and all hell breaks loose if this
    Aidan> happens during working hours.  How can I get the maximum
    Aidan> logging info from the xorp processes?  Anything I can do in
    Aidan> order that you can help me, will be dutifully carried
    Aidan> out. What next, any suggestions?  Thanks Aidan I will On Tue,
    Aidan> 2007-12-04 at 12:19 -0800, Atanu Ghosh wrote:
    >>
    Atanu> Hi,
    >>
    Atanu> The scenario that you describe would be perfectly normal if
    Atanu> the connectivity between the "suspect" router and the
    Atanu> "adjacent" router is lost. Although I would expect the "show
    Atanu> ospf4 neighbor" to show the state of the adjacency to be
    Atanu> "Down" not "Full". When an OSPF router loses its adjancencies
    Atanu> the LSA database will slowly timeout, however, the routes
    Atanu> will be withdrawn as soon as the adjacencies are lost.
    >>
    Atanu> We will require more information to diagnose the problem next
    Atanu> time the problem occurs the output of "show interfaces" and
    Atanu> "show ospf4 neighbor" would be very useful.
    >>
    Atanu> XORP tracks the state of interfaces in particular the carrier
    Atanu> state. If OSPF believes that the Ethernet has been
    Atanu> disconnected it will stop attempting to send hello
    Atanu> packets. Is it possible that there is a problem with an
    Atanu> interface or cable between the two routers?
    >>
    Atanu> Atanu.
    >>  >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
    >> 
    Aidan> Hi All, I am using xorp in a production environment,
    Aidan> admittedly a small one. I operate a local WISP and xorp is
    Aidan> running on my wireless nodes. I have a very simple
    Aidan> configuration and really I could probably get away with
    Aidan> static routing throughout the entire network, but I wanted to
    Aidan> try xorp and see just how stable it was. However as I expand
    Aidan> the network I am having second thoughts. It is not good at
    Aidan> all when a network goes up in smoke and I can't explain why
    Aidan> or predict when and what the causes are.  The network has
    Aidan> been in operation 24x7 for around 9 months. I am running on a
    Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
    Aidan> have no issues. However now for the fourth time I see the
    Aidan> same problem: Suddenly the Linux kernel and the xorp rib
    Aidan> become detached. Normally all routes in the kernel match
    Aidan> those that xorp is generating, receiving and electing as
    Aidan> active. I am running OSPF and the neighbour states remain
    Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
    Aidan> only in one direction (i.e nothing being transmitted from the
    Aidan> router I suspect). The lsdb of OSPF on the suspect and
    Aidan> adjacent routers contain all the routes but they are aging
    Aidan> out slowly on the adjacent router. When I look at the kernel
    Aidan> routes those from OSPF have already vanished.  I can see the
    Aidan> ospf process running on the offending router? and again I can
    Aidan> see the ospf lsdb intact and correct. When I restart xorp the
    Aidan> system recovers and the routes appear in the kernel again. I
    Aidan> suspect a problem with ospf. I tried enabling traceoptions on
    Aidan> the ospf process, but in fact I needed to restart all the
    Aidan> xorp processes before this actually became active. I now have
    Aidan> this running so if/when it happens again I might be able to
    Aidan> offer some more information.  Does anyone have any experience
    Aidan> of ospf begin unstable? any suggestions how I might more
    Aidan> effectively capture some logs from this event. I do not see
    Aidan> any options for logging the fea process. Is there anything I
    Aidan> can enable to help diagnose the issue?  Many thanks, and of
    Aidan> course cheers for the code in the first place.  Aidan
    Aidan> _______________________________________________ Xorp-users
    Aidan> mailing list Xorp-users at xorp.org
    Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From awalton at wires3.net  Fri Dec  7 02:39:32 2007
From: awalton at wires3.net (Aidan Walton)
Date: Fri, 07 Dec 2007 10:39:32 +0000
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: <61495.1197000805@tigger.icir.org>
References: <61495.1197000805@tigger.icir.org>
Message-ID: <1197023972.3531.52.camel@bass.wires3.net>

Hi,
This makes sense, I did not see the net LSA from .221. To be honest even
if I had I'm pretty sure I would not have thought anything was wrong. It
has been a long time since I studied OSPF's workings. I suppose I have
ensured myself a certain re-baptism of fire. If I'm not mistaken I tried
already to configure these links as point-to-point connections.
1. to avoid the DR elections process 
2. to save on IP addresses.
For some reason, I forget, it did not seem to work. This would be the
best approach to stability I would have thought as we avoid DR election
all together, but as you say if I lengthen the dead-interval it may ride
out whatever caused the adjacency to drop. The trouble is I don't think
anything on the physical side caused the adjacency to drop in the first
place, so just increasing the dead time may well not achieve stability.
Why decrease the hello interval?

Regarding the new code. This may be a stupid question but here goes. As
you know these routers are live and as I am the worlds worst admin, I
have different kernels on different routers. If I remember correctly the
xorp code I'm running on the different routers was complied off-line on
a different machine, so they are running code the was not complied
against the actually running kernel headers. Xorp does not produce
kernel modules so will this ever matter? How far can I push this? 

The important question: Is each binary produced at compile time
stand-alone. i.e. if I compile the CVS sources off-line and then take
just the ospfv2 binary, will this work with the other binaries that are
already running on the live network? Can I just replace the ospf module
or are there dependencies in the other binaries that will cause this
approach to break things. The modular approach would of course be nice !

Thanks for help so far, and I'm working on the logging issue. I had this
working in the past and now it doesn't hmmm strange?

Thanks again
Aidan


On Thu, 2007-12-06 at 20:13 -0800, Atanu Ghosh wrote:
> Hi,
> 
> The problem that I see is that that both routers (89.248.141.221 and
> 89.248.141.222) are announcing a Network-LSA for the subnet
> 89.248.141.196/30. There should only be one Network-LSA per subnet, an 
> unfortunate side effect of this behaviour is that from the perspective
> of the LSA database routers 89.248.141.221 and 89.248.141.222 are not
> connected, hence no routes.
> 
> Only the designated router (DR) for a subnet should be announcing a
> Network-LSA from the output of "show ospf4 neighbor detail" router
> 89.248.141.221 doesn't consider itself to be the DR (router
> 89.248.141.222 is the DR, 89.248.141.197 is its interface address).
> 
> >From the sequence number and age of the Network-LSA generated by router
> 89.248.141.221 we can see that it was initially announced 6 mins 48
> secs ago, which is similar to the 8 mins 32 secs the adjacency has
> existed.
> 
> Router 89.248.141.221 is announcing a Network-LSA even though it is not
> the DR. The odd part is that the Network-LSA was initially announced
> after the adjacency was formed and a DR had already been selected.
> 
> Could you try running the latest code from CVS some DR election issues
> have been fixed since the last release?
> 
> My guess would be that the problem only occurs after a loss of
> adjacency. The default settings for hello-interval and
> router-dead-interval are 10 and 40 seconds respectively. You could try
> decreasing the hello-interval and increasing router-dead-interval until
> we get to the bottom of this.
> 
> Next time you see a problem:
> 1) $ print_lsas -S save.lsas
> 2) show ospf4 neighbor detail (On the router in question and the neighbour)
> Just to confirm the problem.
> 
> I will try and reproduce the problem.
> 
> 	   Atanu.
> 
>    OSPF link state database, Area 0.0.0.0
>  Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
> Network  89.248.141.197   89.248.141.222   0x8000003b   409  0x2  0xaf92  32
> Network *89.248.141.198   89.248.141.221   0x80000001   409  0x2  0x2458  32
> 
> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
> 
>     Aidan> Hi Atanu, Now that I'm over the panic of collecting the data
>     Aidan> and recovering the network. I can see that the neighbour
>     Aidan> seems to have been up for 29hrs but adjacent for only
>     Aidan> 8mins. Clearly the adjacency has been dropped and even though
>     Aidan> it has recovered it no longer imports the routes from the
>     Aidan> database. Unfortunately because I do not have the logs, as
>     Aidan> explained in the last email, I have no trace of the failure
>     Aidan> :( Note the tcpdump of the hellos in both directions. I
>     Aidan> thought if the adjacency failed a database update would be
>     Aidan> forced when it is re-established.
> 
>     Aidan> Oh BTW I checked my logs on the interfaces and the physicals
>     Aidan> have been up all the time.
> 
>     Aidan> What's up with ospf?  Aidan
> 
>     Aidan> On Wed, 2007-12-05 at 01:00 -0800, Atanu Ghosh wrote:
>     >> Hi,
>     >> 
>     >> The output that it would be good to see before and after the
>     >> problem occurs.  1) $ netstat -nr 2) Xorp> show interfaces 3)
>     >> Xorp> show route table ipv4 unicast final 4) Xorp> show ospf4
>     >> neighbor detail 5) Xorp> show ospf4 database detail 6) $
>     >> print_lsas -S save.lsas The print_lsas program can be found in
>     >> ospf/tools directory. The program stores the LSA database in a
>     >> form that can be replayed.
>     >> 
>     >> You can also enable tracing in ospf: traceoptions { flag { all {
>     >> disable: false } } }
>     >> 
>     >> Which should show routes being added and deleted.
>     >> 
>     >> The latest code in CVS has a "clear ospf4 database" command, it
>     >> would be interesting to know if once the problem occurs if this
>     >> solves the problem.
>     >> 
>     >> It might also be interesting to keep the "ip mon" command running
>     >> to track routes being added and deleted.
>     >> 
>     >> Would it be possible at some off peak time to flap the ADSL link
>     >> to see if this replicates the problem. I know that you have
>     >> stated that there were no ADSL issues when the problem occurred,
>     >> but I do wonder if we are seeing some issue related to dynamic
>     >> interfaces.
>     >> 
>     >> Atanu.
>     >> 
>     >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
>     >> 
>     Aidan> Hi, The adjacency runs over a wireless link between the
>     Aidan> routers. It can, very possibly, drop in and out, but as far
>     Aidan> as I can see this did not happen and to be honest in the 9
>     Aidan> months I have had this system up I have never seen the
>     Aidan> wireless link drop, but packet corruption could be a
>     Aidan> possibility and this may be less easy to diagnose. It is a
>     Aidan> high power 5.8GHz connection, here in the UK this is a
>     Aidan> licensed band (and yes I have a license). So I don't think
>     Aidan> interference is the likely cause, though I wouldn't rule this
>     Aidan> out. If I look at the logs from the same period I seen
>     Aidan> nothing to indicate the interface flapped, I would see the
>     Aidan> wireless dis-associate and re-associate and cypher exchange
>     Aidan> and this did not happen. But as I say there could be a period
>     Aidan> of high BER on the links. I thought ospf would handle this
>     Aidan> reasonably gracefully? I have to say heavy BER was not
>     Aidan> evident when I came to repair the network, or at least I
>     Aidan> didn't detect it and in the past I have run ospf over another
>     Aidan> one of my wireless links with stations 10km apart with the
>     Aidan> wireless link almost non-functional, dropping packets left
>     Aidan> right and centre and re-associating over and over, but xorp's
>     Aidan> ospf never complained!  I was beginning to suspect that this
>     Aidan> was related to my adsl link on the suspect router, as this is
>     Aidan> a dynamic interface and I have this defined independently of
>     Aidan> xorp. If this interface flaps then the default route
>     Aidan> associated with the adsl ppp session is withdrawn. The
>     Aidan> default from the adsl line is not propagated into ospf
>     Aidan> though, instead I use a static default with a higher metric
>     Aidan> pointed at the loopback and inject this into ospf
>     Aidan> instead. Then the flaps of the adsl line do not cause churn
>     Aidan> in the ospf domain. I was starting to think that the addition
>     Aidan> and removal of the default from the adsl line was affecting
>     Aidan> the kernel table and this was upsetting xorp's ospf. However
>     Aidan> this morning when this happened the adsl line was stable. As
>     Aidan> far as my logs look it suddenly decided to stop functioning
>     Aidan> with no correlated events from other system processes. The
>     Aidan> only things in the logs at the same time is iptables dropping
>     Aidan> DOS attacks, but this in normal, unfortunately far to normal.
>     Aidan> show ospf4 neighbour simply stated 'full' there is only one
>     Aidan> neighbour defined on this router. I didn't look this time at
>     Aidan> show interfaces, but from memory of the last time this
>     Aidan> happened this also was normal.  The problem is that these
>     Aidan> routers are mounted 10m high up telegraph poles. If I loose
>     Aidan> connectivity it requires a ladder and a climbing harness to
>     Aidan> get at them, this is not to mention my upset customers who,
>     Aidan> as is normal with customers, do not delay in telling me they
>     Aidan> have lost their Internet links.  I suppose what I'm trying to
>     Aidan> understand is how to be best prepared for next time, logging,
>     Aidan> processes and checks during the failure period to grab as
>     Aidan> much useful info before I am forced to restart xorp and get
>     Aidan> my customers up and running again. This is a very short
>     Aidan> period I have to say. I have a small group of business units
>     Aidan> supported on this router and all hell breaks loose if this
>     Aidan> happens during working hours.  How can I get the maximum
>     Aidan> logging info from the xorp processes?  Anything I can do in
>     Aidan> order that you can help me, will be dutifully carried
>     Aidan> out. What next, any suggestions?  Thanks Aidan I will On Tue,
>     Aidan> 2007-12-04 at 12:19 -0800, Atanu Ghosh wrote:
>     >>
>     Atanu> Hi,
>     >>
>     Atanu> The scenario that you describe would be perfectly normal if
>     Atanu> the connectivity between the "suspect" router and the
>     Atanu> "adjacent" router is lost. Although I would expect the "show
>     Atanu> ospf4 neighbor" to show the state of the adjacency to be
>     Atanu> "Down" not "Full". When an OSPF router loses its adjancencies
>     Atanu> the LSA database will slowly timeout, however, the routes
>     Atanu> will be withdrawn as soon as the adjacencies are lost.
>     >>
>     Atanu> We will require more information to diagnose the problem next
>     Atanu> time the problem occurs the output of "show interfaces" and
>     Atanu> "show ospf4 neighbor" would be very useful.
>     >>
>     Atanu> XORP tracks the state of interfaces in particular the carrier
>     Atanu> state. If OSPF believes that the Ethernet has been
>     Atanu> disconnected it will stop attempting to send hello
>     Atanu> packets. Is it possible that there is a problem with an
>     Atanu> interface or cable between the two routers?
>     >>
>     Atanu> Atanu.
>     >>  >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
>     >> 
>     Aidan> Hi All, I am using xorp in a production environment,
>     Aidan> admittedly a small one. I operate a local WISP and xorp is
>     Aidan> running on my wireless nodes. I have a very simple
>     Aidan> configuration and really I could probably get away with
>     Aidan> static routing throughout the entire network, but I wanted to
>     Aidan> try xorp and see just how stable it was. However as I expand
>     Aidan> the network I am having second thoughts. It is not good at
>     Aidan> all when a network goes up in smoke and I can't explain why
>     Aidan> or predict when and what the causes are.  The network has
>     Aidan> been in operation 24x7 for around 9 months. I am running on a
>     Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
>     Aidan> have no issues. However now for the fourth time I see the
>     Aidan> same problem: Suddenly the Linux kernel and the xorp rib
>     Aidan> become detached. Normally all routes in the kernel match
>     Aidan> those that xorp is generating, receiving and electing as
>     Aidan> active. I am running OSPF and the neighbour states remain
>     Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
>     Aidan> only in one direction (i.e nothing being transmitted from the
>     Aidan> router I suspect). The lsdb of OSPF on the suspect and
>     Aidan> adjacent routers contain all the routes but they are aging
>     Aidan> out slowly on the adjacent router. When I look at the kernel
>     Aidan> routes those from OSPF have already vanished.  I can see the
>     Aidan> ospf process running on the offending router? and again I can
>     Aidan> see the ospf lsdb intact and correct. When I restart xorp the
>     Aidan> system recovers and the routes appear in the kernel again. I
>     Aidan> suspect a problem with ospf. I tried enabling traceoptions on
>     Aidan> the ospf process, but in fact I needed to restart all the
>     Aidan> xorp processes before this actually became active. I now have
>     Aidan> this running so if/when it happens again I might be able to
>     Aidan> offer some more information.  Does anyone have any experience
>     Aidan> of ospf begin unstable? any suggestions how I might more
>     Aidan> effectively capture some logs from this event. I do not see
>     Aidan> any options for logging the fea process. Is there anything I
>     Aidan> can enable to help diagnose the issue?  Many thanks, and of
>     Aidan> course cheers for the code in the first place.  Aidan
>     Aidan> _______________________________________________ Xorp-users
>     Aidan> mailing list Xorp-users at xorp.org
>     Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From atanu at ICSI.Berkeley.EDU  Fri Dec  7 15:30:04 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Fri, 07 Dec 2007 15:30:04 -0800
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: Message from Aidan Walton <awalton@wires3.net> of "Fri,
	07 Dec 2007 10:39:32 GMT." <1197023972.3531.52.camel@bass.wires3.net> 
Message-ID: <82933.1197070204@tigger.icir.org>

Hi,

I did think about suggesting that you switched to point-to-point but
then we would be ignoring the problem. The XORP OSPF requires that when
point-to-point is selected that the neighbours are explicitly
configured, this may not have been obvious when you tried it
before.

Decreasing the hello interval will cause more hello packets to be sent
(in the router-dead interval), which will need more packets to be lost
before an adjacency is lost.

The only module that is sensitive to operating system differences is the
FEA (Forwarding Engine Abstraction). For example all the protocols send
and receive packets through the FEA, so the vagaries of how to send and
receive raw IP packets are dealt with by the FEA among other things. It
is therefore certainly safe to build OSPF on any of your hosts running
the same operating system. It should also be safe to build the FEA on
any of your hosts that are running the same OS with a similar version
number.

The router manager the process that controls all the XORP processes on
startup reads template files that define how a process can be
configured. These files are in the template directory and have the .tp
extension, the OSPFv2 template file is ospfv2.tp. In general if you
update a binary its matching template file should also be installed. In
this case ospfv2.tp has not changed since the last release. In the
template directory there are also files with the extension .cmds these
define the operational commands that are available for a protocol. The
file ospfv2.cmds has changed as the "clear ospf4 database" command has
been added. You will need to update this file in the templates
directory. You should also update the operational command programs
themselves print_neighbours, print_lsas and clear_database.

In answer to your question it should be safe to just update the OSPF
components of the system. We hope to one day support the updating of
protocols without requiring a restart. 

	   Atanu.

>>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:

    Aidan> Hi, This makes sense, I did not see the net LSA from .221. To
    Aidan> be honest even if I had I'm pretty sure I would not have
    Aidan> thought anything was wrong. It has been a long time since I
    Aidan> studied OSPF's workings. I suppose I have ensured myself a
    Aidan> certain re-baptism of fire. If I'm not mistaken I tried
    Aidan> already to configure these links as point-to-point
    Aidan> connections.  1. to avoid the DR elections process 2. to save
    Aidan> on IP addresses.  For some reason, I forget, it did not seem
    Aidan> to work. This would be the best approach to stability I would
    Aidan> have thought as we avoid DR election all together, but as you
    Aidan> say if I lengthen the dead-interval it may ride out whatever
    Aidan> caused the adjacency to drop. The trouble is I don't think
    Aidan> anything on the physical side caused the adjacency to drop in
    Aidan> the first place, so just increasing the dead time may well
    Aidan> not achieve stability.  Why decrease the hello interval?

    Aidan> Regarding the new code. This may be a stupid question but
    Aidan> here goes. As you know these routers are live and as I am the
    Aidan> worlds worst admin, I have different kernels on different
    Aidan> routers. If I remember correctly the xorp code I'm running on
    Aidan> the different routers was complied off-line on a different
    Aidan> machine, so they are running code the was not complied
    Aidan> against the actually running kernel headers. Xorp does not
    Aidan> produce kernel modules so will this ever matter? How far can
    Aidan> I push this?

    Aidan> The important question: Is each binary produced at compile
    Aidan> time stand-alone. i.e. if I compile the CVS sources off-line
    Aidan> and then take just the ospfv2 binary, will this work with the
    Aidan> other binaries that are already running on the live network?
    Aidan> Can I just replace the ospf module or are there dependencies
    Aidan> in the other binaries that will cause this approach to break
    Aidan> things. The modular approach would of course be nice !

    Aidan> Thanks for help so far, and I'm working on the logging
    Aidan> issue. I had this working in the past and now it doesn't hmmm
    Aidan> strange?

    Aidan> Thanks again Aidan


    Aidan> On Thu, 2007-12-06 at 20:13 -0800, Atanu Ghosh wrote:
    >> Hi,
    >> 
    >> The problem that I see is that that both routers (89.248.141.221
    >> and 89.248.141.222) are announcing a Network-LSA for the subnet
    >> 89.248.141.196/30. There should only be one Network-LSA per
    >> subnet, an unfortunate side effect of this behaviour is that from
    >> the perspective of the LSA database routers 89.248.141.221 and
    >> 89.248.141.222 are not connected, hence no routes.
    >> 
    >> Only the designated router (DR) for a subnet should be announcing
    >> a Network-LSA from the output of "show ospf4 neighbor detail"
    >> router 89.248.141.221 doesn't consider itself to be the DR
    >> (router 89.248.141.222 is the DR, 89.248.141.197 is its interface
    >> address).
    >> 
    >> >From the sequence number and age of the Network-LSA generated by
    >> router 89.248.141.221 we can see that it was initially announced
    >> 6 mins 48 secs ago, which is similar to the 8 mins 32 secs the
    >> adjacency has existed.
    >> 
    >> Router 89.248.141.221 is announcing a Network-LSA even though it
    >> is not the DR. The odd part is that the Network-LSA was initially
    >> announced after the adjacency was formed and a DR had already
    >> been selected.
    >> 
    >> Could you try running the latest code from CVS some DR election
    >> issues have been fixed since the last release?
    >> 
    >> My guess would be that the problem only occurs after a loss of
    >> adjacency. The default settings for hello-interval and
    >> router-dead-interval are 10 and 40 seconds respectively. You
    >> could try decreasing the hello-interval and increasing
    >> router-dead-interval until we get to the bottom of this.
    >> 
    >> Next time you see a problem: 1) $ print_lsas -S save.lsas 2) show
    >> ospf4 neighbor detail (On the router in question and the
    >> neighbour) Just to confirm the problem.
    >> 
    >> I will try and reproduce the problem.
    >> 
    >> Atanu.
    >> 
    >> OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age
    >> Opt Cksum Len Network 89.248.141.197 89.248.141.222 0x8000003b
    >> 409 0x2 0xaf92 32 Network *89.248.141.198 89.248.141.221
    >> 0x80000001 409 0x2 0x2458 32
    >> 
    >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
    >> 
    Aidan> Hi Atanu, Now that I'm over the panic of collecting the data
    Aidan> and recovering the network. I can see that the neighbour
    Aidan> seems to have been up for 29hrs but adjacent for only
    Aidan> 8mins. Clearly the adjacency has been dropped and even though
    Aidan> it has recovered it no longer imports the routes from the
    Aidan> database. Unfortunately because I do not have the logs, as
    Aidan> explained in the last email, I have no trace of the failure
    Aidan> :( Note the tcpdump of the hellos in both directions. I
    Aidan> thought if the adjacency failed a database update would be
    Aidan> forced when it is re-established.
    >>
    Aidan> Oh BTW I checked my logs on the interfaces and the physicals
    Aidan> have been up all the time.
    >>
    Aidan> What's up with ospf?  Aidan
    >>
    Aidan> On Wed, 2007-12-05 at 01:00 -0800, Atanu Ghosh wrote:
    >> >> Hi,
    >> >> 
    >> >> The output that it would be good to see before and after the
    >> >> problem occurs.  1) $ netstat -nr 2) Xorp> show interfaces 3)
    >> >> Xorp> show route table ipv4 unicast final 4) Xorp> show ospf4
    >> >> neighbor detail 5) Xorp> show ospf4 database detail 6) $ >>
    >> print_lsas -S save.lsas The print_lsas program can be found in >>
    >> ospf/tools directory. The program stores the LSA database in a >>
    >> form that can be replayed.
    >> >> 
    >> >> You can also enable tracing in ospf: traceoptions { flag { all
    >> { >> disable: false } } }
    >> >> 
    >> >> Which should show routes being added and deleted.
    >> >> 
    >> >> The latest code in CVS has a "clear ospf4 database" command,
    >> it >> would be interesting to know if once the problem occurs if
    >> this >> solves the problem.
    >> >> 
    >> >> It might also be interesting to keep the "ip mon" command
    >> running >> to track routes being added and deleted.
    >> >> 
    >> >> Would it be possible at some off peak time to flap the ADSL
    >> link >> to see if this replicates the problem. I know that you
    >> have >> stated that there were no ADSL issues when the problem
    >> occurred, >> but I do wonder if we are seeing some issue related
    >> to dynamic >> interfaces.
    >> >> 
    >> >> Atanu.
    >> >> 
    >> >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
    >> >> 
    Aidan> Hi, The adjacency runs over a wireless link between the
    Aidan> routers. It can, very possibly, drop in and out, but as far
    Aidan> as I can see this did not happen and to be honest in the 9
    Aidan> months I have had this system up I have never seen the
    Aidan> wireless link drop, but packet corruption could be a
    Aidan> possibility and this may be less easy to diagnose. It is a
    Aidan> high power 5.8GHz connection, here in the UK this is a
    Aidan> licensed band (and yes I have a license). So I don't think
    Aidan> interference is the likely cause, though I wouldn't rule this
    Aidan> out. If I look at the logs from the same period I seen
    Aidan> nothing to indicate the interface flapped, I would see the
    Aidan> wireless dis-associate and re-associate and cypher exchange
    Aidan> and this did not happen. But as I say there could be a period
    Aidan> of high BER on the links. I thought ospf would handle this
    Aidan> reasonably gracefully? I have to say heavy BER was not
    Aidan> evident when I came to repair the network, or at least I
    Aidan> didn't detect it and in the past I have run ospf over another
    Aidan> one of my wireless links with stations 10km apart with the
    Aidan> wireless link almost non-functional, dropping packets left
    Aidan> right and centre and re-associating over and over, but xorp's
    Aidan> ospf never complained!  I was beginning to suspect that this
    Aidan> was related to my adsl link on the suspect router, as this is
    Aidan> a dynamic interface and I have this defined independently of
    Aidan> xorp. If this interface flaps then the default route
    Aidan> associated with the adsl ppp session is withdrawn. The
    Aidan> default from the adsl line is not propagated into ospf
    Aidan> though, instead I use a static default with a higher metric
    Aidan> pointed at the loopback and inject this into ospf
    Aidan> instead. Then the flaps of the adsl line do not cause churn
    Aidan> in the ospf domain. I was starting to think that the addition
    Aidan> and removal of the default from the adsl line was affecting
    Aidan> the kernel table and this was upsetting xorp's ospf. However
    Aidan> this morning when this happened the adsl line was stable. As
    Aidan> far as my logs look it suddenly decided to stop functioning
    Aidan> with no correlated events from other system processes. The
    Aidan> only things in the logs at the same time is iptables dropping
    Aidan> DOS attacks, but this in normal, unfortunately far to normal.
    Aidan> show ospf4 neighbour simply stated 'full' there is only one
    Aidan> neighbour defined on this router. I didn't look this time at
    Aidan> show interfaces, but from memory of the last time this
    Aidan> happened this also was normal.  The problem is that these
    Aidan> routers are mounted 10m high up telegraph poles. If I loose
    Aidan> connectivity it requires a ladder and a climbing harness to
    Aidan> get at them, this is not to mention my upset customers who,
    Aidan> as is normal with customers, do not delay in telling me they
    Aidan> have lost their Internet links.  I suppose what I'm trying to
    Aidan> understand is how to be best prepared for next time, logging,
    Aidan> processes and checks during the failure period to grab as
    Aidan> much useful info before I am forced to restart xorp and get
    Aidan> my customers up and running again. This is a very short
    Aidan> period I have to say. I have a small group of business units
    Aidan> supported on this router and all hell breaks loose if this
    Aidan> happens during working hours.  How can I get the maximum
    Aidan> logging info from the xorp processes?  Anything I can do in
    Aidan> order that you can help me, will be dutifully carried
    Aidan> out. What next, any suggestions?  Thanks Aidan I will On Tue,
    Aidan> 2007-12-04 at 12:19 -0800, Atanu Ghosh wrote:
    >> >>
    Atanu> Hi,
    >> >>
    Atanu> The scenario that you describe would be perfectly normal if
    Atanu> the connectivity between the "suspect" router and the
    Atanu> "adjacent" router is lost. Although I would expect the "show
    Atanu> ospf4 neighbor" to show the state of the adjacency to be
    Atanu> "Down" not "Full". When an OSPF router loses its adjancencies
    Atanu> the LSA database will slowly timeout, however, the routes
    Atanu> will be withdrawn as soon as the adjacencies are lost.
    >> >>
    Atanu> We will require more information to diagnose the problem next
    Atanu> time the problem occurs the output of "show interfaces" and
    Atanu> "show ospf4 neighbor" would be very useful.
    >> >>
    Atanu> XORP tracks the state of interfaces in particular the carrier
    Atanu> state. If OSPF believes that the Ethernet has been
    Atanu> disconnected it will stop attempting to send hello
    Atanu> packets. Is it possible that there is a problem with an
    Atanu> interface or cable between the two routers?
    >> >>
    Atanu> Atanu.
    >> >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
    >> >> 
    Aidan> Hi All, I am using xorp in a production environment,
    Aidan> admittedly a small one. I operate a local WISP and xorp is
    Aidan> running on my wireless nodes. I have a very simple
    Aidan> configuration and really I could probably get away with
    Aidan> static routing throughout the entire network, but I wanted to
    Aidan> try xorp and see just how stable it was. However as I expand
    Aidan> the network I am having second thoughts. It is not good at
    Aidan> all when a network goes up in smoke and I can't explain why
    Aidan> or predict when and what the causes are.  The network has
    Aidan> been in operation 24x7 for around 9 months. I am running on a
    Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
    Aidan> have no issues. However now for the fourth time I see the
    Aidan> same problem: Suddenly the Linux kernel and the xorp rib
    Aidan> become detached. Normally all routes in the kernel match
    Aidan> those that xorp is generating, receiving and electing as
    Aidan> active. I am running OSPF and the neighbour states remain
    Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
    Aidan> only in one direction (i.e nothing being transmitted from the
    Aidan> router I suspect). The lsdb of OSPF on the suspect and
    Aidan> adjacent routers contain all the routes but they are aging
    Aidan> out slowly on the adjacent router. When I look at the kernel
    Aidan> routes those from OSPF have already vanished.  I can see the
    Aidan> ospf process running on the offending router? and again I can
    Aidan> see the ospf lsdb intact and correct. When I restart xorp the
    Aidan> system recovers and the routes appear in the kernel again. I
    Aidan> suspect a problem with ospf. I tried enabling traceoptions on
    Aidan> the ospf process, but in fact I needed to restart all the
    Aidan> xorp processes before this actually became active. I now have
    Aidan> this running so if/when it happens again I might be able to
    Aidan> offer some more information.  Does anyone have any experience
    Aidan> of ospf begin unstable? any suggestions how I might more
    Aidan> effectively capture some logs from this event. I do not see
    Aidan> any options for logging the fea process. Is there anything I
    Aidan> can enable to help diagnose the issue?  Many thanks, and of
    Aidan> course cheers for the code in the first place.  Aidan
    Aidan> _______________________________________________ Xorp-users
    Aidan> mailing list Xorp-users at xorp.org
    Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From awalton at wires3.net  Sat Dec  8 11:04:38 2007
From: awalton at wires3.net (Aidan Walton)
Date: Sat, 08 Dec 2007 19:04:38 +0000
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: <82933.1197070204@tigger.icir.org>
References: <82933.1197070204@tigger.icir.org>
Message-ID: <1197140678.6184.7.camel@bass.wires3.net>

Woops its done it again, here are both ends of the link and attached the
two replay files, again neither side had an interface failure. It's very
strange that this now seems to occur very day or so, just as I started
this conversation with you:

I agree that we need to get to the bottom of this but I also need a
stable network. Do you think there is anything significant in the
changes to ospf that may be related?

root at woodside-relay> show ospf4 neighbor detail
  Address         Interface             State      ID              Pri
Dead
89.248.141.193   ath0/ath0              Full      89.248.141.223   128
38
  Area 0.0.0.0, opt 0x2, DR 89.248.141.194, BDR 89.248.141.193
  Up 103:53:13, adjacent 103:49:09
89.248.141.198   ath1/ath1              Full      89.248.141.221   128
39
  Area 0.0.0.0, opt 0x2, DR 89.248.141.198, BDR 0.0.0.0
  Up 103:53:11, adjacent 00:04:30
root at woodside-relay> show ospf4 database detail
   OSPF link state database, Area 0.0.0.0
Router-LSA:
LS age  285 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.222 Advertising Router 89.248.141.222 LS sequence
number 0x8000098b LS checksum 0x3f92 length 60
        bit Nt false
        bit V false
        bit E false
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.194 Routers interface address 89.248.141.194 Metric 1
        Type 3 Stub network Subnet number 89.248.141.222 Mask
255.255.255.255 Metric 1
        Type 2 Transit network IP address of Designated router
89.248.141.197 Routers interface address 89.248.141.197 Metric 1
Router-LSA:
LS age 1153 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.223 Advertising Router 89.248.141.223 LS sequence
number 0x80001059 LS checksum 0x76dd length 48
        bit Nt false
        bit V false
        bit E true
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.194 Routers interface address 89.248.141.193 Metric 1
        Type 3 Stub network Subnet number 89.248.141.223 Mask
255.255.255.255 Metric 1
Router-LSA:
LS age  286 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
State ID 89.248.141.221 Advertising Router 89.248.141.221 LS sequence
number 0x800008a2 LS checksum 0x5eb1 length 48
        bit Nt false
        bit V false
        bit E true
        bit B false
        Type 2 Transit network IP address of Designated router
89.248.141.198 Routers interface address 89.248.141.198 Metric 1
        Type 3 Stub network Subnet number 89.248.141.221 Mask
255.255.255.255 Metric 1
Network-LSA:
LS age 1163 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.194 Advertising Router 89.248.141.222 LS sequence
number 0x800000d0 LS checksum 0xbeee length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.222
        Attached Router 89.248.141.223
Network-LSA:
LS age  286 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.198 Advertising Router 89.248.141.221 LS sequence
number 0x80000001 LS checksum 0x2458 length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.221
        Attached Router 89.248.141.222
As-External-LSA:
LS age 1163 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 0.0.0.0 Advertising Router 89.248.141.223 LS sequence number
0x80001016 LS checksum 0xd350 length 36
        Network Mask 0
        bit E true
        Metric 10 0xa
        Forwarding address 89.248.141.223
        External Route Tag 0
As-External-LSA:
LS age  705 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 89.248.141.224 Advertising Router 89.248.141.221 LS sequence
number 0x800000cf LS checksum 0x4e98 length 36
        Network Mask 0xffffffe0
        bit E true
        Metric 0 0
        Forwarding address 89.248.141.221
        External Route Tag 0
As-External-LSA:
LS age  705 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
State ID 89.248.142.128 Advertising Router 89.248.141.221 LS sequence
number 0x800000cf LS checksum 0xfb28 length 36
        Network Mask 0xfffffff8
        bit E true
        Metric 10 0xa
        Forwarding address 89.248.141.221
        External Route Tag 0
Network-LSA:
LS age  286 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 89.248.141.197 Advertising Router 89.248.141.222 LS sequence
number 0x80000093 LS checksum 0xfeea length 32
        Network Mask 0xfffffffc
        Attached Router 89.248.141.222
        Attached Router 89.248.141.221

root at lodgefarm> show ospf4 neighbor  detail
  Address         Interface             State      ID              Pri
Dead
89.248.141.197   ath0/ath0              Full      89.248.141.222   128
33
  Area 0.0.0.0, opt 0x2, DR 89.248.141.197, BDR 0.0.0.0
  Up 25:26:07, adjacent 00:09:17



On Fri, 2007-12-07 at 15:30 -0800, Atanu Ghosh wrote:
> Hi,
> 
> I did think about suggesting that you switched to point-to-point but
> then we would be ignoring the problem. The XORP OSPF requires that when
> point-to-point is selected that the neighbours are explicitly
> configured, this may not have been obvious when you tried it
> before.
> 
> Decreasing the hello interval will cause more hello packets to be sent
> (in the router-dead interval), which will need more packets to be lost
> before an adjacency is lost.
> 
> The only module that is sensitive to operating system differences is the
> FEA (Forwarding Engine Abstraction). For example all the protocols send
> and receive packets through the FEA, so the vagaries of how to send and
> receive raw IP packets are dealt with by the FEA among other things. It
> is therefore certainly safe to build OSPF on any of your hosts running
> the same operating system. It should also be safe to build the FEA on
> any of your hosts that are running the same OS with a similar version
> number.
> 
> The router manager the process that controls all the XORP processes on
> startup reads template files that define how a process can be
> configured. These files are in the template directory and have the .tp
> extension, the OSPFv2 template file is ospfv2.tp. In general if you
> update a binary its matching template file should also be installed. In
> this case ospfv2.tp has not changed since the last release. In the
> template directory there are also files with the extension .cmds these
> define the operational commands that are available for a protocol. The
> file ospfv2.cmds has changed as the "clear ospf4 database" command has
> been added. You will need to update this file in the templates
> directory. You should also update the operational command programs
> themselves print_neighbours, print_lsas and clear_database.
> 
> In answer to your question it should be safe to just update the OSPF
> components of the system. We hope to one day support the updating of
> protocols without requiring a restart. 
> 
> 	   Atanu.
> 
> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
> 
>     Aidan> Hi, This makes sense, I did not see the net LSA from .221. To
>     Aidan> be honest even if I had I'm pretty sure I would not have
>     Aidan> thought anything was wrong. It has been a long time since I
>     Aidan> studied OSPF's workings. I suppose I have ensured myself a
>     Aidan> certain re-baptism of fire. If I'm not mistaken I tried
>     Aidan> already to configure these links as point-to-point
>     Aidan> connections.  1. to avoid the DR elections process 2. to save
>     Aidan> on IP addresses.  For some reason, I forget, it did not seem
>     Aidan> to work. This would be the best approach to stability I would
>     Aidan> have thought as we avoid DR election all together, but as you
>     Aidan> say if I lengthen the dead-interval it may ride out whatever
>     Aidan> caused the adjacency to drop. The trouble is I don't think
>     Aidan> anything on the physical side caused the adjacency to drop in
>     Aidan> the first place, so just increasing the dead time may well
>     Aidan> not achieve stability.  Why decrease the hello interval?
> 
>     Aidan> Regarding the new code. This may be a stupid question but
>     Aidan> here goes. As you know these routers are live and as I am the
>     Aidan> worlds worst admin, I have different kernels on different
>     Aidan> routers. If I remember correctly the xorp code I'm running on
>     Aidan> the different routers was complied off-line on a different
>     Aidan> machine, so they are running code the was not complied
>     Aidan> against the actually running kernel headers. Xorp does not
>     Aidan> produce kernel modules so will this ever matter? How far can
>     Aidan> I push this?
> 
>     Aidan> The important question: Is each binary produced at compile
>     Aidan> time stand-alone. i.e. if I compile the CVS sources off-line
>     Aidan> and then take just the ospfv2 binary, will this work with the
>     Aidan> other binaries that are already running on the live network?
>     Aidan> Can I just replace the ospf module or are there dependencies
>     Aidan> in the other binaries that will cause this approach to break
>     Aidan> things. The modular approach would of course be nice !
> 
>     Aidan> Thanks for help so far, and I'm working on the logging
>     Aidan> issue. I had this working in the past and now it doesn't hmmm
>     Aidan> strange?
> 
>     Aidan> Thanks again Aidan
> 
> 
>     Aidan> On Thu, 2007-12-06 at 20:13 -0800, Atanu Ghosh wrote:
>     >> Hi,
>     >> 
>     >> The problem that I see is that that both routers (89.248.141.221
>     >> and 89.248.141.222) are announcing a Network-LSA for the subnet
>     >> 89.248.141.196/30. There should only be one Network-LSA per
>     >> subnet, an unfortunate side effect of this behaviour is that from
>     >> the perspective of the LSA database routers 89.248.141.221 and
>     >> 89.248.141.222 are not connected, hence no routes.
>     >> 
>     >> Only the designated router (DR) for a subnet should be announcing
>     >> a Network-LSA from the output of "show ospf4 neighbor detail"
>     >> router 89.248.141.221 doesn't consider itself to be the DR
>     >> (router 89.248.141.222 is the DR, 89.248.141.197 is its interface
>     >> address).
>     >> 
>     >> >From the sequence number and age of the Network-LSA generated by
>     >> router 89.248.141.221 we can see that it was initially announced
>     >> 6 mins 48 secs ago, which is similar to the 8 mins 32 secs the
>     >> adjacency has existed.
>     >> 
>     >> Router 89.248.141.221 is announcing a Network-LSA even though it
>     >> is not the DR. The odd part is that the Network-LSA was initially
>     >> announced after the adjacency was formed and a DR had already
>     >> been selected.
>     >> 
>     >> Could you try running the latest code from CVS some DR election
>     >> issues have been fixed since the last release?
>     >> 
>     >> My guess would be that the problem only occurs after a loss of
>     >> adjacency. The default settings for hello-interval and
>     >> router-dead-interval are 10 and 40 seconds respectively. You
>     >> could try decreasing the hello-interval and increasing
>     >> router-dead-interval until we get to the bottom of this.
>     >> 
>     >> Next time you see a problem: 1) $ print_lsas -S save.lsas 2) show
>     >> ospf4 neighbor detail (On the router in question and the
>     >> neighbour) Just to confirm the problem.
>     >> 
>     >> I will try and reproduce the problem.
>     >> 
>     >> Atanu.
>     >> 
>     >> OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age
>     >> Opt Cksum Len Network 89.248.141.197 89.248.141.222 0x8000003b
>     >> 409 0x2 0xaf92 32 Network *89.248.141.198 89.248.141.221
>     >> 0x80000001 409 0x2 0x2458 32
>     >> 
>     >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
>     >> 
>     Aidan> Hi Atanu, Now that I'm over the panic of collecting the data
>     Aidan> and recovering the network. I can see that the neighbour
>     Aidan> seems to have been up for 29hrs but adjacent for only
>     Aidan> 8mins. Clearly the adjacency has been dropped and even though
>     Aidan> it has recovered it no longer imports the routes from the
>     Aidan> database. Unfortunately because I do not have the logs, as
>     Aidan> explained in the last email, I have no trace of the failure
>     Aidan> :( Note the tcpdump of the hellos in both directions. I
>     Aidan> thought if the adjacency failed a database update would be
>     Aidan> forced when it is re-established.
>     >>
>     Aidan> Oh BTW I checked my logs on the interfaces and the physicals
>     Aidan> have been up all the time.
>     >>
>     Aidan> What's up with ospf?  Aidan
>     >>
>     Aidan> On Wed, 2007-12-05 at 01:00 -0800, Atanu Ghosh wrote:
>     >> >> Hi,
>     >> >> 
>     >> >> The output that it would be good to see before and after the
>     >> >> problem occurs.  1) $ netstat -nr 2) Xorp> show interfaces 3)
>     >> >> Xorp> show route table ipv4 unicast final 4) Xorp> show ospf4
>     >> >> neighbor detail 5) Xorp> show ospf4 database detail 6) $ >>
>     >> print_lsas -S save.lsas The print_lsas program can be found in >>
>     >> ospf/tools directory. The program stores the LSA database in a >>
>     >> form that can be replayed.
>     >> >> 
>     >> >> You can also enable tracing in ospf: traceoptions { flag { all
>     >> { >> disable: false } } }
>     >> >> 
>     >> >> Which should show routes being added and deleted.
>     >> >> 
>     >> >> The latest code in CVS has a "clear ospf4 database" command,
>     >> it >> would be interesting to know if once the problem occurs if
>     >> this >> solves the problem.
>     >> >> 
>     >> >> It might also be interesting to keep the "ip mon" command
>     >> running >> to track routes being added and deleted.
>     >> >> 
>     >> >> Would it be possible at some off peak time to flap the ADSL
>     >> link >> to see if this replicates the problem. I know that you
>     >> have >> stated that there were no ADSL issues when the problem
>     >> occurred, >> but I do wonder if we are seeing some issue related
>     >> to dynamic >> interfaces.
>     >> >> 
>     >> >> Atanu.
>     >> >> 
>     >> >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
>     >> >> 
>     Aidan> Hi, The adjacency runs over a wireless link between the
>     Aidan> routers. It can, very possibly, drop in and out, but as far
>     Aidan> as I can see this did not happen and to be honest in the 9
>     Aidan> months I have had this system up I have never seen the
>     Aidan> wireless link drop, but packet corruption could be a
>     Aidan> possibility and this may be less easy to diagnose. It is a
>     Aidan> high power 5.8GHz connection, here in the UK this is a
>     Aidan> licensed band (and yes I have a license). So I don't think
>     Aidan> interference is the likely cause, though I wouldn't rule this
>     Aidan> out. If I look at the logs from the same period I seen
>     Aidan> nothing to indicate the interface flapped, I would see the
>     Aidan> wireless dis-associate and re-associate and cypher exchange
>     Aidan> and this did not happen. But as I say there could be a period
>     Aidan> of high BER on the links. I thought ospf would handle this
>     Aidan> reasonably gracefully? I have to say heavy BER was not
>     Aidan> evident when I came to repair the network, or at least I
>     Aidan> didn't detect it and in the past I have run ospf over another
>     Aidan> one of my wireless links with stations 10km apart with the
>     Aidan> wireless link almost non-functional, dropping packets left
>     Aidan> right and centre and re-associating over and over, but xorp's
>     Aidan> ospf never complained!  I was beginning to suspect that this
>     Aidan> was related to my adsl link on the suspect router, as this is
>     Aidan> a dynamic interface and I have this defined independently of
>     Aidan> xorp. If this interface flaps then the default route
>     Aidan> associated with the adsl ppp session is withdrawn. The
>     Aidan> default from the adsl line is not propagated into ospf
>     Aidan> though, instead I use a static default with a higher metric
>     Aidan> pointed at the loopback and inject this into ospf
>     Aidan> instead. Then the flaps of the adsl line do not cause churn
>     Aidan> in the ospf domain. I was starting to think that the addition
>     Aidan> and removal of the default from the adsl line was affecting
>     Aidan> the kernel table and this was upsetting xorp's ospf. However
>     Aidan> this morning when this happened the adsl line was stable. As
>     Aidan> far as my logs look it suddenly decided to stop functioning
>     Aidan> with no correlated events from other system processes. The
>     Aidan> only things in the logs at the same time is iptables dropping
>     Aidan> DOS attacks, but this in normal, unfortunately far to normal.
>     Aidan> show ospf4 neighbour simply stated 'full' there is only one
>     Aidan> neighbour defined on this router. I didn't look this time at
>     Aidan> show interfaces, but from memory of the last time this
>     Aidan> happened this also was normal.  The problem is that these
>     Aidan> routers are mounted 10m high up telegraph poles. If I loose
>     Aidan> connectivity it requires a ladder and a climbing harness to
>     Aidan> get at them, this is not to mention my upset customers who,
>     Aidan> as is normal with customers, do not delay in telling me they
>     Aidan> have lost their Internet links.  I suppose what I'm trying to
>     Aidan> understand is how to be best prepared for next time, logging,
>     Aidan> processes and checks during the failure period to grab as
>     Aidan> much useful info before I am forced to restart xorp and get
>     Aidan> my customers up and running again. This is a very short
>     Aidan> period I have to say. I have a small group of business units
>     Aidan> supported on this router and all hell breaks loose if this
>     Aidan> happens during working hours.  How can I get the maximum
>     Aidan> logging info from the xorp processes?  Anything I can do in
>     Aidan> order that you can help me, will be dutifully carried
>     Aidan> out. What next, any suggestions?  Thanks Aidan I will On Tue,
>     Aidan> 2007-12-04 at 12:19 -0800, Atanu Ghosh wrote:
>     >> >>
>     Atanu> Hi,
>     >> >>
>     Atanu> The scenario that you describe would be perfectly normal if
>     Atanu> the connectivity between the "suspect" router and the
>     Atanu> "adjacent" router is lost. Although I would expect the "show
>     Atanu> ospf4 neighbor" to show the state of the adjacency to be
>     Atanu> "Down" not "Full". When an OSPF router loses its adjancencies
>     Atanu> the LSA database will slowly timeout, however, the routes
>     Atanu> will be withdrawn as soon as the adjacencies are lost.
>     >> >>
>     Atanu> We will require more information to diagnose the problem next
>     Atanu> time the problem occurs the output of "show interfaces" and
>     Atanu> "show ospf4 neighbor" would be very useful.
>     >> >>
>     Atanu> XORP tracks the state of interfaces in particular the carrier
>     Atanu> state. If OSPF believes that the Ethernet has been
>     Atanu> disconnected it will stop attempting to send hello
>     Atanu> packets. Is it possible that there is a problem with an
>     Atanu> interface or cable between the two routers?
>     >> >>
>     Atanu> Atanu.
>     >> >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
>     >> >> 
>     Aidan> Hi All, I am using xorp in a production environment,
>     Aidan> admittedly a small one. I operate a local WISP and xorp is
>     Aidan> running on my wireless nodes. I have a very simple
>     Aidan> configuration and really I could probably get away with
>     Aidan> static routing throughout the entire network, but I wanted to
>     Aidan> try xorp and see just how stable it was. However as I expand
>     Aidan> the network I am having second thoughts. It is not good at
>     Aidan> all when a network goes up in smoke and I can't explain why
>     Aidan> or predict when and what the causes are.  The network has
>     Aidan> been in operation 24x7 for around 9 months. I am running on a
>     Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
>     Aidan> have no issues. However now for the fourth time I see the
>     Aidan> same problem: Suddenly the Linux kernel and the xorp rib
>     Aidan> become detached. Normally all routes in the kernel match
>     Aidan> those that xorp is generating, receiving and electing as
>     Aidan> active. I am running OSPF and the neighbour states remain
>     Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
>     Aidan> only in one direction (i.e nothing being transmitted from the
>     Aidan> router I suspect). The lsdb of OSPF on the suspect and
>     Aidan> adjacent routers contain all the routes but they are aging
>     Aidan> out slowly on the adjacent router. When I look at the kernel
>     Aidan> routes those from OSPF have already vanished.  I can see the
>     Aidan> ospf process running on the offending router? and again I can
>     Aidan> see the ospf lsdb intact and correct. When I restart xorp the
>     Aidan> system recovers and the routes appear in the kernel again. I
>     Aidan> suspect a problem with ospf. I tried enabling traceoptions on
>     Aidan> the ospf process, but in fact I needed to restart all the
>     Aidan> xorp processes before this actually became active. I now have
>     Aidan> this running so if/when it happens again I might be able to
>     Aidan> offer some more information.  Does anyone have any experience
>     Aidan> of ospf begin unstable? any suggestions how I might more
>     Aidan> effectively capture some logs from this event. I do not see
>     Aidan> any options for logging the fea process. Is there anything I
>     Aidan> can enable to help diagnose the issue?  Many thanks, and of
>     Aidan> course cheers for the code in the first place.  Aidan
>     Aidan> _______________________________________________ Xorp-users
>     Aidan> mailing list Xorp-users at xorp.org
>     Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: save.lsas.lodgefarm
Type: application/octet-stream
Size: 481 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071208/7e145042/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: save.lsas.woodside-relay
Type: application/octet-stream
Size: 481 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071208/7e145042/attachment-0003.obj 

From atanu at ICSI.Berkeley.EDU  Sat Dec  8 11:28:08 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Sat, 08 Dec 2007 11:28:08 -0800
Subject: [Xorp-users] Problems with Linux kernel and OSPF ???
In-Reply-To: Message from Aidan Walton <awalton@wires3.net> of "Sat,
	08 Dec 2007 19:04:38 GMT." <1197140678.6184.7.camel@bass.wires3.net> 
Message-ID: <89609.1197142088@tigger.icir.org>

Hi,

I need to spend a little more time looking at this but at first glance
it looks as if both routers have selected themselves as the DR.

I think this problem is fixed in CVS:
<http://xorpc.icir.org/cgi-bin/cvsweb.cgi/xorp/ospf/peer.cc?rev=1.290&content-type=text/x-cvsweb-markup>.

I think it would make sense for you to take the latest version of OSPF
from the CVS repository.

  Atanu.

>>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:

    Aidan> Woops its done it again, here are both ends of the link and attached the
    Aidan> two replay files, again neither side had an interface failure. It's very
    Aidan> strange that this now seems to occur very day or so, just as I started
    Aidan> this conversation with you:

    Aidan> I agree that we need to get to the bottom of this but I also need a
    Aidan> stable network. Do you think there is anything significant in the
    Aidan> changes to ospf that may be related?

    Aidan> root at woodside-relay> show ospf4 neighbor detail
    Aidan> Address         Interface             State      ID              Pri
    Aidan> Dead
    Aidan> 89.248.141.193   ath0/ath0              Full      89.248.141.223   128
    Aidan> 38
    Aidan> Area 0.0.0.0, opt 0x2, DR 89.248.141.194, BDR 89.248.141.193
    Aidan> Up 103:53:13, adjacent 103:49:09
    Aidan> 89.248.141.198   ath1/ath1              Full      89.248.141.221   128
    Aidan> 39
    Aidan> Area 0.0.0.0, opt 0x2, DR 89.248.141.198, BDR 0.0.0.0
    Aidan> Up 103:53:11, adjacent 00:04:30
    Aidan> root at woodside-relay> show ospf4 database detail
    Aidan> OSPF link state database, Area 0.0.0.0
    Aidan> Router-LSA:
    Aidan> LS age  285 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
    Aidan> State ID 89.248.141.222 Advertising Router 89.248.141.222 LS sequence
    Aidan> number 0x8000098b LS checksum 0x3f92 length 60
    Aidan> bit Nt false
    Aidan> bit V false
    Aidan> bit E false
    Aidan> bit B false
    Aidan> Type 2 Transit network IP address of Designated router
    Aidan> 89.248.141.194 Routers interface address 89.248.141.194 Metric 1
    Aidan> Type 3 Stub network Subnet number 89.248.141.222 Mask
    Aidan> 255.255.255.255 Metric 1
    Aidan> Type 2 Transit network IP address of Designated router
    Aidan> 89.248.141.197 Routers interface address 89.248.141.197 Metric 1
    Aidan> Router-LSA:
    Aidan> LS age 1153 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
    Aidan> State ID 89.248.141.223 Advertising Router 89.248.141.223 LS sequence
    Aidan> number 0x80001059 LS checksum 0x76dd length 48
    Aidan> bit Nt false
    Aidan> bit V false
    Aidan> bit E true
    Aidan> bit B false
    Aidan> Type 2 Transit network IP address of Designated router
    Aidan> 89.248.141.194 Routers interface address 89.248.141.193 Metric 1
    Aidan> Type 3 Stub network Subnet number 89.248.141.223 Mask
    Aidan> 255.255.255.255 Metric 1
    Aidan> Router-LSA:
    Aidan> LS age  286 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link
    Aidan> State ID 89.248.141.221 Advertising Router 89.248.141.221 LS sequence
    Aidan> number 0x800008a2 LS checksum 0x5eb1 length 48
    Aidan> bit Nt false
    Aidan> bit V false
    Aidan> bit E true
    Aidan> bit B false
    Aidan> Type 2 Transit network IP address of Designated router
    Aidan> 89.248.141.198 Routers interface address 89.248.141.198 Metric 1
    Aidan> Type 3 Stub network Subnet number 89.248.141.221 Mask
    Aidan> 255.255.255.255 Metric 1
    Aidan> Network-LSA:
    Aidan> LS age 1163 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
    Aidan> State ID 89.248.141.194 Advertising Router 89.248.141.222 LS sequence
    Aidan> number 0x800000d0 LS checksum 0xbeee length 32
    Aidan> Network Mask 0xfffffffc
    Aidan> Attached Router 89.248.141.222
    Aidan> Attached Router 89.248.141.223
    Aidan> Network-LSA:
    Aidan> LS age  286 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
    Aidan> State ID 89.248.141.198 Advertising Router 89.248.141.221 LS sequence
    Aidan> number 0x80000001 LS checksum 0x2458 length 32
    Aidan> Network Mask 0xfffffffc
    Aidan> Attached Router 89.248.141.221
    Aidan> Attached Router 89.248.141.222
    Aidan> As-External-LSA:
    Aidan> LS age 1163 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
    Aidan> State ID 0.0.0.0 Advertising Router 89.248.141.223 LS sequence number
    Aidan> 0x80001016 LS checksum 0xd350 length 36
    Aidan> Network Mask 0
    Aidan> bit E true
    Aidan> Metric 10 0xa
    Aidan> Forwarding address 89.248.141.223
    Aidan> External Route Tag 0
    Aidan> As-External-LSA:
    Aidan> LS age  705 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
    Aidan> State ID 89.248.141.224 Advertising Router 89.248.141.221 LS sequence
    Aidan> number 0x800000cf LS checksum 0x4e98 length 36
    Aidan> Network Mask 0xffffffe0
    Aidan> bit E true
    Aidan> Metric 0 0
    Aidan> Forwarding address 89.248.141.221
    Aidan> External Route Tag 0
    Aidan> As-External-LSA:
    Aidan> LS age  705 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link
    Aidan> State ID 89.248.142.128 Advertising Router 89.248.141.221 LS sequence
    Aidan> number 0x800000cf LS checksum 0xfb28 length 36
    Aidan> Network Mask 0xfffffff8
    Aidan> bit E true
    Aidan> Metric 10 0xa
    Aidan> Forwarding address 89.248.141.221
    Aidan> External Route Tag 0
    Aidan> Network-LSA:
    Aidan> LS age  286 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
    Aidan> State ID 89.248.141.197 Advertising Router 89.248.141.222 LS sequence
    Aidan> number 0x80000093 LS checksum 0xfeea length 32
    Aidan> Network Mask 0xfffffffc
    Aidan> Attached Router 89.248.141.222
    Aidan> Attached Router 89.248.141.221

    Aidan> root at lodgefarm> show ospf4 neighbor  detail
    Aidan> Address         Interface             State      ID              Pri
    Aidan> Dead
    Aidan> 89.248.141.197   ath0/ath0              Full      89.248.141.222   128
    Aidan> 33
    Aidan> Area 0.0.0.0, opt 0x2, DR 89.248.141.197, BDR 0.0.0.0
    Aidan> Up 25:26:07, adjacent 00:09:17



    Aidan> On Fri, 2007-12-07 at 15:30 -0800, Atanu Ghosh wrote:
    >> Hi,
    >> 
    >> I did think about suggesting that you switched to point-to-point but
    >> then we would be ignoring the problem. The XORP OSPF requires that when
    >> point-to-point is selected that the neighbours are explicitly
    >> configured, this may not have been obvious when you tried it
    >> before.
    >> 
    >> Decreasing the hello interval will cause more hello packets to be sent
    >> (in the router-dead interval), which will need more packets to be lost
    >> before an adjacency is lost.
    >> 
    >> The only module that is sensitive to operating system differences is the
    >> FEA (Forwarding Engine Abstraction). For example all the protocols send
    >> and receive packets through the FEA, so the vagaries of how to send and
    >> receive raw IP packets are dealt with by the FEA among other things. It
    >> is therefore certainly safe to build OSPF on any of your hosts running
    >> the same operating system. It should also be safe to build the FEA on
    >> any of your hosts that are running the same OS with a similar version
    >> number.
    >> 
    >> The router manager the process that controls all the XORP processes on
    >> startup reads template files that define how a process can be
    >> configured. These files are in the template directory and have the .tp
    >> extension, the OSPFv2 template file is ospfv2.tp. In general if you
    >> update a binary its matching template file should also be installed. In
    >> this case ospfv2.tp has not changed since the last release. In the
    >> template directory there are also files with the extension .cmds these
    >> define the operational commands that are available for a protocol. The
    >> file ospfv2.cmds has changed as the "clear ospf4 database" command has
    >> been added. You will need to update this file in the templates
    >> directory. You should also update the operational command programs
    >> themselves print_neighbours, print_lsas and clear_database.
    >> 
    >> In answer to your question it should be safe to just update the OSPF
    >> components of the system. We hope to one day support the updating of
    >> protocols without requiring a restart. 
    >> 
    >> Atanu.
    >> 
    >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
    >> 
    Aidan> Hi, This makes sense, I did not see the net LSA from .221. To
    Aidan> be honest even if I had I'm pretty sure I would not have
    Aidan> thought anything was wrong. It has been a long time since I
    Aidan> studied OSPF's workings. I suppose I have ensured myself a
    Aidan> certain re-baptism of fire. If I'm not mistaken I tried
    Aidan> already to configure these links as point-to-point
    Aidan> connections.  1. to avoid the DR elections process 2. to save
    Aidan> on IP addresses.  For some reason, I forget, it did not seem
    Aidan> to work. This would be the best approach to stability I would
    Aidan> have thought as we avoid DR election all together, but as you
    Aidan> say if I lengthen the dead-interval it may ride out whatever
    Aidan> caused the adjacency to drop. The trouble is I don't think
    Aidan> anything on the physical side caused the adjacency to drop in
    Aidan> the first place, so just increasing the dead time may well
    Aidan> not achieve stability.  Why decrease the hello interval?
    >> 
    Aidan> Regarding the new code. This may be a stupid question but
    Aidan> here goes. As you know these routers are live and as I am the
    Aidan> worlds worst admin, I have different kernels on different
    Aidan> routers. If I remember correctly the xorp code I'm running on
    Aidan> the different routers was complied off-line on a different
    Aidan> machine, so they are running code the was not complied
    Aidan> against the actually running kernel headers. Xorp does not
    Aidan> produce kernel modules so will this ever matter? How far can
    Aidan> I push this?
    >> 
    Aidan> The important question: Is each binary produced at compile
    Aidan> time stand-alone. i.e. if I compile the CVS sources off-line
    Aidan> and then take just the ospfv2 binary, will this work with the
    Aidan> other binaries that are already running on the live network?
    Aidan> Can I just replace the ospf module or are there dependencies
    Aidan> in the other binaries that will cause this approach to break
    Aidan> things. The modular approach would of course be nice !
    >> 
    Aidan> Thanks for help so far, and I'm working on the logging
    Aidan> issue. I had this working in the past and now it doesn't hmmm
    Aidan> strange?
    >> 
    Aidan> Thanks again Aidan
    >> 
    >> 
    Aidan> On Thu, 2007-12-06 at 20:13 -0800, Atanu Ghosh wrote:
    >> >> Hi,
    >> >> 
    >> >> The problem that I see is that that both routers (89.248.141.221
    >> >> and 89.248.141.222) are announcing a Network-LSA for the subnet
    >> >> 89.248.141.196/30. There should only be one Network-LSA per
    >> >> subnet, an unfortunate side effect of this behaviour is that from
    >> >> the perspective of the LSA database routers 89.248.141.221 and
    >> >> 89.248.141.222 are not connected, hence no routes.
    >> >> 
    >> >> Only the designated router (DR) for a subnet should be announcing
    >> >> a Network-LSA from the output of "show ospf4 neighbor detail"
    >> >> router 89.248.141.221 doesn't consider itself to be the DR
    >> >> (router 89.248.141.222 is the DR, 89.248.141.197 is its interface
    >> >> address).
    >> >> 
    >> >> >From the sequence number and age of the Network-LSA generated by
    >> >> router 89.248.141.221 we can see that it was initially announced
    >> >> 6 mins 48 secs ago, which is similar to the 8 mins 32 secs the
    >> >> adjacency has existed.
    >> >> 
    >> >> Router 89.248.141.221 is announcing a Network-LSA even though it
    >> >> is not the DR. The odd part is that the Network-LSA was initially
    >> >> announced after the adjacency was formed and a DR had already
    >> >> been selected.
    >> >> 
    >> >> Could you try running the latest code from CVS some DR election
    >> >> issues have been fixed since the last release?
    >> >> 
    >> >> My guess would be that the problem only occurs after a loss of
    >> >> adjacency. The default settings for hello-interval and
    >> >> router-dead-interval are 10 and 40 seconds respectively. You
    >> >> could try decreasing the hello-interval and increasing
    >> >> router-dead-interval until we get to the bottom of this.
    >> >> 
    >> >> Next time you see a problem: 1) $ print_lsas -S save.lsas 2) show
    >> >> ospf4 neighbor detail (On the router in question and the
    >> >> neighbour) Just to confirm the problem.
    >> >> 
    >> >> I will try and reproduce the problem.
    >> >> 
    >> >> Atanu.
    >> >> 
    >> >> OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age
    >> >> Opt Cksum Len Network 89.248.141.197 89.248.141.222 0x8000003b
    >> >> 409 0x2 0xaf92 32 Network *89.248.141.198 89.248.141.221
    >> >> 0x80000001 409 0x2 0x2458 32
    >> >> 
    >> >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
    >> >> 
    Aidan> Hi Atanu, Now that I'm over the panic of collecting the data
    Aidan> and recovering the network. I can see that the neighbour
    Aidan> seems to have been up for 29hrs but adjacent for only
    Aidan> 8mins. Clearly the adjacency has been dropped and even though
    Aidan> it has recovered it no longer imports the routes from the
    Aidan> database. Unfortunately because I do not have the logs, as
    Aidan> explained in the last email, I have no trace of the failure
    Aidan> :( Note the tcpdump of the hellos in both directions. I
    Aidan> thought if the adjacency failed a database update would be
    Aidan> forced when it is re-established.
    >> >>
    Aidan> Oh BTW I checked my logs on the interfaces and the physicals
    Aidan> have been up all the time.
    >> >>
    Aidan> What's up with ospf?  Aidan
    >> >>
    Aidan> On Wed, 2007-12-05 at 01:00 -0800, Atanu Ghosh wrote:
    >> >> >> Hi,
    >> >> >> 
    >> >> >> The output that it would be good to see before and after the
    >> >> >> problem occurs.  1) $ netstat -nr 2) Xorp> show interfaces 3)
    >> >> >> Xorp> show route table ipv4 unicast final 4) Xorp> show ospf4
    >> >> >> neighbor detail 5) Xorp> show ospf4 database detail 6) $ >>
    >> >> print_lsas -S save.lsas The print_lsas program can be found in >>
    >> >> ospf/tools directory. The program stores the LSA database in a >>
    >> >> form that can be replayed.
    >> >> >> 
    >> >> >> You can also enable tracing in ospf: traceoptions { flag { all
    >> >> { >> disable: false } } }
    >> >> >> 
    >> >> >> Which should show routes being added and deleted.
    >> >> >> 
    >> >> >> The latest code in CVS has a "clear ospf4 database" command,
    >> >> it >> would be interesting to know if once the problem occurs if
    >> >> this >> solves the problem.
    >> >> >> 
    >> >> >> It might also be interesting to keep the "ip mon" command
    >> >> running >> to track routes being added and deleted.
    >> >> >> 
    >> >> >> Would it be possible at some off peak time to flap the ADSL
    >> >> link >> to see if this replicates the problem. I know that you
    >> >> have >> stated that there were no ADSL issues when the problem
    >> >> occurred, >> but I do wonder if we are seeing some issue related
    >> >> to dynamic >> interfaces.
    >> >> >> 
    >> >> >> Atanu.
    >> >> >> 
    >> >> >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
    >> >> >> 
    Aidan> Hi, The adjacency runs over a wireless link between the
    Aidan> routers. It can, very possibly, drop in and out, but as far
    Aidan> as I can see this did not happen and to be honest in the 9
    Aidan> months I have had this system up I have never seen the
    Aidan> wireless link drop, but packet corruption could be a
    Aidan> possibility and this may be less easy to diagnose. It is a
    Aidan> high power 5.8GHz connection, here in the UK this is a
    Aidan> licensed band (and yes I have a license). So I don't think
    Aidan> interference is the likely cause, though I wouldn't rule this
    Aidan> out. If I look at the logs from the same period I seen
    Aidan> nothing to indicate the interface flapped, I would see the
    Aidan> wireless dis-associate and re-associate and cypher exchange
    Aidan> and this did not happen. But as I say there could be a period
    Aidan> of high BER on the links. I thought ospf would handle this
    Aidan> reasonably gracefully? I have to say heavy BER was not
    Aidan> evident when I came to repair the network, or at least I
    Aidan> didn't detect it and in the past I have run ospf over another
    Aidan> one of my wireless links with stations 10km apart with the
    Aidan> wireless link almost non-functional, dropping packets left
    Aidan> right and centre and re-associating over and over, but xorp's
    Aidan> ospf never complained!  I was beginning to suspect that this
    Aidan> was related to my adsl link on the suspect router, as this is
    Aidan> a dynamic interface and I have this defined independently of
    Aidan> xorp. If this interface flaps then the default route
    Aidan> associated with the adsl ppp session is withdrawn. The
    Aidan> default from the adsl line is not propagated into ospf
    Aidan> though, instead I use a static default with a higher metric
    Aidan> pointed at the loopback and inject this into ospf
    Aidan> instead. Then the flaps of the adsl line do not cause churn
    Aidan> in the ospf domain. I was starting to think that the addition
    Aidan> and removal of the default from the adsl line was affecting
    Aidan> the kernel table and this was upsetting xorp's ospf. However
    Aidan> this morning when this happened the adsl line was stable. As
    Aidan> far as my logs look it suddenly decided to stop functioning
    Aidan> with no correlated events from other system processes. The
    Aidan> only things in the logs at the same time is iptables dropping
    Aidan> DOS attacks, but this in normal, unfortunately far to normal.
    Aidan> show ospf4 neighbour simply stated 'full' there is only one
    Aidan> neighbour defined on this router. I didn't look this time at
    Aidan> show interfaces, but from memory of the last time this
    Aidan> happened this also was normal.  The problem is that these
    Aidan> routers are mounted 10m high up telegraph poles. If I loose
    Aidan> connectivity it requires a ladder and a climbing harness to
    Aidan> get at them, this is not to mention my upset customers who,
    Aidan> as is normal with customers, do not delay in telling me they
    Aidan> have lost their Internet links.  I suppose what I'm trying to
    Aidan> understand is how to be best prepared for next time, logging,
    Aidan> processes and checks during the failure period to grab as
    Aidan> much useful info before I am forced to restart xorp and get
    Aidan> my customers up and running again. This is a very short
    Aidan> period I have to say. I have a small group of business units
    Aidan> supported on this router and all hell breaks loose if this
    Aidan> happens during working hours.  How can I get the maximum
    Aidan> logging info from the xorp processes?  Anything I can do in
    Aidan> order that you can help me, will be dutifully carried
    Aidan> out. What next, any suggestions?  Thanks Aidan I will On Tue,
    Aidan> 2007-12-04 at 12:19 -0800, Atanu Ghosh wrote:
    >> >> >>
    Atanu> Hi,
    >> >> >>
    Atanu> The scenario that you describe would be perfectly normal if
    Atanu> the connectivity between the "suspect" router and the
    Atanu> "adjacent" router is lost. Although I would expect the "show
    Atanu> ospf4 neighbor" to show the state of the adjacency to be
    Atanu> "Down" not "Full". When an OSPF router loses its adjancencies
    Atanu> the LSA database will slowly timeout, however, the routes
    Atanu> will be withdrawn as soon as the adjacencies are lost.
    >> >> >>
    Atanu> We will require more information to diagnose the problem next
    Atanu> time the problem occurs the output of "show interfaces" and
    Atanu> "show ospf4 neighbor" would be very useful.
    >> >> >>
    Atanu> XORP tracks the state of interfaces in particular the carrier
    Atanu> state. If OSPF believes that the Ethernet has been
    Atanu> disconnected it will stop attempting to send hello
    Atanu> packets. Is it possible that there is a problem with an
    Atanu> interface or cable between the two routers?
    >> >> >>
    Atanu> Atanu.
    >> >> >> >>>>> "Aidan" == Aidan Walton <awalton at wires3.net> writes:
    >> >> >> 
    Aidan> Hi All, I am using xorp in a production environment,
    Aidan> admittedly a small one. I operate a local WISP and xorp is
    Aidan> running on my wireless nodes. I have a very simple
    Aidan> configuration and really I could probably get away with
    Aidan> static routing throughout the entire network, but I wanted to
    Aidan> try xorp and see just how stable it was. However as I expand
    Aidan> the network I am having second thoughts. It is not good at
    Aidan> all when a network goes up in smoke and I can't explain why
    Aidan> or predict when and what the causes are.  The network has
    Aidan> been in operation 24x7 for around 9 months. I am running on a
    Aidan> Linux kernel 2.6.18-4 and for the vast majority of the time I
    Aidan> have no issues. However now for the fourth time I see the
    Aidan> same problem: Suddenly the Linux kernel and the xorp rib
    Aidan> become detached. Normally all routes in the kernel match
    Aidan> those that xorp is generating, receiving and electing as
    Aidan> active. I am running OSPF and the neighbour states remain
    Aidan> 'full' throughout but if I am not mistaken I see ospf hellos
    Aidan> only in one direction (i.e nothing being transmitted from the
    Aidan> router I suspect). The lsdb of OSPF on the suspect and
    Aidan> adjacent routers contain all the routes but they are aging
    Aidan> out slowly on the adjacent router. When I look at the kernel
    Aidan> routes those from OSPF have already vanished.  I can see the
    Aidan> ospf process running on the offending router? and again I can
    Aidan> see the ospf lsdb intact and correct. When I restart xorp the
    Aidan> system recovers and the routes appear in the kernel again. I
    Aidan> suspect a problem with ospf. I tried enabling traceoptions on
    Aidan> the ospf process, but in fact I needed to restart all the
    Aidan> xorp processes before this actually became active. I now have
    Aidan> this running so if/when it happens again I might be able to
    Aidan> offer some more information.  Does anyone have any experience
    Aidan> of ospf begin unstable? any suggestions how I might more
    Aidan> effectively capture some logs from this event. I do not see
    Aidan> any options for logging the fea process. Is there anything I
    Aidan> can enable to help diagnose the issue?  Many thanks, and of
    Aidan> course cheers for the code in the first place.  Aidan
    Aidan> _______________________________________________ Xorp-users
    Aidan> mailing list Xorp-users at xorp.org
    Aidan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From jeandro at larces.uece.br  Sun Dec  9 10:43:46 2007
From: jeandro at larces.uece.br (Jeandro de M. Bezerra)
Date: Sun, 9 Dec 2007 15:43:46 -0300
Subject: [Xorp-users] Fwd: tests conformance using XORP
In-Reply-To: <5efcb8aa0712091040y146361b6n18646bf4a6828d74@mail.gmail.com>
References: <5efcb8aa0712091040y146361b6n18646bf4a6828d74@mail.gmail.com>
Message-ID: <5efcb8aa0712091043s65a8363dl9b518e0bbd05e54f@mail.gmail.com>

---------- Forwarded message ----------
From: Jeandro Bezerra <jeandro at gmail.com>
Date: 09/12/2007 15:40
Subject: tests conformance using XORP
To: xorp-users at xorp.org

Hi,

I am perform a tests set using ATTEST Testcase for module PIM-SM. The DUT
(device Under Test) is XORP. In the testbed 002 i have  a test.

 #############################################################################

12:33:50.836 # Test Case           :
tc_conf_pim-sm_ast_001                            #
12:33:50.842 # Test Case Version   :   1.0
#
12:33:50.847 # Component Name      :   NET-O2 ATTEST CONFORMANCE TEST
SUITE              #
12:33:50.853 # Module Name         :   PIM-SM/Assert Group
(AST)                         #
12:33:50.859#
#
12:33:50.865 # Purpose             :   To verify that the (S,G) Assert state
machine     #
12:33:50.871 #                         on the interface transit from NO_INFO
state to    #
12:33:50.876 #                         I_AM_ASSERT_WINNER state, on
receiving a (S,G)    #
12:33:50.879 #                         data packet on downstream interface
whose (S,G)   #
12:33:50.880 #                         downstream state machine is in JOIN
state.        #
12:33:50.881#
#
12:33:50.881 # Description         :   In this test-case, on receiving
JOIN(S,G) on      #
12:33:50.881 #                         interface I1, DUT should send the
JOIN(S,G) to    #
12:33:50.881 #                         TEE I2 (towards source S), confirming
that its    #
12:33:50.881 #                         (S,G) downstream state machine on
interface I1    #
12:33:50.881 #                         has transitioned to JOIN
state.                   #
12:33:50.881#
#
12:33:50.882 #                         When multicast data traffic destined
for group G  #
12:33:50.882 #                         is received from source S (TEE I2),
the DUT       #
12:33:50.882 #                         should forward traffic for G to the
downstream    #
12:33:50.882 #                         routers on the outgoing interface
I1.             #
12:33:50.882#
#
12:33:50.882 #                         Later, when the DUT receives
multicast data for   #
12:33:50.882 #                         (S,G) on outgoing interface I1 due to
other       #
12:33:50.883 #                         router also forwards data on I1, it
should send   #
12:33:50.883 #                         ASSERT(S,G) Message on I1, confirming
that its    #
12:33:50.883 #                         (S,G) Assert state machine on I1 has
transitioned #
12:33:50.883 #                         from NO_INFO state to
I_AM_ASSERT_WINNER state.   #
12:33:50.883#
#
12:33:50.883 #                         NI state ---> W
state                             #
12:33:50.883#
#
12:33:50.883#############################################################################
12:33:50.884 # Test Setup
:                                                     #
12:33:50.884 #                              ___
___           #
12:33:50.884 #                             |   |          (I1)
|   |          #
12:33:50.884 #                             | T |--------------------------|
D |          #
12:33:50.884 #                             | E |                          |
U |          #
12:33:50.884 #                             | E |--------------------------|
T |          #
12:33:50.884 #                           S |___|          (I2)
|___|          #
12:33:50.885#
#
12:33:50.885#############################################################################
12:33:50.885 # Ladder Diagram
:                                                      #
12:33:50.885#
#
12:33:50.885 #
|                                          |      #
12:33:50.885 #
|                                          |      #
12:33:50.885 #                       T |JOIN(S,G)
(I1)                            | D    #
12:33:50.886 #
|-------->>--------------------------------|      #
12:33:50.886 #                         |
JOIN(S,G) (I2)|      #
12:33:50.886 #
|---------------------------------<<-------|      #
12:33:50.886 #
|                                          |      #
12:33:50.886 #
|                                          |      #
12:33:50.886 #                         |Mcast data(for G)
(I2)                    |      #
12:33:50.886 #                       E
|------->>---------------------------------| U    #
12:33:50.887 #
|                                          |      #
12:33:50.887 #                         |                    Mcast data(for
G) (I1)|      #
12:33:50.887 #
|---------------------------------<<-------|      #
12:33:50.887 #
|                                          |      #
12:33:50.887 #                         |Mcast data(for G)
(I1)                    |      #
12:33:50.887 #
|------->>---------------------------------|      #
12:33:50.887 #
|                                          |      #
12:33:50.887 #                       E |
ASSERT(S,G) (I1)| T    #
12:33:50.888 #
|---------------------------------<<-------|      #
12:33:50.888 #
|                                          |      #
12:33:50.888#
#
12:33:50.888#############################################################################

But in the step 9 there is a problem with Join (S,G).

################################################################
12:35:59.931 #                      Step 9
#
12:35:59.931 #Error: DUT has not sent the JOIN(S,G) from 192.168.8.5   #
12:35:59.931 #       to TEE on I2
#
12:35:59.931################################################################
12:35:59.931################################################################################

12:35:59.932################################################################################
12:35:59.932 # TEST CASE ABORTED : DUT has not sent the JOIN(S,G) to TEE on
I2
12:35:59.932################################################################################

12:35:59.932################################################################################


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/20071209/b8e76c56/attachment-0001.html 

From pavlin at icir.org  Sun Dec  9 11:07:02 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sun, 09 Dec 2007 11:07:02 -0800
Subject: [Xorp-users] Fwd: tests conformance using XORP
In-Reply-To: Message from "Jeandro de M. Bezerra" <jeandro@larces.uece.br> 
	of "Sun, 09 Dec 2007 15:43:46 -0300."
	<5efcb8aa0712091043s65a8363dl9b518e0bbd05e54f@mail.gmail.com> 
Message-ID: <200712091907.lB9J7293035833@possum.icir.org>

What XORP version are you using?

Could you send your XORP configuration, as well as the output
of "show pim join" xorpsh command right after the test case was
aborted because of the missing (S,G) PIM Join.

Also, could you resend your original test log output without
wrapping/breaking the lines, because it is very difficult to read
the log as it is.
Last but not least, please send the description of the different
steps, because it is unclear what has happened before "Step 9" with
the failure.

Thanks,
Pavlin


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

> ---------- Forwarded message ----------
> From: Jeandro Bezerra <jeandro at gmail.com>
> Date: 09/12/2007 15:40
> Subject: tests conformance using XORP
> To: xorp-users at xorp.org
> 
> Hi,
> 
> I am perform a tests set using ATTEST Testcase for module PIM-SM. The DUT
> (device Under Test) is XORP. In the testbed 002 i have  a test.
> 
>  #############################################################################
> 
> 12:33:50.836 # Test Case           :
> tc_conf_pim-sm_ast_001                            #
> 12:33:50.842 # Test Case Version   :   1.0
> #
> 12:33:50.847 # Component Name      :   NET-O2 ATTEST CONFORMANCE TEST
> SUITE              #
> 12:33:50.853 # Module Name         :   PIM-SM/Assert Group
> (AST)                         #
> 12:33:50.859#
> #
> 12:33:50.865 # Purpose             :   To verify that the (S,G) Assert state
> machine     #
> 12:33:50.871 #                         on the interface transit from NO_INFO
> state to    #
> 12:33:50.876 #                         I_AM_ASSERT_WINNER state, on
> receiving a (S,G)    #
> 12:33:50.879 #                         data packet on downstream interface
> whose (S,G)   #
> 12:33:50.880 #                         downstream state machine is in JOIN
> state.        #
> 12:33:50.881#
> #
> 12:33:50.881 # Description         :   In this test-case, on receiving
> JOIN(S,G) on      #
> 12:33:50.881 #                         interface I1, DUT should send the
> JOIN(S,G) to    #
> 12:33:50.881 #                         TEE I2 (towards source S), confirming
> that its    #
> 12:33:50.881 #                         (S,G) downstream state machine on
> interface I1    #
> 12:33:50.881 #                         has transitioned to JOIN
> state.                   #
> 12:33:50.881#
> #
> 12:33:50.882 #                         When multicast data traffic destined
> for group G  #
> 12:33:50.882 #                         is received from source S (TEE I2),
> the DUT       #
> 12:33:50.882 #                         should forward traffic for G to the
> downstream    #
> 12:33:50.882 #                         routers on the outgoing interface
> I1.             #
> 12:33:50.882#
> #
> 12:33:50.882 #                         Later, when the DUT receives
> multicast data for   #
> 12:33:50.882 #                         (S,G) on outgoing interface I1 due to
> other       #
> 12:33:50.883 #                         router also forwards data on I1, it
> should send   #
> 12:33:50.883 #                         ASSERT(S,G) Message on I1, confirming
> that its    #
> 12:33:50.883 #                         (S,G) Assert state machine on I1 has
> transitioned #
> 12:33:50.883 #                         from NO_INFO state to
> I_AM_ASSERT_WINNER state.   #
> 12:33:50.883#
> #
> 12:33:50.883 #                         NI state ---> W
> state                             #
> 12:33:50.883#
> #
> 12:33:50.883#############################################################################
> 12:33:50.884 # Test Setup
> :                                                     #
> 12:33:50.884 #                              ___
> ___           #
> 12:33:50.884 #                             |   |          (I1)
> |   |          #
> 12:33:50.884 #                             | T |--------------------------|
> D |          #
> 12:33:50.884 #                             | E |                          |
> U |          #
> 12:33:50.884 #                             | E |--------------------------|
> T |          #
> 12:33:50.884 #                           S |___|          (I2)
> |___|          #
> 12:33:50.885#
> #
> 12:33:50.885#############################################################################
> 12:33:50.885 # Ladder Diagram
> :                                                      #
> 12:33:50.885#
> #
> 12:33:50.885 #
> |                                          |      #
> 12:33:50.885 #
> |                                          |      #
> 12:33:50.885 #                       T |JOIN(S,G)
> (I1)                            | D    #
> 12:33:50.886 #
> |-------->>--------------------------------|      #
> 12:33:50.886 #                         |
> JOIN(S,G) (I2)|      #
> 12:33:50.886 #
> |---------------------------------<<-------|      #
> 12:33:50.886 #
> |                                          |      #
> 12:33:50.886 #
> |                                          |      #
> 12:33:50.886 #                         |Mcast data(for G)
> (I2)                    |      #
> 12:33:50.886 #                       E
> |------->>---------------------------------| U    #
> 12:33:50.887 #
> |                                          |      #
> 12:33:50.887 #                         |                    Mcast data(for
> G) (I1)|      #
> 12:33:50.887 #
> |---------------------------------<<-------|      #
> 12:33:50.887 #
> |                                          |      #
> 12:33:50.887 #                         |Mcast data(for G)
> (I1)                    |      #
> 12:33:50.887 #
> |------->>---------------------------------|      #
> 12:33:50.887 #
> |                                          |      #
> 12:33:50.887 #                       E |
> ASSERT(S,G) (I1)| T    #
> 12:33:50.888 #
> |---------------------------------<<-------|      #
> 12:33:50.888 #
> |                                          |      #
> 12:33:50.888#
> #
> 12:33:50.888#############################################################################
> 
> But in the step 9 there is a problem with Join (S,G).
> 
> ################################################################
> 12:35:59.931 #                      Step 9
> #
> 12:35:59.931 #Error: DUT has not sent the JOIN(S,G) from 192.168.8.5   #
> 12:35:59.931 #       to TEE on I2
> #
> 12:35:59.931################################################################
> 12:35:59.931################################################################################
> 
> 12:35:59.932################################################################################
> 12:35:59.932 # TEST CASE ABORTED : DUT has not sent the JOIN(S,G) to TEE on
> I2
> 12:35:59.932################################################################################
> 
> 12:35:59.932################################################################################
> 
> 
> 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 Dragos.Ciobanu at xerox.com  Sun Dec  9 12:35:22 2007
From: Dragos.Ciobanu at xerox.com (Ciobanu, Dragos O)
Date: Sun, 9 Dec 2007 12:35:22 -0800
Subject: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
	fticonfig_entry_set_netlink.cc add_entry ] Error checking
	netlink request
In-Reply-To: <200712070219.lB72JAQR008427@possum.icir.org>
References: Message from "Ciobanu,
	Dragos O" <Dragos.Ciobanu@xerox.com>    of "Thu,
	06 Dec 2007 18:10:06 PST."
	<9C245B9CF8CC6647B6BD9237D6C7EFA9808610@USA7061MS04.na.xerox.net>
	<200712070219.lB72JAQR008427@possum.icir.org>
Message-ID: <9C245B9CF8CC6647B6BD9237D6C7EFA98598CF@USA7061MS04.na.xerox.net>

Ok, here's some more specific details:

- machine: r1 with eth0 and eth1
- machine: r2 with eth0 and eth1
- r1:eth0 and r2:eth0 are connected with a hub
- r1:eth1 and r2:eth1 are on other subnets

- r1:eth0 address is: 10.10.10.10.10.10.10.10/64
- r2:eth0 address is: 10.10.10.10.10.10.10.20/64
- r1:eth1 address is: 10.10.10.20.10.10.10.10/64
- r2:eth1 address is: 10.10.10.30.10.10.10.10/64

I'm trying to create static routes from r1 to r2:eth1 and from r2 to
r1:eth1.
When I'm doing that from r1 let's say:

set protocols static route 10:10:10:30::/64 next-hop
10:10:10:10:10:10:10:20

It accepts the command but when I commit it, it gives me that error.

-----Original Message-----
From: Pavlin Radoslavov [mailto:pavlin at icir.org] 
Sent: Thursday, December 06, 2007 6:19 PM
To: Ciobanu, Dragos O
Cc: Pavlin Radoslavov; xorp-users at xorp.org
Subject: Re: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
fticonfig_entry_set_netlink.cc add_entry ] Error checking netlink
request 

Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:

> Sorry Pavlin,
> 
> But I couldn't log in to the CVS server. I tried leaving the password 
> blank and  it gives me this error:
> Cvs [login aborted]: end of file from server
> 
> Is the CVS server up?

I just tried it and it works for me:

pavlin at xorp13[25] setenv CVSROOT :pserver:xorpcvs at anoncvs.xorp.org:/cvs
pavlin at xorp13[26] cvs login
Logging in to :pserver:xorpcvs at anoncvs.xorp.org:2401/cvs
CVS password: 
pavlin at xorp13[27] cvs checkout xorp
cvs checkout: Updating xorp
U xorp/.cvsignore
U xorp/BUGS
U xorp/BUILD_NOTES
U xorp/ERRATA
^Ccvs [checkout aborted]: received interrupt signal Exit 1
pavlin at xorp13[28] 

Note that "setenv" is used by csh/tcsh; If your login shell is bash,
then replace the first line with export
CVSROOT=:pserver:xorpcvs at anoncvs.xorp.org:/cvs

Pavlin

> -----Original Message-----
> From: Pavlin Radoslavov [mailto:pavlin at icir.org]
> Sent: Thursday, December 06, 2007 4:59 PM
> To: Ciobanu, Dragos O
> Cc: xorp-users at xorp.org
> Subject: Re: [Xorp-users] ERROR: xorp_fea:4361 FEA +324 
> fticonfig_entry_set_netlink.cc add_entry ] Error checking netlink 
> request
> 
> Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:
> 
> > 
> > I'm trying to configure a xorp router with static routes for IPv6. 
> > In xorpsh I can commit the static route, but the output for 
> > xorp_rtrmgr gives me this error:
> > 
> > ERROR: xorp_fea:4361 FEA +324 fticonfig_entry_set_netlink.cc 
> > add_entry
> 
> > ] Error checking netlink request: AF_NETLINK NLMSG_ERROR message: 
> > Invalid argument.
> > 
> > I'm using xorp 1.4. 
> > 
> > Has anyone else seen this and could help me?
> 
> What OS and kernel version are you using?
> 
> Also, can you try the latest code from anon. CVS:
> http://www.xorp.org/cvs.html
> It contains various bug fixes, but no guarantee it contains the fix 
> for the error you see.
> 
> Regards,
> Pavlin
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin at icir.org  Sun Dec  9 20:38:41 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sun, 09 Dec 2007 20:38:41 -0800
Subject: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
	fticonfig_entry_set_netlink.cc add_entry ] Error checking
	netlink request
In-Reply-To: Message from "Ciobanu, Dragos O" <Dragos.Ciobanu@xerox.com> 
	of "Sun, 09 Dec 2007 12:35:22 PST."
	<9C245B9CF8CC6647B6BD9237D6C7EFA98598CF@USA7061MS04.na.xerox.net>
Message-ID: <200712100438.lBA4cfcc039729@possum.icir.org>

Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:

> Ok, here's some more specific details:
> 
> - machine: r1 with eth0 and eth1
> - machine: r2 with eth0 and eth1
> - r1:eth0 and r2:eth0 are connected with a hub
> - r1:eth1 and r2:eth1 are on other subnets
> 
> - r1:eth0 address is: 10.10.10.10.10.10.10.10/64
> - r2:eth0 address is: 10.10.10.10.10.10.10.20/64
> - r1:eth1 address is: 10.10.10.20.10.10.10.10/64
> - r2:eth1 address is: 10.10.10.30.10.10.10.10/64
> 
> I'm trying to create static routes from r1 to r2:eth1 and from r2 to
> r1:eth1.
> When I'm doing that from r1 let's say:
> 
> set protocols static route 10:10:10:30::/64 next-hop
> 10:10:10:10:10:10:10:20
> 
> It accepts the command but when I commit it, it gives me that error.

Thank you for the detailed info.
After some investigation I believe the problem is in the particular
choice of the IPv6 addresses.
First I used the Linux "ip" command to add the route and I got
exactly same error which suggested to me that the problem is not
XORP-specific:

root at ixp[54] ip -f inet6 addr add 10:10:10:10:10:10:10:10/64 dev eth1
root at ixp[55] ip -f inet6 route add 10:10:10:30::/64 via 10:10:10:10:10:10:10:20
RTNETLINK answers: Invalid argument
Exit 2

In fact, if you check the following table with the assigned IPv6
addresses, you would see that the 10:10:10:10... addresses fail
within the 0000::/8 address range which is reserved by IETF:
http://www.iana.org/assignments/ipv6-address-space

In fact, if you replace the first two octets of the interface
addresses with 2010: instead of 10: then everything works as
expected:

interfaces {
    interface eth1 {
        vif eth1 {
            address 2010:10:10:10:10:10:10:10 {
                prefix-length: 64
            }
        }
    }
}

fea {
    unicast-forwarding6 {
        disable: false
    }
}

protocols {
    static {
        route 2010:10:10:30::/64 {
            next-hop: 2010:10:10:10:10:10:10:20
        }
    }
}

Regards,
Pavlin


> -----Original Message-----
> From: Pavlin Radoslavov [mailto:pavlin at icir.org] 
> Sent: Thursday, December 06, 2007 6:19 PM
> To: Ciobanu, Dragos O
> Cc: Pavlin Radoslavov; xorp-users at xorp.org
> Subject: Re: [Xorp-users] ERROR: xorp_fea:4361 FEA +324
> fticonfig_entry_set_netlink.cc add_entry ] Error checking netlink
> request 
> 
> Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:
> 
> > Sorry Pavlin,
> > 
> > But I couldn't log in to the CVS server. I tried leaving the password 
> > blank and  it gives me this error:
> > Cvs [login aborted]: end of file from server
> > 
> > Is the CVS server up?
> 
> I just tried it and it works for me:
> 
> pavlin at xorp13[25] setenv CVSROOT :pserver:xorpcvs at anoncvs.xorp.org:/cvs
> pavlin at xorp13[26] cvs login
> Logging in to :pserver:xorpcvs at anoncvs.xorp.org:2401/cvs
> CVS password: 
> pavlin at xorp13[27] cvs checkout xorp
> cvs checkout: Updating xorp
> U xorp/.cvsignore
> U xorp/BUGS
> U xorp/BUILD_NOTES
> U xorp/ERRATA
> ^Ccvs [checkout aborted]: received interrupt signal Exit 1
> pavlin at xorp13[28] 
> 
> Note that "setenv" is used by csh/tcsh; If your login shell is bash,
> then replace the first line with export
> CVSROOT=:pserver:xorpcvs at anoncvs.xorp.org:/cvs
> 
> Pavlin
> 
> > -----Original Message-----
> > From: Pavlin Radoslavov [mailto:pavlin at icir.org]
> > Sent: Thursday, December 06, 2007 4:59 PM
> > To: Ciobanu, Dragos O
> > Cc: xorp-users at xorp.org
> > Subject: Re: [Xorp-users] ERROR: xorp_fea:4361 FEA +324 
> > fticonfig_entry_set_netlink.cc add_entry ] Error checking netlink 
> > request
> > 
> > Ciobanu, Dragos O <Dragos.Ciobanu at xerox.com> wrote:
> > 
> > > 
> > > I'm trying to configure a xorp router with static routes for IPv6. 
> > > In xorpsh I can commit the static route, but the output for 
> > > xorp_rtrmgr gives me this error:
> > > 
> > > ERROR: xorp_fea:4361 FEA +324 fticonfig_entry_set_netlink.cc 
> > > add_entry
> > 
> > > ] Error checking netlink request: AF_NETLINK NLMSG_ERROR message: 
> > > Invalid argument.
> > > 
> > > I'm using xorp 1.4. 
> > > 
> > > Has anyone else seen this and could help me?
> > 
> > What OS and kernel version are you using?
> > 
> > Also, can you try the latest code from anon. CVS:
> > http://www.xorp.org/cvs.html
> > It contains various bug fixes, but no guarantee it contains the fix 
> > for the error you see.
> > 
> > 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 Dec 10 01:38:17 2007
From: hantongs at gmail.com (Hansi)
Date: Mon, 10 Dec 2007 17:38:17 +0800
Subject: [Xorp-users] Fwd: Fwd: Problem in IPv6 SSM Multicast
In-Reply-To: <200712062000.lB6K0ghj098659@possum.icir.org>
References: <hantongs@gmail.com>
	<2f9e317b0712060319m37ddce34tc1df221325c391f4@mail.gmail.com>
	<200712062000.lB6K0ghj098659@possum.icir.org>
Message-ID: <2f9e317b0712100138g2e5618cdgf68a49027d6e20e7@mail.gmail.com>

Hello Pavlin,

Apparently, the receiver had two interfaces. One interface connected to the
test network I'm currently using and the other one to the production
network. I suspect the MLDv2 Join messages are sent to the wrong interface
(in this case, the production network) though I explicitly set the
link-local address of the xorp router machine as the client's default
gateway.

Yes, you are right. I ran tcpdump on the sender side and it appears the
streaming server is sending out fragmented packets.

Streaming Server to Router 1:

09:51:22.692158 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 100) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xec6a52cc:1232|92)
09:51:22.700132 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xf753c59f:0|1232) 61541 > 1234: UDP, length 1316
09:51:22.700146 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 100) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xf753c59f:1232|92)
09:51:22.708230 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xe37aa8b2:0|1232) 61541 > 1234: UDP, length 1316
09:51:22.708243 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 100) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xe37aa8b2:1232|92)
09:51:22.716214 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xc1fd9920:0|1232) 61541 > 1234: UDP, length 1316

Apparently, a second fragment of length 100 is sent out after the first one.
Oddly though.. once the fragmented packets reached Router 2, the second
fragment is no longer received... probably dropped. I'm suspecting that
Router 2 is unable to associate the second fragment to the first.

Router 1 <------> Router 2

05:57:43.861774 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x40a52867:0|1232) 61542 > 1234: UDP, length 1316
05:57:43.871960 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x33f49657:0|1232) 61542 > 1234: UDP, length 1316
05:57:43.882756 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x2d938af5:0|1232) 61542 > 1234: UDP, length 1316
05:57:43.893746 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x62f4a589:0|1232) 61542 > 1234: UDP, length 1316


Router <------> (sk0)receiver

17:51:56.196244 IP6 (flowlabel 0xb063f, hlim 13, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x48714108:0|1232) 61542 > 1234: UDP, length 1316
17:51:56.205162 IP6 (flowlabel 0xb063f, hlim 13, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x5449397c:0|1232) 61542 > 1234: UDP, length 1316
17:51:56.214114 IP6 (flowlabel 0xb063f, hlim 13, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x3e81a7bf:0|1232) 61542 > 1234: UDP, length 1316

I'm currently investigating this issue right now. Got to read more on IPv6
fragmentation. hehe...

Thanks,
Hansi

On Dec 7, 2007 4:00 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:

> > Finally, IPv6 PIM SSM is working. :) Here are the details:
>
> Good!
> What was the source of the problem?
>
> > What's odd though is that I don't see any video displayed in the vlc
> > receiver application. I'm quite sure PIM-SSM is already working as I can
> see
> > these packets on the interface of the receiver connected to the upstream
> > router:
> >
> > 17:19:39.634155 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment
> (44),
> > length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> > (0x9a8d7789:0|1232) 65336 > 1234: UDP, length 1316
> > 17:19:39.646131 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment
> (44),
> > length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> > (0x89a0d7d2:0|1232) 65336 > 1234: UDP, length 1316
> > 17:19:39.659118 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment
> (44),
> > length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> > (0x960ae0a2:0|1232) 65336 > 1234: UDP, length 1316
> > 17:19:39.670100 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment
> (44),
> > length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> > (0xaa68e0b2:0|1232) 65336 > 1234: UDP, length 1316
> > 17:19:39.683136 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment
> (44),
> > length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> > (0x856c81f0:0|1232) 65336 > 1234: UDP, length 1316
> > 17:19:39.695087 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment
> (44),
> > length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> > (0xd64fbf0f:0|1232) 65336 > 1234: UDP, length 1316
> > 17:19:39.708045 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment
> (44),
> > length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> > (0x99f7d97b:0|1232) 65336 > 1234: UDP, length 1316
> > 17:19:39.720029 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment
> (44),
> > length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> > (0xdc3a139d:0|1232) 65336 > 1234: UDP, length 1316
> > 17:19:39.732111 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment
> (44),
> > length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> > (0xa3688a13:0|1232) 65336 > 1234: UDP, length 1316
> > 17:19:47.410658 IP6 (hlim 1, next-header: Options (0), length: 52)
> > fe80::219:5bff:fe2f:1468 > ff02::16: HBH (rtalert: 0x0000) (padn)ICMP6,
> > multicast listener report v2, length 44, 1 group record(s) [gaddr
> ff3e::1234
> > block {[|icmp6]
> >
> > Is there something wrong with the packets arriving at the receiver's
> side?
>
> It looks like the IPv6 UDP packets that reach the receiver are
> fragmented. Also, I could be wrong here, but it appears that only
> the first fragment of each packet reaches the receiver, and the
> second segment is missing. The way I interpretate the above log
> messages is that the size of each original UDP packet is 1316, but
> each of the above fragments contains only 1240 bytes.
>
> FYI, the IPv6 fragmentation should happen at the sender so you need
> to run tcpdump on the sender's segment to see whether it really
> sends all fragments. You should be looking for the smaller fragments
> with size of 76 or so.
>
> Once you solve the above problem, you should also try to eliminate
> the reason for the fragmentation. E.g., if the sender's application
> allows you to control the transmitted packet size then you should
> eventually reduce it to avoid the fragmentation penalty.
> However, I'd strongly recommend that first you fix the problem with
> the missing fragments. Otherwise, if you mask it by reducing the
> packet size it will come and bite you at later stage :)
>
> Regards,
> Pavlin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071210/76d4f593/attachment-0001.html 

From jeandro at larces.uece.br  Mon Dec 10 05:44:21 2007
From: jeandro at larces.uece.br (Jeandro de M. Bezerra)
Date: Mon, 10 Dec 2007 10:44:21 -0300
Subject: [Xorp-users] Fwd: tests conformance using XORP
In-Reply-To: <200712091907.lB9J7293035833@possum.icir.org>
References: <jeandro@larces.uece.br>
	<5efcb8aa0712091043s65a8363dl9b518e0bbd05e54f@mail.gmail.com>
	<200712091907.lB9J7293035833@possum.icir.org>
Message-ID: <5efcb8aa0712100544v613f7e2ah4fcddccb1f0eefea@mail.gmail.com>

2007/12/9, Pavlin Radoslavov <pavlin at icir.org>:
>
> What XORP version are you using?
> Xorp 1.4.  Slackware kernel 2.4.33.3
>

Could you send your XORP configuration, as well as the output
> of "show pim join" xorpsh command right after the test case was
> aborted because of the missing (S,G) PIM Join.


/* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu
Exp $ */


interfaces {
    restore-original-config-on-shutdown: false
    interface eth0 {
    description: "data interface"
    disable: false
    /* default-system-config */
     vif eth0 {
            disable: false
            address 192.168.7.5 {
                prefix-length: 24
                broadcast: 192.168.7.255
                disable: false
        }
    }
    }

  interface eth1 {
    description: "data interface"
    disable: false
    /* default-system-config */
     vif eth1 {
            disable: false
            address 192.168.8.5 {
                prefix-length: 24
                broadcast: 192.168.8.255
                disable: false
        }
    }

 }

}

fea {
    unicast-forwarding4 {
    disable: false
    forwarding-entries {
        retain-on-startup: false
        retain-on-shutdown:    false
    }
    }

}


protocols {
    static {

    interface-route 192.168.8.0/24 {
     next-hop-interface: "eth0"
     next-hop-vif: "eth0"
     next-hop-router: 192.168.7.5
     metric: 1
     }

    mrib-interface-route 192.168.8.0/24 {
     next-hop-interface: "eth0"
     next-hop-vif: "eth0"
     metric: 1
     }


    }

}



policy {
    /* Describe connected routes for redistribution */
    policy-statement connected {
    term export {
        from {
        protocol: "connected"
        }
    }
    }
}


policy {
    /* Describe static routes for redistribution */
    policy-statement static {
        term export {
            from {
                protocol: "static"
            }
        }
    }
}



plumbing {
    mfea4 {
        disable: false
        interface eth0 {
            vif eth0 {
                disable: false
            }
        }
        interface eth1 {
            vif eth1 {
                disable: false
            }
        }

        interface register_vif {
            vif register_vif {
                /* Note: this vif should be always enabled */
                disable: false
            }
        }
        traceoptions {
            flag all {
                disable: false
            }
        }
    }
}


protocols {
    rip {

/* Connected interfaces will only be advertised if explicitly exported */
        export: "connected"
    export: "static"

/* Run on specified network interface addresses */
        interface eth0 {
            vif eth0 {
                address 192.168.7.5 {
                    disable: false
                }
            }
        }

    interface eth1 {
            vif eth1 {
                address 192.168.8.5 {
                    disable: false
                }
            }
        }

    }
}



protocols {
    igmp {
    disable: false
    interface eth0 {
        vif eth0 {
        disable: false
        /* version: 2 */
        /* enable-ip-router-alert-option-check: false */
        /* query-interval: 125 */
        /* query-last-member-interval: 1 */
        /* query-response-interval: 10 */
        /* robust-count: 2 */
        }
    }
    interface eth1 {
        vif eth1 {
        disable: false
        /* version: 2 */
        /* enable-ip-router-alert-option-check: false */
        /* query-interval: 125 */
        /* query-last-member-interval: 1 */
        /* query-response-interval: 10 */
        /* robust-count: 2 */
        }
    }


    traceoptions {
        flag all {
        disable: false
        }
    }
    }
/*
    mld {
    disable: false
    interface eth0 {
        vif eth0 {
        disable: false
        version: 1
        enable-ip-router-alert-option-check: false
        query-interval: 125
        query-last-member-interval: 1
        query-response-interval: 10
        robust-count: 2
        }
    }
    traceoptions {
        flag all {
        disable: false
        }
    }
    }
*/
}

protocols {
    pimsm4 {
    disable: false
    interface eth0 {
        vif eth0 {
        disable: false
        /* enable-ip-router-alert-option-check: false */
        /* dr-priority: 1 */
        /* hello-period: 30 */
        /* hello-triggered-delay: 5 */
        /* alternative-subnet 10.40.0.0/16 */
        }
    }

    interface eth1 {
        vif eth1 {
        disable: false
        /* enable-ip-router-alert-option-check: false */
        /* dr-priority: 1 */
        /* hello-period: 30 */
        /* hello-triggered-delay: 5 */
        /* alternative-subnet 10.40.0.0/16 */
        }
    }

    interface register_vif {
        vif register_vif {
        /* Note: this vif should be always enabled */
        disable: false
        }
    }

      /*     static-rps {*/
    /*    rp 192.168.7.5 {*/
    /*    group-prefix 224.0.0.0/4 {*/
            /* rp-priority: 192 */
            /* hash-mask-len: 30 */
    /*    } */
    /*    } */
/*    } */

    bootstrap {
        disable: false
        cand-bsr {
        scope-zone 224.0.0.0/8 {
            /* is-scope-zone: false */
            cand-bsr-by-vif-name: "eth0"
            /* cand-bsr-by-vif-addr: 10.10.10.10 */
             bsr-priority: 1
            /* hash-mask-len: 30 */
        }
          }
        cand-bsr {
        scope-zone 224.0.0.0/8 {
            /* is-scope-zone: false */
            cand-bsr-by-vif-name: "eth1"
            /* cand-bsr-by-vif-addr: 10.10.10.10 */
             bsr-priority: 2
            /* hash-mask-len: 30 */
        }

        }

        cand-rp {
        group-prefix 224.0.0.0/8 {
            /* is-scope-zone: false */
            cand-rp-by-vif-name: "eth0"
            /* cand-rp-by-vif-addr: 10.10.10.10 */
             rp-priority: 192
            /* rp-holdtime: 150 */
        }
        }
            cand-rp {
        group-prefix 224.0.0.0/8 {
            /* is-scope-zone: false */
            cand-rp-by-vif-name: "eth1"
            /* cand-rp-by-vif-addr: 10.10.10.10 */
             rp-priority: 195
            /* rp-holdtime: 150 */
        }
        }


    }

    switch-to-spt-threshold {
        /* approx. 1K bytes/s (10Kbps) threshold */
        disable: false
        interval: 100
        bytes: 102400
    }

    traceoptions {
        flag all {
        disable: false
        }
    }
    }


/*
 * Note: fib2mrib is needed for multicast only if the unicast protocols
 * don't populate the MRIB with multicast-specific routes.
 */
protocols {
    fib2mrib {
    disable: false
    }
}



/*
 * See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in your
host
 * before uncommenting the snmp section below.
 * Also check that the "bgp4_mib_1657.so" exists in the correct location.
 */

/*
protocols {
    snmp {
    mib-module bgp4_mib_1657 {
        abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so"
    }
    }
}
*/

__________________________________________

root at thiago> show pim join
Group           Source          RP              Flags
224.1.1.1       192.168.6.1     192.168.8.5     SG
    Upstream interface (S):    UNKNOWN
    Upstream interface (RP):   register_vif
    Upstream MRIB next hop (RP): UNKNOWN
    Upstream MRIB next hop (S):  UNKNOWN
    Upstream RPF'(S,G):        UNKNOWN
    Upstream state:            Joined
    Join timer:                48
    KAT(S,G) running:          false
    Local receiver include WC: ...
    Local receiver include SG: ...
    Local receiver exclude SG: ...
    Joins RP:                  ...
    Joins WC:                  ...
    Joins SG:                  O..
    Join state:                O..
    Prune state:               ...
    Prune pending state:       ...
    I am assert winner state:  ...
    I am assert loser state:   ...
    Assert winner WC:          ...
    Assert winner SG:          ...
    Assert lost WC:            ...
    Assert lost SG:            ...
    Assert lost SG_RPT:        ...
    Assert tracking SG:        O..
    Could assert WC:           ...
    Could assert SG:           ...
    I am DR:                   O.O
    Immediate olist RP:        ...
    Immediate olist WC:        ...
    Immediate olist SG:        O..
    Inherited olist SG:        O..
    Inherited olist SG_RPT:    ...
    PIM include WC:            ...
    PIM include SG:            ...
    PIM exclude SG:            ...
 (END)




Also, could you resend your original test log output without
> wrapping/breaking the lines, because it is very difficult to read
> the log as it is.
> Last but not least, please send the description of the different
> steps, because it is unclear what has happened before "Step 9" with
> the failure.


12:33:50.819 Net-O2 TEE LOG REPORT
12:33:50.826 Date :     2007-12-08
12:33:50.830#############################################################################
12:33:50.836 # Test Case           :
tc_conf_pim-sm_ast_001                            #
12:33:50.842 # Test Case Version   :   1.0
#
12:33:50.847 # Component Name      :   NET-O2 ATTEST CONFORMANCE TEST
SUITE              #
12:33:50.853 # Module Name         :   PIM-SM/Assert Group
(AST)                         #
12:33:50.859#
#
12:33:50.865 # Purpose             :   To verify that the (S,G) Assert state
machine     #
12:33:50.871 #                         on the interface transit from NO_INFO
state to    #
12:33:50.876 #                         I_AM_ASSERT_WINNER state, on
receiving a (S,G)    #
12:33:50.879 #                         data packet on downstream interface
whose (S,G)   #
12:33:50.880 #                         downstream state machine is in JOIN
state.        #
12:33:50.881#
#
12:33:50.881 # Description         :   In this test-case, on receiving
JOIN(S,G) on      #
12:33:50.881 #                         interface I1, DUT should send the
JOIN(S,G) to    #
12:33:50.881 #                         TEE I2 (towards source S), confirming
that its    #
12:33:50.881 #                         (S,G) downstream state machine on
interface I1    #
12:33:50.881 #                         has transitioned to JOIN
state.                   #
12:33:50.881#
#
12:33:50.882 #                         When multicast data traffic destined
for group G  #
12:33:50.882 #                         is received from source S (TEE I2),
the DUT       #
12:33:50.882 #                         should forward traffic for G to the
downstream    #
12:33:50.882 #                         routers on the outgoing interface
I1.             #
12:33:50.882#
#
12:33:50.882 #                         Later, when the DUT receives
multicast data for   #
12:33:50.882 #                         (S,G) on outgoing interface I1 due to
other       #
12:33:50.883 #                         router also forwards data on I1, it
should send   #
12:33:50.883 #                         ASSERT(S,G) Message on I1, confirming
that its    #
12:33:50.883 #                         (S,G) Assert state machine on I1 has
transitioned #
12:33:50.883 #                         from NO_INFO state to
I_AM_ASSERT_WINNER state.   #
12:33:50.883#
#
12:33:50.883 #                         NI state ---> W
state                             #
12:33:50.883#
#
12:33:50.883#############################################################################
12:33:50.884 # Test Setup
:                                                     #
12:33:50.884 #                              ___
___           #
12:33:50.884 #                             |   |          (I1)
|   |          #
12:33:50.884 #                             | T |--------------------------|
D |          #
12:33:50.884 #                             | E |                          |
U |          #
12:33:50.884 #                             | E |--------------------------|
T |          #
12:33:50.884 #                           S |___|          (I2)
|___|          #
12:33:50.885#
#
12:33:50.885#############################################################################
12:33:50.885 # Ladder Diagram
:                                                      #
12:33:50.885#
#
12:33:50.885 #
|                                          |      #
12:33:50.885 #
|                                          |      #
12:33:50.885 #                       T |JOIN(S,G)
(I1)                            | D    #
12:33:50.886 #
|-------->>--------------------------------|      #
12:33:50.886 #                         |
JOIN(S,G) (I2)|      #
12:33:50.886 #
|---------------------------------<<-------|      #
12:33:50.886 #
|                                          |      #
12:33:50.886 #
|                                          |      #
12:33:50.886 #                         |Mcast data(for G)
(I2)                    |      #
12:33:50.886 #                       E
|------->>---------------------------------| U    #
12:33:50.887 #
|                                          |      #
12:33:50.887 #                         |                    Mcast data(for
G) (I1)|      #
12:33:50.887 #
|---------------------------------<<-------|      #
12:33:50.887 #
|                                          |      #
12:33:50.887 #                         |Mcast data(for G)
(I1)                    |      #
12:33:50.887 #
|------->>---------------------------------|      #
12:33:50.887 #
|                                          |      #
12:33:50.887 #                       E |
ASSERT(S,G) (I1)| T    #
12:33:50.888 #
|---------------------------------<<-------|      #
12:33:50.888 #
|                                          |      #
12:33:50.888#
#
12:33:50.888#############################################################################
12:33:50.888#
#
12:33:50.888 # Procedure
:                                                               #
12:33:50.888#
#
12:33:50.889 #    (Initial
Part)                                                         #
12:33:50.889 # Step 1 :  Initialize the DUT with two interfaces(I1 & I2) and
Enable      #
12:33:50.889 #           PIM-SM on both the
interfaces.                                  #
12:33:50.889 # Step 2 :  Initialize the TEE with two interfaces(I1 & I2) and
Enable      #
12:33:50.889 #           PIM-SM on both the
interfaces.                                  #
12:33:50.889#
#
12:33:50.890 #
(Part-I)                                                               #
12:33:50.890 # Step 3 :  Send HELLO Messages from interface (I1) of
TEE.                 #
12:33:50.890 # Step 4 :  Observe the Neighbor come up in the Neighbor table
of DUT(I1).  #
12:33:50.890 # Step 5 :  Send HELLO Messages from interface (I2) of
TEE.                 #
12:33:50.890 # Step 6 :  Observe the Neighbor come up in the Neighbor table
of DUT(I2).  #
12:33:50.890#
#
12:33:50.890 #
(Part-II)                                                              #
12:33:50.890 # Step 7 :  Set Static route for source S on DUT with normal
metric and     #
12:33:50.891 #           gateway as
TEE(I2).                                             #
12:33:50.891 # Step 8 :  Send JOIN(S,G) Message on the interface I1 from
TEE.            #
12:33:50.891 # Step 9 :  To observe that JOIN(S,G) is sent by DUT towards
source S, Check#
12:33:50.891 #           that DUT forwards JOIN(S,G) towards TEE on
I2.                  #
12:33:50.891#
#
12:33:50.891 #
(Part-III)                                                             #
12:33:50.891 # Step 10:  Start Capturing the Multicast Data packets on TEE
(I1) for      #
12:33:50.892 #           Group
G.                                                        #
12:33:50.892 # Step 11:  Send Multicast Data packets for Group G on
Interface I2         #
12:33:50.892 #           from
TEE.                                                       #
12:33:50.892 # Step 12:  Observe Multicast Data packets for Group G are
forwarded by     #
12:33:50.892 #           DUT on
I1.                                                      #
12:33:50.892#
#
12:33:50.892 #
(Part-IV)                                                              #
12:33:50.893 # Step 13:  Send Multicast Data packets for Group G on
Interface I1         #
12:33:50.893 #           from
TEE.                                                       #
12:33:50.893 # Step 14:  Observe that ASSERT(S,G) is sent by DUT on
interface I1.        #
12:33:50.893#
#
12:33:50.893#
#
12:33:50.893#############################################################################
12:33:50.893 # History       Date     Author         Addition/
Alteration                #
12:33:50.894#
#
12:33:50.894 #    1.        Jan/2003  NET-O2
Initial                             #
12:33:50.894#
#
12:33:50.894#
#
12:33:50.894#############################################################################
12:33:50.894#
#
12:33:50.894 # Copyright (C) 2002-03 Net-O2 Technologies (P)
Ltd.                        #
12:33:50.894#############################################################################
12:33:50.895******************************************************************
12:33:50.895 *                Test Case ID : tc_conf_pim-sm_ast_001.tcl
12:33:50.895 *            Logfile Location :
tc_conf_pim-sm_ast_001_123350.log
12:33:50.895******************************************************************
12:33:50.895 *               ENVIRONMENTAL VARIABLES               *
12:33:50.895******************************************************************
12:33:50.896 *         env(tee_to_dut_1_LOCATION) :  eth0
12:33:50.896 *         env(tee_to_dut_2_LOCATION) :  eth1
12:33:50.896 *         env(tee_to_dut_3_LOCATION) :  eth2
12:33:50.896 *         env(tee_to_dut_4_LOCATION) :  eth3
12:33:50.896 *         env(tee_to_dut_5_LOCATION) :  eth16
12:33:50.897 *         env(tee_to_dut_6_LOCATION) :  eth17
12:33:50.897 *         env(tee_to_dut_7_LOCATION) :  eth18
12:33:50.897 *         env(tee_to_dut_8_LOCATION) :  eth19
12:33:50.897 *         env(dut_to_tee_1_LOCATION) :  fa0/1
12:33:50.897 *         env(dut_to_tee_2_LOCATION) :  fa0/7
12:33:50.898 *         env(dut_to_tee_3_LOCATION) :  fa0/9
12:33:50.898 *         env(dut_to_tee_4_LOCATION) :  a17
12:33:50.898 *         env(dut_to_tee_5_LOCATION) :  9
12:33:50.898 *         env(dut_to_tee_6_LOCATION) :  10
12:33:50.898 *         env(dut_to_tee_7_LOCATION) :  11
12:33:50.899 *         env(dut_to_tee_8_LOCATION) :  12
12:33:50.899 *             env(dut_TEST_ADDRESS1) :  192.168.7.5
12:33:50.899 *             env(dut_TEST_ADDRESS2) :  192.168.8.5
12:33:50.941 *             env(dut_TEST_ADDRESS3) :  192.168.9.5
12:33:50.941 *      env(tee_THIRD_INTERFACE_FLAG) :  1
12:33:50.942 *     env(tee_FOURTH_INTERFACE_FLAG) :  yes
12:33:50.942 *            env(dut_COMMAND_PROMPT) :  NETO2*
12:33:50.942 *               env(DUT_CONFIG_MODE) :  manual
12:33:50.974 *                        MAC_Address :   0854201E9D
0854DA93E5  0A5E30C5EF
12:33:50.974******************************************************************
12:33:50.974 *                      Start of
Log                              *
12:33:50.975******************************************************************
12:33:51.008*******************************************************************
12:33:51.008 *  tc_conf_pim-sm_ast_001: Start of
Testcase                      *
12:33:51.008*******************************************************************
12:33:51.008*                                                                 *
12:33:51.008 * Purpose     : To verify that the (S,G) Assert state
machine     *
12:33:51.008 *               on the interface transit from NO_INFO state
to    *
12:33:51.009 *               I_AM_ASSERT_WINNER state, on receiving a
(S,G)    *
12:33:51.009 *               data packet on downstream interface whose
(S,G)   *
12:33:51.009 *               downstream state machine is in JOIN
state.        *
12:33:51.009*                                                                 *
12:33:51.009 * Description : In this test-case, on receiving JOIN(S,G)
on      *
12:33:51.014 *               interface I1, DUT should send the JOIN(S,G)
to    *
12:33:51.014 *               TEE I2 (towards source S), confirming that
its    *
12:33:51.014 *               (S,G) downstream state machine on interface
I1    *
12:33:51.014 *               has transitioned to JOIN
state.                   *
12:33:51.014*                                                                 *
12:33:51.014 *               When multicast data traffic destined for group
G  *
12:33:51.014 *               is received from source S (TEE I2), the
DUT       *
12:33:51.014 *               should forward traffic for G to the
downstream    *
12:33:51.014 *               routers on the outgoing interface
I1.             *
12:33:51.014*                                                                 *
12:33:51.014 *               Later, when the DUT receives multicast data
for   *
12:33:51.014 *               (S,G) on outgoing interface I1 due to
other       *
12:33:51.014 *               router also forwards data on I1, it should
send   *
12:33:51.015 *               ASSERT(S,G) Message on I1, confirming that
its    *
12:33:51.015 *               (S,G) Assert state machine on I1 has
transitioned *
12:33:51.015 *               from NO_INFO state to I_AM_ASSERT_WINNER
state.   *
12:33:51.015*                                                                 *
12:33:51.015 *               NI state ---> W
state                             *
12:33:51.015*                                                                 *
12:33:51.015*******************************************************************
12:33:51.015 On I1, DUT IP address is : 192.168.7.5
12:33:51.015 On I1, TEE IP address is : 192.168.7.4
12:33:51.015 On I2, DUT IP address is : 192.168.8.5
12:33:51.015 On I2, TEE IP address is : 192.168.8.6
12:33:51.015******************************************************************
12:33:51.015 *      Running Under Manual Configuration Setup
12:33:51.015******************************************************************
12:33:51.016*******************************************************************
12:33:51.016 *           DUT Session Initialized
successfully                  *
12:33:51.016*******************************************************************
12:33:51.016 Size of Shared Memory->2868
12:33:51.016 ####################################
12:33:51.016 #==================================#
12:33:51.016 #           NETO2-TEE              #
12:33:51.016 #==================================#
12:33:51.016 # CURRENT so VERSION-->VER 0.1.0   #
12:33:51.016 #==================================#
12:33:51.016 ####################################
12:33:51.016 TEE:  Locked for Semafore and Timer
12:33:51.099 Process Id Path : /usr/local/Attest/NetO2Attest/Net-O2/Neto2tee
12:33:51.101 TEE:  PIMCS:Enabling Debug for PIM
12:33:51.101 TEE:  CS UnLocked semafore
12:33:51.132*******************************************************************
12:33:51.132 *          TEE Session Initialized
successfully                   *
12:33:51.132*******************************************************************
12:33:51.133 TEE:  Function dut_ip_add_one_interface() :
12:33:51.133 TEE:           session_handler  -> 1
12:33:51.134 TEE:           Location         -> fa0/1
12:33:51.134 TEE:           IP Address       -> 192.168.7.5
12:33:51.135 TEE:           Mask Length      -> 255.255.255.0
12:33:51.135 TEE:  ---------------------------------------------
12:33:51.136 TEE:  Function manual_ip_add_interface:
12:33:51.136 TEE:           session_handler  -> 1
12:33:51.137 TEE:           Location         -> fa0/1
12:33:51.137 TEE:           IP Address       -> 192.168.7.5
12:33:51.137 TEE:           Mask Length      -> 255.255.255.0
12:33:51.138 TEE:           MTU              -> 1500
12:33:51.138 TEE:  ---------------------------------------------
12:33:51.138*******************************************************************
12:33:51.139 *      Running Under Manual Configuration Setup
12:33:51.139 *
12:33:51.139 *      Assuming User has added Interface fa0/1 with
12:33:51.139 *                ip address 192.168.7.5
12:33:51.139 *                mask       255.255.255.0 and
12:33:51.151 *                mtu        1500
12:33:51.151*******************************************************************
12:33:51.152 TEE:  dut_ip_add_one_interface: return value -> 1
12:33:51.152 TEE:  Function dut_ip_add_one_interface() :
12:33:51.152 TEE:           session_handler  -> 1
12:33:51.153 TEE:           Location         -> fa0/7
12:33:51.153 TEE:           IP Address       -> 192.168.8.5
12:33:51.154 TEE:           Mask Length      -> 255.255.255.0
12:33:51.154 TEE:  ---------------------------------------------
12:33:51.155 TEE:  Function manual_ip_add_interface:
12:33:51.155 TEE:           session_handler  -> 1
12:33:51.155 TEE:           Location         -> fa0/7
12:33:51.156 TEE:           IP Address       -> 192.168.8.5
12:33:51.156 TEE:           Mask Length      -> 255.255.255.0
12:33:51.156 TEE:           MTU              -> 1500
12:33:51.157 TEE:  ---------------------------------------------
12:33:51.157*******************************************************************
12:33:51.157 *      Running Under Manual Configuration Setup
12:33:51.157 *
12:33:51.157 *      Assuming User has added Interface fa0/7 with
12:33:51.157 *                ip address 192.168.8.5
12:33:51.158 *                mask       255.255.255.0 and
12:33:51.158 *                mtu        1500
12:33:51.158*******************************************************************
12:33:51.158 TEE:  dut_ip_add_one_interface: return value -> 1
12:33:51.159 TEE:  dut_ip_add_interface: return value -> 1
12:33:51.159*******************************************************************
12:33:51.159 *                         Step
1                                  *
12:33:51.159 *          DUT interfaces added
successfully                      *
12:33:51.159*******************************************************************
12:33:51.160 TEE:  Function dut_pim_add_one_interface:
12:33:51.160 TEE:           session_handler  -> 1
12:33:51.161 TEE:           Location         -> fa0/1
12:33:51.161 TEE:           Mode             -> sparse
12:33:51.161 TEE:  ---------------------------------------------
12:33:51.162 TEE:  Function manual_pim_add_interface:
12:33:51.162 TEE:           session_handler  -> 1
12:33:51.163 TEE:           Location         -> fa0/1
12:33:51.163 TEE:           Mode             -> sparse
12:33:51.163 TEE:  ---------------------------------------------
12:33:51.164*******************************************************************
12:33:51.164 *      Running Under Manual Configuration Setup
12:33:51.164 *
12:33:51.164 *      Assuming User has enabled PIM in sparse-mode
12:33:51.164 *      on Interface fa0/1
12:33:51.164*******************************************************************
12:33:51.165 TEE:  dut_pim_add_one_interface: return value -> 1
12:33:51.165 TEE:  Function dut_pim_add_one_interface:
12:33:51.165 TEE:           session_handler  -> 1
12:33:51.166 TEE:           Location         -> fa0/7
12:33:51.166 TEE:           Mode             -> sparse
12:33:51.167 TEE:  ---------------------------------------------
12:33:51.167 TEE:  Function manual_pim_add_interface:
12:33:51.168 TEE:           session_handler  -> 1
12:33:51.168 TEE:           Location         -> fa0/7
12:33:51.168 TEE:           Mode             -> sparse
12:33:51.169 TEE:  ---------------------------------------------
12:33:51.169*******************************************************************
12:33:51.169 *      Running Under Manual Configuration Setup
12:33:51.169 *
12:33:51.169 *      Assuming User has enabled PIM in sparse-mode
12:33:51.169 *      on Interface fa0/7
12:33:51.169*******************************************************************
12:33:51.170 TEE:  dut_pim_add_one_interface: return value -> 1
12:33:51.170 TEE:  dut_pim_add_interface: return value -> 1
12:33:51.170*******************************************************************
12:33:51.170 *                         Step
1                                  *
12:33:51.171 *          PIM Enabled at DUT Interfaces
successfully             *
12:33:51.171*******************************************************************
12:33:51.171 TEE:  tee_ip_add_interface: location -> eth0
12:33:51.172 TEE:  ip_address -> 192.168.7.4
12:33:51.172 TEE:  mask       -> 255.255.255.0
12:33:51.172 TEE:  tee_ip_add_one_interface: location  -> eth0
12:33:51.173 TEE:  ip_addr   -> 192.168.7.4
12:33:51.173 TEE:  mask      -> 255.255.255.0
12:33:51.173 TEE:  Locked for Semafore and Timer
12:33:52.099 TEE:  The interface eth0 is already UP!!
12:33:52.100 TEE:  CS UnLocked semafore
12:33:52.101 TEE:  tee_ip_add_one_interface: return value -> 1 1
12:33:52.101 TEE:  tee_ip_add_interface: location -> eth1
12:33:52.101 TEE:  ip_address -> 192.168.8.6
12:33:52.102 TEE:  mask       -> 255.255.255.0
12:33:52.102 TEE:  tee_ip_add_one_interface: location  -> eth1
12:33:52.102 TEE:  ip_addr   -> 192.168.8.6
12:33:52.102 TEE:  mask      -> 255.255.255.0
12:33:52.102 TEE:  Locked for Semafore and Timer
12:33:53.101 TEE:  The interface eth1 is already UP!!
12:33:53.102 TEE:  CS UnLocked semafore
12:33:53.104 TEE:  tee_ip_add_one_interface: return value -> 1 1
12:33:53.104 TEE:  tee_ip_add_interface: return value -> 1 1
12:33:53.104*******************************************************************
12:33:53.104 *                         Step
2                                  *
12:33:53.104 *              TEE interfaces added
successfully                  *
12:33:53.104*******************************************************************
12:33:53.104 TEE:   Function tee_pim_add_interface():
12:33:53.104 TEE:            Location       -> eth0
12:33:53.104 TEE:  -------------------------------------
12:33:53.105 TEE:   Function tee_pim_add_one_interface():
12:33:53.105 TEE:            Location       -> eth0
12:33:53.105 TEE:  --------------------------------------
12:33:53.105 TEE:  Locked for Semafore and Timer
12:33:54.102 TEE:  CS UnLocked semafore
12:33:54.104 TEE:  tee_pim_add_one_interface: return value -> 1 1
12:33:54.104 TEE:   Function tee_pim_add_interface():
12:33:54.104 TEE:            Location       -> eth1
12:33:54.104 TEE:  -------------------------------------
12:33:54.104 TEE:   Function tee_pim_add_one_interface():
12:33:54.104 TEE:            Location       -> eth1
12:33:54.104 TEE:  --------------------------------------
12:33:54.104 TEE:  Locked for Semafore and Timer
12:33:54.120 TEE:  CS UnLocked semafore
12:33:54.122 TEE:  tee_pim_add_one_interface: return value -> 1 1
12:33:54.122 TEE:  tee_pim_add_interface: return value -> 1
12:33:54.123*******************************************************************
12:33:54.123 *                         Step
2                                  *
12:33:54.123 *          PIM Enabled at TEE Interfaces
successfully             *
12:33:54.123*******************************************************************
12:33:54.123 TEE:   Function tee_pim_send_hello_periodic():
12:33:54.123 TEE:    Interface Address      -> 192.168.7.4
12:33:54.125 TEE:    Times                  -> 255
12:33:54.125 TEE:    flag                   -> 0
12:33:54.125 TEE:    Holdtime               -> 105
12:33:54.125 TEE:    DR Priority            -> 0
12:33:54.125 TEE:    GenID                  -> 0
12:33:54.125 TEE:    Lan_Prune_delay        -> 0
12:33:54.126 TEE:    Override interval      -> 0
12:33:54.126 TEE:    State Refresh interval -> 0
12:33:54.126 TEE:  -----------------------------------------
12:33:54.126 TEE:  Locked for Semafore and Timer
12:33:54.140 TEE:  Sending HELLO Message from Source 192.168.7.4 to
Destination 224.0.0.13
12:33:54.140 TEE:  with Holdtime 105
12:33:54.140 TEE:  PIM v2 HELLO  sent successfully from 192.168.7.4 to
224.0.0.13
12:33:54.140 TEE:  CS UnLocked semafore
12:33:54.143 TEE:  tee_pim_send_hello_periodic: return value -> 1 1
12:33:54.143*******************************************************************
12:33:54.143 *                         Step
3                                  *
12:33:54.143 *  PIM HELLO Message sent successfully from TEE 192.168.7.4  *
12:33:54.143*******************************************************************
12:33:54.143 TEE:  Function manual_pim_check_neighbor:
12:33:54.143 TEE:           session_handler  -> 1
12:33:54.143 TEE:           Location         -> fa0/1
12:33:54.143 TEE:           Neighbor Address -> 192.168.7.4
12:33:54.144 TEE:           Timeout Value    -> 105
12:33:54.144 TEE:  ---------------------------------------------
12:33:54.144*******************************************************************
12:33:54.144 *      Running under Manual Configuration Setup
12:33:54.144 *
12:33:54.144 *        Checking  if the neighbour entry 192.168.7.4 is
present
12:33:54.145 *        at the location fa0/1
12:33:54.145 *
12:33:54.145 *                    Press 'y' for YES
12:33:54.145 *                    Press 'n' for NO
12:33:54.145*******************************************************************
12:33:54.145 MessageStart~Check if the neighbour entry 192.168.7.4 is
present at interface fa0/1~MessageEnd~yesno
12:33:56.429 TEE:  dut_pim_check_neighbor: return value -> 1
12:33:56.429*******************************************************************
12:33:56.429 *                         Step
4                                  *
12:33:56.429 *Neighbor Entry 192.168.7.4 found at DUT on fa0/1*
12:33:56.429*******************************************************************
12:33:56.429 TEE:   Function tee_pim_send_hello_periodic():
12:33:56.429 TEE:    Interface Address      -> 192.168.8.6
12:33:56.429 TEE:    Times                  -> 255
12:33:56.430 TEE:    flag                   -> 0
12:33:56.430 TEE:    Holdtime               -> 105
12:33:56.430 TEE:    DR Priority            -> 0
12:33:56.430 TEE:    GenID                  -> 0
12:33:56.430 TEE:    Lan_Prune_delay        -> 0
12:33:56.430 TEE:    Override interval      -> 0
12:33:56.430 TEE:    State Refresh interval -> 0
12:33:56.430 TEE:  -----------------------------------------
12:33:56.430 TEE:  Locked for Semafore and Timer
12:33:57.142 TEE:  Sending HELLO Message from Source 192.168.8.6 to
Destination 224.0.0.13
12:33:57.142 TEE:  with Holdtime 105
12:33:57.142 TEE:  PIM v2 HELLO  sent successfully from 192.168.8.6 to
224.0.0.13
12:33:57.142 TEE:  CS UnLocked semafore
12:33:57.142 TEE:  tee_pim_send_hello_periodic: return value -> 1 1
12:33:57.143*******************************************************************
12:33:57.143 *                         Step
5                                  *
12:33:57.143 *  PIM HELLO Messages sent successfully from TEE 192.168.8.6 *
12:33:57.143*******************************************************************
12:33:57.143 TEE:  Function manual_pim_check_neighbor:
12:33:57.143 TEE:           session_handler  -> 1
12:33:57.143 TEE:           Location         -> fa0/7
12:33:57.143 TEE:           Neighbor Address -> 192.168.8.6
12:33:57.143 TEE:           Timeout Value    -> 105
12:33:57.143 TEE:  ---------------------------------------------
12:33:57.144*******************************************************************
12:33:57.144 *      Running under Manual Configuration Setup
12:33:57.144 *
12:33:57.144 *        Checking  if the neighbour entry 192.168.8.6 is
present
12:33:57.144 *        at the location fa0/7
12:33:57.144 *
12:33:57.144 *                    Press 'y' for YES
12:33:57.144 *                    Press 'n' for NO
12:33:57.144*******************************************************************
12:33:57.144 MessageStart~Check if the neighbour entry 192.168.8.6 is
present at interface fa0/7~MessageEnd~yesno
12:33:57.848 TEE:  HELLO Message received from 192.168.7.5
12:33:57.848 TEE:  with Holdtime = 105
12:33:57.848 TEE:  LAN_Prune Delay = 500
12:33:57.848 TEE:  Override_Interval = 2500
12:33:57.848 TEE:  DR Priority = 1
12:33:57.848 TEE:  GenId = 2062682234
12:33:59.390 TEE:  dut_pim_check_neighbor: return value -> 1
12:33:59.390*******************************************************************
12:33:59.390 *                         Step
6                                  *
12:33:59.390 *Neighbor Entry 192.168.8.6 found at DUT on fa0/7*
12:33:59.390*******************************************************************
12:33:59.390 TEE:  Function manual_ip_add_static_route:
12:33:59.391 TEE:           session_handler     -> 1
12:33:59.391 TEE:           Destination Address -> 192.168.6.0
12:33:59.391 TEE:           Mask Length         -> 255.255.255.0
12:33:59.391 TEE:           Gateway             -> 192.168.8.6
12:33:59.391 TEE:           Metric              -> 10
12:33:59.391 TEE:  ------------------------------------------------
12:33:59.391*******************************************************************
12:33:59.391 *      Running Under Manual Configuration Setup
12:33:59.391 *
12:33:59.391 *      Assuming User has Added Static Route with
12:33:59.391 *                  Destination Address 192.168.6.0
12:33:59.391 *                  Gateway             192.168.8.6
12:33:59.392 *                  Mask                255.255.255.0
12:33:59.392 *                  Metric              10
12:33:59.392*******************************************************************
12:33:59.392 TEE:  dut_ip_add_static_route: return value -> 1
12:33:59.392*******************************************************************
12:33:59.392 *                         Step
7                                  *
12:33:59.392 *    Static Route set on DUT for Destination - 192.168.6.0
*
12:33:59.392 *         Mask - 255.255.255.0  Gateway - 192.168.8.6         *
12:33:59.392 *                       Metric - 10               *
12:33:59.392*******************************************************************
12:33:59.392*******************************************************************
12:33:59.392 *                         Step
8                                  *
12:33:59.393 *         Sending JOIN(S,G) from TEE to DUT on
I1                 *
12:33:59.393*******************************************************************
12:33:59.393 TEE:   Function tee_pim_send_join_periodic():
12:33:59.393 TEE:    Interface Address    -> 192.168.7.4
12:33:59.393 TEE:    Join type            -> S_G_JOIN
12:33:59.393 TEE:    Source               -> 192.168.6.1
12:33:59.393 TEE:    Source masklen       -> 32
12:33:59.393 TEE:    Group                -> 224.1.1.1
12:33:59.393 TEE:    Group masklen        -> 32
12:33:59.393 TEE:    Upstream Neighbor    -> 192.168.7.5
12:33:59.394 TEE:    Holdtime             -> 210
12:33:59.394 TEE:  -----------------------------------------
12:33:59.402 TEE:  Locked for Semafore and Timer
12:33:59.919 TEE:  Number of JOIN/PRUNE Messages  1
12:33:59.919 TEE:  Group Address 224.1.1.1
12:33:59.920 TEE:  Source Address 192.168.6.1
12:33:59.920 TEE:  JOIN/PRUNE type - JOIN(S,G)
12:33:59.920 TEE:  Sending JOIN(S,G) Message from 192.168.7.4
12:33:59.920 TEE:  with Upstream Neighbor 192.168.7.5
12:33:59.920 TEE:  Source Address 192.168.6.1 Group Address 224.1.1.1
12:33:59.920 TEE:  S   Bit set
12:33:59.920 TEE:  PIM v2 JOIN/PRUNE  sent successfully from 192.168.7.4 to
224.0.0.13
12:33:59.920 TEE:  CS UnLocked semafore
12:33:59.923 TEE:  tee_pim_send_join_periodic: return value -> 1 1
12:33:59.923*******************************************************************
12:33:59.923 *                         Step
8                                  *
12:33:59.923 *     JOIN(S,G) sent from TEE 192.168.7.4 to DUT on I1       *
12:33:59.923*******************************************************************
12:33:59.923*******************************************************************
12:33:59.923 *                         Step
9                                  *
12:33:59.924 *  Waiting for 120.0 secs for JOIN(S,G) from DUT on I2...*
12:33:59.924*******************************************************************
12:33:59.924 TEE:   Function tee_pim_recv_join_pkt():
12:33:59.924 TEE:           Interface Address    -> 192.168.8.6
12:33:59.924 TEE:           Join Type            -> S_G_JOIN
12:33:59.924 TEE:           Source Address       -> 192.168.6.1
12:33:59.924 TEE:           Group Address        -> 224.1.1.1
12:33:59.924 TEE:           RP Address           -> 0
12:33:59.924 TEE:           Upstream Neighbor    -> 192.168.8.6
12:33:59.924 TEE:           Timeout              -> 120
12:33:59.925 TEE:  -------------------------------------------
12:33:59.930 TEE:  Locked for Semafore and Timer
12:34:00.138 TEE:  HELLO Message received from 192.168.8.5
12:34:00.138 TEE:  with Holdtime = 105
12:34:00.138 TEE:  LAN_Prune Delay = 500
12:34:00.138 TEE:  Override_Interval = 2500
12:34:00.138 TEE:  DR Priority = 1
12:34:00.138 TEE:  GenId = 1385585707
12:34:00.631 TEE:  HELLO Message received from 192.168.7.5
12:34:00.631 TEE:  with Holdtime = 105
12:34:00.631 TEE:  LAN_Prune Delay = 500
12:34:00.631 TEE:  Override_Interval = 2500
12:34:00.631 TEE:  DR Priority = 1
12:34:00.631 TEE:  GenId = 2062682234
12:34:03.458 TEE:  HELLO Message received from 192.168.8.5
12:34:03.458 TEE:  with Holdtime = 105
12:34:03.458 TEE:  LAN_Prune Delay = 500
12:34:03.458 TEE:  Override_Interval = 2500
12:34:03.458 TEE:  DR Priority = 1
12:34:03.458 TEE:  GenId = 1385585707
12:34:24.450 TEE:  Sending HELLO Message from Source 192.168.7.4 to
Destination 224.0.0.13
12:34:24.450 TEE:  with Holdtime 105
12:34:24.450 TEE:  PIM v2 HELLO  sent successfully from 192.168.7.4 to
224.0.0.13
12:34:24.450 TEE:  Starting HELLO Timer on the interface 192.168.7.4  for an
interval of 30 secs
12:34:27.449 TEE:  Sending HELLO Message from Source 192.168.8.6 to
Destination 224.0.0.13
12:34:27.449 TEE:  with Holdtime 105
12:34:27.450 TEE:  PIM v2 HELLO  sent successfully from 192.168.8.6 to
224.0.0.13
12:34:27.450 TEE:  Starting HELLO Timer on the interface 192.168.8.6  for an
interval of 30 secs
12:34:30.628 TEE:  HELLO Message received from 192.168.7.5
12:34:30.629 TEE:  with Holdtime = 105
12:34:30.629 TEE:  LAN_Prune Delay = 500
12:34:30.629 TEE:  Override_Interval = 2500
12:34:30.629 TEE:  DR Priority = 1
12:34:30.629 TEE:  GenId = 2062682234
12:34:33.456 TEE:  HELLO Message received from 192.168.8.5
12:34:33.456 TEE:  with Holdtime = 105
12:34:33.456 TEE:  LAN_Prune Delay = 500
12:34:33.456 TEE:  Override_Interval = 2500
12:34:33.456 TEE:  DR Priority = 1
12:34:33.456 TEE:  GenId = 1385585707
12:34:54.459 TEE:  Sending HELLO Message from Source 192.168.7.4 to
Destination 224.0.0.13
12:34:54.459 TEE:  with Holdtime 105
12:34:54.460 TEE:  PIM v2 HELLO  sent successfully from 192.168.7.4 to
224.0.0.13
12:34:54.460 TEE:  Starting HELLO Timer on the interface 192.168.7.4  for an
interval of 30 secs
12:34:57.459 TEE:  Sending HELLO Message from Source 192.168.8.6 to
Destination 224.0.0.13
12:34:57.459 TEE:  with Holdtime 105
12:34:57.460 TEE:  PIM v2 HELLO  sent successfully from 192.168.8.6 to
224.0.0.13
12:34:57.460 TEE:  Starting HELLO Timer on the interface 192.168.8.6  for an
interval of 30 secs
12:35:00.630 TEE:  HELLO Message received from 192.168.7.5
12:35:00.630 TEE:  with Holdtime = 105
12:35:00.630 TEE:  LAN_Prune Delay = 500
12:35:00.630 TEE:  Override_Interval = 2500
12:35:00.630 TEE:  DR Priority = 1
12:35:00.630 TEE:  GenId = 2062682234
12:35:03.463 TEE:  HELLO Message received from 192.168.8.5
12:35:03.464 TEE:  with Holdtime = 105
12:35:03.464 TEE:  LAN_Prune Delay = 500
12:35:03.464 TEE:  Override_Interval = 2500
12:35:03.464 TEE:  DR Priority = 1
12:35:03.464 TEE:  GenId = 1385585707
12:35:24.459 TEE:  Sending HELLO Message from Source 192.168.7.4 to
Destination 224.0.0.13
12:35:24.461 TEE:  with Holdtime 105
12:35:24.461 TEE:  PIM v2 HELLO  sent successfully from 192.168.7.4 to
224.0.0.13
12:35:24.461 TEE:  Starting HELLO Timer on the interface 192.168.7.4  for an
interval of 30 secs
12:35:27.459 TEE:  Sending HELLO Message from Source 192.168.8.6 to
Destination 224.0.0.13
12:35:27.459 TEE:  with Holdtime 105
12:35:27.460 TEE:  PIM v2 HELLO  sent successfully from 192.168.8.6 to
224.0.0.13
12:35:27.460 TEE:  Starting HELLO Timer on the interface 192.168.8.6  for an
interval of 30 secs
12:35:30.628 TEE:  HELLO Message received from 192.168.7.5
12:35:30.628 TEE:  with Holdtime = 105
12:35:30.628 TEE:  LAN_Prune Delay = 500
12:35:30.628 TEE:  Override_Interval = 2500
12:35:30.628 TEE:  DR Priority = 1
12:35:30.628 TEE:  GenId = 2062682234
12:35:33.461 TEE:  HELLO Message received from 192.168.8.5
12:35:33.461 TEE:  with Holdtime = 105
12:35:33.462 TEE:  LAN_Prune Delay = 500
12:35:33.462 TEE:  Override_Interval = 2500
12:35:33.462 TEE:  DR Priority = 1
12:35:33.462 TEE:  GenId = 1385585707
12:35:38.873 TEE:  PIM v2 BOOTSTRAP  sent successfully from 192.168.7.4 to
224.0.0.13
12:35:54.869 TEE:  Sending HELLO Message from Source 192.168.7.4 to
Destination 224.0.0.13
12:35:54.870 TEE:  with Holdtime 105
12:35:54.870 TEE:  PIM v2 HELLO  sent successfully from 192.168.7.4 to
224.0.0.13
12:35:54.870 TEE:  Starting HELLO Timer on the interface 192.168.7.4  for an
interval of 30 secs
12:35:57.869 TEE:  Sending HELLO Message from Source 192.168.8.6 to
Destination 224.0.0.13
12:35:57.870 TEE:  with Holdtime 105
12:35:57.870 TEE:  PIM v2 HELLO  sent successfully from 192.168.8.6 to
224.0.0.13
12:35:57.870 TEE:  Starting HELLO Timer on the interface 192.168.8.6  for an
interval of 30 secs
12:35:59.931 TEE:  Timer UnLocked semafore
12:35:59.931 TEE:  tee_pim_recv_join_pkt: return value -> 0 0
12:35:59.931################################################################
12:35:59.931 #                      Step 9
#
12:35:59.931 #Error: DUT has not sent the JOIN(S,G) from 192.168.8.5   #
12:35:59.931 #       to TEE on I2
#
12:35:59.931################################################################
12:35:59.931################################################################################
12:35:59.932################################################################################
12:35:59.932 # TEST CASE ABORTED : DUT has not sent the JOIN(S,G) to TEE on
I2
12:35:59.932################################################################################
12:35:59.932################################################################################
12:36:00.626 TEE:  HELLO Message received from 192.168.7.5
12:36:00.626 TEE:  with Holdtime = 105
12:36:00.626 TEE:  LAN_Prune Delay = 500
12:36:00.626 TEE:  Override_Interval = 2500
12:36:00.626 TEE:  DR Priority = 1
12:36:00.626 TEE:  GenId = 2062682234
12:36:00.940 tee_pim_close_session: Closing TEE session
12:36:00.940 TEE:  Locked for Semafore and Timer
12:36:01.619 TEE:  CS UnLocked semafore
12:36:01.637 Time taken for execution : 130 seconds

Thanks !!!




Thanks,
> Pavlin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071210/4ea682c0/attachment-0001.html 

From pavlin at icir.org  Mon Dec 10 10:45:50 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 10 Dec 2007 10:45:50 -0800
Subject: [Xorp-users] Fwd: Fwd: Problem in IPv6 SSM Multicast
In-Reply-To: Message from Hansi <hantongs@gmail.com> of "Mon,
	10 Dec 2007 17:38:17 +0800."
	<2f9e317b0712100138g2e5618cdgf68a49027d6e20e7@mail.gmail.com> 
Message-ID: <200712101845.lBAIjoRD047086@possum.icir.org>

> Yes, you are right. I ran tcpdump on the sender side and it appears the
> streaming server is sending out fragmented packets.

>From your logs below it appears that the second fragment is not
forwarded by the first router (Router 1), so you might want to
concentrate your effort on Router 1.

BTW, the reassembly of the fragments should happen on the receiver
side, so the routers in the middle should only forward the
fragments.

Regards,
Pavlin

> Streaming Server to Router 1:
> 
> 09:51:22.692158 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
> length: 100) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xec6a52cc:1232|92)
> 09:51:22.700132 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xf753c59f:0|1232) 61541 > 1234: UDP, length 1316
> 09:51:22.700146 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
> length: 100) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xf753c59f:1232|92)
> 09:51:22.708230 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xe37aa8b2:0|1232) 61541 > 1234: UDP, length 1316
> 09:51:22.708243 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
> length: 100) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xe37aa8b2:1232|92)
> 09:51:22.716214 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xc1fd9920:0|1232) 61541 > 1234: UDP, length 1316
> 
> Apparently, a second fragment of length 100 is sent out after the first one.
> Oddly though.. once the fragmented packets reached Router 2, the second
> fragment is no longer received... probably dropped. I'm suspecting that
> Router 2 is unable to associate the second fragment to the first.
> 
> Router 1 <------> Router 2
> 
> 05:57:43.861774 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x40a52867:0|1232) 61542 > 1234: UDP, length 1316
> 05:57:43.871960 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x33f49657:0|1232) 61542 > 1234: UDP, length 1316
> 05:57:43.882756 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x2d938af5:0|1232) 61542 > 1234: UDP, length 1316
> 05:57:43.893746 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x62f4a589:0|1232) 61542 > 1234: UDP, length 1316
> 
> 
> Router <------> (sk0)receiver
> 
> 17:51:56.196244 IP6 (flowlabel 0xb063f, hlim 13, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x48714108:0|1232) 61542 > 1234: UDP, length 1316
> 17:51:56.205162 IP6 (flowlabel 0xb063f, hlim 13, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x5449397c:0|1232) 61542 > 1234: UDP, length 1316
> 17:51:56.214114 IP6 (flowlabel 0xb063f, hlim 13, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x3e81a7bf:0|1232) 61542 > 1234: UDP, length 1316
> 
> I'm currently investigating this issue right now. Got to read more on IPv6
> fragmentation. hehe...
> 
> Thanks,
> Hansi


From pavlin at icir.org  Mon Dec 10 11:24:05 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 10 Dec 2007 11:24:05 -0800
Subject: [Xorp-users] Fwd: tests conformance using XORP
In-Reply-To: Message from "Jeandro de M. Bezerra" <jeandro@larces.uece.br> 
	of "Mon, 10 Dec 2007 10:44:21 -0300."
	<5efcb8aa0712100544v613f7e2ah4fcddccb1f0eefea@mail.gmail.com> 
Message-ID: <200712101924.lBAJO5IG047427@possum.icir.org>

See comments inline.

> interfaces {
>     restore-original-config-on-shutdown: false
>     interface eth0 {
>     description: "data interface"
>     disable: false
>     /* default-system-config */
>      vif eth0 {
>             disable: false
>             address 192.168.7.5 {
>                 prefix-length: 24
>                 broadcast: 192.168.7.255
>                 disable: false
>         }
>     }
>     }
> 
>   interface eth1 {
>     description: "data interface"
>     disable: false
>     /* default-system-config */
>      vif eth1 {
>             disable: false
>             address 192.168.8.5 {
>                 prefix-length: 24
>                 broadcast: 192.168.8.255
>                 disable: false
>         }
>     }
> 
>  }
> 
> }

<DEL>

> protocols {
>     static {
> 
>     interface-route 192.168.8.0/24 {
>      next-hop-interface: "eth0"
>      next-hop-vif: "eth0"
>      next-hop-router: 192.168.7.5
>      metric: 1
>      }
> 
>     mrib-interface-route 192.168.8.0/24 {
>      next-hop-interface: "eth0"
>      next-hop-vif: "eth0"
>      metric: 1
>      }

Few things about the above static routers configuration:

* The "interface-route" and "mrib-interface-route" entries are
  needed in special cases when you want to force the route to point
  toward a specific interface even if the next-hop router's IP
  address doesn't belong to the same subnet.
  If you want to use static routes, in your setup it is better to
  use the "route" and "mrib-route" configuration statements instead.

* In the interface-route statement above you have set the
  next-hop-router to the eth0's IP address which is probably not
  what you want.

* Typically the "mrib-route" or "mrib-interface-route" should be
  used if you want to add multicast-specific entries that are used
  for multicast RPF check only, but are not used by the unicast
  routing.
  In your case probably you don't need them to be different, so for
  simplicity you might want to remove the "mrib-" static route
  entry.

* The particular static routes are for the 192.168.8.0/24 subnet
  which actually is the subnet of interface eth1.
  You cannot overwrite the routes for directly connected subnets so
  you shouldn't add such routes.

Said that, if you want to add a static route for a non-directly
connected subnet (say, 192.168.6.0/24), it should look like:

    route 192.168.6.0/24 {
        next-hop: 192.168.7.20
    }

where I assume that 192.168.7.20 is the next-hop router toward
the destination.

> 
>     }
> 
> }
> 
> 
> 
> policy {
>     /* Describe connected routes for redistribution */
>     policy-statement connected {
>     term export {
>         from {
>         protocol: "connected"
>         }
>     }
>     }
> }
> 
> 
> policy {
>     /* Describe static routes for redistribution */
>     policy-statement static {
>         term export {
>             from {
>                 protocol: "static"
>             }
>         }
>     }
> }

<DEL>

> protocols {
>     rip {
> 
> /* Connected interfaces will only be advertised if explicitly exported */
>         export: "connected"
>     export: "static"

If you want to export both "connected" and "static", then you should
add them with the same export statement. E.g.:
    export: "connected,static"

If you have two "export" statements, the second one will overwrite
the first one.

> /* Run on specified network interface addresses */
>         interface eth0 {
>             vif eth0 {
>                 address 192.168.7.5 {
>                     disable: false
>                 }
>             }
>         }
> 
>     interface eth1 {
>             vif eth1 {
>                 address 192.168.8.5 {
>                     disable: false
>                 }
>             }
>         }
> 
>     }
> }

<DEL>

> protocols {
>     pimsm4 {
>     disable: false
>     interface eth0 {
>         vif eth0 {
>         disable: false
>         /* enable-ip-router-alert-option-check: false */
>         /* dr-priority: 1 */
>         /* hello-period: 30 */
>         /* hello-triggered-delay: 5 */
>         /* alternative-subnet 10.40.0.0/16 */
>         }
>     }
> 
>     interface eth1 {
>         vif eth1 {
>         disable: false
>         /* enable-ip-router-alert-option-check: false */
>         /* dr-priority: 1 */
>         /* hello-period: 30 */
>         /* hello-triggered-delay: 5 */
>         /* alternative-subnet 10.40.0.0/16 */
>         }
>     }
> 
>     interface register_vif {
>         vif register_vif {
>         /* Note: this vif should be always enabled */
>         disable: false
>         }
>     }
> 
>       /*     static-rps {*/
>     /*    rp 192.168.7.5 {*/
>     /*    group-prefix 224.0.0.0/4 {*/
>             /* rp-priority: 192 */
>             /* hash-mask-len: 30 */
>     /*    } */
>     /*    } */
> /*    } */
> 
>     bootstrap {
>         disable: false
>         cand-bsr {
>         scope-zone 224.0.0.0/8 {
>             /* is-scope-zone: false */
>             cand-bsr-by-vif-name: "eth0"
>             /* cand-bsr-by-vif-addr: 10.10.10.10 */
>              bsr-priority: 1
>             /* hash-mask-len: 30 */
>         }
>           }
>         cand-bsr {
>         scope-zone 224.0.0.0/8 {
>             /* is-scope-zone: false */
>             cand-bsr-by-vif-name: "eth1"
>             /* cand-bsr-by-vif-addr: 10.10.10.10 */
>              bsr-priority: 2
>             /* hash-mask-len: 30 */
>         }
> 
>         }
> 
>         cand-rp {
>         group-prefix 224.0.0.0/8 {
>             /* is-scope-zone: false */
>             cand-rp-by-vif-name: "eth0"
>             /* cand-rp-by-vif-addr: 10.10.10.10 */
>              rp-priority: 192
>             /* rp-holdtime: 150 */
>         }
>         }
>             cand-rp {
>         group-prefix 224.0.0.0/8 {
>             /* is-scope-zone: false */
>             cand-rp-by-vif-name: "eth1"
>             /* cand-rp-by-vif-addr: 10.10.10.10 */
>              rp-priority: 195
>             /* rp-holdtime: 150 */
>         }
>         }
> 
> 
>     }

It appears that you have decided to use the dynamic Bootstrap
mechanism instead of static RPs. You should know that on startup it
can take up to 2-3 minutes or so until the Bootstrap election is
completed and the Cand-RP set has converged.
For testing purpose you might want to use a static RP so you can
avoid the startup delay.
There is nothing wrong with using the Bootstrap mechanism, and if
you deal only with (S,G) Joins then the RPs are not used, but you
should be aware of the startup delay.

Also, you might want to use 224.0.0.0/4 prefix to cover the whole
multicast address space (in case you decide to use multicast with
some group addresses that are outside the 224.0.0.0/8 prefix).

>     switch-to-spt-threshold {
>         /* approx. 1K bytes/s (10Kbps) threshold */
>         disable: false
>         interval: 100
>         bytes: 102400
>     }
> 
>     traceoptions {
>         flag all {
>         disable: false
>         }
>     }
>     }

<DEL>

> __________________________________________
> 
> root at thiago> show pim join
> Group           Source          RP              Flags
> 224.1.1.1       192.168.6.1     192.168.8.5     SG
>     Upstream interface (S):    UNKNOWN
                                 ~~~~~~~
>     Upstream interface (RP):   register_vif
>     Upstream MRIB next hop (RP): UNKNOWN
>     Upstream MRIB next hop (S):  UNKNOWN
                                   ~~~~~~~
>     Upstream RPF'(S,G):        UNKNOWN
                                 ~~~~~~~

The real reason that the (S,G) Join wasn't originated by the XORP
router is because the next-hop toward S (192.168.6.1) is unknown.
In your configuration there isn't a static route toward that
destination, so the route should come from the dynamic protocol (RIP
in your case).
It appears that the route is not received by RIP. You could verify
that by running the "show route table ipv4 unicast rip" xorpsh
command.
If you are using same multiple "export" statements in all XORP
routers, then probably none of them is advertising its connected
routes.

Though, again for testing purpose you might want just to use static
routes so you will avoid the extra startup delay with the dynamic
routing protocols.

After you apply the above fixes, use the "show pim join" command to
make sure that the upstream information is received correctly by the
PIM-SM module.

Regards,
Pavlin

>     Upstream state:            Joined
>     Join timer:                48
>     KAT(S,G) running:          false
>     Local receiver include WC: ...
>     Local receiver include SG: ...
>     Local receiver exclude SG: ...
>     Joins RP:                  ...
>     Joins WC:                  ...
>     Joins SG:                  O..
>     Join state:                O..
>     Prune state:               ...
>     Prune pending state:       ...
>     I am assert winner state:  ...
>     I am assert loser state:   ...
>     Assert winner WC:          ...
>     Assert winner SG:          ...
>     Assert lost WC:            ...
>     Assert lost SG:            ...
>     Assert lost SG_RPT:        ...
>     Assert tracking SG:        O..
>     Could assert WC:           ...
>     Could assert SG:           ...
>     I am DR:                   O.O
>     Immediate olist RP:        ...
>     Immediate olist WC:        ...
>     Immediate olist SG:        O..
>     Inherited olist SG:        O..
>     Inherited olist SG_RPT:    ...
>     PIM include WC:            ...
>     PIM include SG:            ...
>     PIM exclude SG:            ...
>  (END)


From pascal.watteel at winlin.be  Tue Dec 11 02:29:59 2007
From: pascal.watteel at winlin.be (Pascal Watteel)
Date: Tue, 11 Dec 2007 11:29:59 +0100
Subject: [Xorp-users] as-path-lenght and prepend
Message-ID: <E47F8DA68F58434D9F44E599228890FD1912E9@lupus.winlin.local>

Hi, i'm searching high and low to make the following work

 

I have 2 vyatta routers doing eBGP to 2 different peers.

And a iBgp session between them.

 

One of the is mutch cheaper bandwith...

So I used to do on my Mikrotik routers the following...

 

I made a export filter. That said if the as-path was greater then 2
prepend-our AS 4 times

This way I could adjust the as-path length for as'ses that where further
away to always use the cheap bandwith.

 

How do I do something like this in vyatta

 

Thxs

 

Pascal

 


EMAIL NOTICE: This message and any attachment(s) may contain confidential information and may be subject 
to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized 
to use, disclose, distribute or copy any part of this message including attachment(s). If you have received this 
message in error, please notify the sender immediately and delete all copies. Any views expressed in this message
are those of the individual sender and not necessarily that of the company. Before opening any attachment(s),
please check for viruses and other defects.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071211/2c13f373/attachment.html 

From rsuk at ucsc.edu  Tue Dec 11 15:00:44 2007
From: rsuk at ucsc.edu (Robert Joseph Suk)
Date: Tue, 11 Dec 2007 15:00:44 -0800
Subject: [Xorp-users] xorp with click and RIP
In-Reply-To: <200712070201.lB721tDk008173@possum.icir.org>
References: <200712070201.lB721tDk008173@possum.icir.org>
Message-ID: <web-14536720@email-prod-be-1.ucsc.edu>

I upgraded to the CVS versions of both xorp(1.52) and 
click(1.6.0) and it solved the problem of using the click 
forwarding path.  My hardware is set up as follows:

PC2--PC3--PC4

PC2: xl0: 10.0.1.22, xl1: 10.0.2.22
PC3: xl0: 10.0.2.33, xl1: 10.0.3.33
PC4: xl0: 10.0.3.44, xl1: 10.0.4.44

The click forwarding path works fine, and RIP runs just 
fine in userspace, but XORP routes are not being added to 
click.

Below is my xorp config:
PC3# cat xorpclick_pc3.boot
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: false
                 duplicate-routes-to-kernel: true

                 kernel-click{
                         disable: true
                 }
                 user-click{
                         disable: false
                         command-file: 
"/usr/local/bin/click"
                         command-extra-arguments: "-R"
                         command-execute-on-startup: true
                         startup-config-file: 
"/usr/local/xorp/iprouter_auto.click"
                         user-click-config-generator-file: 
"/usr/local/fea/xorp_fea_click_config_generator"
                 }
         }
} /* </fea> */
policy {
         /*Describe connected routes for redistribution*/
         policy-statement connected {
                 term export {
                         from {
                                 protocol: "connected"
                         }
                 }
         }
}

protocols {
         static{
                 route 224.0.0.0/4{
                         next-hop: 10.0.2.22
                         metric: 1
                 }
         }
         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>*/



And here is my click_config_generator:
*note, this is the same click config as 
iprouter_auto.click in my xorp config.


PC3# cat xorp_fea_click_config_generator
printf("
// Generated by make-ip-conf.pl
// xl0 10.0.2.33 00:01:02:42:20:EC
// xl1 10.0.3.33 00:01:02:3E:4E:3A

// Shared IP input path and routing table
ip :: Strip(14)
     -> good_header :: CheckIPHeader(INTERFACES 
10.0.2.33/255.255.255.0 10.0.3.33/255.255.255.0)
good_header[0] -> _xorp_rt4 :: LinearIPLookup(
         10.0.2.33/32 2,
         10.0.2.255/32 2,
         10.0.2.0/32 2,
         10.0.3.33/32 2,
         10.0.3.255/32 2,
         10.0.3.0/32 2,  //above are local interfaces. 
 deliver locally
         10.0.2.0/255.255.255.0 0,       //xl0
         10.0.3.0/255.255.255.0 1,       //xl1
         255.255.255.255/32 0.0.0.0 2,   //broadcasts are 
local and get dropped
         0.0.0.0/32 2,
         0.0.0.0/0.0.0.0 10.0.2.22 0);

// ARP responses are copied to each ARPQuerier and the 
host.
arpt :: Tee(3);

// Input and output paths for xl0
c0 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 
12/0800, -);
FromDevice(xl0) -> c0;
out0 :: Queue(200) -> todevice0 :: ToDevice(xl0);
c0[0] -> ar0 :: ARPResponder(10.0.2.33 00:01:02:42:20:EC) 
-> out0;
arpq0 :: ARPQuerier(10.0.2.33, 00:01:02:42:20:EC) -> 
newOUT::Tee(2);
newOUT[0]->out0;
c0[1] -> arpt;
arpt[0] -> [1]arpq0;
c0[2] -> Paint(1) -> ip;
c0[3] -> Print("xl0 non-IP") -> Discard;

// Input and output paths for xl1
c1 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 
12/0800, -);
FromDevice(xl1) -> c1;
out1 :: Queue(200) -> todevice1 :: ToDevice(xl1);
c1[0] -> ar1 :: ARPResponder(10.0.3.33 00:01:02:3E:4E:3A) 
-> out1;
arpq1 :: ARPQuerier(10.0.3.33, 00:01:02:3E:4E:3A) -> out1;
newOUT[1]->out1;
c1[1] -> arpt;
arpt[1] -> [1]arpq1;
c1[2] -> Paint(2) -> ip;
c1[3] -> Print("xl1 non-IP") -> Discard;

// Local delivery
toh :: Print(toh) -> Discard;
arpt[2] -> toh;
_xorp_rt4[2] -> IPReassembler -> ping_ipc :: 
IPClassifier(icmp type echo, -);
ping_ipc[0] -> ICMPPingResponder -> [0]_xorp_rt4;
ping_ipc[1] -> EtherEncap(0x0800, 1:1:1:1:1:1, 
2:2:2:2:2:2) -> toh;

// Forwarding path for xl0
_xorp_rt4[0] -> DropBroadcasts
     -> cp0 :: PaintTee(1)
     -> gio0 :: IPGWOptions(10.0.2.33)
     -> FixIPSrc(10.0.2.33)
     -> dt0 :: DecIPTTL
     -> fr0 :: IPFragmenter(1500)
     -> [0]arpq0;
dt0[1] -> ICMPError(10.0.2.33, timeexceeded) -> _xorp_rt4;
fr0[1] -> ICMPError(10.0.2.33, unreachable, needfrag) -> 
_xorp_rt4;
gio0[1] -> ICMPError(10.0.2.33, parameterproblem) -> 
_xorp_rt4;
cp0[1] -> ICMPError(10.0.2.33, redirect, host) -> 
_xorp_rt4;

// Forwarding path for xl1
_xorp_rt4[1] -> DropBroadcasts
     -> cp1 :: PaintTee(2)
     -> gio1 :: IPGWOptions(10.0.3.33)
     -> FixIPSrc(10.0.3.33)
     -> dt1 :: DecIPTTL
     -> fr1 :: IPFragmenter(1500)
     -> [0]arpq1;
dt1[1] -> ICMPError(10.0.3.33, timeexceeded) -> _xorp_rt4;
fr1[1] -> ICMPError(10.0.3.33, unreachable, needfrag) -> 
_xorp_rt4;
gio1[1] -> ICMPError(10.0.3.33, parameterproblem) -> 
_xorp_rt4;
cp1[1] -> ICMPError(10.0.3.33, redirect, host) -> 
_xorp_rt4;
");



On Thu, 06 Dec 2007 18:01:55 -0800
  Pavlin Radoslavov <pavlin at icir.org> wrote:
> Robert Joseph Suk <rsuk at ucsc.edu> wrote:
> 
>> Thanks for your reply, Pavlin.
>> I'm not exactly sure the best way to get the 
>> xorp_fea_click_config_generator to unconditionally 
>>return 
>> my static config, but I replaced the config_generator 
>> script with my config file, inside a printf("") and it 
>> seems to work.  I also made sure to rename my 
>> LinearIPlookup from "rt" to "_xorp_rt4" so xorp could 
>> handle it.  The router still receives updates from 
> 
> Yes, this hack should do it.
> 
>> neighboring routers and updates the RIB, but now xorp 
>> throws an error:
>> 
>> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +71 
>> fti_transaction.cc operation_result ] FTI transaction 
>> commit failed on AddE
>> ntry4: net = 10.0.0.0/24 nexthop = 10.0.2.22 ifname = 
>>xl0 
>> vifname = xl0 metric = 2 admin_distance = 120 xorp_route 
>>= 
>> true is_d
>> eleted = false is_unresolved = false is_connected_route 
>>= 
>> false
>> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +301 
>> fticonfig_entry_set_click.cc add_entry ] Cannot find 
>> outgoing port number
>> for the Click forwarding table element to add entry net 
>>= 
>> 10.0.1.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname = 
>>xl0 
>> metric =
>> 1 admin_distance = 120 xorp_route = true is_deleted = 
>> false is_unresolved = false is_connected_route = false
> 
> There seems to be some error with adding the routes to 
>Click.
> Could you update to the latest XORP from CVS.
> The update might not fix the problem, but will make it 
>easier to
> debug it:
> 
> http://www.xorp.org/cvs.html
> 
> Please send me your latest XORP configuration as well as 
>your
> hacked xorp_fea_click_config_generator.
> Also, please tell me the Click version you are using.
> 
> Thanks,
> Pavlin
> 
>> 
>> and click still won't function.
>> When I run "click myconfig.click", pings across the 
>>router 
>> work fine, while pinging the router directly generates 
>> Duplicate replies (one from the kernel, and one from 
>> click).
>> As a debug, in my click config I added a Tee to the 
>>output 
>> of xl0 and copied all click-generated responses out to 
>>The 
>> other interface, xl1. Now when I ping the router, I can 
>> see the extra traffic on a TCPdump of xl1.  When I run 
>> xorp with my config and ping the router, I only get one 
>> response, and nothing on xl1, leading me to believe that 
>> either my click config isn't running, or it just isnt 
>> getting any traffic.
>> 
>> 
>> On Thu, 06 Dec 2007 12:39:47 -0800
>>   Pavlin Radoslavov <pavlin at icir.org> wrote:
>> >>   I'm trying to set up a xorp/click configuration 
>>which 
>> >> runs RIP. I have RIP working with xorp, but when I 
>> >>enable 
>> >> the user click forwarding path, I get strange 
>>behavior. 
>> >>If 
>> >> I 'duplicate-routes-to-kernel' everything works fine. 
>> >> However, when I don't duplicate routes-to-kernel, the 
>> >> routes still show up in xorpsh (show route table ipv4 
>> >> unicast rip/final), but if I ping any of those 
>> >>addresses, 
>> >> I get 'no route to host'. Xorp also cannot send RIP 
>> >> updates, getting the send_from_multicast_if failed.
>> > 
>> >First the (hopefully) easy part:
>> > As you know already, FreeBSD requires to have a 
>>matching 
>> >route
>> > (e.g., 0.0.0.0/0) in the unicast forwarding table in 
>>the 
>> >kernel to
>> > be able to originate multicast packets. If you use 
>>XORP 
>> >to configure
>> > the 0.0.0.0/0 static route, and if 
>> >"duplicate-routes-to-kernel" is
>> > disabled, this route won't reach the kernel.
>> > Hence, to get around this problem you should add 
>> >0.0.0.0/0 to the
>> > kernel by hand before starting XORP.
>> > 
>> >> The reason I want to turn 
>>'duplicate-routes-to-kernel' 
>> >> off, is so that I can check that the click forwarding 
>> >>path 
>> >> is working.
>> >> 
>> >> I already added a static route 0.0.0.0/0 to an 
>>attached 
>> >> interface, and put "multicast_host="YES"" in my 
>>rc.conf.
>> >> I'm running BSD6.2, and my xorp config is below. The 
>> >>click 
>> >> config I'm running is simply the one generated by 
>> >> 'make-ip-conf.pl' which is a basic IP router
>> >> Any ideas why xorp sees the routes in xorpsh but 
>>can't 
>> >>use 
>> >> them?
>> > 
>> > If you are to use your own static config with 
>> >make-ip-conf.pl, it
>> > will be safer if you also modify the sample
>> > "/usr/local/fea/xorp_fea_click_config_generator" 
>> >generator to
>> > unconditionally return that configuration. FYI, the 
>> >config generator
>> > is automatically called by XORP whenenever something 
>>in 
>> >the
>> > interface configuration changes, so on startup it 
>>might 
>> >actually be
>> > overwriting your own static config.
>> > 
>> > Once you eliminate the config generation factor, then 
>> >you need to
>> > investigate whether userland Click itself is working 
>>as
>> > expected. For that purpose I'd recommend to start 
>> >userland Click by
>> > hand (without XORP), and then manually configure it 
>>with 
>> >your static
>> > config (including the routes that should be generated 
>>by 
>> >RIP).
>> > Then do the ping test to see whether userland Click on 
>> >its own is
>> > fine.
>> > One thing to have in mind is that the ping packets 
>> >originated on the
>> > router running Click might not actually be processed 
>>by 
>> >Click: such
>> > packets will lookup the unicast forwarding table in 
>>the 
>> >kernel, and
>> > therefore fail. Hence, you might want to run ping on a 
>> >machine
>> > directly connected to the router running Click.
>> > 
>> > Hopefully the above tests will narrow the problem.
>> > 
>> > Regards,
>> > Pavlin
>> > 
>> > P.S. In your config you don't need the plumbing/mfea4 
>> >and mfea6
>> > sections.
>> > 
>> > 
>> >> 
>> >> 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: true
>> >>          }
>> >> 
>> >>          unicast-forwarding6 {
>> >>                  disable: true
>> >>          }
>> >> 
>> >>          click {
>> >>                  disable: false  /*run autogenerated 
>> >> config from /conf/make-ip-conf.pl*/
>> >>                  duplicate-routes-to-kernel: true
>> >> 
>> >>                  kernel-click{
>> >>                          disable: true
>> >>                  }
>> >> 
>> >>                  user-click{
>> >>                          disable: false
>> >>                          command-file: 
>> >> "/usr/local/bin/click"
>> >>                          command-extra-arguments: 
>>"-R"
>> >>                          command-execute-on-startup: 
>> >>true
>> >>                          startup-config-file: 
>> >> "/usr/local/xorp/iprouter_auto.click"
>> >> 
>>                         user-click-config-generator-file: 
>> >> "/usr/local/fea/xorp_fea_click_config_generator"
>> >>                  }
>> >>          }
>> >> } /* </fea> */
>> >> plumbing{
>> >>          mfea4 {
>> >>                  disable: true
>> >>          }
>> >>          mfea6{
>> >>                  disable: true
>> >>          }
>> >> }
>> >> policy {
>> >>          /*Describe connected routes for 
>> >>redistribution*/
>> >>          policy-statement connected {
>> >>                  term export {
>> >>                          from {
>> >>                                  protocol: 
>>"connected"
>> >>                          }
>> >>                  }
>> >>          }
>> >> }
>> >> 
>> >> protocols {
>> >>          static{
>> >>                  route 0.0.0.0/0{
>> >>                          next-hop: 10.0.2.22
>> >>                          metric: 1
>> >>                  }
>> >>          }
>> >>          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>*/
>> >> 
>> >> 
>> >> 
>> >> -Robbie
>> >> 
>> >> _______________________________________________
>> >> Xorp-users mailing list
>> >> Xorp-users at xorp.org
>> >> 
>>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>> 
>> -Robbie
>> 
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

-Robbie


From pavlin at icir.org  Tue Dec 11 15:38:59 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 11 Dec 2007 15:38:59 -0800
Subject: [Xorp-users] xorp with click and RIP
In-Reply-To: Message from "Robert Joseph Suk" <rsuk@ucsc.edu> of "Tue,
	11 Dec 2007 15:00:44 PST." <web-14536720@email-prod-be-1.ucsc.edu> 
Message-ID: <200712112338.lBBNcxVM066830@possum.icir.org>

If the problem is what I think it is, this might require some time
to investigate it, so probably I won't be able to look into the
details of the problem until next week or so.

In the mean time I have few questions: 

* Can you confirm that route 224.0.0.0/4 was actually added to the
  kernel. I don't remember whether adding such multicast routes will
  actually work, but if it didn't work then you should add it by
  hand before starting XORP.

* Is the error you are seeing same as before:
  "Cannot find outgoing port number"

* What happens if you use unicast static routes (only) instead of
  RIP. Do you see same "Cannot find outgoing port number" error?

Thanks,
Pavlin


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

> I upgraded to the CVS versions of both xorp(1.52) and 
> click(1.6.0) and it solved the problem of using the click 
> forwarding path.  My hardware is set up as follows:
> 
> PC2--PC3--PC4
> 
> PC2: xl0: 10.0.1.22, xl1: 10.0.2.22
> PC3: xl0: 10.0.2.33, xl1: 10.0.3.33
> PC4: xl0: 10.0.3.44, xl1: 10.0.4.44
> 
> The click forwarding path works fine, and RIP runs just 
> fine in userspace, but XORP routes are not being added to 
> click.
> 
> Below is my xorp config:
> PC3# cat xorpclick_pc3.boot
> 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: false
>                  duplicate-routes-to-kernel: true
> 
>                  kernel-click{
>                          disable: true
>                  }
>                  user-click{
>                          disable: false
>                          command-file: 
> "/usr/local/bin/click"
>                          command-extra-arguments: "-R"
>                          command-execute-on-startup: true
>                          startup-config-file: 
> "/usr/local/xorp/iprouter_auto.click"
>                          user-click-config-generator-file: 
> "/usr/local/fea/xorp_fea_click_config_generator"
>                  }
>          }
> } /* </fea> */
> policy {
>          /*Describe connected routes for redistribution*/
>          policy-statement connected {
>                  term export {
>                          from {
>                                  protocol: "connected"
>                          }
>                  }
>          }
> }
> 
> protocols {
>          static{
>                  route 224.0.0.0/4{
>                          next-hop: 10.0.2.22
>                          metric: 1
>                  }
>          }
>          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>*/
> 
> 
> 
> And here is my click_config_generator:
> *note, this is the same click config as 
> iprouter_auto.click in my xorp config.
> 
> 
> PC3# cat xorp_fea_click_config_generator
> printf("
> // Generated by make-ip-conf.pl
> // xl0 10.0.2.33 00:01:02:42:20:EC
> // xl1 10.0.3.33 00:01:02:3E:4E:3A
> 
> // Shared IP input path and routing table
> ip :: Strip(14)
>      -> good_header :: CheckIPHeader(INTERFACES 
> 10.0.2.33/255.255.255.0 10.0.3.33/255.255.255.0)
> good_header[0] -> _xorp_rt4 :: LinearIPLookup(
>          10.0.2.33/32 2,
>          10.0.2.255/32 2,
>          10.0.2.0/32 2,
>          10.0.3.33/32 2,
>          10.0.3.255/32 2,
>          10.0.3.0/32 2,  //above are local interfaces. 
>  deliver locally
>          10.0.2.0/255.255.255.0 0,       //xl0
>          10.0.3.0/255.255.255.0 1,       //xl1
>          255.255.255.255/32 0.0.0.0 2,   //broadcasts are 
> local and get dropped
>          0.0.0.0/32 2,
>          0.0.0.0/0.0.0.0 10.0.2.22 0);
> 
> // ARP responses are copied to each ARPQuerier and the 
> host.
> arpt :: Tee(3);
> 
> // Input and output paths for xl0
> c0 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 
> 12/0800, -);
> FromDevice(xl0) -> c0;
> out0 :: Queue(200) -> todevice0 :: ToDevice(xl0);
> c0[0] -> ar0 :: ARPResponder(10.0.2.33 00:01:02:42:20:EC) 
> -> out0;
> arpq0 :: ARPQuerier(10.0.2.33, 00:01:02:42:20:EC) -> 
> newOUT::Tee(2);
> newOUT[0]->out0;
> c0[1] -> arpt;
> arpt[0] -> [1]arpq0;
> c0[2] -> Paint(1) -> ip;
> c0[3] -> Print("xl0 non-IP") -> Discard;
> 
> // Input and output paths for xl1
> c1 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 
> 12/0800, -);
> FromDevice(xl1) -> c1;
> out1 :: Queue(200) -> todevice1 :: ToDevice(xl1);
> c1[0] -> ar1 :: ARPResponder(10.0.3.33 00:01:02:3E:4E:3A) 
> -> out1;
> arpq1 :: ARPQuerier(10.0.3.33, 00:01:02:3E:4E:3A) -> out1;
> newOUT[1]->out1;
> c1[1] -> arpt;
> arpt[1] -> [1]arpq1;
> c1[2] -> Paint(2) -> ip;
> c1[3] -> Print("xl1 non-IP") -> Discard;
> 
> // Local delivery
> toh :: Print(toh) -> Discard;
> arpt[2] -> toh;
> _xorp_rt4[2] -> IPReassembler -> ping_ipc :: 
> IPClassifier(icmp type echo, -);
> ping_ipc[0] -> ICMPPingResponder -> [0]_xorp_rt4;
> ping_ipc[1] -> EtherEncap(0x0800, 1:1:1:1:1:1, 
> 2:2:2:2:2:2) -> toh;
> 
> // Forwarding path for xl0
> _xorp_rt4[0] -> DropBroadcasts
>      -> cp0 :: PaintTee(1)
>      -> gio0 :: IPGWOptions(10.0.2.33)
>      -> FixIPSrc(10.0.2.33)
>      -> dt0 :: DecIPTTL
>      -> fr0 :: IPFragmenter(1500)
>      -> [0]arpq0;
> dt0[1] -> ICMPError(10.0.2.33, timeexceeded) -> _xorp_rt4;
> fr0[1] -> ICMPError(10.0.2.33, unreachable, needfrag) -> 
> _xorp_rt4;
> gio0[1] -> ICMPError(10.0.2.33, parameterproblem) -> 
> _xorp_rt4;
> cp0[1] -> ICMPError(10.0.2.33, redirect, host) -> 
> _xorp_rt4;
> 
> // Forwarding path for xl1
> _xorp_rt4[1] -> DropBroadcasts
>      -> cp1 :: PaintTee(2)
>      -> gio1 :: IPGWOptions(10.0.3.33)
>      -> FixIPSrc(10.0.3.33)
>      -> dt1 :: DecIPTTL
>      -> fr1 :: IPFragmenter(1500)
>      -> [0]arpq1;
> dt1[1] -> ICMPError(10.0.3.33, timeexceeded) -> _xorp_rt4;
> fr1[1] -> ICMPError(10.0.3.33, unreachable, needfrag) -> 
> _xorp_rt4;
> gio1[1] -> ICMPError(10.0.3.33, parameterproblem) -> 
> _xorp_rt4;
> cp1[1] -> ICMPError(10.0.3.33, redirect, host) -> 
> _xorp_rt4;
> ");
> 
> 
> 
> On Thu, 06 Dec 2007 18:01:55 -0800
>   Pavlin Radoslavov <pavlin at icir.org> wrote:
> > Robert Joseph Suk <rsuk at ucsc.edu> wrote:
> > 
> >> Thanks for your reply, Pavlin.
> >> I'm not exactly sure the best way to get the 
> >> xorp_fea_click_config_generator to unconditionally 
> >>return 
> >> my static config, but I replaced the config_generator 
> >> script with my config file, inside a printf("") and it 
> >> seems to work.  I also made sure to rename my 
> >> LinearIPlookup from "rt" to "_xorp_rt4" so xorp could 
> >> handle it.  The router still receives updates from 
> > 
> > Yes, this hack should do it.
> > 
> >> neighboring routers and updates the RIB, but now xorp 
> >> throws an error:
> >> 
> >> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +71 
> >> fti_transaction.cc operation_result ] FTI transaction 
> >> commit failed on AddE
> >> ntry4: net = 10.0.0.0/24 nexthop = 10.0.2.22 ifname = 
> >>xl0 
> >> vifname = xl0 metric = 2 admin_distance = 120 xorp_route 
> >>= 
> >> true is_d
> >> eleted = false is_unresolved = false is_connected_route 
> >>= 
> >> false
> >> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +301 
> >> fticonfig_entry_set_click.cc add_entry ] Cannot find 
> >> outgoing port number
> >> for the Click forwarding table element to add entry net 
> >>= 
> >> 10.0.1.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname = 
> >>xl0 
> >> metric =
> >> 1 admin_distance = 120 xorp_route = true is_deleted = 
> >> false is_unresolved = false is_connected_route = false
> > 
> > There seems to be some error with adding the routes to 
> >Click.
> > Could you update to the latest XORP from CVS.
> > The update might not fix the problem, but will make it 
> >easier to
> > debug it:
> > 
> > http://www.xorp.org/cvs.html
> > 
> > Please send me your latest XORP configuration as well as 
> >your
> > hacked xorp_fea_click_config_generator.
> > Also, please tell me the Click version you are using.
> > 
> > Thanks,
> > Pavlin
> > 
> >> 
> >> and click still won't function.
> >> When I run "click myconfig.click", pings across the 
> >>router 
> >> work fine, while pinging the router directly generates 
> >> Duplicate replies (one from the kernel, and one from 
> >> click).
> >> As a debug, in my click config I added a Tee to the 
> >>output 
> >> of xl0 and copied all click-generated responses out to 
> >>The 
> >> other interface, xl1. Now when I ping the router, I can 
> >> see the extra traffic on a TCPdump of xl1.  When I run 
> >> xorp with my config and ping the router, I only get one 
> >> response, and nothing on xl1, leading me to believe that 
> >> either my click config isn't running, or it just isnt 
> >> getting any traffic.
> >> 
> >> 
> >> On Thu, 06 Dec 2007 12:39:47 -0800
> >>   Pavlin Radoslavov <pavlin at icir.org> wrote:
> >> >>   I'm trying to set up a xorp/click configuration 
> >>which 
> >> >> runs RIP. I have RIP working with xorp, but when I 
> >> >>enable 
> >> >> the user click forwarding path, I get strange 
> >>behavior. 
> >> >>If 
> >> >> I 'duplicate-routes-to-kernel' everything works fine. 
> >> >> However, when I don't duplicate routes-to-kernel, the 
> >> >> routes still show up in xorpsh (show route table ipv4 
> >> >> unicast rip/final), but if I ping any of those 
> >> >>addresses, 
> >> >> I get 'no route to host'. Xorp also cannot send RIP 
> >> >> updates, getting the send_from_multicast_if failed.
> >> > 
> >> >First the (hopefully) easy part:
> >> > As you know already, FreeBSD requires to have a 
> >>matching 
> >> >route
> >> > (e.g., 0.0.0.0/0) in the unicast forwarding table in 
> >>the 
> >> >kernel to
> >> > be able to originate multicast packets. If you use 
> >>XORP 
> >> >to configure
> >> > the 0.0.0.0/0 static route, and if 
> >> >"duplicate-routes-to-kernel" is
> >> > disabled, this route won't reach the kernel.
> >> > Hence, to get around this problem you should add 
> >> >0.0.0.0/0 to the
> >> > kernel by hand before starting XORP.
> >> > 
> >> >> The reason I want to turn 
> >>'duplicate-routes-to-kernel' 
> >> >> off, is so that I can check that the click forwarding 
> >> >>path 
> >> >> is working.
> >> >> 
> >> >> I already added a static route 0.0.0.0/0 to an 
> >>attached 
> >> >> interface, and put "multicast_host="YES"" in my 
> >>rc.conf.
> >> >> I'm running BSD6.2, and my xorp config is below. The 
> >> >>click 
> >> >> config I'm running is simply the one generated by 
> >> >> 'make-ip-conf.pl' which is a basic IP router
> >> >> Any ideas why xorp sees the routes in xorpsh but 
> >>can't 
> >> >>use 
> >> >> them?
> >> > 
> >> > If you are to use your own static config with 
> >> >make-ip-conf.pl, it
> >> > will be safer if you also modify the sample
> >> > "/usr/local/fea/xorp_fea_click_config_generator" 
> >> >generator to
> >> > unconditionally return that configuration. FYI, the 
> >> >config generator
> >> > is automatically called by XORP whenenever something 
> >>in 
> >> >the
> >> > interface configuration changes, so on startup it 
> >>might 
> >> >actually be
> >> > overwriting your own static config.
> >> > 
> >> > Once you eliminate the config generation factor, then 
> >> >you need to
> >> > investigate whether userland Click itself is working 
> >>as
> >> > expected. For that purpose I'd recommend to start 
> >> >userland Click by
> >> > hand (without XORP), and then manually configure it 
> >>with 
> >> >your static
> >> > config (including the routes that should be generated 
> >>by 
> >> >RIP).
> >> > Then do the ping test to see whether userland Click on 
> >> >its own is
> >> > fine.
> >> > One thing to have in mind is that the ping packets 
> >> >originated on the
> >> > router running Click might not actually be processed 
> >>by 
> >> >Click: such
> >> > packets will lookup the unicast forwarding table in 
> >>the 
> >> >kernel, and
> >> > therefore fail. Hence, you might want to run ping on a 
> >> >machine
> >> > directly connected to the router running Click.
> >> > 
> >> > Hopefully the above tests will narrow the problem.
> >> > 
> >> > Regards,
> >> > Pavlin
> >> > 
> >> > P.S. In your config you don't need the plumbing/mfea4 
> >> >and mfea6
> >> > sections.
> >> > 
> >> > 
> >> >> 
> >> >> 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: true
> >> >>          }
> >> >> 
> >> >>          unicast-forwarding6 {
> >> >>                  disable: true
> >> >>          }
> >> >> 
> >> >>          click {
> >> >>                  disable: false  /*run autogenerated 
> >> >> config from /conf/make-ip-conf.pl*/
> >> >>                  duplicate-routes-to-kernel: true
> >> >> 
> >> >>                  kernel-click{
> >> >>                          disable: true
> >> >>                  }
> >> >> 
> >> >>                  user-click{
> >> >>                          disable: false
> >> >>                          command-file: 
> >> >> "/usr/local/bin/click"
> >> >>                          command-extra-arguments: 
> >>"-R"
> >> >>                          command-execute-on-startup: 
> >> >>true
> >> >>                          startup-config-file: 
> >> >> "/usr/local/xorp/iprouter_auto.click"
> >> >> 
> >>                         user-click-config-generator-file: 
> >> >> "/usr/local/fea/xorp_fea_click_config_generator"
> >> >>                  }
> >> >>          }
> >> >> } /* </fea> */
> >> >> plumbing{
> >> >>          mfea4 {
> >> >>                  disable: true
> >> >>          }
> >> >>          mfea6{
> >> >>                  disable: true
> >> >>          }
> >> >> }
> >> >> policy {
> >> >>          /*Describe connected routes for 
> >> >>redistribution*/
> >> >>          policy-statement connected {
> >> >>                  term export {
> >> >>                          from {
> >> >>                                  protocol: 
> >>"connected"
> >> >>                          }
> >> >>                  }
> >> >>          }
> >> >> }
> >> >> 
> >> >> protocols {
> >> >>          static{
> >> >>                  route 0.0.0.0/0{
> >> >>                          next-hop: 10.0.2.22
> >> >>                          metric: 1
> >> >>                  }
> >> >>          }
> >> >>          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>*/
> >> >> 
> >> >> 
> >> >> 
> >> >> -Robbie
> >> >> 
> >> >> _______________________________________________
> >> >> Xorp-users mailing list
> >> >> Xorp-users at xorp.org
> >> >> 
> >>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> >> 
> >> -Robbie
> >> 
> >> _______________________________________________
> >> Xorp-users mailing list
> >> Xorp-users at xorp.org
> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> 
> -Robbie
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From rsuk at ucsc.edu  Tue Dec 11 16:53:45 2007
From: rsuk at ucsc.edu (Robert Joseph Suk)
Date: Tue, 11 Dec 2007 16:53:45 -0800
Subject: [Xorp-users] xorp with click and RIP
In-Reply-To: <200712112338.lBBNcxVM066830@possum.icir.org>
References: <200712112338.lBBNcxVM066830@possum.icir.org>
Message-ID: <web-14246191@email-prod-be-2.ucsc.edu>

Pavlin,
   *The route to 224.0.0.0/4 does show up in the kernel 
and with xorpsh
   *I do still get the same error when I add static routes
   *a dump of stderr, from starting xorp_rtrmgr:
     the error is: FTI transaction commit failed on 
AddEntry4
      ...Cannot find outgoing port number for the Click 
forwarding table element to add entry net...

There's also an error about the External click generator 
failing.  I played around with it a little bit but 
couldn't get it to stop throwing that error.  Maybe that 
is causing the problem?

[ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] MFEA enabled
[ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] CLI enabled
[ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] CLI started
[ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] MFEA enabled
[ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] CLI enabled
[ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] CLI started
[ 2007/12/11 16:31:01  ERROR xorp_fea:13867 FEA +740 
ifconfig_set_click.cc click_config_generator_done ] 
External Click config
uration generator 
(/usr/local/fea/xorp_fea_click_config_generator) failed: 
Command "/usr/local/fea/xorp_fea_click_config_gener
ator": exited with exit status 127.
[ 2007/12/11 16:31:04  ERROR xorp_fea:13867 FEA +301 
fticonfig_entry_set_click.cc add_entry ] Cannot find 
outgoing port number
  for the Click forwarding table element to add entry net 
= 10.0.2.0/24 nexthop = 10.0.2.33 ifname = xl0 vifname = 
xl0 metric =
  0 admin_distance = 0 xorp_route = true is_deleted = 
false is_unresolved = false is_connected_route = true
[ 2007/12/11 16:31:04  ERROR xorp_fea:13867 FEA +71 
fti_transaction.cc operation_result ] FTI transaction 
commit failed on Add
Entry4: net = 10.0.2.0/24 nexthop = 10.0.2.33 ifname = xl0 
vifname = xl0 metric = 0 admin_distance = 0 xorp_route = 
true is_de
leted = false is_unresolved = false is_connected_route = 
true
[ 2007/12/11 16:31:04  ERROR xorp_fea:13867 FEA +301 
fticonfig_entry_set_click.cc add_entry ] Cannot find 
outgoing port number
  for the Click forwarding table element to add entry net 
= 10.0.3.0/24 nexthop = 10.0.3.33 ifname = xl1 vifname = 
xl1 metric =
  0 admin_distance = 0 xorp_route = true is_deleted = 
false is_unresolved = false is_connected_route = true
[ 2007/12/11 16:31:04 WARNING xorp_fea XrlFeaTarget ] 
Handling method for 
redist_transaction4/0.1/commit_transaction failed: X
rlCmdError 102 Command failed AddEntry4: net = 10.0.2.0/24 
nexthop = 10.0.2.33 ifname = xl0 vifname = xl0 metric = 0 
admin_dis
tance = 0 xorp_route = true is_deleted = false 
is_unresolved = false is_connected_route = true
[ 2007/12/11 16:31:04  ERROR xorp_rib:13870 RIB +910 
redist_xrl.cc dispatch_complete ] Failed to commit 
transaction: 102 Comma
nd failed AddEntry4: net = 10.0.2.0/24 nexthop = 10.0.2.33 
ifname = xl0 vifname = xl0 metric = 0 admin_distance = 0 
xorp_route
  = true is_deleted = false is_unresolved = false 
is_connected_route = true
[ 2007/12/11 16:31:09  ERROR xorp_fea:13867 FEA +301 
fticonfig_entry_set_click.cc add_entry ] Cannot find 
outgoing port number
  for the Click forwarding table element to add entry net 
= 224.0.0.0/4 nexthop = 10.0.2.22 ifname = xl0 vifname = 
xl0 metric =
  1 admin_distance = 1 xorp_route = true is_deleted = 
false is_unresolved = false is_connected_route = false
[ 2007/12/11 16:31:09  ERROR xorp_fea:13867 FEA +71 
fti_transaction.cc operation_result ] FTI transaction 
commit failed on Add
Entry4: net = 224.0.0.0/4 nexthop = 10.0.2.22 ifname = xl0 
vifname = xl0 metric = 1 admin_distance = 1 xorp_route = 
true is_de
leted = false is_unresolved = false is_connected_route = 
false
[ 2007/12/11 16:31:09  ERROR xorp_fea:13867 FEA +301 
fticonfig_entry_set_click.cc add_entry ] Cannot find 
outgoing port number
  for the Click forwarding table element to add entry net 
= 10.0.1.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname = 
xl0 metric =
  2 admin_distance = 1 xorp_route = true is_deleted = 
false is_unresolved = false is_connected_route = false
[ 2007/12/11 16:31:09  ERROR xorp_fea:13867 FEA +301 
fticonfig_entry_set_click.cc add_entry ] Cannot find 
outgoing port number
  for the Click forwarding table element to add entry net 
= 10.0.4.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname = 
xl0 metric =
  3 admin_distance = 1 xorp_route = true is_deleted = 
false is_unresolved = false is_connected_route = false
[ 2007/12/11 16:31:09 WARNING xorp_fea XrlFeaTarget ] 
Handling method for 
redist_transaction4/0.1/commit_transaction failed: X
rlCmdError 102 Command failed AddEntry4: net = 224.0.0.0/4 
nexthop = 10.0.2.22 ifname = xl0 vifname = xl0 metric = 1 
admin_dis
tance = 1 xorp_route = true is_deleted = false 
is_unresolved = false is_connected_route = false
[ 2007/12/11 16:31:09  ERROR xorp_rib:13870 RIB +910 
redist_xrl.cc dispatch_complete ] Failed to commit 
transaction: 102 Comma
nd failed AddEntry4: net = 224.0.0.0/4 nexthop = 10.0.2.22 
ifname = xl0 vifname = xl0 metric = 1 admin_distance = 1 
xorp_route
  = true is_deleted = false is_unresolved = false 
is_connected_route = false

On Tue, 11 Dec 2007 15:38:59 -0800
  Pavlin Radoslavov <pavlin at icir.org> wrote:
> If the problem is what I think it is, this might require 
>some time
> to investigate it, so probably I won't be able to look 
>into the
> details of the problem until next week or so.
> 
> In the mean time I have few questions: 
> 
> * Can you confirm that route 224.0.0.0/4 was actually 
>added to the
>  kernel. I don't remember whether adding such multicast 
>routes will
>  actually work, but if it didn't work then you should 
>add it by
>  hand before starting XORP.
> 
> * Is the error you are seeing same as before:
>  "Cannot find outgoing port number"
> 
> * What happens if you use unicast static routes (only) 
>instead of
>  RIP. Do you see same "Cannot find outgoing port number" 
>error?
> 
> Thanks,
> Pavlin
> 
> 
> Robert Joseph Suk <rsuk at ucsc.edu> wrote:
> 
>> I upgraded to the CVS versions of both xorp(1.52) and 
>> click(1.6.0) and it solved the problem of using the 
>>click 
>> forwarding path.  My hardware is set up as follows:
>> 
>> PC2--PC3--PC4
>> 
>> PC2: xl0: 10.0.1.22, xl1: 10.0.2.22
>> PC3: xl0: 10.0.2.33, xl1: 10.0.3.33
>> PC4: xl0: 10.0.3.44, xl1: 10.0.4.44
>> 
>> The click forwarding path works fine, and RIP runs just 
>> fine in userspace, but XORP routes are not being added 
>>to 
>> click.
>> 
>> Below is my xorp config:
>> PC3# cat xorpclick_pc3.boot
>> 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: false
>>                  duplicate-routes-to-kernel: true
>> 
>>                  kernel-click{
>>                          disable: true
>>                  }
>>                  user-click{
>>                          disable: false
>>                          command-file: 
>> "/usr/local/bin/click"
>>                          command-extra-arguments: "-R"
>>                          command-execute-on-startup: 
>>true
>>                          startup-config-file: 
>> "/usr/local/xorp/iprouter_auto.click"
>>                          user-click-config-generator-file: 
>> "/usr/local/fea/xorp_fea_click_config_generator"
>>                  }
>>          }
>> } /* </fea> */
>> policy {
>>          /*Describe connected routes for 
>>redistribution*/
>>          policy-statement connected {
>>                  term export {
>>                          from {
>>                                  protocol: "connected"
>>                          }
>>                  }
>>          }
>> }
>> 
>> protocols {
>>          static{
>>                  route 224.0.0.0/4{
>>                          next-hop: 10.0.2.22
>>                          metric: 1
>>                  }
>>          }
>>          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>*/
>> 
>> 
>> 
>> And here is my click_config_generator:
>> *note, this is the same click config as 
>> iprouter_auto.click in my xorp config.
>> 
>> 
>> PC3# cat xorp_fea_click_config_generator
>> printf("
>> // Generated by make-ip-conf.pl
>> // xl0 10.0.2.33 00:01:02:42:20:EC
>> // xl1 10.0.3.33 00:01:02:3E:4E:3A
>> 
>> // Shared IP input path and routing table
>> ip :: Strip(14)
>>      -> good_header :: CheckIPHeader(INTERFACES 
>> 10.0.2.33/255.255.255.0 10.0.3.33/255.255.255.0)
>> good_header[0] -> _xorp_rt4 :: LinearIPLookup(
>>          10.0.2.33/32 2,
>>          10.0.2.255/32 2,
>>          10.0.2.0/32 2,
>>          10.0.3.33/32 2,
>>          10.0.3.255/32 2,
>>          10.0.3.0/32 2,  //above are local interfaces. 
>>  deliver locally
>>          10.0.2.0/255.255.255.0 0,       //xl0
>>          10.0.3.0/255.255.255.0 1,       //xl1
>>          255.255.255.255/32 0.0.0.0 2,   //broadcasts 
>>are 
>> local and get dropped
>>          0.0.0.0/32 2,
>>          0.0.0.0/0.0.0.0 10.0.2.22 0);
>> 
>> // ARP responses are copied to each ARPQuerier and the 
>> host.
>> arpt :: Tee(3);
>> 
>> // Input and output paths for xl0
>> c0 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 
>> 12/0800, -);
>> FromDevice(xl0) -> c0;
>> out0 :: Queue(200) -> todevice0 :: ToDevice(xl0);
>> c0[0] -> ar0 :: ARPResponder(10.0.2.33 
>>00:01:02:42:20:EC) 
>> -> out0;
>> arpq0 :: ARPQuerier(10.0.2.33, 00:01:02:42:20:EC) -> 
>> newOUT::Tee(2);
>> newOUT[0]->out0;
>> c0[1] -> arpt;
>> arpt[0] -> [1]arpq0;
>> c0[2] -> Paint(1) -> ip;
>> c0[3] -> Print("xl0 non-IP") -> Discard;
>> 
>> // Input and output paths for xl1
>> c1 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 
>> 12/0800, -);
>> FromDevice(xl1) -> c1;
>> out1 :: Queue(200) -> todevice1 :: ToDevice(xl1);
>> c1[0] -> ar1 :: ARPResponder(10.0.3.33 
>>00:01:02:3E:4E:3A) 
>> -> out1;
>> arpq1 :: ARPQuerier(10.0.3.33, 00:01:02:3E:4E:3A) -> 
>>out1;
>> newOUT[1]->out1;
>> c1[1] -> arpt;
>> arpt[1] -> [1]arpq1;
>> c1[2] -> Paint(2) -> ip;
>> c1[3] -> Print("xl1 non-IP") -> Discard;
>> 
>> // Local delivery
>> toh :: Print(toh) -> Discard;
>> arpt[2] -> toh;
>> _xorp_rt4[2] -> IPReassembler -> ping_ipc :: 
>> IPClassifier(icmp type echo, -);
>> ping_ipc[0] -> ICMPPingResponder -> [0]_xorp_rt4;
>> ping_ipc[1] -> EtherEncap(0x0800, 1:1:1:1:1:1, 
>> 2:2:2:2:2:2) -> toh;
>> 
>> // Forwarding path for xl0
>> _xorp_rt4[0] -> DropBroadcasts
>>      -> cp0 :: PaintTee(1)
>>      -> gio0 :: IPGWOptions(10.0.2.33)
>>      -> FixIPSrc(10.0.2.33)
>>      -> dt0 :: DecIPTTL
>>      -> fr0 :: IPFragmenter(1500)
>>      -> [0]arpq0;
>> dt0[1] -> ICMPError(10.0.2.33, timeexceeded) -> 
>>_xorp_rt4;
>> fr0[1] -> ICMPError(10.0.2.33, unreachable, needfrag) -> 
>> _xorp_rt4;
>> gio0[1] -> ICMPError(10.0.2.33, parameterproblem) -> 
>> _xorp_rt4;
>> cp0[1] -> ICMPError(10.0.2.33, redirect, host) -> 
>> _xorp_rt4;
>> 
>> // Forwarding path for xl1
>> _xorp_rt4[1] -> DropBroadcasts
>>      -> cp1 :: PaintTee(2)
>>      -> gio1 :: IPGWOptions(10.0.3.33)
>>      -> FixIPSrc(10.0.3.33)
>>      -> dt1 :: DecIPTTL
>>      -> fr1 :: IPFragmenter(1500)
>>      -> [0]arpq1;
>> dt1[1] -> ICMPError(10.0.3.33, timeexceeded) -> 
>>_xorp_rt4;
>> fr1[1] -> ICMPError(10.0.3.33, unreachable, needfrag) -> 
>> _xorp_rt4;
>> gio1[1] -> ICMPError(10.0.3.33, parameterproblem) -> 
>> _xorp_rt4;
>> cp1[1] -> ICMPError(10.0.3.33, redirect, host) -> 
>> _xorp_rt4;
>> ");
>> 
>> 
>> 
>> On Thu, 06 Dec 2007 18:01:55 -0800
>>   Pavlin Radoslavov <pavlin at icir.org> wrote:
>> > Robert Joseph Suk <rsuk at ucsc.edu> wrote:
>> > 
>> >> Thanks for your reply, Pavlin.
>> >> I'm not exactly sure the best way to get the 
>> >> xorp_fea_click_config_generator to unconditionally 
>> >>return 
>> >> my static config, but I replaced the config_generator 
>> >> script with my config file, inside a printf("") and 
>>it 
>> >> seems to work.  I also made sure to rename my 
>> >> LinearIPlookup from "rt" to "_xorp_rt4" so xorp could 
>> >> handle it.  The router still receives updates from 
>> > 
>> > Yes, this hack should do it.
>> > 
>> >> neighboring routers and updates the RIB, but now xorp 
>> >> throws an error:
>> >> 
>> >> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +71 
>> >> fti_transaction.cc operation_result ] FTI transaction 
>> >> commit failed on AddE
>> >> ntry4: net = 10.0.0.0/24 nexthop = 10.0.2.22 ifname = 
>> >>xl0 
>> >> vifname = xl0 metric = 2 admin_distance = 120 
>>xorp_route 
>> >>= 
>> >> true is_d
>> >> eleted = false is_unresolved = false 
>>is_connected_route 
>> >>= 
>> >> false
>> >> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +301 
>> >> fticonfig_entry_set_click.cc add_entry ] Cannot find 
>> >> outgoing port number
>> >> for the Click forwarding table element to add entry 
>>net 
>> >>= 
>> >> 10.0.1.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname 
>>= 
>> >>xl0 
>> >> metric =
>> >> 1 admin_distance = 120 xorp_route = true is_deleted = 
>> >> false is_unresolved = false is_connected_route = 
>>false
>> > 
>> > There seems to be some error with adding the routes to 
>> >Click.
>> > Could you update to the latest XORP from CVS.
>> > The update might not fix the problem, but will make it 
>> >easier to
>> > debug it:
>> > 
>> > http://www.xorp.org/cvs.html
>> > 
>> > Please send me your latest XORP configuration as well 
>>as 
>> >your
>> > hacked xorp_fea_click_config_generator.
>> > Also, please tell me the Click version you are using.
>> > 
>> > Thanks,
>> > Pavlin
>> > 
>> >> 
>> >> and click still won't function.
>> >> When I run "click myconfig.click", pings across the 
>> >>router 
>> >> work fine, while pinging the router directly 
>>generates 
>> >> Duplicate replies (one from the kernel, and one from 
>> >> click).
>> >> As a debug, in my click config I added a Tee to the 
>> >>output 
>> >> of xl0 and copied all click-generated responses out 
>>to 
>> >>The 
>> >> other interface, xl1. Now when I ping the router, I 
>>can 
>> >> see the extra traffic on a TCPdump of xl1.  When I 
>>run 
>> >> xorp with my config and ping the router, I only get 
>>one 
>> >> response, and nothing on xl1, leading me to believe 
>>that 
>> >> either my click config isn't running, or it just isnt 
>> >> getting any traffic.
>> >> 
>> >> 
>> >> On Thu, 06 Dec 2007 12:39:47 -0800
>> >>   Pavlin Radoslavov <pavlin at icir.org> wrote:
>> >> >>   I'm trying to set up a xorp/click configuration 
>> >>which 
>> >> >> runs RIP. I have RIP working with xorp, but when I 
>> >> >>enable 
>> >> >> the user click forwarding path, I get strange 
>> >>behavior. 
>> >> >>If 
>> >> >> I 'duplicate-routes-to-kernel' everything works 
>>fine. 
>> >> >> However, when I don't duplicate routes-to-kernel, 
>>the 
>> >> >> routes still show up in xorpsh (show route table 
>>ipv4 
>> >> >> unicast rip/final), but if I ping any of those 
>> >> >>addresses, 
>> >> >> I get 'no route to host'. Xorp also cannot send 
>>RIP 
>> >> >> updates, getting the send_from_multicast_if 
>>failed.
>> >> > 
>> >> >First the (hopefully) easy part:
>> >> > As you know already, FreeBSD requires to have a 
>> >>matching 
>> >> >route
>> >> > (e.g., 0.0.0.0/0) in the unicast forwarding table 
>>in 
>> >>the 
>> >> >kernel to
>> >> > be able to originate multicast packets. If you use 
>> >>XORP 
>> >> >to configure
>> >> > the 0.0.0.0/0 static route, and if 
>> >> >"duplicate-routes-to-kernel" is
>> >> > disabled, this route won't reach the kernel.
>> >> > Hence, to get around this problem you should add 
>> >> >0.0.0.0/0 to the
>> >> > kernel by hand before starting XORP.
>> >> > 
>> >> >> The reason I want to turn 
>> >>'duplicate-routes-to-kernel' 
>> >> >> off, is so that I can check that the click 
>>forwarding 
>> >> >>path 
>> >> >> is working.
>> >> >> 
>> >> >> I already added a static route 0.0.0.0/0 to an 
>> >>attached 
>> >> >> interface, and put "multicast_host="YES"" in my 
>> >>rc.conf.
>> >> >> I'm running BSD6.2, and my xorp config is below. 
>>The 
>> >> >>click 
>> >> >> config I'm running is simply the one generated by 
>> >> >> 'make-ip-conf.pl' which is a basic IP router
>> >> >> Any ideas why xorp sees the routes in xorpsh but 
>> >>can't 
>> >> >>use 
>> >> >> them?
>> >> > 
>> >> > If you are to use your own static config with 
>> >> >make-ip-conf.pl, it
>> >> > will be safer if you also modify the sample
>> >> > "/usr/local/fea/xorp_fea_click_config_generator" 
>> >> >generator to
>> >> > unconditionally return that configuration. FYI, the 
>> >> >config generator
>> >> > is automatically called by XORP whenenever 
>>something 
>> >>in 
>> >> >the
>> >> > interface configuration changes, so on startup it 
>> >>might 
>> >> >actually be
>> >> > overwriting your own static config.
>> >> > 
>> >> > Once you eliminate the config generation factor, 
>>then 
>> >> >you need to
>> >> > investigate whether userland Click itself is 
>>working 
>> >>as
>> >> > expected. For that purpose I'd recommend to start 
>> >> >userland Click by
>> >> > hand (without XORP), and then manually configure it 
>> >>with 
>> >> >your static
>> >> > config (including the routes that should be 
>>generated 
>> >>by 
>> >> >RIP).
>> >> > Then do the ping test to see whether userland Click 
>>on 
>> >> >its own is
>> >> > fine.
>> >> > One thing to have in mind is that the ping packets 
>> >> >originated on the
>> >> > router running Click might not actually be 
>>processed 
>> >>by 
>> >> >Click: such
>> >> > packets will lookup the unicast forwarding table in 
>> >>the 
>> >> >kernel, and
>> >> > therefore fail. Hence, you might want to run ping 
>>on a 
>> >> >machine
>> >> > directly connected to the router running Click.
>> >> > 
>> >> > Hopefully the above tests will narrow the problem.
>> >> > 
>> >> > Regards,
>> >> > Pavlin
>> >> > 
>> >> > P.S. In your config you don't need the 
>>plumbing/mfea4 
>> >> >and mfea6
>> >> > sections.
>> >> > 
>> >> > 
>> >> >> 
>> >> >> 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: true
>> >> >>          }
>> >> >> 
>> >> >>          unicast-forwarding6 {
>> >> >>                  disable: true
>> >> >>          }
>> >> >> 
>> >> >>          click {
>> >> >>                  disable: false  /*run 
>>autogenerated 
>> >> >> config from /conf/make-ip-conf.pl*/
>> >> >>                  duplicate-routes-to-kernel: true
>> >> >> 
>> >> >>                  kernel-click{
>> >> >>                          disable: true
>> >> >>                  }
>> >> >> 
>> >> >>                  user-click{
>> >> >>                          disable: false
>> >> >>                          command-file: 
>> >> >> "/usr/local/bin/click"
>> >> >>                          command-extra-arguments: 
>> >>"-R"
>> >> >> 
>>                         command-execute-on-startup: 
>> >> >>true
>> >> >>                          startup-config-file: 
>> >> >> "/usr/local/xorp/iprouter_auto.click"
>> >> >> 
>> >> 
>>                        user-click-config-generator-file: 
>> >> >> "/usr/local/fea/xorp_fea_click_config_generator"
>> >> >>                  }
>> >> >>          }
>> >> >> } /* </fea> */
>> >> >> plumbing{
>> >> >>          mfea4 {
>> >> >>                  disable: true
>> >> >>          }
>> >> >>          mfea6{
>> >> >>                  disable: true
>> >> >>          }
>> >> >> }
>> >> >> policy {
>> >> >>          /*Describe connected routes for 
>> >> >>redistribution*/
>> >> >>          policy-statement connected {
>> >> >>                  term export {
>> >> >>                          from {
>> >> >>                                  protocol: 
>> >>"connected"
>> >> >>                          }
>> >> >>                  }
>> >> >>          }
>> >> >> }
>> >> >> 
>> >> >> protocols {
>> >> >>          static{
>> >> >>                  route 0.0.0.0/0{
>> >> >>                          next-hop: 10.0.2.22
>> >> >>                          metric: 1
>> >> >>                  }
>> >> >>          }
>> >> >>          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>*/
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> -Robbie
>> >> >> 
>> >> >> _______________________________________________
>> >> >> Xorp-users mailing list
>> >> >> Xorp-users at xorp.org
>> >> >> 
>> >>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>> >> 
>> >> -Robbie
>> >> 
>> >> _______________________________________________
>> >> Xorp-users mailing list
>> >> Xorp-users at xorp.org
>> >> 
>>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>> 
>> -Robbie
>> 
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

-Robbie


From pavlin at icir.org  Tue Dec 11 17:05:58 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 11 Dec 2007 17:05:58 -0800
Subject: [Xorp-users] xorp with click and RIP
In-Reply-To: Message from "Robert Joseph Suk" <rsuk@ucsc.edu> of "Tue,
	11 Dec 2007 16:53:45 PST." <web-14246191@email-prod-be-2.ucsc.edu> 
Message-ID: <200712120105.lBC15wH2067781@possum.icir.org>

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

> Pavlin,
>    *The route to 224.0.0.0/4 does show up in the kernel 
> and with xorpsh
>    *I do still get the same error when I add static routes
>    *a dump of stderr, from starting xorp_rtrmgr:
>      the error is: FTI transaction commit failed on 
> AddEntry4
>       ...Cannot find outgoing port number for the Click 
> forwarding table element to add entry net...

Thank you for the update.
In your previous email you said that that you updated the XORP
version to the latest code from CVS. However from some of your log
messages below it seems that you are still using the older version.
For example, some of the FEA log messages are from file
fti_transaction.cc, but the latest code in CVS doesn't have that
file anymore.
Hence, please double-check that you are running the latest code.

> There's also an error about the External click generator 
> failing.  I played around with it a little bit but 
> couldn't get it to stop throwing that error.  Maybe that 
> is causing the problem?

The failed generator name is
/usr/local/fea/xorp_fea_click_config_generator

Is this the correct file location?
If you are using vanilla XORP and if you did "gmake check" the
default FEA installation path would be /usr/local/xorp/fea/

Even if the file is not in the right place I doubt it is
related to the "Cannot find outgoing port number", though I won't
rule it out.

Pavlin


> [ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] MFEA enabled
> [ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] CLI enabled
> [ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] CLI started
> [ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] MFEA enabled
> [ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] CLI enabled
> [ 2007/12/11 16:30:55 INFO xorp_fea MFEA ] CLI started
> [ 2007/12/11 16:31:01  ERROR xorp_fea:13867 FEA +740 
> ifconfig_set_click.cc click_config_generator_done ] 
> External Click config
> uration generator 
> (/usr/local/fea/xorp_fea_click_config_generator) failed: 
> Command "/usr/local/fea/xorp_fea_click_config_gener
> ator": exited with exit status 127.
> [ 2007/12/11 16:31:04  ERROR xorp_fea:13867 FEA +301 
> fticonfig_entry_set_click.cc add_entry ] Cannot find 
> outgoing port number
>   for the Click forwarding table element to add entry net 
> = 10.0.2.0/24 nexthop = 10.0.2.33 ifname = xl0 vifname = 
> xl0 metric =
>   0 admin_distance = 0 xorp_route = true is_deleted = 
> false is_unresolved = false is_connected_route = true
> [ 2007/12/11 16:31:04  ERROR xorp_fea:13867 FEA +71 
> fti_transaction.cc operation_result ] FTI transaction 
> commit failed on Add
> Entry4: net = 10.0.2.0/24 nexthop = 10.0.2.33 ifname = xl0 
> vifname = xl0 metric = 0 admin_distance = 0 xorp_route = 
> true is_de
> leted = false is_unresolved = false is_connected_route = 
> true
> [ 2007/12/11 16:31:04  ERROR xorp_fea:13867 FEA +301 
> fticonfig_entry_set_click.cc add_entry ] Cannot find 
> outgoing port number
>   for the Click forwarding table element to add entry net 
> = 10.0.3.0/24 nexthop = 10.0.3.33 ifname = xl1 vifname = 
> xl1 metric =
>   0 admin_distance = 0 xorp_route = true is_deleted = 
> false is_unresolved = false is_connected_route = true
> [ 2007/12/11 16:31:04 WARNING xorp_fea XrlFeaTarget ] 
> Handling method for 
> redist_transaction4/0.1/commit_transaction failed: X
> rlCmdError 102 Command failed AddEntry4: net = 10.0.2.0/24 
> nexthop = 10.0.2.33 ifname = xl0 vifname = xl0 metric = 0 
> admin_dis
> tance = 0 xorp_route = true is_deleted = false 
> is_unresolved = false is_connected_route = true
> [ 2007/12/11 16:31:04  ERROR xorp_rib:13870 RIB +910 
> redist_xrl.cc dispatch_complete ] Failed to commit 
> transaction: 102 Comma
> nd failed AddEntry4: net = 10.0.2.0/24 nexthop = 10.0.2.33 
> ifname = xl0 vifname = xl0 metric = 0 admin_distance = 0 
> xorp_route
>   = true is_deleted = false is_unresolved = false 
> is_connected_route = true
> [ 2007/12/11 16:31:09  ERROR xorp_fea:13867 FEA +301 
> fticonfig_entry_set_click.cc add_entry ] Cannot find 
> outgoing port number
>   for the Click forwarding table element to add entry net 
> = 224.0.0.0/4 nexthop = 10.0.2.22 ifname = xl0 vifname = 
> xl0 metric =
>   1 admin_distance = 1 xorp_route = true is_deleted = 
> false is_unresolved = false is_connected_route = false
> [ 2007/12/11 16:31:09  ERROR xorp_fea:13867 FEA +71 
> fti_transaction.cc operation_result ] FTI transaction 
> commit failed on Add
> Entry4: net = 224.0.0.0/4 nexthop = 10.0.2.22 ifname = xl0 
> vifname = xl0 metric = 1 admin_distance = 1 xorp_route = 
> true is_de
> leted = false is_unresolved = false is_connected_route = 
> false
> [ 2007/12/11 16:31:09  ERROR xorp_fea:13867 FEA +301 
> fticonfig_entry_set_click.cc add_entry ] Cannot find 
> outgoing port number
>   for the Click forwarding table element to add entry net 
> = 10.0.1.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname = 
> xl0 metric =
>   2 admin_distance = 1 xorp_route = true is_deleted = 
> false is_unresolved = false is_connected_route = false
> [ 2007/12/11 16:31:09  ERROR xorp_fea:13867 FEA +301 
> fticonfig_entry_set_click.cc add_entry ] Cannot find 
> outgoing port number
>   for the Click forwarding table element to add entry net 
> = 10.0.4.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname = 
> xl0 metric =
>   3 admin_distance = 1 xorp_route = true is_deleted = 
> false is_unresolved = false is_connected_route = false
> [ 2007/12/11 16:31:09 WARNING xorp_fea XrlFeaTarget ] 
> Handling method for 
> redist_transaction4/0.1/commit_transaction failed: X
> rlCmdError 102 Command failed AddEntry4: net = 224.0.0.0/4 
> nexthop = 10.0.2.22 ifname = xl0 vifname = xl0 metric = 1 
> admin_dis
> tance = 1 xorp_route = true is_deleted = false 
> is_unresolved = false is_connected_route = false
> [ 2007/12/11 16:31:09  ERROR xorp_rib:13870 RIB +910 
> redist_xrl.cc dispatch_complete ] Failed to commit 
> transaction: 102 Comma
> nd failed AddEntry4: net = 224.0.0.0/4 nexthop = 10.0.2.22 
> ifname = xl0 vifname = xl0 metric = 1 admin_distance = 1 
> xorp_route
>   = true is_deleted = false is_unresolved = false 
> is_connected_route = false
> 
> On Tue, 11 Dec 2007 15:38:59 -0800
>   Pavlin Radoslavov <pavlin at icir.org> wrote:
> > If the problem is what I think it is, this might require 
> >some time
> > to investigate it, so probably I won't be able to look 
> >into the
> > details of the problem until next week or so.
> > 
> > In the mean time I have few questions: 
> > 
> > * Can you confirm that route 224.0.0.0/4 was actually 
> >added to the
> >  kernel. I don't remember whether adding such multicast 
> >routes will
> >  actually work, but if it didn't work then you should 
> >add it by
> >  hand before starting XORP.
> > 
> > * Is the error you are seeing same as before:
> >  "Cannot find outgoing port number"
> > 
> > * What happens if you use unicast static routes (only) 
> >instead of
> >  RIP. Do you see same "Cannot find outgoing port number" 
> >error?
> > 
> > Thanks,
> > Pavlin
> > 
> > 
> > Robert Joseph Suk <rsuk at ucsc.edu> wrote:
> > 
> >> I upgraded to the CVS versions of both xorp(1.52) and 
> >> click(1.6.0) and it solved the problem of using the 
> >>click 
> >> forwarding path.  My hardware is set up as follows:
> >> 
> >> PC2--PC3--PC4
> >> 
> >> PC2: xl0: 10.0.1.22, xl1: 10.0.2.22
> >> PC3: xl0: 10.0.2.33, xl1: 10.0.3.33
> >> PC4: xl0: 10.0.3.44, xl1: 10.0.4.44
> >> 
> >> The click forwarding path works fine, and RIP runs just 
> >> fine in userspace, but XORP routes are not being added 
> >>to 
> >> click.
> >> 
> >> Below is my xorp config:
> >> PC3# cat xorpclick_pc3.boot
> >> 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: false
> >>                  duplicate-routes-to-kernel: true
> >> 
> >>                  kernel-click{
> >>                          disable: true
> >>                  }
> >>                  user-click{
> >>                          disable: false
> >>                          command-file: 
> >> "/usr/local/bin/click"
> >>                          command-extra-arguments: "-R"
> >>                          command-execute-on-startup: 
> >>true
> >>                          startup-config-file: 
> >> "/usr/local/xorp/iprouter_auto.click"
> >>                          user-click-config-generator-file: 
> >> "/usr/local/fea/xorp_fea_click_config_generator"
> >>                  }
> >>          }
> >> } /* </fea> */
> >> policy {
> >>          /*Describe connected routes for 
> >>redistribution*/
> >>          policy-statement connected {
> >>                  term export {
> >>                          from {
> >>                                  protocol: "connected"
> >>                          }
> >>                  }
> >>          }
> >> }
> >> 
> >> protocols {
> >>          static{
> >>                  route 224.0.0.0/4{
> >>                          next-hop: 10.0.2.22
> >>                          metric: 1
> >>                  }
> >>          }
> >>          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>*/
> >> 
> >> 
> >> 
> >> And here is my click_config_generator:
> >> *note, this is the same click config as 
> >> iprouter_auto.click in my xorp config.
> >> 
> >> 
> >> PC3# cat xorp_fea_click_config_generator
> >> printf("
> >> // Generated by make-ip-conf.pl
> >> // xl0 10.0.2.33 00:01:02:42:20:EC
> >> // xl1 10.0.3.33 00:01:02:3E:4E:3A
> >> 
> >> // Shared IP input path and routing table
> >> ip :: Strip(14)
> >>      -> good_header :: CheckIPHeader(INTERFACES 
> >> 10.0.2.33/255.255.255.0 10.0.3.33/255.255.255.0)
> >> good_header[0] -> _xorp_rt4 :: LinearIPLookup(
> >>          10.0.2.33/32 2,
> >>          10.0.2.255/32 2,
> >>          10.0.2.0/32 2,
> >>          10.0.3.33/32 2,
> >>          10.0.3.255/32 2,
> >>          10.0.3.0/32 2,  //above are local interfaces. 
> >>  deliver locally
> >>          10.0.2.0/255.255.255.0 0,       //xl0
> >>          10.0.3.0/255.255.255.0 1,       //xl1
> >>          255.255.255.255/32 0.0.0.0 2,   //broadcasts 
> >>are 
> >> local and get dropped
> >>          0.0.0.0/32 2,
> >>          0.0.0.0/0.0.0.0 10.0.2.22 0);
> >> 
> >> // ARP responses are copied to each ARPQuerier and the 
> >> host.
> >> arpt :: Tee(3);
> >> 
> >> // Input and output paths for xl0
> >> c0 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 
> >> 12/0800, -);
> >> FromDevice(xl0) -> c0;
> >> out0 :: Queue(200) -> todevice0 :: ToDevice(xl0);
> >> c0[0] -> ar0 :: ARPResponder(10.0.2.33 
> >>00:01:02:42:20:EC) 
> >> -> out0;
> >> arpq0 :: ARPQuerier(10.0.2.33, 00:01:02:42:20:EC) -> 
> >> newOUT::Tee(2);
> >> newOUT[0]->out0;
> >> c0[1] -> arpt;
> >> arpt[0] -> [1]arpq0;
> >> c0[2] -> Paint(1) -> ip;
> >> c0[3] -> Print("xl0 non-IP") -> Discard;
> >> 
> >> // Input and output paths for xl1
> >> c1 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 
> >> 12/0800, -);
> >> FromDevice(xl1) -> c1;
> >> out1 :: Queue(200) -> todevice1 :: ToDevice(xl1);
> >> c1[0] -> ar1 :: ARPResponder(10.0.3.33 
> >>00:01:02:3E:4E:3A) 
> >> -> out1;
> >> arpq1 :: ARPQuerier(10.0.3.33, 00:01:02:3E:4E:3A) -> 
> >>out1;
> >> newOUT[1]->out1;
> >> c1[1] -> arpt;
> >> arpt[1] -> [1]arpq1;
> >> c1[2] -> Paint(2) -> ip;
> >> c1[3] -> Print("xl1 non-IP") -> Discard;
> >> 
> >> // Local delivery
> >> toh :: Print(toh) -> Discard;
> >> arpt[2] -> toh;
> >> _xorp_rt4[2] -> IPReassembler -> ping_ipc :: 
> >> IPClassifier(icmp type echo, -);
> >> ping_ipc[0] -> ICMPPingResponder -> [0]_xorp_rt4;
> >> ping_ipc[1] -> EtherEncap(0x0800, 1:1:1:1:1:1, 
> >> 2:2:2:2:2:2) -> toh;
> >> 
> >> // Forwarding path for xl0
> >> _xorp_rt4[0] -> DropBroadcasts
> >>      -> cp0 :: PaintTee(1)
> >>      -> gio0 :: IPGWOptions(10.0.2.33)
> >>      -> FixIPSrc(10.0.2.33)
> >>      -> dt0 :: DecIPTTL
> >>      -> fr0 :: IPFragmenter(1500)
> >>      -> [0]arpq0;
> >> dt0[1] -> ICMPError(10.0.2.33, timeexceeded) -> 
> >>_xorp_rt4;
> >> fr0[1] -> ICMPError(10.0.2.33, unreachable, needfrag) -> 
> >> _xorp_rt4;
> >> gio0[1] -> ICMPError(10.0.2.33, parameterproblem) -> 
> >> _xorp_rt4;
> >> cp0[1] -> ICMPError(10.0.2.33, redirect, host) -> 
> >> _xorp_rt4;
> >> 
> >> // Forwarding path for xl1
> >> _xorp_rt4[1] -> DropBroadcasts
> >>      -> cp1 :: PaintTee(2)
> >>      -> gio1 :: IPGWOptions(10.0.3.33)
> >>      -> FixIPSrc(10.0.3.33)
> >>      -> dt1 :: DecIPTTL
> >>      -> fr1 :: IPFragmenter(1500)
> >>      -> [0]arpq1;
> >> dt1[1] -> ICMPError(10.0.3.33, timeexceeded) -> 
> >>_xorp_rt4;
> >> fr1[1] -> ICMPError(10.0.3.33, unreachable, needfrag) -> 
> >> _xorp_rt4;
> >> gio1[1] -> ICMPError(10.0.3.33, parameterproblem) -> 
> >> _xorp_rt4;
> >> cp1[1] -> ICMPError(10.0.3.33, redirect, host) -> 
> >> _xorp_rt4;
> >> ");
> >> 
> >> 
> >> 
> >> On Thu, 06 Dec 2007 18:01:55 -0800
> >>   Pavlin Radoslavov <pavlin at icir.org> wrote:
> >> > Robert Joseph Suk <rsuk at ucsc.edu> wrote:
> >> > 
> >> >> Thanks for your reply, Pavlin.
> >> >> I'm not exactly sure the best way to get the 
> >> >> xorp_fea_click_config_generator to unconditionally 
> >> >>return 
> >> >> my static config, but I replaced the config_generator 
> >> >> script with my config file, inside a printf("") and 
> >>it 
> >> >> seems to work.  I also made sure to rename my 
> >> >> LinearIPlookup from "rt" to "_xorp_rt4" so xorp could 
> >> >> handle it.  The router still receives updates from 
> >> > 
> >> > Yes, this hack should do it.
> >> > 
> >> >> neighboring routers and updates the RIB, but now xorp 
> >> >> throws an error:
> >> >> 
> >> >> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +71 
> >> >> fti_transaction.cc operation_result ] FTI transaction 
> >> >> commit failed on AddE
> >> >> ntry4: net = 10.0.0.0/24 nexthop = 10.0.2.22 ifname = 
> >> >>xl0 
> >> >> vifname = xl0 metric = 2 admin_distance = 120 
> >>xorp_route 
> >> >>= 
> >> >> true is_d
> >> >> eleted = false is_unresolved = false 
> >>is_connected_route 
> >> >>= 
> >> >> false
> >> >> [ 2007/12/06 17:28:07  ERROR xorp_fea:1612 FEA +301 
> >> >> fticonfig_entry_set_click.cc add_entry ] Cannot find 
> >> >> outgoing port number
> >> >> for the Click forwarding table element to add entry 
> >>net 
> >> >>= 
> >> >> 10.0.1.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname 
> >>= 
> >> >>xl0 
> >> >> metric =
> >> >> 1 admin_distance = 120 xorp_route = true is_deleted = 
> >> >> false is_unresolved = false is_connected_route = 
> >>false
> >> > 
> >> > There seems to be some error with adding the routes to 
> >> >Click.
> >> > Could you update to the latest XORP from CVS.
> >> > The update might not fix the problem, but will make it 
> >> >easier to
> >> > debug it:
> >> > 
> >> > http://www.xorp.org/cvs.html
> >> > 
> >> > Please send me your latest XORP configuration as well 
> >>as 
> >> >your
> >> > hacked xorp_fea_click_config_generator.
> >> > Also, please tell me the Click version you are using.
> >> > 
> >> > Thanks,
> >> > Pavlin
> >> > 
> >> >> 
> >> >> and click still won't function.
> >> >> When I run "click myconfig.click", pings across the 
> >> >>router 
> >> >> work fine, while pinging the router directly 
> >>generates 
> >> >> Duplicate replies (one from the kernel, and one from 
> >> >> click).
> >> >> As a debug, in my click config I added a Tee to the 
> >> >>output 
> >> >> of xl0 and copied all click-generated responses out 
> >>to 
> >> >>The 
> >> >> other interface, xl1. Now when I ping the router, I 
> >>can 
> >> >> see the extra traffic on a TCPdump of xl1.  When I 
> >>run 
> >> >> xorp with my config and ping the router, I only get 
> >>one 
> >> >> response, and nothing on xl1, leading me to believe 
> >>that 
> >> >> either my click config isn't running, or it just isnt 
> >> >> getting any traffic.
> >> >> 
> >> >> 
> >> >> On Thu, 06 Dec 2007 12:39:47 -0800
> >> >>   Pavlin Radoslavov <pavlin at icir.org> wrote:
> >> >> >>   I'm trying to set up a xorp/click configuration 
> >> >>which 
> >> >> >> runs RIP. I have RIP working with xorp, but when I 
> >> >> >>enable 
> >> >> >> the user click forwarding path, I get strange 
> >> >>behavior. 
> >> >> >>If 
> >> >> >> I 'duplicate-routes-to-kernel' everything works 
> >>fine. 
> >> >> >> However, when I don't duplicate routes-to-kernel, 
> >>the 
> >> >> >> routes still show up in xorpsh (show route table 
> >>ipv4 
> >> >> >> unicast rip/final), but if I ping any of those 
> >> >> >>addresses, 
> >> >> >> I get 'no route to host'. Xorp also cannot send 
> >>RIP 
> >> >> >> updates, getting the send_from_multicast_if 
> >>failed.
> >> >> > 
> >> >> >First the (hopefully) easy part:
> >> >> > As you know already, FreeBSD requires to have a 
> >> >>matching 
> >> >> >route
> >> >> > (e.g., 0.0.0.0/0) in the unicast forwarding table 
> >>in 
> >> >>the 
> >> >> >kernel to
> >> >> > be able to originate multicast packets. If you use 
> >> >>XORP 
> >> >> >to configure
> >> >> > the 0.0.0.0/0 static route, and if 
> >> >> >"duplicate-routes-to-kernel" is
> >> >> > disabled, this route won't reach the kernel.
> >> >> > Hence, to get around this problem you should add 
> >> >> >0.0.0.0/0 to the
> >> >> > kernel by hand before starting XORP.
> >> >> > 
> >> >> >> The reason I want to turn 
> >> >>'duplicate-routes-to-kernel' 
> >> >> >> off, is so that I can check that the click 
> >>forwarding 
> >> >> >>path 
> >> >> >> is working.
> >> >> >> 
> >> >> >> I already added a static route 0.0.0.0/0 to an 
> >> >>attached 
> >> >> >> interface, and put "multicast_host="YES"" in my 
> >> >>rc.conf.
> >> >> >> I'm running BSD6.2, and my xorp config is below. 
> >>The 
> >> >> >>click 
> >> >> >> config I'm running is simply the one generated by 
> >> >> >> 'make-ip-conf.pl' which is a basic IP router
> >> >> >> Any ideas why xorp sees the routes in xorpsh but 
> >> >>can't 
> >> >> >>use 
> >> >> >> them?
> >> >> > 
> >> >> > If you are to use your own static config with 
> >> >> >make-ip-conf.pl, it
> >> >> > will be safer if you also modify the sample
> >> >> > "/usr/local/fea/xorp_fea_click_config_generator" 
> >> >> >generator to
> >> >> > unconditionally return that configuration. FYI, the 
> >> >> >config generator
> >> >> > is automatically called by XORP whenenever 
> >>something 
> >> >>in 
> >> >> >the
> >> >> > interface configuration changes, so on startup it 
> >> >>might 
> >> >> >actually be
> >> >> > overwriting your own static config.
> >> >> > 
> >> >> > Once you eliminate the config generation factor, 
> >>then 
> >> >> >you need to
> >> >> > investigate whether userland Click itself is 
> >>working 
> >> >>as
> >> >> > expected. For that purpose I'd recommend to start 
> >> >> >userland Click by
> >> >> > hand (without XORP), and then manually configure it 
> >> >>with 
> >> >> >your static
> >> >> > config (including the routes that should be 
> >>generated 
> >> >>by 
> >> >> >RIP).
> >> >> > Then do the ping test to see whether userland Click 
> >>on 
> >> >> >its own is
> >> >> > fine.
> >> >> > One thing to have in mind is that the ping packets 
> >> >> >originated on the
> >> >> > router running Click might not actually be 
> >>processed 
> >> >>by 
> >> >> >Click: such
> >> >> > packets will lookup the unicast forwarding table in 
> >> >>the 
> >> >> >kernel, and
> >> >> > therefore fail. Hence, you might want to run ping 
> >>on a 
> >> >> >machine
> >> >> > directly connected to the router running Click.
> >> >> > 
> >> >> > Hopefully the above tests will narrow the problem.
> >> >> > 
> >> >> > Regards,
> >> >> > Pavlin
> >> >> > 
> >> >> > P.S. In your config you don't need the 
> >>plumbing/mfea4 
> >> >> >and mfea6
> >> >> > sections.
> >> >> > 
> >> >> > 
> >> >> >> 
> >> >> >> 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: true
> >> >> >>          }
> >> >> >> 
> >> >> >>          unicast-forwarding6 {
> >> >> >>                  disable: true
> >> >> >>          }
> >> >> >> 
> >> >> >>          click {
> >> >> >>                  disable: false  /*run 
> >>autogenerated 
> >> >> >> config from /conf/make-ip-conf.pl*/
> >> >> >>                  duplicate-routes-to-kernel: true
> >> >> >> 
> >> >> >>                  kernel-click{
> >> >> >>                          disable: true
> >> >> >>                  }
> >> >> >> 
> >> >> >>                  user-click{
> >> >> >>                          disable: false
> >> >> >>                          command-file: 
> >> >> >> "/usr/local/bin/click"
> >> >> >>                          command-extra-arguments: 
> >> >>"-R"
> >> >> >> 
> >>                         command-execute-on-startup: 
> >> >> >>true
> >> >> >>                          startup-config-file: 
> >> >> >> "/usr/local/xorp/iprouter_auto.click"
> >> >> >> 
> >> >> 
> >>                        user-click-config-generator-file: 
> >> >> >> "/usr/local/fea/xorp_fea_click_config_generator"
> >> >> >>                  }
> >> >> >>          }
> >> >> >> } /* </fea> */
> >> >> >> plumbing{
> >> >> >>          mfea4 {
> >> >> >>                  disable: true
> >> >> >>          }
> >> >> >>          mfea6{
> >> >> >>                  disable: true
> >> >> >>          }
> >> >> >> }
> >> >> >> policy {
> >> >> >>          /*Describe connected routes for 
> >> >> >>redistribution*/
> >> >> >>          policy-statement connected {
> >> >> >>                  term export {
> >> >> >>                          from {
> >> >> >>                                  protocol: 
> >> >>"connected"
> >> >> >>                          }
> >> >> >>                  }
> >> >> >>          }
> >> >> >> }
> >> >> >> 
> >> >> >> protocols {
> >> >> >>          static{
> >> >> >>                  route 0.0.0.0/0{
> >> >> >>                          next-hop: 10.0.2.22
> >> >> >>                          metric: 1
> >> >> >>                  }
> >> >> >>          }
> >> >> >>          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>*/
> >> >> >> 
> >> >> >> 
> >> >> >> 
> >> >> >> -Robbie
> >> >> >> 
> >> >> >> _______________________________________________
> >> >> >> Xorp-users mailing list
> >> >> >> Xorp-users at xorp.org
> >> >> >> 
> >> >>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> >> >> 
> >> >> -Robbie
> >> >> 
> >> >> _______________________________________________
> >> >> Xorp-users mailing list
> >> >> Xorp-users at xorp.org
> >> >> 
> >>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> >> 
> >> -Robbie
> >> 
> >> _______________________________________________
> >> Xorp-users mailing list
> >> Xorp-users at xorp.org
> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> 
> -Robbie
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From reach_dinesh at hotmail.com  Tue Dec 11 18:51:04 2007
From: reach_dinesh at hotmail.com (Dinesh Kumar)
Date: Wed, 12 Dec 2007 10:51:04 +0800
Subject: [Xorp-users] (no subject)
Message-ID: <BLU104-W35022CB20F79A9CBEA64E7F0650@phx.gbl>


Hello Xorp users,

I get these following statements when I try to start XORP. I think the routing process has failed to start. I have attached my config.boot with the mail. Please let me know if I am missing anything in my config file.

Thanks,
Dinesh

linux-xorp:/xorp-1.4/rtrmgr # ./xorp_rtrmgr
[ 2007/12/11 12:27:33  INFO xorp_rtrmgr:30838 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, policy, static_routes, bgp, ospf4
[ 2007/12/11 12:27:33  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea)
[ 2007/12/11 12:27:34  ERROR xorp_fea:30839 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol
[ 2007/12/11 12:27:34  ERROR xorp_fea:30839 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol
[ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] MFEA enabled
[ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI enabled
[ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI started
[ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] MFEA enabled
[ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI enabled
[ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI started
[ 2007/12/11 12:27:35  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea)
[ 2007/12/11 12:27:41  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: rib (rib/xorp_rib)
[ 2007/12/11 12:27:43  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: policy (policy/xorp_policy)
[ 2007/12/11 12:27:45  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: static_routes (static_routes/xorp_static_routes)
[ 2007/12/11 12:27:47  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: bgp (bgp/xorp_bgp)
[ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 172.16.1.2, my_port = 0): Cannot assign requested address
[ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 172.16.1.2, my_port = 179): Cannot assign requested address
[ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 BGP +65 socket.cc create_listener ] comm_bind_tcp failed
[ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 10.1.0.2, my_port = 0): Cannot assign requested address
[ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 10.1.0.2, my_port = 179): Cannot assign requested address
[ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 BGP +65 socket.cc create_listener ] comm_bind_tcp failed
[ 2007/12/11 12:27:49  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2)
[ 2007/12/11 12:27:52  WARNING xorp_ospfv2:30850 XrlOspfv2Target +522 ospfv2_base.cc handle_ospfv2_0_1_create_peer ] Handling method for ospfv2/0.1/create_peer failed: XrlCmdError 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for eth1/eth1/10.2.0.1
[ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +675 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for eth1/eth1/10.2.0.1
[ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +251 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for eth1/eth1/10.2.0.1
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +2228 task.cc run_task ] No more tasks to run
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: bgp
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: bgp
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: fea
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: interfaces
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: interfaces
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: ospf4
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: ospf4
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: policy
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: policy
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: rib
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: rib
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: static_routes
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: static_routes
[ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/fea/xorp_fea": terminated with signal 15.
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: interfaces
[ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/rib/xorp_rib": terminated with signal 15.
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: rib
[ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/policy/xorp_policy": terminated with signal 15.
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: policy
[ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/bgp/xorp_bgp": terminated with signal 15.
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: bgp
[ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/static_routes/xorp_static_routes": terminated with signal 15.
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: static_routes
[ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/ospf/xorp_ospfv2": terminated with signal 15.
[ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: ospf4
linux-xorp:/xorp-1.4/rtrmgr #

_________________________________________________________________
Publish your photos to your Space easily with Photo Gallery.
http://www.get.live.com/wl/all
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.boot
Type: application/octet-stream
Size: 1816 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071212/68f5d7f7/attachment.obj 

From pavlin at icir.org  Tue Dec 11 19:48:31 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 11 Dec 2007 19:48:31 -0800
Subject: [Xorp-users] (no subject)
In-Reply-To: Message from Dinesh Kumar <reach_dinesh@hotmail.com> of "Wed,
	12 Dec 2007 10:51:04 +0800."
	<BLU104-W35022CB20F79A9CBEA64E7F0650@phx.gbl> 
Message-ID: <200712120348.lBC3mVPZ009511@possum.icir.org>

Dinesh Kumar <reach_dinesh at hotmail.com> wrote:

> 
> Hello Xorp users,
> 
> I get these following statements when I try to start XORP. I think the routing process has failed to start. I have attached my config.boot with the mail. Please let me know if I am missing anything in my config file.

In your config file you are missing the configuration for the local
IP addresses you are using inside BGP and OSPF: 10.2.0.1, 10.1.0.2,
and 172.16.1.2 .
Note that your interfaces section contains configuration only for
eth0 with IP address of 10.0.0.2.

Hope that helps,
Pavlin

> Thanks,
> Dinesh
> 
> linux-xorp:/xorp-1.4/rtrmgr # ./xorp_rtrmgr
> [ 2007/12/11 12:27:33  INFO xorp_rtrmgr:30838 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, policy, static_routes, bgp, ospf4
> [ 2007/12/11 12:27:33  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea)
> [ 2007/12/11 12:27:34  ERROR xorp_fea:30839 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol
> [ 2007/12/11 12:27:34  ERROR xorp_fea:30839 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol
> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] MFEA enabled
> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI enabled
> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI started
> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] MFEA enabled
> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI enabled
> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI started
> [ 2007/12/11 12:27:35  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea)
> [ 2007/12/11 12:27:41  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: rib (rib/xorp_rib)
> [ 2007/12/11 12:27:43  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: policy (policy/xorp_policy)
> [ 2007/12/11 12:27:45  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: static_routes (static_routes/xorp_static_routes)
> [ 2007/12/11 12:27:47  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: bgp (bgp/xorp_bgp)
> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 172.16.1.2, my_port = 0): Cannot assign requested address
> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 172.16.1.2, my_port = 179): Cannot assign requested address
> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 BGP +65 socket.cc create_listener ] comm_bind_tcp failed
> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 10.1.0.2, my_port = 0): Cannot assign requested address
> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 10.1.0.2, my_port = 179): Cannot assign requested address
> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 BGP +65 socket.cc create_listener ] comm_bind_tcp failed
> [ 2007/12/11 12:27:49  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2)
> [ 2007/12/11 12:27:52  WARNING xorp_ospfv2:30850 XrlOspfv2Target +522 ospfv2_base.cc handle_ospfv2_0_1_create_peer ] Handling method for ospfv2/0.1/create_peer failed: XrlCmdError 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for eth1/eth1/10.2.0.1
> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +675 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for eth1/eth1/10.2.0.1
> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +251 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for eth1/eth1/10.2.0.1
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +2228 task.cc run_task ] No more tasks to run
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: bgp
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: bgp
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: fea
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: interfaces
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: interfaces
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: ospf4
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: ospf4
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: policy
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: policy
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: rib
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: rib
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: static_routes
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: static_routes
> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/fea/xorp_fea": terminated with signal 15.
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: interfaces
> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/rib/xorp_rib": terminated with signal 15.
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: rib
> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/policy/xorp_policy": terminated with signal 15.
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: policy
> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/bgp/xorp_bgp": terminated with signal 15.
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: bgp
> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/static_routes/xorp_static_routes": terminated with signal 15.
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: static_routes
> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/ospf/xorp_ospfv2": terminated with signal 15.
> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: ospf4
> linux-xorp:/xorp-1.4/rtrmgr #
> 
> _________________________________________________________________
> Publish your photos to your Space easily with Photo Gallery.
> http://www.get.live.com/wl/all_______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From reach_dinesh at hotmail.com  Tue Dec 11 23:28:44 2007
From: reach_dinesh at hotmail.com (Dinesh Kumar)
Date: Wed, 12 Dec 2007 15:28:44 +0800
Subject: [Xorp-users] Configure mode
In-Reply-To: <200712120348.lBC3mVPZ009511@possum.icir.org>
References: Message from Dinesh Kumar <reach_dinesh@hotmail.com>    of 
	<200712120348.lBC3mVPZ009511@possum.icir.org>
Message-ID: <BLU104-W27C3A45A88B689B70712BF0650@phx.gbl>


Thanks Pavlin.  xorp processes are running now. But I am not able to go into configure mode. 

root at linux-xorp> configure
ERROR: You do not have permission for this operation.
root at linux-xorp> 

I checked if the user 'root' is present in  group 'xorp' 

linux-xorp:~ # useradd -G xorp root
useradd: Account `root' already exists.
linux-xorp:~ #      

Not sure what is the error :(

Thanks,
Dinesh
----------------------------------------
> To: reach_dinesh at hotmail.com
> CC: xorp-users at xorp.org
> Subject: Re: [Xorp-users] (no subject) 
> Date: Tue, 11 Dec 2007 19:48:31 -0800
> From: pavlin at icir.org
> 
> Dinesh Kumar  wrote:
> 
>> 
>> Hello Xorp users,
>> 
>> I get these following statements when I try to start XORP. I think the routing process has failed to start. I have attached my config.boot with the mail. Please let me know if I am missing anything in my config file.
> 
> In your config file you are missing the configuration for the local
> IP addresses you are using inside BGP and OSPF: 10.2.0.1, 10.1.0.2,
> and 172.16.1.2 .
> Note that your interfaces section contains configuration only for
> eth0 with IP address of 10.0.0.2.
> 
> Hope that helps,
> Pavlin
> 
>> Thanks,
>> Dinesh
>> 
>> linux-xorp:/xorp-1.4/rtrmgr # ./xorp_rtrmgr
>> [ 2007/12/11 12:27:33  INFO xorp_rtrmgr:30838 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, policy, static_routes, bgp, ospf4
>> [ 2007/12/11 12:27:33  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea)
>> [ 2007/12/11 12:27:34  ERROR xorp_fea:30839 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol
>> [ 2007/12/11 12:27:34  ERROR xorp_fea:30839 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol
>> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] MFEA enabled
>> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI enabled
>> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI started
>> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] MFEA enabled
>> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI enabled
>> [ 2007/12/11 12:27:35 INFO xorp_fea MFEA ] CLI started
>> [ 2007/12/11 12:27:35  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea)
>> [ 2007/12/11 12:27:41  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: rib (rib/xorp_rib)
>> [ 2007/12/11 12:27:43  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: policy (policy/xorp_policy)
>> [ 2007/12/11 12:27:45  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: static_routes (static_routes/xorp_static_routes)
>> [ 2007/12/11 12:27:47  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: bgp (bgp/xorp_bgp)
>> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 172.16.1.2, my_port = 0): Cannot assign requested address
>> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 172.16.1.2, my_port = 179): Cannot assign requested address
>> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 BGP +65 socket.cc create_listener ] comm_bind_tcp failed
>> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 10.1.0.2, my_port = 0): Cannot assign requested address
>> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 10.1.0.2, my_port = 179): Cannot assign requested address
>> [ 2007/12/11 12:27:49  ERROR xorp_bgp:30849 BGP +65 socket.cc create_listener ] comm_bind_tcp failed
>> [ 2007/12/11 12:27:49  INFO xorp_rtrmgr:30838 RTRMGR +96 module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2)
>> [ 2007/12/11 12:27:52  WARNING xorp_ospfv2:30850 XrlOspfv2Target +522 ospfv2_base.cc handle_ospfv2_0_1_create_peer ] Handling method for ospfv2/0.1/create_peer failed: XrlCmdError 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for eth1/eth1/10.2.0.1
>> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +675 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for eth1/eth1/10.2.0.1
>> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +251 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for eth1/eth1/10.2.0.1
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +2228 task.cc run_task ] No more tasks to run
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: bgp
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: bgp
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: fea
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: interfaces
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: interfaces
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: ospf4
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: ospf4
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: policy
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: policy
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: rib
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: rib
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +171 module_manager.cc terminate ] Terminating module: static_routes
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +194 module_manager.cc terminate ] Killing module: static_routes
>> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/fea/xorp_fea": terminated with signal 15.
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: interfaces
>> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/rib/xorp_rib": terminated with signal 15.
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: rib
>> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/policy/xorp_policy": terminated with signal 15.
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: policy
>> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/bgp/xorp_bgp": terminated with signal 15.
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: bgp
>> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/static_routes/xorp_static_routes": terminated with signal 15.
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: static_routes
>> [ 2007/12/11 12:27:52  ERROR xorp_rtrmgr:30838 RTRMGR +747 module_manager.cc done_cb ] Command "/xorp-1.4/ospf/xorp_ospfv2": terminated with signal 15.
>> [ 2007/12/11 12:27:52  INFO xorp_rtrmgr:30838 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: ospf4
>> linux-xorp:/xorp-1.4/rtrmgr #
>> 
>> _________________________________________________________________
>> Publish your photos to your Space easily with Photo Gallery.
>> http://www.get.live.com/wl/all_______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

_________________________________________________________________
Edit your photos like a pro with Photo Gallery.
http://www.get.live.com/wl/all


From pavlin at icir.org  Wed Dec 12 00:00:51 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 12 Dec 2007 00:00:51 -0800
Subject: [Xorp-users] Configure mode
In-Reply-To: Message from Dinesh Kumar <reach_dinesh@hotmail.com> of "Wed,
	12 Dec 2007 15:28:44 +0800."
	<BLU104-W27C3A45A88B689B70712BF0650@phx.gbl> 
Message-ID: <200712120800.lBC80peN048203@possum.icir.org>

Dinesh Kumar <reach_dinesh at hotmail.com> wrote:

> 
> Thanks Pavlin.  xorp processes are running now. But I am not able to go into configure mode. 
> 
> root at linux-xorp> configure
> ERROR: You do not have permission for this operation.
> root at linux-xorp> 
> 
> I checked if the user 'root' is present in  group 'xorp' 
> 
> linux-xorp:~ # useradd -G xorp root
> useradd: Account `root' already exists.
> linux-xorp:~ #      
> 
> Not sure what is the error :(

The simplest suggestion that comes to mind is to exit and login
again. This might be needed if, for example, you just
created the xorp group. After the re-login run the "groups" command
to see the list of groups the user belongs to.

Pavlin






From reach_dinesh at hotmail.com  Wed Dec 12 21:14:18 2007
From: reach_dinesh at hotmail.com (Dinesh Kumar)
Date: Thu, 13 Dec 2007 13:14:18 +0800
Subject: [Xorp-users] Not able to go into 'configure' mode
Message-ID: <BLU104-W26F84E4E561A4BB394D8EFF0660@phx.gbl>


Dear Pavlin, Thanks a lot for your prompt reply.

I did an exit and logged in again.  I am still not able to go into config mode.

root at linux-xorp> configure
ERROR: You do not have permission for this operation.
root at linux-xorp>

I got the following comment in the shell window running 'xorp_rtrmgr' 

[ 2007/12/13 13:05:19  WARNING xorp_rtrmgr:24886 XrlRtrmgrTarget +338 rtrmgr_base.cc handle_rtrmgr_0_1_enter_config_mode ] Handling method for rtrmgr/0.1/enter_config_mode failed: XrlCmdError 102 Command failed You do not have permission for this operation

It says XrlCmdError 102. Does it mean anything?

Kind Regards,
Dinesh

----------------------------------------
> To: reach_dinesh at hotmail.com
> CC: xorp-users at xorp.org; pavlin at icir.org
> Subject: Re: [Xorp-users] Configure mode 
> Date: Wed, 12 Dec 2007 00:00:51 -0800
> From: pavlin at icir.org
> 
> Dinesh Kumar  wrote:
> 
>> 
>> Thanks Pavlin.  xorp processes are running now. But I am not able to go into configure mode. 
>> 
>> root at linux-xorp> configure
>> ERROR: You do not have permission for this operation.
>> root at linux-xorp> 
>> 
>> I checked if the user 'root' is present in  group 'xorp' 
>> 
>> linux-xorp:~ # useradd -G xorp root
>> useradd: Account `root' already exists.
>> linux-xorp:~ #      
>> 
>> Not sure what is the error :(
> 
> The simplest suggestion that comes to mind is to exit and login
> again. This might be needed if, for example, you just
> created the xorp group. After the re-login run the "groups" command
> to see the list of groups the user belongs to.
> 
> Pavlin
> 
> 
> 
> 
> 

_________________________________________________________________
Publish your photos to your Space easily with Photo Gallery.
http://www.get.live.com/wl/all


From pavlin at icir.org  Wed Dec 12 21:47:15 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 12 Dec 2007 21:47:15 -0800
Subject: [Xorp-users] Not able to go into 'configure' mode
In-Reply-To: Message from Dinesh Kumar <reach_dinesh@hotmail.com> of "Thu,
	13 Dec 2007 13:14:18 +0800."
	<BLU104-W26F84E4E561A4BB394D8EFF0660@phx.gbl> 
Message-ID: <200712130547.lBD5lFdc066043@possum.icir.org>

Dinesh Kumar <reach_dinesh at hotmail.com> wrote:

> 
> Dear Pavlin, Thanks a lot for your prompt reply.
> 
> I did an exit and logged in again.  I am still not able to go into config mode.
> 
> root at linux-xorp> configure
> ERROR: You do not have permission for this operation.
> root at linux-xorp>

What is the output of the "groups" UNIX command before starting
xorpsh?

Pavlin

> I got the following comment in the shell window running 'xorp_rtrmgr' 
> 
> [ 2007/12/13 13:05:19  WARNING xorp_rtrmgr:24886 XrlRtrmgrTarget +338 rtrmgr_base.cc handle_rtrmgr_0_1_enter_config_mode ] Handling method for rtrmgr/0.1/enter_config_mode failed: XrlCmdError 102 Command failed You do not have permission for this operation
> 
> It says XrlCmdError 102. Does it mean anything?
> 
> Kind Regards,
> Dinesh
> 
> ----------------------------------------
> > To: reach_dinesh at hotmail.com
> > CC: xorp-users at xorp.org; pavlin at icir.org
> > Subject: Re: [Xorp-users] Configure mode 
> > Date: Wed, 12 Dec 2007 00:00:51 -0800
> > From: pavlin at icir.org
> > 
> > Dinesh Kumar  wrote:
> > 
> >> 
> >> Thanks Pavlin.  xorp processes are running now. But I am not able to go into configure mode. 
> >> 
> >> root at linux-xorp> configure
> >> ERROR: You do not have permission for this operation.
> >> root at linux-xorp> 
> >> 
> >> I checked if the user 'root' is present in  group 'xorp' 
> >> 
> >> linux-xorp:~ # useradd -G xorp root
> >> useradd: Account `root' already exists.
> >> linux-xorp:~ #      
> >> 
> >> Not sure what is the error :(
> > 
> > The simplest suggestion that comes to mind is to exit and login
> > again. This might be needed if, for example, you just
> > created the xorp group. After the re-login run the "groups" command
> > to see the list of groups the user belongs to.
> > 
> > Pavlin
> > 
> > 
> > 
> > 
> > 
> 
> _________________________________________________________________
> Publish your photos to your Space easily with Photo Gallery.
> http://www.get.live.com/wl/all
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From reach_dinesh at hotmail.com  Wed Dec 12 23:21:15 2007
From: reach_dinesh at hotmail.com (Dinesh Kumar)
Date: Thu, 13 Dec 2007 15:21:15 +0800
Subject: [Xorp-users] Not able to go into 'configure' mode
In-Reply-To: <200712130547.lBD5lFdc066043@possum.icir.org>
References: Message from Dinesh Kumar <reach_dinesh@hotmail.com>    of 
	<200712130547.lBD5lFdc066043@possum.icir.org>
Message-ID: <BLU104-W31A19A1A2BE4B5B56D4BE9F0660@phx.gbl>


The following is the output before running xorpsh:

linux-xorp:~ # groups
root
linux-xorp:~ #

Thanks,
Dinesh
----------------------------------------
> To: reach_dinesh at hotmail.com
> CC: xorp-users at xorp.org
> Subject: Re: [Xorp-users] Not able to go into 'configure' mode 
> Date: Wed, 12 Dec 2007 21:47:15 -0800
> From: pavlin at icir.org
> 
> Dinesh Kumar  wrote:
> 
>> 
>> Dear Pavlin, Thanks a lot for your prompt reply.
>> 
>> I did an exit and logged in again.  I am still not able to go into config mode.
>> 
>> root at linux-xorp> configure
>> ERROR: You do not have permission for this operation.
>> root at linux-xorp>
> 
> What is the output of the "groups" UNIX command before starting
> xorpsh?
> 
> Pavlin
> 
>> I got the following comment in the shell window running 'xorp_rtrmgr' 
>> 
>> [ 2007/12/13 13:05:19  WARNING xorp_rtrmgr:24886 XrlRtrmgrTarget +338 rtrmgr_base.cc handle_rtrmgr_0_1_enter_config_mode ] Handling method for rtrmgr/0.1/enter_config_mode failed: XrlCmdError 102 Command failed You do not have permission for this operation
>> 
>> It says XrlCmdError 102. Does it mean anything?
>> 
>> Kind Regards,
>> Dinesh
>> 
>> ----------------------------------------
>>> To: reach_dinesh at hotmail.com
>>> CC: xorp-users at xorp.org; pavlin at icir.org
>>> Subject: Re: [Xorp-users] Configure mode 
>>> Date: Wed, 12 Dec 2007 00:00:51 -0800
>>> From: pavlin at icir.org
>>> 
>>> Dinesh Kumar  wrote:
>>> 
>>>> 
>>>> Thanks Pavlin.  xorp processes are running now. But I am not able to go into configure mode. 
>>>> 
>>>> root at linux-xorp> configure
>>>> ERROR: You do not have permission for this operation.
>>>> root at linux-xorp> 
>>>> 
>>>> I checked if the user 'root' is present in  group 'xorp' 
>>>> 
>>>> linux-xorp:~ # useradd -G xorp root
>>>> useradd: Account `root' already exists.
>>>> linux-xorp:~ #      
>>>> 
>>>> Not sure what is the error :(
>>> 
>>> The simplest suggestion that comes to mind is to exit and login
>>> again. This might be needed if, for example, you just
>>> created the xorp group. After the re-login run the "groups" command
>>> to see the list of groups the user belongs to.
>>> 
>>> Pavlin
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> _________________________________________________________________
>> Publish your photos to your Space easily with Photo Gallery.
>> http://www.get.live.com/wl/all
>> 
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

_________________________________________________________________
Edit your photos like a pro with Photo Gallery.
http://www.get.live.com/wl/all


From pavlin at icir.org  Wed Dec 12 23:27:45 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 12 Dec 2007 23:27:45 -0800
Subject: [Xorp-users] Not able to go into 'configure' mode
In-Reply-To: Message from Dinesh Kumar <reach_dinesh@hotmail.com> of "Thu,
	13 Dec 2007 15:21:15 +0800."
	<BLU104-W31A19A1A2BE4B5B56D4BE9F0660@phx.gbl> 
Message-ID: <200712130727.lBD7Rjl9066793@possum.icir.org>

Dinesh Kumar <reach_dinesh at hotmail.com> wrote:

> 
> The following is the output before running xorpsh:
> 
> linux-xorp:~ # groups
> root
> linux-xorp:~ #

The user must belong to group "xorp" to be able to run xorpsh in
configuration mode.
First create this group if it is not created, and then add the user
to that group.

Pavlin

> Thanks,
> Dinesh
> ----------------------------------------
> > To: reach_dinesh at hotmail.com
> > CC: xorp-users at xorp.org
> > Subject: Re: [Xorp-users] Not able to go into 'configure' mode 
> > Date: Wed, 12 Dec 2007 21:47:15 -0800
> > From: pavlin at icir.org
> > 
> > Dinesh Kumar  wrote:
> > 
> >> 
> >> Dear Pavlin, Thanks a lot for your prompt reply.
> >> 
> >> I did an exit and logged in again.  I am still not able to go into config mode.
> >> 
> >> root at linux-xorp> configure
> >> ERROR: You do not have permission for this operation.
> >> root at linux-xorp>
> > 
> > What is the output of the "groups" UNIX command before starting
> > xorpsh?
> > 
> > Pavlin
> > 
> >> I got the following comment in the shell window running 'xorp_rtrmgr' 
> >> 
> >> [ 2007/12/13 13:05:19  WARNING xorp_rtrmgr:24886 XrlRtrmgrTarget +338 rtrmgr_base.cc handle_rtrmgr_0_1_enter_config_mode ] Handling method for rtrmgr/0.1/enter_config_mode failed: XrlCmdError 102 Command failed You do not have permission for this operation
> >> 
> >> It says XrlCmdError 102. Does it mean anything?
> >> 
> >> Kind Regards,
> >> Dinesh
> >> 
> >> ----------------------------------------
> >>> To: reach_dinesh at hotmail.com
> >>> CC: xorp-users at xorp.org; pavlin at icir.org
> >>> Subject: Re: [Xorp-users] Configure mode 
> >>> Date: Wed, 12 Dec 2007 00:00:51 -0800
> >>> From: pavlin at icir.org
> >>> 
> >>> Dinesh Kumar  wrote:
> >>> 
> >>>> 
> >>>> Thanks Pavlin.  xorp processes are running now. But I am not able to go into configure mode. 
> >>>> 
> >>>> root at linux-xorp> configure
> >>>> ERROR: You do not have permission for this operation.
> >>>> root at linux-xorp> 
> >>>> 
> >>>> I checked if the user 'root' is present in  group 'xorp' 
> >>>> 
> >>>> linux-xorp:~ # useradd -G xorp root
> >>>> useradd: Account `root' already exists.
> >>>> linux-xorp:~ #      
> >>>> 
> >>>> Not sure what is the error :(
> >>> 
> >>> The simplest suggestion that comes to mind is to exit and login
> >>> again. This might be needed if, for example, you just
> >>> created the xorp group. After the re-login run the "groups" command
> >>> to see the list of groups the user belongs to.
> >>> 
> >>> Pavlin
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> _________________________________________________________________
> >> Publish your photos to your Space easily with Photo Gallery.
> >> http://www.get.live.com/wl/all
> >> 
> >> _______________________________________________
> >> Xorp-users mailing list
> >> Xorp-users at xorp.org
> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> 
> _________________________________________________________________
> Edit your photos like a pro with Photo Gallery.
> http://www.get.live.com/wl/all
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From joshihirenn at gmail.com  Thu Dec 13 04:58:59 2007
From: joshihirenn at gmail.com (hiren joshi)
Date: Thu, 13 Dec 2007 18:28:59 +0530
Subject: [Xorp-users] XORP and multicast promiscuous mode
Message-ID: <29820bf40712130458m1c99942dw8f599cfcf1527962@mail.gmail.com>

I believe that XORP (and all other multicast (pim, igmp, ...) routers) uses
multicast promiscuous mode to capture all multicast packets.
Means they catch all ethernet frames with multicast bit set to 1.
Am I right?

Also, what about LANs not using shared media to forward frames.

Thanks in advance.

Regards,
-hiren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071213/27cb66e7/attachment.html 

From pavlin at icir.org  Thu Dec 13 19:59:07 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 13 Dec 2007 19:59:07 -0800
Subject: [Xorp-users] XORP and multicast promiscuous mode
In-Reply-To: Message from "hiren joshi" <joshihirenn@gmail.com> of "Thu,
	13 Dec 2007 18:28:59 +0530."
	<29820bf40712130458m1c99942dw8f599cfcf1527962@mail.gmail.com> 
Message-ID: <200712140359.lBE3x7IP076327@possum.icir.org>

hiren joshi <joshihirenn at gmail.com> wrote:

> I believe that XORP (and all other multicast (pim, igmp, ...) routers) uses
> multicast promiscuous mode to capture all multicast packets.
> Means they catch all ethernet frames with multicast bit set to 1.
> Am I right?

Yes, all frames with the multicast bit set are captured by the
network interfaces, but only those that contain IP packets get
through the IP stack in the kernel.

> Also, what about LANs not using shared media to forward frames.

Do you mean other LANs like FDDI and Token Ring?
It is similar story, but the exact details depend on the particular
technology.

Pavlin

> Thanks in advance.
> 
> Regards,
> -hiren
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From alankp1 at optusnet.com.au  Wed Dec 19 02:18:03 2007
From: alankp1 at optusnet.com.au (Alan Patterson)
Date: Wed, 19 Dec 2007 21:18:03 +1100
Subject: [Xorp-users] Basic static route configuration problem
Message-ID: <4768EFDB.3010701@optusnet.com.au>

I hope someone can help me with a problem I am having with static routes 
on the LiveCD version of Xorp 1.4.  I have the following simple 
configuration file:

interfaces {
    restore-original-config-on-shutdown: false
    interface xl0 {
        disable: false
        discard: false
        description: "LAN 1"
        vif xl0 {
            disable: false
            address 192.168.10.99 {
                prefix-length: 24
                broadcast: 192.168.10.255
                disable: false
            }
        }
    }
    interface xl1 {
        disable: false
        discard: false
        description: "LAN 2"
        vif xl1 {
            disable: false
            address 192.168.20.100 {
                prefix-length: 24
                broadcast: 192.168.20.255
                disable: false
            }
        }
    }
    interface lo0 {
        disable: false
        discard: false
        description: "Loopback interface"
        vif lo0 {
            disable: false
        }
    }
}

protocols {
        static {
              route 192.168.30.0/24 {
                        next-hop: 192.168.10.100
                        metric: 1
                }
        }
}

fea {
    unicast-forwarding4 {
        disable: false
    }
}

Communication between hosts on the two directly connected networks 
192.168.10.0/24 and 192.168.20.0/24 works fine, but packets to the 
192.168.30.0/24 network are not forwarded to 192.168.10.100. The command 
'show route table .....' returns a completely empty table. What have I 
got wrong?
Thanks for any help,

Alan


From pavlin at icir.org  Fri Dec 21 11:54:17 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 21 Dec 2007 11:54:17 -0800
Subject: [Xorp-users] Basic static route configuration problem
In-Reply-To: Message from Alan Patterson <alankp1@optusnet.com.au> of "Wed,
	19 Dec 2007 21:18:03 +1100." <4768EFDB.3010701@optusnet.com.au> 
Message-ID: <200712211954.lBLJsHQe020005@possum.icir.org>

Alan Patterson <alankp1 at optusnet.com.au> wrote:

> I hope someone can help me with a problem I am having with static routes 
> on the LiveCD version of Xorp 1.4.  I have the following simple 
> configuration file:
> 
> interfaces {
>     restore-original-config-on-shutdown: false
>     interface xl0 {
>         disable: false
>         discard: false
>         description: "LAN 1"
>         vif xl0 {
>             disable: false
>             address 192.168.10.99 {
>                 prefix-length: 24
>                 broadcast: 192.168.10.255
>                 disable: false
>             }
>         }
>     }
>     interface xl1 {
>         disable: false
>         discard: false
>         description: "LAN 2"
>         vif xl1 {
>             disable: false
>             address 192.168.20.100 {
>                 prefix-length: 24
>                 broadcast: 192.168.20.255
>                 disable: false
>             }
>         }
>     }
>     interface lo0 {
>         disable: false
>         discard: false
>         description: "Loopback interface"
>         vif lo0 {
>             disable: false
>         }
>     }
> }
> 
> protocols {
>         static {
>               route 192.168.30.0/24 {
>                         next-hop: 192.168.10.100
>                         metric: 1
>                 }
>         }
> }
> 
> fea {
>     unicast-forwarding4 {
>         disable: false
>     }
> }
> 
> Communication between hosts on the two directly connected networks 
> 192.168.10.0/24 and 192.168.20.0/24 works fine, but packets to the 
> 192.168.30.0/24 network are not forwarded to 192.168.10.100. The command 
> 'show route table .....' returns a completely empty table. What have I 
> got wrong?

Your configuration seems fine, so I find it odd that it doesn't work
for you. Could you double-check that the
"show route table ipv4 unicast static" xorpsh command indeed doesn't
return the 192.168.30.0/24 route.

In general, the following two reasons could prevent a static route
being added to the RIB:
a) The next-hop IP address is not directly connected to
   XORP-configured interface.
   This is not the case in your config.
b) The cable toward the next-hop IP address is disconnected.
   If the forwarding toward 192.168.10.0/24 is OK, then you don't
   have a disconnected cable.

If the above "show route ..." command indeed returns an empty table,
could you restart the xorp_rtrmgr with XRL tracing enabled.
Off the top of my head, the commands for the LiveCD will be
something like:

1. Login as a root and kill the running xorp_rtrmgr process:

killall xorp_rtrmgr

   Make sure that there are no leftover XORP processes (i.e.,
   processes with "xorp" name prefix):

ps -auxww | egrep xorp

2. Start the XORP instance by hand, by enabling the XRL tracing and
   saving the output to a file:

cd /tmp
export XRLTRACE=yes
script
/usr/local/xorp/bin/xorp_rtrmgr -b /etc/xorp.cfg

3. Let XORP run, and use a separate terminal (use Alt-F2, Alt-F3,
Alt-F4 to switch to a new terminal) to login as user "xorp" and
double-check that the static route is not in the RIB.

4. Stop the xorp_rtrmgr process in the terminal you started it:

Ctrl-C
exit

The log file with the output should be saved in /tmp/typescript .
Please send me that file so I can analyze it. No need to send it to
the list, because it will be a large file.

Pavlin


From jeandro at gmail.com  Fri Dec 21 14:41:27 2007
From: jeandro at gmail.com (Jeandro Bezerra)
Date: Fri, 21 Dec 2007 19:41:27 -0300
Subject: [Xorp-users] Fwd: tests conformance using XORP
In-Reply-To: <200712101924.lBAJO5IG047427@possum.icir.org>
References: <jeandro@larces.uece.br>
	<5efcb8aa0712100544v613f7e2ah4fcddccb1f0eefea@mail.gmail.com>
	<200712101924.lBAJO5IG047427@possum.icir.org>
Message-ID: <5efcb8aa0712211441s8138256t92b0457f6d48c4a9@mail.gmail.com>

First of all, thank you for the answers

but i am with problems in the RIP. In the show pim join output

root at thiago> show pim join
Group           Source          RP              Flags
224.1.1.1       192.168.6.1     192.168.8.5     SG
    Upstream interface (S):    UNKNOWN
    Upstream interface (RP):   register_vif
    Upstream MRIB next hop (RP): UNKNOWN
    Upstream MRIB next hop (S):  UNKNOWN
    Upstream RPF'(S,G):        UNKNOWN
    Upstream state:            Joined
    Join timer:                48
    KAT(S,G) running:          false
    Local receiver include WC: ...
    Local receiver include SG: ...
    Local receiver exclude SG: ...
    Joins RP:                  ...
    Joins WC:                  ...
    Joins SG:                  O..
    Join state:                O..
    Prune state:               ...
    Prune pending state:       ...
    I am assert winner state:  ...
    I am assert loser state:   ...
    Assert winner WC:          ...
    Assert winner SG:          ...
    Assert lost WC:            ...
    Assert lost SG:            ...
    Assert lost SG_RPT:        ...
    Assert tracking SG:        O..
    Could assert WC:           ...
    Could assert SG:           ...
    I am DR:                   O.O
    Immediate olist RP:        ...
    Immediate olist WC:        ...
    Immediate olist SG:        O..
    Inherited olist SG:        O..
    Inherited olist SG_RPT:    ...
    PIM include WC:            ...
    PIM include SG:            ...
    PIM exclude SG:            ...

The source 192.168.6.1 is generated by TEE (another router). It
appears that the route is not received by RIP. You could verify
that by running the "show route table ipv4 unicast rip". I do not show nothing.

I am attached my config.boot. Can you help me in my rip configuration?

Thanks



2007/12/10, Pavlin Radoslavov < pavlin at icir.org>:
>
> See comments inline.
>
> > interfaces {
> >     restore-original-config-on-shutdown: false
> >     interface eth0 {
> >     description: "data interface"
> >     disable: false
> >     /* default-system-config */
> >      vif eth0 {
> >             disable: false
> >             address 192.168.7.5 {
> >                 prefix-length: 24
> >                 broadcast: 192.168.7.255
> >                 disable: false
> >         }
> >     }
> >     }
> >
> >   interface eth1 {
> >     description: "data interface"
> >     disable: false
> >     /* default-system-config */
> >      vif eth1 {
> >             disable: false
> >             address 192.168.8.5 {
> >                 prefix-length: 24
> >                 broadcast: 192.168.8.255
> >                 disable: false
> >         }
> >     }
> >
> >  }
> >
> > }
>
> <DEL>
>
> > protocols {
> >     static {
> >
> >     interface-route 192.168.8.0/24 {
> >      next-hop-interface: "eth0"
> >      next-hop-vif: "eth0"
> >      next-hop-router: 192.168.7.5
> >      metric: 1
> >      }
> >
> >     mrib-interface-route 192.168.8.0/24 {
> >      next-hop-interface: "eth0"
> >      next-hop-vif: "eth0"
> >      metric: 1
> >      }
>
> Few things about the above static routers configuration:
>
> * The "interface-route" and "mrib-interface-route" entries are
>   needed in special cases when you want to force the route to point
>   toward a specific interface even if the next-hop router's IP
>   address doesn't belong to the same subnet.
>   If you want to use static routes, in your setup it is better to
>   use the "route" and "mrib-route" configuration statements instead.
>
> * In the interface-route statement above you have set the
>   next-hop-router to the eth0's IP address which is probably not
>   what you want.
>
> * Typically the "mrib-route" or "mrib-interface-route" should be
>   used if you want to add multicast-specific entries that are used
>   for multicast RPF check only, but are not used by the unicast
>   routing.
>   In your case probably you don't need them to be different, so for
>   simplicity you might want to remove the "mrib-" static route
>   entry.
>
> * The particular static routes are for the 192.168.8.0/24 subnet
>   which actually is the subnet of interface eth1.
>   You cannot overwrite the routes for directly connected subnets so
>   you shouldn't add such routes.
>
> Said that, if you want to add a static route for a non-directly
> connected subnet (say, 192.168.6.0/24), it should look like:
>
>     route 192.168.6.0/24 {
>         next-hop: 192.168.7.20
>     }
>
> where I assume that 192.168.7.20 is the next-hop router toward
> the destination.
>
> >
> >     }
> >
> > }
> >
> >
> >
> > policy {
> >     /* Describe connected routes for redistribution */
> >     policy-statement connected {
> >     term export {
> >         from {
> >         protocol: "connected"
> >         }
> >     }
> >     }
> > }
> >
> >
> > policy {
> >     /* Describe static routes for redistribution */
> >     policy-statement static {
> >         term export {
> >             from {
> >                 protocol: "static"
> >             }
> >         }
> >     }
> > }
>
> <DEL>
>
> > protocols {
> >     rip {
> >
> > /* Connected interfaces will only be advertised if explicitly exported
> */
> >         export: "connected"
> >     export: "static"
>
> If you want to export both "connected" and "static", then you should
> add them with the same export statement. E.g.:
>     export: "connected,static"
>
> If you have two "export" statements, the second one will overwrite
> the first one.
>
> > /* Run on specified network interface addresses */
> >         interface eth0 {
> >             vif eth0 {
> >                 address 192.168.7.5 {
> >                     disable: false
> >                 }
> >             }
> >         }
> >
> >     interface eth1 {
> >             vif eth1 {
> >                 address 192.168.8.5 {
> >                     disable: false
> >                 }
> >             }
> >         }
> >
> >     }
> > }
>
> <DEL>
>
> > protocols {
> >     pimsm4 {
> >     disable: false
> >     interface eth0 {
> >         vif eth0 {
> >         disable: false
> >         /* enable-ip-router-alert-option-check: false */
> >         /* dr-priority: 1 */
> >         /* hello-period: 30 */
> >         /* hello-triggered-delay: 5 */
> >         /* alternative-subnet 10.40.0.0/16 */
> >         }
> >     }
> >
> >     interface eth1 {
> >         vif eth1 {
> >         disable: false
> >         /* enable-ip-router-alert-option-check: false */
> >         /* dr-priority: 1 */
> >         /* hello-period: 30 */
> >         /* hello-triggered-delay: 5 */
> >         /* alternative-subnet 10.40.0.0/16 */
> >         }
> >     }
> >
> >     interface register_vif {
> >         vif register_vif {
> >         /* Note: this vif should be always enabled */
> >         disable: false
> >         }
> >     }
> >
> >       /*     static-rps {*/
> >     /*    rp 192.168.7.5 {*/
> >     /*    group-prefix 224.0.0.0/4 {*/
> >             /* rp-priority: 192 */
> >             /* hash-mask-len: 30 */
> >     /*    } */
> >     /*    } */
> > /*    } */
> >
> >     bootstrap {
> >         disable: false
> >         cand-bsr {
> >         scope-zone 224.0.0.0/8 {
> >             /* is-scope-zone: false */
> >             cand-bsr-by-vif-name: "eth0"
> >             /* cand-bsr-by-vif-addr: 10.10.10.10 */
> >              bsr-priority: 1
> >             /* hash-mask-len: 30 */
> >         }
> >           }
> >         cand-bsr {
> >         scope-zone 224.0.0.0/8 {
> >             /* is-scope-zone: false */
> >             cand-bsr-by-vif-name: "eth1"
> >             /* cand-bsr-by-vif-addr: 10.10.10.10 */
> >              bsr-priority: 2
> >             /* hash-mask-len: 30 */
> >         }
> >
> >         }
> >
> >         cand-rp {
> >         group-prefix 224.0.0.0/8 {
> >             /* is-scope-zone: false */
> >             cand-rp-by-vif-name: "eth0"
> >             /* cand-rp-by-vif-addr: 10.10.10.10 */
> >              rp-priority: 192
> >             /* rp-holdtime: 150 */
> >         }
> >         }
> >             cand-rp {
> >         group-prefix 224.0.0.0/8 {
> >             /* is-scope-zone: false */
> >             cand-rp-by-vif-name: "eth1"
> >             /* cand-rp-by-vif-addr: 10.10.10.10 */
> >              rp-priority: 195
> >             /* rp-holdtime: 150 */
> >         }
> >         }
> >
> >
> >     }
>
> It appears that you have decided to use the dynamic Bootstrap
> mechanism instead of static RPs. You should know that on startup it
> can take up to 2-3 minutes or so until the Bootstrap election is
> completed and the Cand-RP set has converged.
> For testing purpose you might want to use a static RP so you can
> avoid the startup delay.
> There is nothing wrong with using the Bootstrap mechanism, and if
> you deal only with (S,G) Joins then the RPs are not used, but you
> should be aware of the startup delay.
>
> Also, you might want to use 224.0.0.0/4 prefix to cover the whole
> multicast address space (in case you decide to use multicast with
> some group addresses that are outside the 224.0.0.0/8 prefix).
>
> >     switch-to-spt-threshold {
> >         /* approx. 1K bytes/s (10Kbps) threshold */
> >         disable: false
> >         interval: 100
> >         bytes: 102400
> >     }
> >
> >     traceoptions {
> >         flag all {
> >         disable: false
> >         }
> >     }
> >     }
>
> <DEL>
>
> > __________________________________________
> >
> > root at thiago> show pim join
> > Group           Source          RP              Flags
> > 224.1.1.1       192.168.6.1     192.168.8.5     SG
> >     Upstream interface (S):    UNKNOWN
>                                  ~~~~~~~
> >     Upstream interface (RP):   register_vif
> >     Upstream MRIB next hop (RP): UNKNOWN
> >     Upstream MRIB next hop (S):  UNKNOWN
>                                    ~~~~~~~
> >     Upstream RPF'(S,G):        UNKNOWN
>                                  ~~~~~~~
>
> The real reason that the (S,G) Join wasn't originated by the XORP
> router is because the next-hop toward S (192.168.6.1) is unknown.
> In your configuration there isn't a static route toward that
> destination, so the route should come from the dynamic protocol (RIP
> in your case).
> It appears that the route is not received by RIP. You could verify
> that by running the "show route table ipv4 unicast rip" xorpsh
> command.
> If you are using same multiple "export" statements in all XORP
> routers, then probably none of them is advertising its connected
> routes.
>
> Though, again for testing purpose you might want just to use static
> routes so you will avoid the extra startup delay with the dynamic
> routing protocols.
>
> After you apply the above fixes, use the "show pim join" command to
> make sure that the upstream information is received correctly by the
> PIM-SM module.
>
> Regards,
> Pavlin
>
> >     Upstream state:            Joined
> >     Join timer:                48
> >     KAT(S,G) running:          false
> >     Local receiver include WC: ...
> >     Local receiver include SG: ...
> >     Local receiver exclude SG: ...
> >     Joins RP:                  ...
> >     Joins WC:                  ...
> >     Joins SG:                  O..
> >     Join state:                O..
> >     Prune state:               ...
> >     Prune pending state:       ...
> >     I am assert winner state:  ...
> >     I am assert loser state:   ...
> >     Assert winner WC:          ...
> >     Assert winner SG:          ...
> >     Assert lost WC:            ...
> >     Assert lost SG:            ...
> >     Assert lost SG_RPT:        ...
> >     Assert tracking SG:        O..
> >     Could assert WC:           ...
> >     Could assert SG:           ...
> >     I am DR:                   O.O
> >     Immediate olist RP:        ...
> >     Immediate olist WC:        ...
> >     Immediate olist SG:        O..
> >     Inherited olist SG:        O..
> >     Inherited olist SG_RPT:    ...
> >     PIM include WC:            ...
> >     PIM include SG:            ...
> >     PIM exclude SG:            ...
> >  (END)
>



-- 
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/20071221/77983521/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.boot
Type: application/octet-stream
Size: 8355 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071221/77983521/attachment-0001.obj 

From jeandro at larces.uece.br  Fri Dec 21 14:43:22 2007
From: jeandro at larces.uece.br (Jeandro de M. Bezerra)
Date: Fri, 21 Dec 2007 19:43:22 -0300
Subject: [Xorp-users] Fwd:  Fwd: tests conformance using XORP
In-Reply-To: <5efcb8aa0712211441s8138256t92b0457f6d48c4a9@mail.gmail.com>
References: <jeandro@larces.uece.br>
	<5efcb8aa0712100544v613f7e2ah4fcddccb1f0eefea@mail.gmail.com>
	<200712101924.lBAJO5IG047427@possum.icir.org>
	<5efcb8aa0712211441s8138256t92b0457f6d48c4a9@mail.gmail.com>
Message-ID: <5efcb8aa0712211443q54d86077rf89068eb3379e462@mail.gmail.com>

---------- Forwarded message ----------
From: Jeandro Bezerra <jeandro at gmail.com>
Date: 21/12/2007 19:41
Subject: Re: [Xorp-users] Fwd: tests conformance using XORP
To: Pavlin Radoslavov <pavlin at icir.org>
Cc: xorp-users at xorp.org, Laure Waha Mendouga <laure18 at gmail.com>

First of all, thank you for the answers

but i am with problems in the RIP. In the show pim join output

root at thiago> show pim join
Group           Source          RP              Flags

224.1.1.1       192.168.6.1     192.168.8.5     SG
    Upstream interface (S):    UNKNOWN
    Upstream interface (RP):   register_vif

    Upstream MRIB next hop (RP): UNKNOWN
    Upstream MRIB next hop (S):  UNKNOWN
    Upstream RPF'(S,G):        UNKNOWN
    Upstream state:            Joined
    Join timer:                48
    KAT(S,G) running:          false

    Local receiver include WC: ...
    Local receiver include SG: ...
    Local receiver exclude SG: ...
    Joins RP:                  ...
    Joins WC:                  ...
    Joins SG:                  O..

    Join state:                O..
    Prune state:               ...
    Prune pending state:       ...
    I am assert winner state:  ...
    I am assert loser state:   ...
    Assert winner WC:          ...

    Assert winner SG:          ...
    Assert lost WC:            ...
    Assert lost SG:            ...
    Assert lost SG_RPT:        ...
    Assert tracking SG:        O..
    Could assert WC:           ...

    Could assert SG:           ...
    I am DR:                   O.O
    Immediate olist RP:        ...
    Immediate olist WC:        ...
    Immediate olist SG:        O..
    Inherited olist SG:        O..

    Inherited olist SG_RPT:    ...
    PIM include WC:            ...
    PIM include SG:            ...
    PIM exclude SG:            ...

The source 192.168.6.1 is generated by TEE (another router).
It appears that the route is not received by RIP. You could verify
that by running the "show route table ipv4 unicast rip". I do not show nothing.

I am attached my config.boot. Can you help me in my rip configuration?


Thanks



2007/12/10, Pavlin Radoslavov < pavlin at icir.org>:
>
> See comments inline.
>
> > interfaces {
> >     restore-original-config-on-shutdown: false
> >     interface eth0 {
> >     description: "data interface"
> >     disable: false
> >     /* default-system-config */
> >      vif eth0 {
> >             disable: false
> >             address 192.168.7.5 {
> >                 prefix-length: 24
> >                 broadcast: 192.168.7.255
> >                 disable: false
> >         }
> >     }
> >     }
> >
> >   interface eth1 {
> >     description: "data interface"
> >     disable: false
> >     /* default-system-config */
> >      vif eth1 {
> >             disable: false
> >             address 192.168.8.5 {
> >                 prefix-length: 24
> >                 broadcast: 192.168.8.255
> >                 disable: false
> >         }
> >     }
> >
> >  }
> >
> > }
>
> <DEL>
>
> > protocols {
> >     static {
> >
> >     interface-route 192.168.8.0/24 {
> >      next-hop-interface: "eth0"
> >      next-hop-vif: "eth0"
> >      next-hop-router: 192.168.7.5
> >      metric: 1
> >      }
> >
> >     mrib-interface-route 192.168.8.0/24 {
> >      next-hop-interface: "eth0"
> >      next-hop-vif: "eth0"
> >      metric: 1
> >      }
>
> Few things about the above static routers configuration:
>
> * The "interface-route" and "mrib-interface-route" entries are
>   needed in special cases when you want to force the route to point
>   toward a specific interface even if the next-hop router's IP
>   address doesn't belong to the same subnet.
>   If you want to use static routes, in your setup it is better to
>   use the "route" and "mrib-route" configuration statements instead.
>
> * In the interface-route statement above you have set the
>   next-hop-router to the eth0's IP address which is probably not
>   what you want.
>
> * Typically the "mrib-route" or "mrib-interface-route" should be
>   used if you want to add multicast-specific entries that are used
>   for multicast RPF check only, but are not used by the unicast
>   routing.
>   In your case probably you don't need them to be different, so for
>   simplicity you might want to remove the "mrib-" static route
>   entry.
>
> * The particular static routes are for the 192.168.8.0/24 subnet
>   which actually is the subnet of interface eth1.
>   You cannot overwrite the routes for directly connected subnets so
>   you shouldn't add such routes.
>
> Said that, if you want to add a static route for a non-directly
> connected subnet (say, 192.168.6.0/24), it should look like:
>
>     route 192.168.6.0/24 {
>         next-hop: 192.168.7.20
>     }
>
> where I assume that 192.168.7.20 is the next-hop router toward
> the destination.
>
> >
> >     }
> >
> > }
> >
> >
> >
> > policy {
> >     /* Describe connected routes for redistribution */
> >     policy-statement connected {
> >     term export {
> >         from {
> >         protocol: "connected"
> >         }
> >     }
> >     }
> > }
> >
> >
> > policy {
> >     /* Describe static routes for redistribution */
> >     policy-statement static {
> >         term export {
> >             from {
> >                 protocol: "static"
> >             }
> >         }
> >     }
> > }
>
> <DEL>
>
> > protocols {
> >     rip {
> >
> > /* Connected interfaces will only be advertised if explicitly exported
> */
> >         export: "connected"
> >     export: "static"
>
> If you want to export both "connected" and "static", then you should
> add them with the same export statement. E.g.:
>     export: "connected,static"
>
> If you have two "export" statements, the second one will overwrite
> the first one.
>
> > /* Run on specified network interface addresses */
> >         interface eth0 {
> >             vif eth0 {
> >                 address 192.168.7.5 {
> >                     disable: false
> >                 }
> >             }
> >         }
> >
> >     interface eth1 {
> >             vif eth1 {
> >                 address 192.168.8.5 {
> >                     disable: false
> >                 }
> >             }
> >         }
> >
> >     }
> > }
>
> <DEL>
>
> > protocols {
> >     pimsm4 {
> >     disable: false
> >     interface eth0 {
> >         vif eth0 {
> >         disable: false
> >         /* enable-ip-router-alert-option-check: false */
> >         /* dr-priority: 1 */
> >         /* hello-period: 30 */
> >         /* hello-triggered-delay: 5 */
> >         /* alternative-subnet 10.40.0.0/16 */
> >         }
> >     }
> >
> >     interface eth1 {
> >         vif eth1 {
> >         disable: false
> >         /* enable-ip-router-alert-option-check: false */
> >         /* dr-priority: 1 */
> >         /* hello-period: 30 */
> >         /* hello-triggered-delay: 5 */
> >         /* alternative-subnet 10.40.0.0/16 */
> >         }
> >     }
> >
> >     interface register_vif {
> >         vif register_vif {
> >         /* Note: this vif should be always enabled */
> >         disable: false
> >         }
> >     }
> >
> >       /*     static-rps {*/
> >     /*    rp 192.168.7.5 {*/
> >     /*    group-prefix 224.0.0.0/4 {*/
> >             /* rp-priority: 192 */
> >             /* hash-mask-len: 30 */
> >     /*    } */
> >     /*    } */
> > /*    } */
> >
> >     bootstrap {
> >         disable: false
> >         cand-bsr {
> >         scope-zone 224.0.0.0/8 {
> >             /* is-scope-zone: false */
> >             cand-bsr-by-vif-name: "eth0"
> >             /* cand-bsr-by-vif-addr: 10.10.10.10 */
> >              bsr-priority: 1
> >             /* hash-mask-len: 30 */
> >         }
> >           }
> >         cand-bsr {
> >         scope-zone 224.0.0.0/8 {
> >             /* is-scope-zone: false */
> >             cand-bsr-by-vif-name: "eth1"
> >             /* cand-bsr-by-vif-addr: 10.10.10.10 */
> >              bsr-priority: 2
> >             /* hash-mask-len: 30 */
> >         }
> >
> >         }
> >
> >         cand-rp {
> >         group-prefix 224.0.0.0/8 {
> >             /* is-scope-zone: false */
> >             cand-rp-by-vif-name: "eth0"
> >             /* cand-rp-by-vif-addr: 10.10.10.10 */
> >              rp-priority: 192
> >             /* rp-holdtime: 150 */
> >         }
> >         }
> >             cand-rp {
> >         group-prefix 224.0.0.0/8 {
> >             /* is-scope-zone: false */
> >             cand-rp-by-vif-name: "eth1"
> >             /* cand-rp-by-vif-addr: 10.10.10.10 */
> >              rp-priority: 195
> >             /* rp-holdtime: 150 */
> >         }
> >         }
> >
> >
> >     }
>
> It appears that you have decided to use the dynamic Bootstrap
> mechanism instead of static RPs. You should know that on startup it
> can take up to 2-3 minutes or so until the Bootstrap election is
> completed and the Cand-RP set has converged.
> For testing purpose you might want to use a static RP so you can
> avoid the startup delay.
> There is nothing wrong with using the Bootstrap mechanism, and if
> you deal only with (S,G) Joins then the RPs are not used, but you
> should be aware of the startup delay.
>
> Also, you might want to use 224.0.0.0/4 prefix to cover the whole
> multicast address space (in case you decide to use multicast with
> some group addresses that are outside the 224.0.0.0/8 prefix).
>
> >     switch-to-spt-threshold {
> >         /* approx. 1K bytes/s (10Kbps) threshold */
> >         disable: false
> >         interval: 100
> >         bytes: 102400
> >     }
> >
> >     traceoptions {
> >         flag all {
> >         disable: false
> >         }
> >     }
> >     }
>
> <DEL>
>
> > __________________________________________
> >
> > root at thiago> show pim join
> > Group           Source          RP              Flags
> > 224.1.1.1        192.168.6.1     192.168.8.5     SG
> >     Upstream interface (S):    UNKNOWN
>                                  ~~~~~~~
> >     Upstream interface (RP):   register_vif
> >     Upstream MRIB next hop (RP): UNKNOWN
> >     Upstream MRIB next hop (S):  UNKNOWN
>                                    ~~~~~~~
> >     Upstream RPF'(S,G):        UNKNOWN
>                                  ~~~~~~~
>
> The real reason that the (S,G) Join wasn't originated by the XORP
> router is because the next-hop toward S (192.168.6.1) is unknown.
> In your configuration there isn't a static route toward that
> destination, so the route should come from the dynamic protocol (RIP
> in your case).
> It appears that the route is not received by RIP. You could verify
> that by running the "show route table ipv4 unicast rip" xorpsh
> command.
> If you are using same multiple "export" statements in all XORP
> routers, then probably none of them is advertising its connected
> routes.
>
> Though, again for testing purpose you might want just to use static
> routes so you will avoid the extra startup delay with the dynamic
> routing protocols.
>
> After you apply the above fixes, use the "show pim join" command to
> make sure that the upstream information is received correctly by the
> PIM-SM module.
>
> Regards,
> Pavlin
>
> >     Upstream state:            Joined
> >     Join timer:                48
> >     KAT(S,G) running:          false
> >     Local receiver include WC: ...
> >     Local receiver include SG: ...
> >     Local receiver exclude SG: ...
> >     Joins RP:                  ...
> >     Joins WC:                  ...
> >     Joins SG:                  O..
> >     Join state:                O..
> >     Prune state:               ...
> >     Prune pending state:       ...
> >     I am assert winner state:  ...
> >     I am assert loser state:   ...
> >     Assert winner WC:          ...
> >     Assert winner SG:          ...
> >     Assert lost WC:            ...
> >     Assert lost SG:            ...
> >     Assert lost SG_RPT:        ...
> >     Assert tracking SG:        O..
> >     Could assert WC:           ...
> >     Could assert SG:           ...
> >     I am DR:                   O.O
> >     Immediate olist RP:        ...
> >     Immediate olist WC:        ...
> >     Immediate olist SG:        O..
> >     Inherited olist SG:        O..
> >     Inherited olist SG_RPT:    ...
> >     PIM include WC:            ...
> >     PIM include SG:            ...
> >     PIM exclude SG:            ...
> >  (END)
>



-- 
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/20071221/7140470b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.boot
Type: application/octet-stream
Size: 8355 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071221/7140470b/attachment-0001.obj 

From pavlin at icir.org  Fri Dec 21 15:34:02 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 21 Dec 2007 15:34:02 -0800
Subject: [Xorp-users] Fwd: tests conformance using XORP
In-Reply-To: Message from "Jeandro Bezerra" <jeandro@gmail.com> of "Fri,
	21 Dec 2007 19:41:27 -0300."
	<5efcb8aa0712211441s8138256t92b0457f6d48c4a9@mail.gmail.com> 
Message-ID: <200712212334.lBLNY2Zi022037@possum.icir.org>

> First of all, thank you for the answers
> 
> but i am with problems in the RIP. In the show pim join output
> 
> root at thiago> show pim join
> Group           Source          RP              Flags
> 224.1.1.1       192.168.6.1     192.168.8.5     SG
>     Upstream interface (S):    UNKNOWN
>     Upstream interface (RP):   register_vif
>     Upstream MRIB next hop (RP): UNKNOWN
>     Upstream MRIB next hop (S):  UNKNOWN
>     Upstream RPF'(S,G):        UNKNOWN
>     Upstream state:            Joined
>     Join timer:                48
>     KAT(S,G) running:          false
>     Local receiver include WC: ...
>     Local receiver include SG: ...
>     Local receiver exclude SG: ...
>     Joins RP:                  ...
>     Joins WC:                  ...
>     Joins SG:                  O..
>     Join state:                O..
>     Prune state:               ...
>     Prune pending state:       ...
>     I am assert winner state:  ...
>     I am assert loser state:   ...
>     Assert winner WC:          ...
>     Assert winner SG:          ...
>     Assert lost WC:            ...
>     Assert lost SG:            ...
>     Assert lost SG_RPT:        ...
>     Assert tracking SG:        O..
>     Could assert WC:           ...
>     Could assert SG:           ...
>     I am DR:                   O.O
>     Immediate olist RP:        ...
>     Immediate olist WC:        ...
>     Immediate olist SG:        O..
>     Inherited olist SG:        O..
>     Inherited olist SG_RPT:    ...
>     PIM include WC:            ...
>     PIM include SG:            ...
>     PIM exclude SG:            ...
> 
> The source 192.168.6.1 is generated by TEE (another router). It
> appears that the route is not received by RIP. You could verify
> that by running the "show route table ipv4 unicast rip". I do not show nothing.
> 
> I am attached my config.boot. Can you help me in my rip configuration?

Few things to apply to your config:

 * Delete the following configuration statement:

        mrib-route 192.168.7.0/24 {
            next-hop: 192.168.6.1
            metric: 1
        }

   You shouldn't use static mrib-route for a directly connected subnet
   (192.168.7.0/24).

 * The 192.168.6.0/24 static route has next-hop set to your own IP
   address (192.168.7.5).
   It should be set to the IP address of the next-hop router toward
   192.168.6.0/24, and that router should be running PIM-SM.
   However, if you have 192.168.6.0/24 static route, then that route
   will be preferred regardless of the RIP routes.
   There is nothing wrong with that, as long as you understand the
   result of it.

 * In RIP you are exporting static routes only.
   Most likely you need to export the connected routes (only).
   Only if you have special static routes you need to export, then
   you should export both connected and static.

 * In your RIP config you haven't configured eth2.
   I am pointing this in case it was omitted unintentionally.

Hope that helps,
Pavlin


From reach_dinesh at hotmail.com  Tue Dec 25 20:17:45 2007
From: reach_dinesh at hotmail.com (Dinesh Kumar)
Date: Wed, 26 Dec 2007 12:17:45 +0800
Subject: [Xorp-users] Config Settings before starting XORP
Message-ID: <BLU104-W202E268A6F535877955D1FF05B0@phx.gbl>


Hi,

I have a basic doubt about the configuration of the Ethernet card before starting XORP. Should I preconfigure my ethernet cards with an IP address and subnet mask through 'ifconfig' commands or does xorp enforce the IP address set in the config file ?

Merry Christmas and a Happy New Year to everyone :)

Kind Regards,
Dinesh
_________________________________________________________________
Help Splitzo Sally Before It?s Too Late! 
http://www.thegirlwhosplitinto5.com/


From a.greenhalgh at cs.ucl.ac.uk  Wed Dec 26 00:20:06 2007
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Wed, 26 Dec 2007 08:20:06 +0000
Subject: [Xorp-users] Config Settings before starting XORP
In-Reply-To: <BLU104-W202E268A6F535877955D1FF05B0@phx.gbl>
References: <BLU104-W202E268A6F535877955D1FF05B0@phx.gbl>
Message-ID: <4769af410712260020h10dc0b29nf7383f08222c8542@mail.gmail.com>

No, set them in the xorp config file.

See http://www.xorp.org/releases/current/docs/user_manual/user_manual.pdf

Adam

On 26/12/2007, Dinesh Kumar <reach_dinesh at hotmail.com> wrote:
>
> Hi,
>
> I have a basic doubt about the configuration of the Ethernet card before starting XORP. Should I preconfigure my ethernet cards with an IP address and subnet mask through 'ifconfig' commands or does xorp enforce the IP address set in the config file ?
>
> Merry Christmas and a Happy New Year to everyone :)
>
> Kind Regards,
> Dinesh
> _________________________________________________________________
> Help Splitzo Sally Before It's Too Late!
> http://www.thegirlwhosplitinto5.com/
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>


From reach_dinesh at hotmail.com  Wed Dec 26 01:51:53 2007
From: reach_dinesh at hotmail.com (Dinesh Kumar)
Date: Wed, 26 Dec 2007 17:51:53 +0800
Subject: [Xorp-users] Config Settings before starting XORP
In-Reply-To: <4769af410712260020h10dc0b29nf7383f08222c8542@mail.gmail.com>
References: <BLU104-W202E268A6F535877955D1FF05B0@phx.gbl>
	<4769af410712260020h10dc0b29nf7383f08222c8542@mail.gmail.com>
Message-ID: <BLU104-W1424CD4EE7EA3FA1EB65CAF05B0@phx.gbl>


Dear Adam,
Thanks for your time.
----------------------------------------
> Date: Wed, 26 Dec 2007 08:20:06 +0000
> From: a.greenhalgh at cs.ucl.ac.uk
> To: reach_dinesh at hotmail.com
> Subject: Re: [Xorp-users] Config Settings before starting XORP
> CC: xorp-users at xorp.org
> 
> No, set them in the xorp config file.
> 
> See http://www.xorp.org/releases/current/docs/user_manual/user_manual.pdf
> 
> Adam
> 
> On 26/12/2007, Dinesh Kumar  wrote:
>>
>> Hi,
>>
>> I have a basic doubt about the configuration of the Ethernet card before starting XORP. Should I preconfigure my ethernet cards with an IP address and subnet mask through 'ifconfig' commands or does xorp enforce the IP address set in the config file ?
>>
>> Merry Christmas and a Happy New Year to everyone :)
>>
>> Kind Regards,
>> Dinesh
>> _________________________________________________________________
>> Help Splitzo Sally Before It's Too Late!
>> http://www.thegirlwhosplitinto5.com/
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>>

_________________________________________________________________
Edit your photos like a pro with Photo Gallery.
http://www.get.live.com/wl/all


From reach_dinesh at hotmail.com  Wed Dec 26 01:53:38 2007
From: reach_dinesh at hotmail.com (Dinesh Kumar)
Date: Wed, 26 Dec 2007 17:53:38 +0800
Subject: [Xorp-users] Missing OSPF neighbours
Message-ID: <BLU104-W180B94E5358759A6D164FAF05B0@phx.gbl>


Dear XORP users,

I have configured OSPF using xorp between 2 PCs running linux. I am not able to see any OSPF neighbours in the xorp shell (xorpsh) in both the PCs.

PC1:(using config1.boot)
------------------------------
dinesh at linux-xorp> show ospf4 neighbor
  Address         Interface             State      ID              Pri  Dead
dinesh at linux-xorp>

dinesh at linux-xorp> show route table ipv4 unicast ospf
dinesh at linux-xorp>

dinesh at linux-xorp> show ospf4 database
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *10.0.0.2         10.0.0.2         0x80000001   105  0x2  0x260a  36
dinesh at linux-xorp>


I am really not sure why there is no adjacency between these two PCs. I have checked the reachability between them also.

>From PC1 to PC2:
-----------------------
dinesh at linux-xorp> ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=3.54 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.204 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.212 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.204 ms

Command interrupted!

dinesh at linux-xorp>

>From PC2 to PC1:
----------------------
dinesh at linux-xorp2> ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.191 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.182 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.177 ms

Command interrupted!

dinesh at linux-xorp2>

I have attached the config.boot files of both the PCs. I would be very much obliged if somebody can point out if i have missed anything in config.boot. Thanks in advance.

Regards,
Dinesh

_________________________________________________________________
Get your free suite of Windows Live services today!
http://www.get.live.com/wl/all
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config1.boot
Type: application/octet-stream
Size: 675 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071226/9bd39e1b/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config2.boot
Type: application/octet-stream
Size: 679 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071226/9bd39e1b/attachment-0001.obj 

From atanu at ICSI.Berkeley.EDU  Wed Dec 26 14:26:58 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 26 Dec 2007 14:26:58 -0800
Subject: [Xorp-users] Missing OSPF neighbours
In-Reply-To: Message from Dinesh Kumar <reach_dinesh@hotmail.com> of "Wed,
	26 Dec 2007 17:53:38 +0800."
	<BLU104-W180B94E5358759A6D164FAF05B0@phx.gbl> 
Message-ID: <19110.1198708018@tigger.icir.org>

Hi,

Your config files worked fine for me (I changed the interface addresses
for my setup and didn't include the static route). By the way I wouldn't
expect to see any ospf routes, the two routers can already reach each
other.

    Atanu.

Xorp> show ospf4 neighbor 
  Address         Interface             State      ID              Pri  Dead
10.0.1.5         fxp1/fxp1              Full      10.0.0.1         128    33

Xorp> show ospf4 neighbor 
  Address         Interface             State      ID              Pri  Dead
10.0.1.1         xl0/xl0                Full      10.0.0.2         128    35

D>>>>> "Dinesh" == Dinesh Kumar <reach_dinesh at hotmail.com> writes:
    Dinesh> ear XORP users,

    Dinesh> I have configured OSPF using xorp between 2 PCs running linux. I am not able to see any OSPF neighbours in the xorp shell (xorpsh) in both the PCs.

    Dinesh> PC1:(using config1.boot)
    Dinesh> ------------------------------
    Dinesh> dinesh at linux-xorp> show ospf4 neighbor
    Dinesh> Address         Interface             State      ID              Pri  Dead
    Dinesh> dinesh at linux-xorp>

    Dinesh> dinesh at linux-xorp> show route table ipv4 unicast ospf
    Dinesh> dinesh at linux-xorp>

    Dinesh> dinesh at linux-xorp> show ospf4 database
    Dinesh> OSPF link state database, Area 0.0.0.0
    Dinesh> Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
    Dinesh> Router  *10.0.0.2         10.0.0.2         0x80000001   105  0x2  0x260a  36
    Dinesh> dinesh at linux-xorp>


    Dinesh> I am really not sure why there is no adjacency between these two PCs. I have checked the reachability between them also.

    Dinesh> From PC1 to PC2:
    Dinesh> -----------------------
    Dinesh> dinesh at linux-xorp> ping 10.0.0.1
    Dinesh> PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
    Dinesh> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=3.54 ms
    Dinesh> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.204 ms
    Dinesh> 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.212 ms
    Dinesh> 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.204 ms

    Dinesh> Command interrupted!

    Dinesh> dinesh at linux-xorp>

    Dinesh> From PC2 to PC1:
    Dinesh> ----------------------
    Dinesh> dinesh at linux-xorp2> ping 10.0.0.2
    Dinesh> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
    Dinesh> 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.191 ms
    Dinesh> 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.182 ms
    Dinesh> 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.177 ms

    Dinesh> Command interrupted!

    Dinesh> dinesh at linux-xorp2>

    Dinesh> I have attached the config.boot files of both the PCs. I would be very much obliged if somebody can point out if i have missed anything in config.boot. Thanks in advance.

    Dinesh> Regards,
    Dinesh> Dinesh

    Dinesh> _________________________________________________________________
    Dinesh> Get your free suite of Windows Live services today!
    Dinesh> http://www.get.live.com/wl/all_______________________________________________
    Dinesh> Xorp-users mailing list
    Dinesh> Xorp-users at xorp.org
    Dinesh> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From reach_dinesh at hotmail.com  Wed Dec 26 20:12:27 2007
From: reach_dinesh at hotmail.com (Dinesh Kumar)
Date: Thu, 27 Dec 2007 12:12:27 +0800
Subject: [Xorp-users] Missing OSPF neighbours
In-Reply-To: <19110.1198708018@tigger.icir.org>
References: Message from Dinesh Kumar <reach_dinesh@hotmail.com>    of 
	<19110.1198708018@tigger.icir.org>
Message-ID: <BLU104-W171674F6C640A2849FC62DF0540@phx.gbl>


Hi Atanu,

Thank you so much for your reply. I tried removing the static routes and restarted the xorp_rtrmgr processes in both the PCs. But there is no adjacency yet.  Also, I am connecting two PCs through a cross-cable, ethernet to ethernet direct. 

dinesh at linux-xorp> show ospf4 neighbor
  Address         Interface             State      ID              Pri  Dead
dinesh at linux-xorp>      

But in one of the PC, I am getting the following error while starting xorp_rtrmgr process, which I did not notice it before.

[ 2007/12/27 12:02:34  ERROR xorp_fea:18805 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol
[ 2007/12/27 12:02:34  ERROR xorp_fea:18805 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol

Is this error related to forming adjacency between the PCs ?

Thanks,
Dinesh
----------------------------------------
> To: reach_dinesh at hotmail.com
> CC: xorp-users at xorp.org
> Subject: Re: [Xorp-users] Missing OSPF neighbours 
> From: atanu at icsi.berkeley.edu
> Date: Wed, 26 Dec 2007 14:26:58 -0800
> 
> Hi,
> 
> Your config files worked fine for me (I changed the interface addresses
> for my setup and didn't include the static route). By the way I wouldn't
> expect to see any ospf routes, the two routers can already reach each
> other.
> 
>     Atanu.
> 
> Xorp> show ospf4 neighbor 
>   Address         Interface             State      ID              Pri  Dead
> 10.0.1.5         fxp1/fxp1              Full      10.0.0.1         128    33
> 
> Xorp> show ospf4 neighbor 
>   Address         Interface             State      ID              Pri  Dead
> 10.0.1.1         xl0/xl0                Full      10.0.0.2         128    35
> 
> D>>>>> "Dinesh" == Dinesh Kumar  writes:
>     Dinesh> ear XORP users,
> 
>     Dinesh> I have configured OSPF using xorp between 2 PCs running linux. I am not able to see any OSPF neighbours in the xorp shell (xorpsh) in both the PCs.
> 
>     Dinesh> PC1:(using config1.boot)
>     Dinesh> ------------------------------
>     Dinesh> dinesh at linux-xorp> show ospf4 neighbor
>     Dinesh> Address         Interface             State      ID              Pri  Dead
>     Dinesh> dinesh at linux-xorp>
> 
>     Dinesh> dinesh at linux-xorp> show route table ipv4 unicast ospf
>     Dinesh> dinesh at linux-xorp>
> 
>     Dinesh> dinesh at linux-xorp> show ospf4 database
>     Dinesh> OSPF link state database, Area 0.0.0.0
>     Dinesh> Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
>     Dinesh> Router  *10.0.0.2         10.0.0.2         0x80000001   105  0x2  0x260a  36
>     Dinesh> dinesh at linux-xorp>
> 
> 
>     Dinesh> I am really not sure why there is no adjacency between these two PCs. I have checked the reachability between them also.
> 
>     Dinesh> From PC1 to PC2:
>     Dinesh> -----------------------
>     Dinesh> dinesh at linux-xorp> ping 10.0.0.1
>     Dinesh> PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
>     Dinesh> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=3.54 ms
>     Dinesh> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.204 ms
>     Dinesh> 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.212 ms
>     Dinesh> 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.204 ms
> 
>     Dinesh> Command interrupted!
> 
>     Dinesh> dinesh at linux-xorp>
> 
>     Dinesh> From PC2 to PC1:
>     Dinesh> ----------------------
>     Dinesh> dinesh at linux-xorp2> ping 10.0.0.2
>     Dinesh> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
>     Dinesh> 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.191 ms
>     Dinesh> 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.182 ms
>     Dinesh> 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.177 ms
> 
>     Dinesh> Command interrupted!
> 
>     Dinesh> dinesh at linux-xorp2>
> 
>     Dinesh> I have attached the config.boot files of both the PCs. I would be very much obliged if somebody can point out if i have missed anything in config.boot. Thanks in advance.
> 
>     Dinesh> Regards,
>     Dinesh> Dinesh
> 
>     Dinesh> _________________________________________________________________
>     Dinesh> Get your free suite of Windows Live services today!
>     Dinesh> http://www.get.live.com/wl/all_______________________________________________
>     Dinesh> Xorp-users mailing list
>     Dinesh> Xorp-users at xorp.org
>     Dinesh> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

_________________________________________________________________
Publish your photos to your Space easily with Photo Gallery.
http://www.get.live.com/wl/all


From joshihirenn at gmail.com  Fri Dec 28 22:58:46 2007
From: joshihirenn at gmail.com (hiren joshi)
Date: Sat, 29 Dec 2007 12:28:46 +0530
Subject: [Xorp-users] PIM-DM and Flood-and-Prune approach
Message-ID: <29820bf40712282258g66bd9dc9yd4d0220b32bdb601@mail.gmail.com>

Hello,

First, thanks for answering all my previous questions. Here is my current
question:

PIM-DM uses state-refresh mechanism to refresh the prune state of outgoing
interfaces of multicast routers.
This consumes bandwidth. What if we make the prune state sticky. Here is
what I want to say -

1. Initially traffic is flooded everywhere.
2. Those who do not want it, send Prune. Prune state will not be timed out.
3. If you have sent Prune previously and want the traffic now, send Graft.
4. If you have sent Graft previously and do not want the traffic now, send
Prune.

What can be the problem with this approach?
Basically I want to ask: why the prune state do have a finite lifetime. Why
the traffic is flooded everywhere when the prune timer expires?

Thanks.

-hiren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071229/cc620af5/attachment.html 

From pavlin at icir.org  Sat Dec 29 12:11:46 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 29 Dec 2007 12:11:46 -0800
Subject: [Xorp-users] PIM-DM and Flood-and-Prune approach
In-Reply-To: Message from "hiren joshi" <joshihirenn@gmail.com> of "Sat,
	29 Dec 2007 12:28:46 +0530."
	<29820bf40712282258g66bd9dc9yd4d0220b32bdb601@mail.gmail.com> 
Message-ID: <200712292011.lBTKBkZc007883@possum.icir.org>

hiren joshi <joshihirenn at gmail.com> wrote:

> Hello,
> 
> First, thanks for answering all my previous questions. Here is my current
> question:
> 
> PIM-DM uses state-refresh mechanism to refresh the prune state of outgoing
> interfaces of multicast routers.
> This consumes bandwidth. What if we make the prune state sticky. Here is
> what I want to say -
> 
> 1. Initially traffic is flooded everywhere.
> 2. Those who do not want it, send Prune. Prune state will not be timed out.
> 3. If you have sent Prune previously and want the traffic now, send Graft.
> 4. If you have sent Graft previously and do not want the traffic now, send
> Prune.
> 
> What can be the problem with this approach?
> Basically I want to ask: why the prune state do have a finite lifetime. Why
> the traffic is flooded everywhere when the prune timer expires?

This is not really XORP-related subject, so the PIM mailing list
would be more appropriate for that: pim at ietf.org

Anyway, here is some information on the subject.
One of the problems with the above approach is "reliability".
If a Graft or Prune packet is lost, then the forwarding state in the
upstream routers will be wrong. The forwarding state will be also be
wrong if a downstream router crashes without sending a Prune
message.

The so-called "soft state" routing protocols (incl. PIM-SM and
PIM-DM) use periodic messages so if a message is lost, the state
will be refreshed later by the periodic retransmission. Also, each
state has timeout so if it isn't refreshed after some period (e.g.,
if the transmitting router crashes), the state will be removed.

Hope that helps,
Pavlin