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
        Attache