From Prasanna.S@trilogy.com  Wed Aug  4 19:03:52 2004
From: Prasanna.S@trilogy.com (Prasanna.S@trilogy.com)
Date: Thu, 5 Aug 2004 00:33:52 +0630
Subject: [Xorp-users] query
Message-ID: <OFAAFAABA2.AB26275C-ON86256EE6.00632E83@trilogy.com>

This is a multipart message in MIME format.
--=_alternative 0063B810E5256EE6_=
Content-Type: text/plain; charset="us-ascii"

Can somebody elucidate the differences between click router and xorp and 
their relative merits and demerits? 
--=_alternative 0063B810E5256EE6_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Can somebody elucidate the differences between click router and xorp and their relative merits and demerits? </font>
--=_alternative 0063B810E5256EE6_=--

From kohler@CS.UCLA.EDU  Wed Aug  4 19:07:12 2004
From: kohler@CS.UCLA.EDU (Eddie Kohler)
Date: Wed, 4 Aug 2004 11:07:12 -0700
Subject: [Xorp-users] query
In-Reply-To: <OFAAFAABA2.AB26275C-ON86256EE6.00632E83@trilogy.com>
References: <OFAAFAABA2.AB26275C-ON86256EE6.00632E83@trilogy.com>
Message-ID: <1C0E5316-E641-11D8-B8A0-000A95A6D9BC@cs.ucla.edu>

Simply put, Click is a forwarding path, and XORP is a collection of 
user-level routing daemons.  XORP will eventually have the option of 
using Click as a flexible forwarding path, although the current 
released code uses FreeBSD's default forwarding path.

Eddie


On Aug 4, 2004, at 11:03 AM, Prasanna.S@trilogy.com wrote:

>
> Can somebody elucidate the differences between click router and xorp 
> and their relative merits and demerits?


From adam@hiddennet.net  Wed Aug  4 19:16:20 2004
From: adam@hiddennet.net (Adam Greenhalgh)
Date: Wed, 04 Aug 2004 19:16:20 +0100
Subject: [Xorp-users] query
In-Reply-To: <OFAAFAABA2.AB26275C-ON86256EE6.00632E83@trilogy.com>
References: <OFAAFAABA2.AB26275C-ON86256EE6.00632E83@trilogy.com>
Message-ID: <1091643380.8079.6.camel@localhost>

click is a unicast forwarding engine, it takes packets in and send them
out of the correct interface, based on the host operating systems
routing tables.

xorp is a routing engine, it is made up of a collection of routing
protocols (both unicast and multicast) and works out the routing table
which a forwarding engine such as click would use. xorp uses either the
freebsd or linux forwarding paths at the moment.

adam

On Thu, 2004-08-05 at 00:33 +0630, wrote:
> 
> Can somebody elucidate the differences between click router and xorp
> and their relative merits and demerits? 
-- 
Adam Greenhalgh <adam@hiddennet.net>


From manu@netbsd.org  Tue Aug 10 15:25:42 2004
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Tue, 10 Aug 2004 14:25:42 +0000
Subject: [Xorp-users] open ports
Message-ID: <20040810142542.GH5337@NetBSD.org>

Hi

I installed xorp-1.0 as an IPv4 PIM-SM router on NetBSD. It works fine,
apart from the bug #99 (if build with IPv6 enabled, it won't work on 
an IPv6-unaware kernel, ignoring the configuration directivea that disable 
IPv6s).

Now I have one last concern: it opens a lot of TCP ports:
$ netstat -na|grep LISTEN
tcp        0      0  193.54.89.1.64040      *.*                    LISTEN
tcp        0      0  193.54.89.1.64046      *.*                    LISTEN
tcp        0      0  193.54.89.1.64052      *.*                    LISTEN
tcp        0      0  193.54.89.1.64054      *.*                    LISTEN
tcp        0      0  193.54.89.1.64060      *.*                    LISTEN
tcp        0      0  193.54.89.1.64062      *.*                    LISTEN
tcp        0      0  193.54.89.1.64066      *.*                    LISTEN
tcp        0      0  *.12000                *.*                    LISTEN
tcp        0      0  193.54.89.1.64071      *.*                    LISTEN
tcp        0      0  193.54.89.1.64073      *.*                    LISTEN
tcp        0      0  193.54.89.1.64076      *.*                    LISTEN
tcp        0      0  193.54.89.1.64077      *.*                    LISTEN
tcp        0      0  193.54.89.1.64079      *.*                    LISTEN
tcp        0      0  127.0.0.1.19999        *.*                    LISTEN

I'm a bit paranoid on the security front, and I'm absolutely sure I 
want no remote control of xorp. How do I close these ports? Or at least,
how do I bind them only to 127.0.0.1?

-- 
Emmanuel Dreyfus
manu@netbsd.org

From orion@icir.org  Wed Aug 11 04:02:07 2004
From: orion@icir.org (Orion Hodson)
Date: Tue, 10 Aug 2004 20:02:07 -0700
Subject: [Xorp-users] open ports
In-Reply-To: <20040810142542.GH5337@NetBSD.org>
References: <20040810142542.GH5337@NetBSD.org>
Message-ID: <D4989E4B-EB42-11D8-8751-000A958D5B3A@icir.org>

On Aug 10, 2004, at 7:25 AM, Emmanuel Dreyfus wrote:

> Hi
>
> I installed xorp-1.0 as an IPv4 PIM-SM router on NetBSD. It works fine,
> apart from the bug #99 (if build with IPv6 enabled, it won't work on
> an IPv6-unaware kernel, ignoring the configuration directivea that 
> disable
> IPv6s).
>
> Now I have one last concern: it opens a lot of TCP ports:
> $ netstat -na|grep LISTEN
> tcp        0      0  193.54.89.1.64040      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64046      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64052      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64054      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64060      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64062      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64066      *.*                    
> LISTEN
> tcp        0      0  *.12000                *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64071      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64073      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64076      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64077      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64079      *.*                    
> LISTEN
> tcp        0      0  127.0.0.1.19999        *.*                    
> LISTEN
>
> I'm a bit paranoid on the security front, and I'm absolutely sure I
> want no remote control of xorp. How do I close these ports? Or at 
> least,
> how do I bind them only to 127.0.0.1?

The are ports used for IPC.  There's a co-ordinator process that 
advertises the ports to other xorp processes.  The default interface is 
chosen to be the first interface that matches some hardcoded criteria.  
The accept() code for each of these sockets checks the incoming IP and 
shouldn't accept connections that are not from the same interface 
address (and maybe loopback, I don't recall).  However, loopback would 
be better from a DDOS perspective.

The default IPC interface is accessed and modified through 
if_get_preferred and if_set_preferred (sockutil.{hh,cc}).  A revised 
version of the default interface picking code could check loopback 
first and use it if available and if not fall back to the current 
default value.

In general, having an argument for all XORP processes at the 
command-line to set this address would probably be useful.  It's a bit 
of tedious chore, but going the extra mile and adding a common 
command-line parser with standard argument handling would fix this and 
would be a good idea anyway.

Any takers?
	Orion




From jonny@jonny.eng.br  Wed Aug 11 15:54:17 2004
From: jonny@jonny.eng.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=)
Date: Wed, 11 Aug 2004 11:54:17 -0300
Subject: [Xorp-users] open ports
In-Reply-To: <D4989E4B-EB42-11D8-8751-000A958D5B3A@icir.org>
References: <20040810142542.GH5337@NetBSD.org> <D4989E4B-EB42-11D8-8751-000A958D5B3A@icir.org>
Message-ID: <411A3319.4040800@jonny.eng.br>

Orion Hodson wrote:
> On Aug 10, 2004, at 7:25 AM, Emmanuel Dreyfus wrote:
> 
>> Hi
>>
>> I installed xorp-1.0 as an IPv4 PIM-SM router on NetBSD. It works fine,
>> apart from the bug #99 (if build with IPv6 enabled, it won't work on
>> an IPv6-unaware kernel, ignoring the configuration directivea that 
>> disable
>> IPv6s).
>>
>> Now I have one last concern: it opens a lot of TCP ports:
>> $ netstat -na|grep LISTEN
>> tcp        0      0  193.54.89.1.64040      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64046      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64052      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64054      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64060      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64062      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64066      *.*                    LISTEN
>> tcp        0      0  *.12000                *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64071      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64073      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64076      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64077      *.*                    LISTEN
>> tcp        0      0  193.54.89.1.64079      *.*                    LISTEN
>> tcp        0      0  127.0.0.1.19999        *.*                    LISTEN
>>
>> I'm a bit paranoid on the security front, and I'm absolutely sure I
>> want no remote control of xorp. How do I close these ports? Or at least,
>> how do I bind them only to 127.0.0.1?
> 
> 
> The are ports used for IPC.  There's a co-ordinator process that 
> advertises the ports to other xorp processes.  The default interface is 
> chosen to be the first interface that matches some hardcoded criteria.  
> The accept() code for each of these sockets checks the incoming IP and 
> shouldn't accept connections that are not from the same interface 
> address (and maybe loopback, I don't recall).  However, loopback would 
> be better from a DDOS perspective.

     Unix domain sockets would be even better...

     If TCP sockets must be used for portability purposes, then loopback 
is the way.  If remote monitoring and control are needed, then this 
shuld be the last option, and the binding IP address should be 
configured by the user.

> The default IPC interface is accessed and modified through 
> if_get_preferred and if_set_preferred (sockutil.{hh,cc}).  A revised 
> version of the default interface picking code could check loopback first 
> and use it if available and if not fall back to the current default value.
> 
> In general, having an argument for all XORP processes at the 
> command-line to set this address would probably be useful.  It's a bit 
> of tedious chore, but going the extra mile and adding a common 
> command-line parser with standard argument handling would fix this and 
> would be a good idea anyway.

     Very good from an user's perspective.



From doesnotcount@hotmail.com  Wed Aug 11 18:05:32 2004
From: doesnotcount@hotmail.com (Nathan K)
Date: Wed, 11 Aug 2004 13:05:32 -0400
Subject: [Xorp-users] MD5 Support
Message-ID: <BAY19-F146mTBb5VYUd0002573c@hotmail.com>

Are there plans (or work in progress) to support TCP MD5 connectivity 
between BGP Peer Routers?

-Nathan.

_________________________________________________________________
Take advantage of powerful junk e-mail filters built on patented Microsoft® 
SmartScreen Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.


From atanu@ICSI.Berkeley.EDU  Wed Aug 11 18:41:04 2004
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 11 Aug 2004 10:41:04 -0700
Subject: [Xorp-users] MD5 Support
In-Reply-To: Message from "Nathan K" <doesnotcount@hotmail.com>
 of "Wed, 11 Aug 2004 13:05:32 EDT." <BAY19-F146mTBb5VYUd0002573c@hotmail.com>
Message-ID: <88315.1092246064@tigger.icir.org>

We are working on putting in some TCP MD5 support. Initially it will only
work with FreeBSD.

In what context would you use this feature?

   Atanu.

>>>>> "Nathan" == Nathan K <doesnotcount@hotmail.com> writes:

    Nathan> Are there plans (or work in progress) to support TCP MD5
    Nathan> connectivity between BGP Peer Routers?

    Nathan> -Nathan.

    Nathan> _________________________________________________________________
    Nathan> Take advantage of powerful junk e-mail filters built on
    Nathan> patented Microsoft® SmartScreen
    Nathan> Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines
    Nathan> Start enjoying all the benefits of MSN® Premium right now
    Nathan> and get the first two months FREE*.

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

From doesnotcount@hotmail.com  Wed Aug 11 20:09:37 2004
From: doesnotcount@hotmail.com (Nathan K)
Date: Wed, 11 Aug 2004 15:09:37 -0400
Subject: [Xorp-users] MD5 Support
Message-ID: <BAY19-F21dtPBA6pLSQ0002656f@hotmail.com>

Definately in a FreeBSD context. Although we may be using an older version 
of FreeBSD that we have written MD5 support for ourselves.


>From: Atanu Ghosh <atanu@ICSI.Berkeley.EDU>
>Reply-To: atanu@ICSI.Berkeley.EDU
>To: "Nathan K" <doesnotcount@hotmail.com>
>CC: xorp-users@xorp.org
>Subject: Re: [Xorp-users] MD5 Support Date: Wed, 11 Aug 2004 10:41:04 -0700
>
>We are working on putting in some TCP MD5 support. Initially it will only
>work with FreeBSD.
>
>In what context would you use this feature?
>
>    Atanu.
>
> >>>>> "Nathan" == Nathan K <doesnotcount@hotmail.com> writes:
>
>     Nathan> Are there plans (or work in progress) to support TCP MD5
>     Nathan> connectivity between BGP Peer Routers?
>
>     Nathan> -Nathan.
>
>     Nathan> 
>_________________________________________________________________
>     Nathan> Take advantage of powerful junk e-mail filters built on
>     Nathan> patented Microsoft® SmartScreen
>     Nathan> Technology. 
>http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines
>     Nathan> Start enjoying all the benefits of MSN® Premium right now
>     Nathan> and get the first two months FREE*.
>
>     Nathan> _______________________________________________ Xorp-users
>     Nathan> mailing list Xorp-users@xorp.org
>     Nathan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>_______________________________________________
>Xorp-users mailing list
>Xorp-users@xorp.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

_________________________________________________________________
Designer Mail isn't just fun to send, it's fun to receive. Use special 
stationery, fonts and colors. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.


From manu@netbsd.org  Wed Aug 11 17:03:59 2004
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Wed, 11 Aug 2004 16:03:59 +0000
Subject: [Xorp-users] open ports
In-Reply-To: <411A3319.4040800@jonny.eng.br>
References: <20040810142542.GH5337@NetBSD.org> <D4989E4B-EB42-11D8-8751-000A958D5B3A@icir.org> <411A3319.4040800@jonny.eng.br>
Message-ID: <20040811160359.GN5337@NetBSD.org>

On Wed, Aug 11, 2004 at 11:54:17AM -0300, João Carlos Mendes Luís wrote:
>     Unix domain sockets would be even better...

I'd appreciate Unix sockets. That ensures communication remain local, 
whetever mess you can have in the network stack..

-- 
Emmanuel Dreyfus
manu@netbsd.org

From Orion Hodson <oho@acm.org>  Thu Aug 12 03:42:06 2004
From: Orion Hodson <oho@acm.org> (Orion Hodson)
Date: Wed, 11 Aug 2004 19:42:06 -0700
Subject: [Xorp-users] open ports
In-Reply-To: <411A3319.4040800@jonny.eng.br>
References: <20040810142542.GH5337@NetBSD.org> <D4989E4B-EB42-11D8-8751-000A958D5B3A@icir.org> <411A3319.4040800@jonny.eng.br>
Message-ID: <3311292C-EC09-11D8-8751-000A958D5B3A@icir.org>

On Aug 11, 2004, at 7:54 AM, João Carlos Mendes Luís wrote:
>
> Orion Hodson wrote:
>   However, loopback would be better from a DDOS perspective.
>
>     Unix domain sockets would be even better...
>
>     If TCP sockets must be used for portability purposes, then 
> loopback is the way.  If remote monitoring and control are needed, 
> then this shuld be the last option, and the binding IP address should 
> be configured by the user.

Unix domain sockets would be useful to have.  The reason UNIX domain 
sockets don't exist as an IPC scheme already is largely a question of 
resources.  If somebody is interested, then writing a Unix domain 
socket protocol family for XORP's IPC system is a smallish well-defined 
piece of work with several existing examples (inproc, udp, and esp. 
tcp).  AFAIK, it's not something that is slated to be done in the near 
future by the core team.

If anybody is interested in doing this send a note to 
xorp-hackers@xorp.org or feedback@xorp.org.

- Orion



From bms@spc.org  Thu Aug 12 05:07:45 2004
From: bms@spc.org (Bruce M Simpson)
Date: Wed, 11 Aug 2004 21:07:45 -0700
Subject: [Xorp-users] MD5 Support
In-Reply-To: <BAY19-F146mTBb5VYUd0002573c@hotmail.com>
References: <BAY19-F146mTBb5VYUd0002573c@hotmail.com>
Message-ID: <20040812040745.GA781@empiric.icir.org>

--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[Crossposted to freebsd-net by way of FAQ material]

On Wed, Aug 11, 2004 at 01:05:32PM -0400, Nathan K wrote:
> Are there plans (or work in progress) to support TCP MD5 connectivity=20
> between BGP Peer Routers?

This is likely to be an FAQ, so please consider this message authoritative
FAQ material for the time being.

I committed preliminary support for this to XORP over the past week. This
is more or less a direct port of the work I did on Quagga.

Currently there are some restrictions.

1) All the XORP support does is enable and disable the use of the TCP_MD5SIG
   socket option for BGP *active opens*, that is, outgoing peer connections.

   This socket option is 'de facto' standardized across the open source BSD=
s.
   The password argument is effectively ignored, just as for the Quagga
   support. This will not be the case in future, hopefully (see below).

2) You will need to set up a security association containing the key for
   the TCP-MD5 session via the use of the setkey(8) command on FreeBSD.

   The means for doing this will vary across BSDs; I believe ipsecadm(8)
   is appropriate for OpenBSD, whereas setkey(8) will work on NetBSD.

   On FreeBSD, there is an example in the setkey(8) man page.

Future Directions for XORP
--------------------------

What I'd like to do in future is introduce PF_KEY support to XORP, probably
as an extension of the infrastructure which the FEA module provides.

The reasons for this are twofold. One, it will allow XORP to control
TCP-MD5 security associations directly. Two, it will provide us with the
infrastructure needed to control things like IPSEC associations in future
if we chose to introduce this functionality into XORP.

As PF_KEY is somewhat standardized (RFC 2367 Informational) and well
documented (UNIX Network Programming Vol1 2e Fenner et al) this is a
portable way of achieving this across the BSDs. Linux (FreeS/WAN et
cetera) may be another story.

Future Directions for TCP-MD5
-----------------------------

Recently, itojun considerably expanded on my work, in the NetBSD tree. I
have a crossport of this further work to the FreeBSD tree which is almost
complete but needs further testing. This adds support for KAME IPSEC as
well as FAST_IPSEC, and TCP over IPv6, and the input verification path.

This work will not be merged into FreeBSD until after the 5.3 branch.

There are a few issues with the current state of this work in that it's
impossible to conduct non-TCP-MD5 and TCP-MD5 protected sessions over the
same TCP socket in LISTEN state without effectively denying non-TCPMD5
connections.

This is the reason for the unavailability of TCP-MD5 with regards to
BGP passive opens at this time.

I have a fork of my original code which attempts to address this by placing
policies into the SPD, rather than relying on a TCP protocol-level socket
option. itojun's further hacking makes the SPD method easier to implement.

The SPD fork of my patch set is unstable.

The reason for this is that SPI granularity is impossible with TCP, as it
has no notion of an SPI field, which is specific to IPSEC AH/ESP.

This would however require that applications such as Quagga and XORP speak
fluent PF_KEY in the BSD dialect.

Regards,
BMS

--82I3+IH0IqGh5yIs
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Comment: ''

iD8DBQFBGu0QueUpAYYNtTsRArjiAJ0SHCP7LDBUonHWDO+XfPNfQsEUWgCgnJPM
xmLRquk0wbsJWltBMnn8RvY=
=EnyM
-----END PGP SIGNATURE-----

--82I3+IH0IqGh5yIs--

From bms@spc.org  Thu Aug 12 05:09:56 2004
From: bms@spc.org (Bruce M Simpson)
Date: Wed, 11 Aug 2004 21:09:56 -0700
Subject: [Xorp-users] MD5 Support
In-Reply-To: <BAY19-F21dtPBA6pLSQ0002656f@hotmail.com>
References: <BAY19-F21dtPBA6pLSQ0002656f@hotmail.com>
Message-ID: <20040812040956.GB781@empiric.icir.org>

On Wed, Aug 11, 2004 at 03:09:37PM -0400, Nathan K wrote:
> Definately in a FreeBSD context. Although we may be using an older version 
> of FreeBSD that we have written MD5 support for ourselves.

I'd be very interested to see this, if you're willing to share.

BMS

From bms@spc.org  Thu Aug 12 05:13:27 2004
From: bms@spc.org (Bruce M Simpson)
Date: Wed, 11 Aug 2004 21:13:27 -0700
Subject: [Xorp-users] open ports
In-Reply-To: <20040811160359.GN5337@NetBSD.org>
References: <20040810142542.GH5337@NetBSD.org> <D4989E4B-EB42-11D8-8751-000A958D5B3A@icir.org> <411A3319.4040800@jonny.eng.br> <20040811160359.GN5337@NetBSD.org>
Message-ID: <20040812041327.GC781@empiric.icir.org>

On Wed, Aug 11, 2004 at 04:03:59PM +0000, Emmanuel Dreyfus wrote:
> On Wed, Aug 11, 2004 at 11:54:17AM -0300, João Carlos Mendes Luís wrote:
> >     Unix domain sockets would be even better...
> 
> I'd appreciate Unix sockets. That ensures communication remain local, 
> whetever mess you can have in the network stack..

I'd say: localhost-bound PF_INET sockets considered more desirable right now.

I can see us having problems with PF_UNIX on non-UNIX platforms, and support
for such platforms is planned.

BMS

From pavlin@icir.org  Thu Aug 12 23:47:24 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 12 Aug 2004 15:47:24 -0700
Subject: [Xorp-users] open ports
In-Reply-To: Message from Emmanuel Dreyfus <manu@netbsd.org>
 of "Tue, 10 Aug 2004 14:25:42 -0000." <20040810142542.GH5337@NetBSD.org>
Message-ID: <200408122247.i7CMlOwK007184@possum.icir.org>

> I installed xorp-1.0 as an IPv4 PIM-SM router on NetBSD. It works fine,
> apart from the bug #99 (if build with IPv6 enabled, it won't work on 
> an IPv6-unaware kernel, ignoring the configuration directivea that disable 
> IPv6s).

Just curious, do you really mean IPv4 PIM-SM router, or is it IPv6?

The reason I ask this is because currently NetBSD doesn't have PIM
kernel support for IPv4 (but only for IPv6). Hence, it could appear
that PIM-SM for IPv4 is working on NetBSD, but it reality it
wouldn't. E.g., the PIM-SM+MFEA modules may send and receive PIM-SM
control messages (and even manage to install multicast forwarding
cache in the kernel), but the special PIM Register vif (needed for
handling the PIM Register encapsulated packets) wouldn't be handled
properly, because it requires some kernel support.

Sigh, there should have been an explicit check with an appropriate
error message whether the underlying system really supports PIM...

Pavlin

P.S. Bug #99 is fixed in the CVS repository.

From doesnotcount@hotmail.com  Fri Aug 13 17:33:00 2004
From: doesnotcount@hotmail.com (Nathan K)
Date: Fri, 13 Aug 2004 12:33:00 -0400
Subject: [Xorp-users] MD5 Support
Message-ID: <BAY19-F10NTxGtc0tdf000349f8@hotmail.com>

Honestly I would be willing to share but I don't know if the guys on the 
other team that wrote it would be willing to share. I'll see what I can do, 
if something progresses I'll let you know.


>From: Bruce M Simpson <bms@spc.org>
>To: Nathan K <doesnotcount@hotmail.com>
>CC: atanu@ICSI.Berkeley.EDU, xorp-users@xorp.org
>Subject: Re: [Xorp-users] MD5 Support
>Date: Wed, 11 Aug 2004 21:09:56 -0700
>
>On Wed, Aug 11, 2004 at 03:09:37PM -0400, Nathan K wrote:
> > Definately in a FreeBSD context. Although we may be using an older 
>version
> > of FreeBSD that we have written MD5 support for ourselves.
>
>I'd be very interested to see this, if you're willing to share.
>
>BMS

_________________________________________________________________
Powerful Parental Controls Let your child discover the best the Internet has 
to offer.  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.


From vjardin@free.fr  Fri Aug 13 18:39:23 2004
From: vjardin@free.fr (Vincent Jardin)
Date: Fri, 13 Aug 2004 19:39:23 +0200
Subject: [Xorp-users] MD5 Support
In-Reply-To: <20040812040745.GA781@empiric.icir.org>
References: <BAY19-F146mTBb5VYUd0002573c@hotmail.com> <20040812040745.GA781@empiric.icir.org>
Message-ID: <200408131939.30875.vjardin@free.fr>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Future Directions for XORP
> --------------------------
>
> As PF_KEY is somewhat standardized (RFC 2367 Informational) and well
> documented (UNIX Network Programming Vol1 2e Fenner et al) this is a
> portable way of achieving this across the BSDs. Linux (FreeS/WAN et
> cetera) may be another story.

FYI, Linux does support PF_KEY too.

>
> Future Directions for TCP-MD5
> -----------------------------
>
> This would however require that applications such as Quagga and XORP speak
> fluent PF_KEY in the BSD dialect.

I think that the routing protocols will have to speak fluently PF_KEY because 
even for OSPFv2/MD5 or RIP/MD5 the keys could be provided by a "key daemon". 
This concept is already described by the RFC 2367, section 1.2 and section 
5.3 (OSPF Securrity Example).

Regards,
  Vincent
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFBHPzRj1uHAMmANdgRAprWAKDtG8oLQUa7SevIgqVNyjZpzsguoACfZMUy
LsKFJkGeWhH+lhXNZw7ShA4=
=Lvtl
-----END PGP SIGNATURE-----


From pavlin@icir.org  Fri Aug 13 21:02:18 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 13 Aug 2004 13:02:18 -0700
Subject: [Xorp-users] open ports
In-Reply-To: Message from manu@netbsd.org (Emmanuel Dreyfus)
 of "Fri, 13 Aug 2004 08:23:18 +0200." <1gig6rz.g739pi182fut4M%manu@netbsd.org>
Message-ID: <200408132002.i7DK2IwK016765@possum.icir.org>

> > Just curious, do you really mean IPv4 PIM-SM router, or is it IPv6?
> 
> It's IPv4 PIM-SM. 
>  
> > The reason I ask this is because currently NetBSD doesn't have PIM
> > kernel support for IPv4 (but only for IPv6). 
> 
> There are unintegrated PIM patches available, I'm running them.
> Moreover, xorp is running with igmp disabled and dr-priority = 0. Thus
> it never have to send encapsulated mulicast packets, the upstream and
> dowtream routers always handle that.
> 
> Is it possible that this configuration could work without the kernel PIM
> patches? It only have to exchange PIM packets with neightbors and
> install multicast routes.

If you are running PIM-SM as you describe above, and if you are not
the RP, then yes, you don't need the kernel support for PIM
Registers. In that case the only thing you need from the kernel is
to deliver to you the PIM control packets which I guess it can do
without any additional patches.

Hence, I would like to say that you can run PIM-SM without PIM
kernel patches, but myself I have never tried it and there could be
some surprises. For example, the *BSD kernels have a PIM-SM specific
bug regarding handing the delivery of the IGMPMSG_WRONGVIF upcalls
from the kernel to user-space (the signal is delivered only if the
network interface is broadcast capable). If you put this into the
PIM context, this means that if your NetBSD router is on the
cross-path between the source-specific tree and the shared tree, and
it uses p2p links, it may never complete the SPT switch: the SPT
data will be arriving to that router, but it will be dropped
there. Though, the downstream receivers will still be receiving the
data on the shared tree so you wouldn't observe any connectivity
problems; i.e., the only downside of this is the extra wasted bw on
the SPT that is not needed, and the fact that the data would be
arriving via the RP rather than the shortest path.

Another example that comes to mind is if some of your PIM-SM
neighbors on a LAN don't support the optional DR Priority Option. In
that case the dr-priority is not considered in the DR election,
hence your XORP router may still become the DR (if it has the
numerically largest IP address on the LAN). Hence, if that LAN has
senders, the XORP router running on non-modified kernel won't be
able to take care of transmitting the PIM Register packets.

Regards,
Pavlin

From manu@netbsd.org  Fri Aug 13 07:23:18 2004
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Fri, 13 Aug 2004 08:23:18 +0200
Subject: [Xorp-users] open ports
In-Reply-To: <200408122247.i7CMlOwK007184@possum.icir.org>
Message-ID: <1gig6rz.g739pi182fut4M%manu@netbsd.org>

Pavlin Radoslavov <pavlin@icir.org> wrote:

> Just curious, do you really mean IPv4 PIM-SM router, or is it IPv6?

It's IPv4 PIM-SM. 
 
> The reason I ask this is because currently NetBSD doesn't have PIM
> kernel support for IPv4 (but only for IPv6). 

There are unintegrated PIM patches available, I'm running them.
Moreover, xorp is running with igmp disabled and dr-priority = 0. Thus
it never have to send encapsulated mulicast packets, the upstream and
dowtream routers always handle that.

Is it possible that this configuration could work without the kernel PIM
patches? It only have to exchange PIM packets with neightbors and
install multicast routes.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@netbsd.org

From atanu@ICSI.Berkeley.EDU  Fri Aug 13 21:18:11 2004
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Fri, 13 Aug 2004 13:18:11 -0700
Subject: [Xorp-users] open ports
In-Reply-To: Message from Orion Hodson <orion@icir.org>
 of "Tue, 10 Aug 2004 20:02:07 PDT." <D4989E4B-EB42-11D8-8751-000A958D5B3A@icir.org>
Message-ID: <91510.1092428291@tigger.icir.org>

Another problem that has been reported is that if the interface that has
been choosen is taken down the the router stops working.

<http://www.xorp.org/bugzilla/show_bug.cgi?id=94>.

	Atanu.

>>>>> "Orion" == Orion Hodson <orion@icir.org> writes:

    Orion> On Aug 10, 2004, at 7:25 AM, Emmanuel Dreyfus wrote:

    >> Hi
    >> 
    >> I installed xorp-1.0 as an IPv4 PIM-SM router on NetBSD. It works fine,
    >> apart from the bug #99 (if build with IPv6 enabled, it won't work on
    >> an IPv6-unaware kernel, ignoring the configuration directivea that
    >> disable
    >> IPv6s).
    >> 
    >> Now I have one last concern: it opens a lot of TCP ports:
    >> $ netstat -na|grep LISTEN
    >> tcp        0      0  193.54.89.1.64040      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64046      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64052      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64054      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64060      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64062      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64066      *.*
    >> LISTEN
    >> tcp        0      0  *.12000                *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64071      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64073      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64076      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64077      *.*
    >> LISTEN
    >> tcp        0      0  193.54.89.1.64079      *.*
    >> LISTEN
    >> tcp        0      0  127.0.0.1.19999        *.*
    >> LISTEN
    >> 
    >> I'm a bit paranoid on the security front, and I'm absolutely sure I
    >> want no remote control of xorp. How do I close these ports? Or at
    >> least,
    >> how do I bind them only to 127.0.0.1?

    Orion> The are ports used for IPC.  There's a co-ordinator process that
    Orion> advertises the ports to other xorp processes.  The default interface
    Orion> is chosen to be the first interface that matches some hardcoded
    Orion> criteria.  The accept() code for each of these sockets checks the
    Orion> incoming IP and shouldn't accept connections that are not from the
    Orion> same interface address (and maybe loopback, I don't recall).  However,
    Orion> loopback would be better from a DDOS perspective.

    Orion> The default IPC interface is accessed and modified through
    Orion> if_get_preferred and if_set_preferred (sockutil.{hh,cc}).  A revised
    Orion> version of the default interface picking code could check loopback
    Orion> first and use it if available and if not fall back to the current
    Orion> default value.

    Orion> In general, having an argument for all XORP processes at the
    Orion> command-line to set this address would probably be useful.  It's a bit
    Orion> of tedious chore, but going the extra mile and adding a common
    Orion> command-line parser with standard argument handling would fix this and
    Orion> would be a good idea anyway.

    Orion> Any takers?
    Orion> Orion



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

From pavlin@icir.org  Fri Aug 13 21:35:53 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 13 Aug 2004 13:35:53 -0700
Subject: [Xorp-users] open ports
In-Reply-To: Message from manu@netbsd.org (Emmanuel Dreyfus)
 of "Fri, 13 Aug 2004 08:23:18 +0200." <1gig6rz.g739pi182fut4M%manu@netbsd.org>
Message-ID: <200408132035.i7DKZrwK017050@possum.icir.org>

> Pavlin Radoslavov <pavlin@icir.org> wrote:
> 
> > Just curious, do you really mean IPv4 PIM-SM router, or is it IPv6?
> 
> It's IPv4 PIM-SM. 
>  
> > The reason I ask this is because currently NetBSD doesn't have PIM
> > kernel support for IPv4 (but only for IPv6). 
> 
> There are unintegrated PIM patches available, I'm running them.

Interesting. Is it a recent patch from say, the FreeBSD PIM kernel
patches that support the advanced multicast API or is this an
independent patch?

FYI, approximately a month ago I did a port of the FreeBSD PIM
kernel patches to OpenBSD (the choice of porting first to OpenBSD
rather than NetBSD was based on a specific user's request :)

My original intention was that once the patch makes it into OpenBSD,
then I will port the patch to NetBSD as well. The idea was that by
doing it sequentially I can incorporate the feedbacks from the
OpenBSD folks into the NetBSD port so both patches can be kept
reasonably in sync. You can get my original email with the links to
the patch from the following URL:

http://www.sigmasoft.com/~openbsd/archive/openbsd-tech/200407/msg00145.html

Though, the OpenBSD patch hasn't been incorporated yet, so that had
delayed my attempt to work on the NetBSD port.
Unfortunately, due to time constraints I may not be able to work
immediately on the NetBSD port.

If you know someone who can port the OpenBSD patch to NetBSD I will
be glad to pass the token. Otherwise, can you give me some rough
estimation (from NetBSD release schedule point of view) when would
be good time to do the port. The reason I ask is because if I am to
do the port I will be doing it for NetBSD-current, and if the CVS
repository is feature-freezed waiting for the next release to
happen, then I'd like to avoid updating the patches to keep-up with
NetBSD-current.

Thanks,
Pavlin

From manu@netbsd.org  Fri Aug 13 21:10:04 2004
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Fri, 13 Aug 2004 22:10:04 +0200
Subject: [Xorp-users] open ports
In-Reply-To: <200408132002.i7DK2IwK016765@possum.icir.org>
Message-ID: <1gih9g5.18pj5m1442fnnM%manu@netbsd.org>

Pavlin Radoslavov <pavlin@icir.org> wrote:

> If you are running PIM-SM as you describe above, and if you are not
> the RP, then yes, you don't need the kernel support for PIM
> Registers. In that case the only thing you need from the kernel is
> to deliver to you the PIM control packets which I guess it can do
> without any additional patches.

I tried it this afternoon, and it doesn't work. I can get some multicast
streams with an extra delay (about 10-20 seconds) and other streams are
just unavailable. 
 
> Another example that comes to mind is if some of your PIM-SM
> neighbors on a LAN don't support the optional DR Priority Option. In
> that case the dr-priority is not considered in the DR election,
> hence your XORP router may still become the DR (if it has the
> numerically largest IP address on the LAN). 

The machine has x.x.x.1 on one interface and x.x.y.1 on the other one :)

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@netbsd.org

From pavlin@icir.org  Fri Aug 13 21:47:39 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 13 Aug 2004 13:47:39 -0700
Subject: [Xorp-users] open ports
In-Reply-To: Message from manu@netbsd.org (Emmanuel Dreyfus)
 of "Fri, 13 Aug 2004 22:10:04 +0200." <1gih9g5.18pj5m1442fnnM%manu@netbsd.org>
Message-ID: <200408132047.i7DKldwK017158@possum.icir.org>

> Pavlin Radoslavov <pavlin@icir.org> wrote:
> 
> > If you are running PIM-SM as you describe above, and if you are not
> > the RP, then yes, you don't need the kernel support for PIM
> > Registers. In that case the only thing you need from the kernel is
> > to deliver to you the PIM control packets which I guess it can do
> > without any additional patches.
> 
> I tried it this afternoon, and it doesn't work. I can get some multicast
> streams with an extra delay (about 10-20 seconds) and other streams are
> just unavailable. 

Is this with vanilla NetBSD, or is this with the PIM kernel patches
you have?

If it is with vanilla NetBSD, it is difficult to say whether the
problem is because of the kernel or because of something else
without looking into the xorpsh CLI output, debug messages, etc.

Though, instead of debugging the problem with vanilla kernel, I'd
recommend that the effort is spent on porting the PIM patches into
the NetBSD kernel (e.g., see my previous email in this thread).

Regards,
Pavlin

From manu@netbsd.org  Fri Aug 13 21:59:20 2004
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Fri, 13 Aug 2004 22:59:20 +0200
Subject: [Xorp-users] open ports
In-Reply-To: <200408132047.i7DKldwK017158@possum.icir.org>
Message-ID: <1gihbp3.zhvzax1ldcwniM%manu@netbsd.org>

Pavlin Radoslavov <pavlin@icir.org> wrote:

> > I tried it this afternoon, and it doesn't work. I can get some multicast
> > streams with an extra delay (about 10-20 seconds) and other streams are
> > just unavailable. 
> 
> Is this with vanilla NetBSD, or is this with the PIM kernel patches
> you have?

This is with vanilla kernel. With PIM patches everything works almost
immediatly.
 
> Though, instead of debugging the problem with vanilla kernel, I'd
> recommend that the effort is spent on porting the PIM patches into
> the NetBSD kernel (e.g., see my previous email in this thread).

I agree: IPv4 PIM support should be added to the NetBSD kernel, that's
The Right Way to go.  

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@netbsd.org

From Hitoshi.Asaeda@sophia.inria.fr  Fri Aug 13 23:56:55 2004
From: Hitoshi.Asaeda@sophia.inria.fr (Hitoshi Asaeda)
Date: Sat, 14 Aug 2004 00:56:55 +0200 (MEST)
Subject: [Xorp-users] open ports
In-Reply-To: <200408132047.i7DKldwK017158@possum.icir.org>
References: <1gih9g5.18pj5m1442fnnM%manu@netbsd.org>
 <200408132047.i7DKldwK017158@possum.icir.org>
Message-ID: <20040814.005655.41651110.Hitoshi.Asaeda@sophia.inria.fr>

> Is this with vanilla NetBSD, or is this with the PIM kernel patches
> you have?

Actually, I guess Pavlin and Manu have been talking about my previous
kernel patch for pimd.
Just for NetBSD stuff, I may be able to develop the new patch during
my spare time. Pavlin will also help us.:)
Stay tuned.
--
Hitoshi Asaeda

From doesnotcount@hotmail.com  Tue Aug 17 23:14:24 2004
From: doesnotcount@hotmail.com (Nathan K)
Date: Tue, 17 Aug 2004 18:14:24 -0400
Subject: [Xorp-users] Routing info
Message-ID: <BAY19-F1593Lx9w5dRu0004ebc9@hotmail.com>

What is the easiest way to get bgp's routes from the bgpd. Basically I need 
all the information that is usually generated by a "show ip bgp" command on 
a router. What is the best way to do this? Does an xrl call to the BGPD 
currently exist that could give me this information, or will I have to write 
one. And if I have to write one, where would this information be stored?

I also need to be able to get the routes for a specific community. Some 
routers offer a "show ip bgp community xx:xx::xx:xx" command to allow this.

Thanks for your help.

-Nathan.

_________________________________________________________________
Take advantage of powerful junk e-mail filters built on patented Microsoft® 
SmartScreen Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.


From M.Handley@cs.ucl.ac.uk  Wed Aug 18 00:25:44 2004
From: M.Handley@cs.ucl.ac.uk (Mark Handley)
Date: Wed, 18 Aug 2004 00:25:44 +0100
Subject: [Xorp-users] Routing info
In-Reply-To: Your message of "Tue, 17 Aug 2004 18:14:24 EDT." <BAY19-F1593Lx9w5dRu0004ebc9@hotmail.com>
Message-ID: <2387.1092785144@cs.ucl.ac.uk>

>What is the easiest way to get bgp's routes from the bgpd. Basically I need 
>all the information that is usually generated by a "show ip bgp" command on 
>a router. What is the best way to do this? Does an xrl call to the BGPD 
>currently exist that could give me this information, or will I have to write 
>one. And if I have to write one, where would this information be stored?

If you're asking how you get this from the CLI, there's a
not-quite-complete XORP user manual at
  http://nrg.cs.ucl.ac.uk/mjh/tmp/user_manual.pdf
The operational mode commands for BGP are listed around pages 71-74.
The basic command you need is "show bgp routes" and related subcommands.


If you're asking how you get this via an XRL interface, the place to
look is the source code for the command that implements "show bgp
routes".  This is in bgp/tools/print_routes.cc.  Note that it's not
one XRL, but multiple calls to get the whole BGP table.

>I also need to be able to get the routes for a specific community. Some 
>routers offer a "show ip bgp community xx:xx::xx:xx" command to allow this.

Currently there's no way to do this.  I agree there should be.  If you
really need this soon, can you submit a bugzilla report, to ensure it
stays on our radar.

 - Mark

From atanu@ICSI.Berkeley.EDU  Wed Aug 18 00:30:01 2004
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Tue, 17 Aug 2004 16:30:01 -0700
Subject: [Xorp-users] Routing info
In-Reply-To: Message from "Nathan K" <doesnotcount@hotmail.com>
 of "Tue, 17 Aug 2004 18:14:24 EDT." <BAY19-F1593Lx9w5dRu0004ebc9@hotmail.com>
Message-ID: <50893.1092785401@tigger.icir.org>

The XORP BGP process has a mechanism for returning the routing table via
XRLs. In the bgp/tools directory you will find a "print_routes" program
that uses the XRL interface to extract the routes from BGP. There is
another program "xorpsh_print_routes" that is used by the xorpsh to
print routes.

If you want to add the equivalent of "show ip bgp community" from within
the xorpsh then you need to take a look at the "bgp.cmds" in
etc/templates. As well as teaching "xorp_print_routes" about selecting
routes based on communities.

	Atanu.

>>>>> "Nathan" == Nathan K <doesnotcount@hotmail.com> writes:

    Nathan> What is the easiest way to get bgp's routes from the
    Nathan> bgpd. Basically I need all the information that is usually
    Nathan> generated by a "show ip bgp" command on a router. What is
    Nathan> the best way to do this? Does an xrl call to the BGPD
    Nathan> currently exist that could give me this information, or will
    Nathan> I have to write one. And if I have to write one, where would
    Nathan> this information be stored?

    Nathan> I also need to be able to get the routes for a specific
    Nathan> community. Some routers offer a "show ip bgp community
    Nathan> xx:xx::xx:xx" command to allow this.

    Nathan> Thanks for your help.

    Nathan> -Nathan.

    Nathan> _________________________________________________________________
    Nathan> Take advantage of powerful junk e-mail filters built on
    Nathan> patented Microsoft® SmartScreen
    Nathan> Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines
    Nathan> Start enjoying all the benefits of MSN® Premium right now
    Nathan> and get the first two months FREE*.

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

From doesnotcount@hotmail.com  Wed Aug 18 17:12:08 2004
From: doesnotcount@hotmail.com (Nathan K)
Date: Wed, 18 Aug 2004 12:12:08 -0400
Subject: [Xorp-users] connection to bgpd
Message-ID: <BAY19-F16wuAAMk0J4600054cb8@hotmail.com>

I'm writing a process that will communicate with the bgpd via xrls, however, 
in the case that that process fails, I need the bgpd to reset its state, 
(ie. retract all BGP Updates and disconnect from all bgp peers). Is there a 
way to have a persistent tcp connection between my process and the bgpd? If 
so, I could have the bgpd check the socket to see if the session has been 
ended and then reset state. Otherwise, I may have to implement a keep alive 
mechanism via xrl in which case I'd have a timer in the main loop that 
causes state reset upon a keep-alive timeout.

-Nathan.

_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen 
Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.


From atanu@ICSI.Berkeley.EDU  Wed Aug 18 19:07:34 2004
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 18 Aug 2004 11:07:34 -0700
Subject: [Xorp-users] connection to bgpd
In-Reply-To: Message from "Nathan K" <doesnotcount@hotmail.com>
 of "Wed, 18 Aug 2004 12:12:08 EDT." <BAY19-F16wuAAMk0J4600054cb8@hotmail.com>
Message-ID: <67952.1092852454@tigger.icir.org>

As a XORP router is composed of a number of processes we have a
mechanism for monitoring processes. Our IPC system monitors all processes
that register with it. Any process can be notified of the birth and
death events of any other process. I believe this is implemented with a
TCP connection.

One example of how this is used can be found in
bgp/process_watch.cc. The XORP BGP process registers interest in the FEA
,RIB and snmp process (if this exists BGP will send events to it). If
the FEA or RIB dies then BGP will shutdown.

As your process, lets call it N is using XRLs it will be registered with
the system. Therefore you could register interest in N and just take
whatever action you deem appropriate on birth/death events.

	 Atanu.

>>>>> "Nathan" == Nathan K <doesnotcount@hotmail.com> writes:

    Nathan> I'm writing a process that will communicate with the bgpd
    Nathan> via xrls, however, in the case that that process fails, I
    Nathan> need the bgpd to reset its state, (ie. retract all BGP
    Nathan> Updates and disconnect from all bgp peers). Is there a way
    Nathan> to have a persistent tcp connection between my process and
    Nathan> the bgpd? If so, I could have the bgpd check the socket to
    Nathan> see if the session has been ended and then reset
    Nathan> state. Otherwise, I may have to implement a keep alive
    Nathan> mechanism via xrl in which case I'd have a timer in the main
    Nathan> loop that causes state reset upon a keep-alive timeout.

    Nathan> -Nathan.

    Nathan> _________________________________________________________________
    Nathan> Take charge with a pop-up guard built on patented Microsoft®
    Nathan> SmartScreen
    Nathan> Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines
    Nathan> Start enjoying all the benefits of MSN® Premium right now
    Nathan> and get the first two months FREE*.

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

From crobson@cmf.nrl.navy.mil  Thu Aug 19 06:20:12 2004
From: crobson@cmf.nrl.navy.mil (Chris Robson)
Date: Thu, 19 Aug 2004 01:20:12 -0400
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
Message-ID: <6.1.2.0.2.20040819011202.02061ec0@ginger.cmf.nrl.navy.mil>

--=======7BB17866=======
Content-Type: text/plain; x-avg-checked=avg-ok-A7C6C9A; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit


First, this appears not to be a problem with XORP alone but so far as I can 
tell every implementation of the protocol stack and Linux 2.6, aka zebra 
and GATED (commerical) have the same problem.  PIM doesnt seem to reply to 
hello messages, aka no multicast routing is successful.  Yes, this isnt 
much and I apologies for what little information I'm giving here, just 
havent had the time to collect much more at this point.  What I really 
would like to know is.... has anyone heard of multicast problems with Linux 
2.6 in general.  What I have heard, via rumor mill, is there is a fix, 
something to do with how the API has changed in Linux 2.6 and the mutlicast 
process.

thanks...chris

--=======7BB17866=======
Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-A7C6C9A
Content-Disposition: inline


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 8/16/2004

--=======7BB17866=======--


From adam@hiddennet.net  Thu Aug 19 10:33:26 2004
From: adam@hiddennet.net (Adam Greenhalgh)
Date: Thu, 19 Aug 2004 10:33:26 +0100
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <6.1.2.0.2.20040819011202.02061ec0@ginger.cmf.nrl.navy.mil>
References: <6.1.2.0.2.20040819011202.02061ec0@ginger.cmf.nrl.navy.mil>
Message-ID: <1092908006.12024.43.camel@cellini.cs.ucl.ac.uk>

I don't think the v6 multicast stack on linux is as mature the one on
freebsd, a number of things aren't there. I am not quite sure what they
are, Pavlin is probably the best source of information. However the
linux network developers seem to be aware of problems, perhaps it is
time to talk with them and try and pull linux up in line with freebsd.
The recent linux kernel summit generated the following,

http://developer.osdl.org/shemminger/ns2004/

It would seem that prior to the recent linux kernel summit that there
was a two day linux networking summit, above is a link to the slides and
notes from that summit. I guess it gives us an idea who is doing what
and what is planned to be done, perhaps now is time to send ideas or
patches to them for the bits that we are missing.

Some info about the linux kernel summit is here.

http://lwn.net/Articles/93985/

Is anyone involved with the linux kernel networking stack ? As now would
be a good time to get xorp's requirements into the linux path.


Adam

On Thu, 2004-08-19 at 01:20 -0400, Chris Robson wrote:
> First, this appears not to be a problem with XORP alone but so far as I can 
> tell every implementation of the protocol stack and Linux 2.6, aka zebra 
> and GATED (commerical) have the same problem.  PIM doesnt seem to reply to 
> hello messages, aka no multicast routing is successful.  Yes, this isnt 
> much and I apologies for what little information I'm giving here, just 
> havent had the time to collect much more at this point.  What I really 
> would like to know is.... has anyone heard of multicast problems with Linux 
> 2.6 in general.  What I have heard, via rumor mill, is there is a fix, 
> something to do with how the API has changed in Linux 2.6 and the mutlicast 
> process.
> 
> thanks...chris
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.740 / Virus Database: 494 - Release Date: 8/16/2004


From darkoparic@net.hr  Fri Aug 20 14:00:57 2004
From: darkoparic@net.hr (Darko Paric)
Date: Fri, 20 Aug 2004 15:00:57 +0200
Subject: [Xorp-users] IPv6 multicast  forwarding help needed
Message-ID: <4125f609.2b41.0@net.hr>


  We are using two boxes with Live CD. We are trying to establish simple
testing network with two clients and two routers between them.  One client
sends multicast stream and the other client should be able to receive that
stream. (we use VLC apllication). PIMSM6 & MLD seem to work, but there is
no multicast forwarding ie. packets from stream reach inner interface but
none are forwarded on outer interface.


could someone send a sugesstion

here is our configuration:

___________________________________________________________________________



/*XORP Configuration File*/
interfaces {
    interface rl0 {
        description: "inner"
	enabled: true
	default-system-config
        vif rl0 {
		enabled: true
        }
    }
    interface rl1 {
        description: "outer"
	enabled: true
	default-system-config
        vif rl1 {
		enabled: true
        }
    }
    interface lo0 {
        description: "Loopback interface"
        vif lo0 {
        }
    }
}
fea {
	enable-unicast-forwarding6: true
}

protocols {
	static {
		route6 ::/0 {
			nexthop: 2001:b68:e201:2
			metric: 1
		}
	}
}

plumbing {
	mfea6 {
		enabled: true
		interface rl0 {
			vif rl0 {
				enabled: true
			}
		}
		interface rl1 {
			vif rl1 {
				enabled: true
			}
		}
		interface register_vif {
			vif register_vif {
				enabled: true
			}
		}
		traceoptions {
			flag all {
				enabled: true
			}
		}
	}
}
protocols {
	mld {
		enabled: true
		interface rl1 {
			vif rl1 {
				enabled: true
			}
		}
		traceoptions {
			flag all {
				enabled: true
			}
		}
	}
}
protocols {
	pimsm6 {
		enabled: true
		interface rl0 {
			vif rl0 {
				enabled: true
				dr-priority: 1
			}
		}
		interface register_vif {
			vif register_vif {
				enabled: true
			}
		}
		static-rps {
			rp 2001:b68:e201::1 {
				group-prefix ff00::/8 {
					rp-priority: 192
					hash-mask-len: 126
				}
			}
		}
		switch-to-spt-threshold {
			enabled: true
			interval-sec: 100
			bytes: 102400
		}
		traceoptions {
			flag all {
				enabled: true
			}
		}
	}
}
protocols {
	fib2mrib {
		enabled: true
	}
} 

--
Sudjelujte u Iskon Bonus nagradnom programu i osvajajte nagrade.
Saznajte vi¹e na web adresi http://www.iskon.biz/bonus/

From doesnotcount@hotmail.com  Fri Aug 20 21:10:49 2004
From: doesnotcount@hotmail.com (Nathan K)
Date: Fri, 20 Aug 2004 16:10:49 -0400
Subject: [Xorp-users] Peer error
Message-ID: <BAY19-F7WDIfn1gLtuU000119b5@hotmail.com>

I'm attempting to use the BGPD to take requests (most likely in the form of 
xrls) to take a router-ip, a host-ip and a nextHop-ip and send BGP Updates 
setting the nextHop of host-ip to nextHop-ip only on the bgp peer with the 
given router-ip. My question is this: if one of those bgp peer routers goes 
down and then comes back up, will the BGPD automatically resend those 
updates? If not, I may have to have the BGPD notify my process (most likely 
in the form of an xrl call) that the router has gone down and when the 
router comes back up, I'll have to reissue all those updates, but I'd rather 
not have to do this.

-Nathan.

_________________________________________________________________
Take advantage of powerful junk e-mail filters built on patented Microsoft® 
SmartScreen Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.


From atanu@ICSI.Berkeley.EDU  Fri Aug 20 21:33:49 2004
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Fri, 20 Aug 2004 13:33:49 -0700
Subject: [Xorp-users] Peer error
In-Reply-To: Message from "Nathan K" <doesnotcount@hotmail.com>
 of "Fri, 20 Aug 2004 16:10:49 EDT." <BAY19-F7WDIfn1gLtuU000119b5@hotmail.com>
Message-ID: <96324.1093034029@tigger.icir.org>

The BGP protocol is totally stateful. It does not use periodic refreshes
of state to synchronise BGP processes. A BGP speaker is therefore
required to send all its winning routes when a new session is
established.

The XORP BGP will send all the winning routes when a new session is
established.

Take a look in bgp/harness/test_peering2.sh, it contains tests to verify
that we handle sessions being brought up and taken down, it
also demonstrates how to add peerings using XRLs.

	Atanu.

>>>>> "Nathan" == Nathan K <doesnotcount@hotmail.com> writes:

    Nathan> I'm attempting to use the BGPD to take requests (most likely
    Nathan> in the form of xrls) to take a router-ip, a host-ip and a
    Nathan> nextHop-ip and send BGP Updates setting the nextHop of
    Nathan> host-ip to nextHop-ip only on the bgp peer with the given
    Nathan> router-ip. My question is this: if one of those bgp peer
    Nathan> routers goes down and then comes back up, will the BGPD
    Nathan> automatically resend those updates? If not, I may have to
    Nathan> have the BGPD notify my process (most likely in the form of
    Nathan> an xrl call) that the router has gone down and when the
    Nathan> router comes back up, I'll have to reissue all those
    Nathan> updates, but I'd rather not have to do this.

    Nathan> -Nathan.

    Nathan> _________________________________________________________________
    Nathan> Take advantage of powerful junk e-mail filters built on
    Nathan> patented Microsoft® SmartScreen Technology.
    Nathan> http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines
    Nathan> Start enjoying all the benefits of MSN® Premium right now
    Nathan> and get the first two months FREE*.

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

From pavlin@icir.org  Sat Aug 21 10:32:39 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Sat, 21 Aug 2004 02:32:39 -0700
Subject: [Xorp-users] IPv6 multicast forwarding help needed
In-Reply-To: Message from "Darko Paric" <darkoparic@net.hr>
 of "Fri, 20 Aug 2004 15:00:57 +0200." <4125f609.2b41.0@net.hr>
Message-ID: <200408210932.i7L9WewK081318@possum.icir.org>

>   We are using two boxes with Live CD. We are trying to establish simple
> testing network with two clients and two routers between them.  One client
> sends multicast stream and the other client should be able to receive that
> stream. (we use VLC apllication). PIMSM6 & MLD seem to work, but there is
> no multicast forwarding ie. packets from stream reach inner interface but
> none are forwarded on outer interface.
> 
> 
> could someone send a sugesstion
> 
> here is our configuration:

A quick question. It appears that inside the "interface" and "mfea6"
sections you have enabled interfaces rl0 and rl1. However, inside
the "mld" section you have enabled rl1 only, and inside the "pimsm6"
you have enabled rl0 only. Is this mismatch intentional?
Typically, within "mld" and "pimsm6" you would enable both rl0 and rl1.

Regards,
Pavlin

> 
> ___________________________________________________________________________
> 
> 
> 
> /*XORP Configuration File*/
> interfaces {
>     interface rl0 {
>         description: "inner"
> 	enabled: true
> 	default-system-config
>         vif rl0 {
> 		enabled: true
>         }
>     }
>     interface rl1 {
>         description: "outer"
> 	enabled: true
> 	default-system-config
>         vif rl1 {
> 		enabled: true
>         }
>     }
>     interface lo0 {
>         description: "Loopback interface"
>         vif lo0 {
>         }
>     }
> }
> fea {
> 	enable-unicast-forwarding6: true
> }
> 
> protocols {
> 	static {
> 		route6 ::/0 {
> 			nexthop: 2001:b68:e201:2
> 			metric: 1
> 		}
> 	}
> }
> 
> plumbing {
> 	mfea6 {
> 		enabled: true
> 		interface rl0 {
> 			vif rl0 {
> 				enabled: true
> 			}
> 		}
> 		interface rl1 {
> 			vif rl1 {
> 				enabled: true
> 			}
> 		}
> 		interface register_vif {
> 			vif register_vif {
> 				enabled: true
> 			}
> 		}
> 		traceoptions {
> 			flag all {
> 				enabled: true
> 			}
> 		}
> 	}
> }
> protocols {
> 	mld {
> 		enabled: true
> 		interface rl1 {
> 			vif rl1 {
> 				enabled: true
> 			}
> 		}
> 		traceoptions {
> 			flag all {
> 				enabled: true
> 			}
> 		}
> 	}
> }
> protocols {
> 	pimsm6 {
> 		enabled: true
> 		interface rl0 {
> 			vif rl0 {
> 				enabled: true
> 				dr-priority: 1
> 			}
> 		}
> 		interface register_vif {
> 			vif register_vif {
> 				enabled: true
> 			}
> 		}
> 		static-rps {
> 			rp 2001:b68:e201::1 {
> 				group-prefix ff00::/8 {
> 					rp-priority: 192
> 					hash-mask-len: 126
> 				}
> 			}
> 		}
> 		switch-to-spt-threshold {
> 			enabled: true
> 			interval-sec: 100
> 			bytes: 102400
> 		}
> 		traceoptions {
> 			flag all {
> 				enabled: true
> 			}
> 		}
> 	}
> }
> protocols {
> 	fib2mrib {
> 		enabled: true
> 	}
> } 
> 
> --
> Sudjelujte u Iskon Bonus nagradnom programu i osvajajte nagrade.
> Saznajte vi¹e na web adresi http://www.iskon.biz/bonus/
> _______________________________________________
> Xorp-users mailing list
> Xorp-users@xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin@icir.org  Sat Aug 21 11:29:32 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Sat, 21 Aug 2004 03:29:32 -0700
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: Message from Chris Robson <crobson@cmf.nrl.navy.mil>
 of "Thu, 19 Aug 2004 01:20:12 EDT." <6.1.2.0.2.20040819011202.02061ec0@ginger.cmf.nrl.navy.mil>
Message-ID: <200408211029.i7LATWwK081832@possum.icir.org>

> First, this appears not to be a problem with XORP alone but so far as I can 
> tell every implementation of the protocol stack and Linux 2.6, aka zebra 
> and GATED (commerical) have the same problem.  PIM doesnt seem to reply to 
> hello messages, aka no multicast routing is successful.  Yes, this isnt 
> much and I apologies for what little information I'm giving here, just 
> havent had the time to collect much more at this point.  What I really 
> would like to know is.... has anyone heard of multicast problems with Linux 
> 2.6 in general.  What I have heard, via rumor mill, is there is a fix, 
> something to do with how the API has changed in Linux 2.6 and the mutlicast 
> process.

Chris,

If you want to use IPv6 multicast routing on Linux, it won't work
simply because the Linux kernel doesn't support it. It has been on
the TODO list on the Linux IPv6 kernel folks for quite some time
(e.g., see the Kernel Summit presentations that Adam pointed to in
his email).


If you want to use IPv4 multicast routing on Linux, I just did some
tests with a 2.6 kernel (running on FedoraCore2) and it appears fine.

OS: 
Linux fedora 2.6.5-1.358smp #1 SMP Sat May 8 09:25:36 EDT 2004 i686
i686 i386 GNU/Linux

Setup:

[Host1]-----[FreeBSD-4.9]---------[Linux-2.6]------[Host2]

[FreeBSD-4.9] and [Linux-2.6] were running lastest XORP code from CVS.
[Linux-2.6] was actually running within vmware, and was connected to
[FreeBSD-4.9] via an openvpn tunnel, so as you can see this was a bit
of extreme setup. I tried all 4 possible combinations:

* [FreeBSD-4.9] is the RP and [Linux-2.6] is just a router (and
  vice-versa).
* [Host1] is the sender, and [Host2] is the receiver (and
  vice-versa).

In all tests I didn't see anything unusual.

Regards,
Pavlin

P.S. BTW, can you verify that you have the following options enabled
in your kernel config:

CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V2=y

From crobson@cmf.nrl.navy.mil  Sat Aug 21 17:13:05 2004
From: crobson@cmf.nrl.navy.mil (Chris Robson)
Date: Sat, 21 Aug 2004 12:13:05 -0400
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <200408211029.i7LATWwK081832@possum.icir.org>
References: <200408211029.i7LATWwK081832@possum.icir.org>
Message-ID: <6.1.2.0.2.20040821120200.01eefd00@ginger.cmf.nrl.navy.mil>

--=======F922DC=======
Content-Type: text/plain; x-avg-checked=avg-ok-4A4A2D28; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

Pavlin

Thanks for the info, but I dont think the setup is the same and I'm no 
expert but not running all Linux 2.6 Fedora Core 2 is also a concern.  From 
your setup I wonder if FreeBSD is hiding a problem?

My setup was the following.......

Host <--> Core 2 (acting as edge router) <--> Core 2 (acting as backbone 
rtr) <--> Core 2 (edge rtr) <--> Host.

I've tried these combos of with no success:
QUAGGA, PIMD
GATED (binaries for Red Hat 7.3 linux 2.4)
XORP

and the PIMDs I find on the net are all from circa linux 2.4 but they do 
build for Linux 2.6.

What I saw was Pim Hellos going out but nothing coming back when running 
tcpdump on one of the edge rtrs.  But as you indicate and I havent done yet 
is run the latest XORP (CVS, I'm  using release 1.0) and just this morning 
I downloaded a new kernel release for Fedora Core 2 on my Web server, so 
obviously I have some updating to do and more testing to run.......

....thanks......

At 06:29 AM 8/21/2004, Pavlin Radoslavov wrote:

> > First, this appears not to be a problem with XORP alone but so far as I 
> can
> > tell every implementation of the protocol stack and Linux 2.6, aka zebra
> > and GATED (commerical) have the same problem.  PIM doesnt seem to reply to
> > hello messages, aka no multicast routing is successful.  Yes, this isnt
> > much and I apologies for what little information I'm giving here, just
> > havent had the time to collect much more at this point.  What I really
> > would like to know is.... has anyone heard of multicast problems with 
> Linux
> > 2.6 in general.  What I have heard, via rumor mill, is there is a fix,
> > something to do with how the API has changed in Linux 2.6 and the 
> mutlicast
> > process.
>
>Chris,
>
>If you want to use IPv6 multicast routing on Linux, it won't work
>simply because the Linux kernel doesn't support it. It has been on
>the TODO list on the Linux IPv6 kernel folks for quite some time
>(e.g., see the Kernel Summit presentations that Adam pointed to in
>his email).
>
>
>If you want to use IPv4 multicast routing on Linux, I just did some
>tests with a 2.6 kernel (running on FedoraCore2) and it appears fine.
>
>OS:
>Linux fedora 2.6.5-1.358smp #1 SMP Sat May 8 09:25:36 EDT 2004 i686
>i686 i386 GNU/Linux
>
>Setup:
>
>[Host1]-----[FreeBSD-4.9]---------[Linux-2.6]------[Host2]
>
>[FreeBSD-4.9] and [Linux-2.6] were running lastest XORP code from CVS.
>[Linux-2.6] was actually running within vmware, and was connected to
>[FreeBSD-4.9] via an openvpn tunnel, so as you can see this was a bit
>of extreme setup. I tried all 4 possible combinations:
>
>* [FreeBSD-4.9] is the RP and [Linux-2.6] is just a router (and
>   vice-versa).
>* [Host1] is the sender, and [Host2] is the receiver (and
>   vice-versa).
>
>In all tests I didn't see anything unusual.
>
>Regards,
>Pavlin
>
>P.S. BTW, can you verify that you have the following options enabled
>in your kernel config:
>
>CONFIG_IP_MROUTE=y
>CONFIG_IP_PIMSM_V2=y
>_______________________________________________
>Xorp-users mailing list
>Xorp-users@xorp.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004

--=======F922DC=======
Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-4A4A2D28
Content-Disposition: inline


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004

--=======F922DC=======--


From pavlin@icir.org  Sat Aug 21 19:10:48 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Sat, 21 Aug 2004 11:10:48 -0700
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: Message from Chris Robson <crobson@cmf.nrl.navy.mil>
 of "Sat, 21 Aug 2004 12:13:05 EDT." <6.1.2.0.2.20040821120200.01eefd00@ginger.cmf.nrl.navy.mil>
Message-ID: <200408211810.i7LIAmwK088234@possum.icir.org>

Chris,

> Thanks for the info, but I dont think the setup is the same and I'm no 
> expert but not running all Linux 2.6 Fedora Core 2 is also a concern.  From 
> your setup I wonder if FreeBSD is hiding a problem?
> 
> My setup was the following.......
> 
> Host <--> Core 2 (acting as edge router) <--> Core 2 (acting as backbone 
> rtr) <--> Core 2 (edge rtr) <--> Host.
> 
> I've tried these combos of with no success:
> QUAGGA, PIMD
> GATED (binaries for Red Hat 7.3 linux 2.4)
> XORP
> 
> and the PIMDs I find on the net are all from circa linux 2.4 but they do 
> build for Linux 2.6.
> 
> What I saw was Pim Hellos going out but nothing coming back when running 
> tcpdump on one of the edge rtrs.  But as you indicate and I havent done yet 
> is run the latest XORP (CVS, I'm  using release 1.0) and just this morning 
> I downloaded a new kernel release for Fedora Core 2 on my Web server, so 
> obviously I have some updating to do and more testing to run.......

I very doubt that FreeBSD would be hiding the Hello problem you are
having.

BTW, are the edge routers directly connected to the backbone router
or do you use some virtual tunnels (or something else) between them?

Regards,
Pavlin

From dikshie@lapi.itb.ac.id  Mon Aug 23 08:12:26 2004
From: dikshie@lapi.itb.ac.id (Dikshie)
Date: Mon, 23 Aug 2004 14:12:26 +0700
Subject: [Xorp-users] freebsd-5.3
Message-ID: <20040823071226.GA73575@lapi.itb.ac.id>

dear all,
I always get error messages:
------------
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g  -W -Wall -Wwrite-strings -Wcast-qua
l -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-20
-c -o mfea_proto_comm.o `test -f mfea_proto_comm.cc || echo './'`mfea_proto_comm
.cc
mfea_proto_comm.cc: In member function `int ProtoComm::proto_socket_write(uint16
_t, const IPvX&, const IPvX&, int, int, bool, const uint8_t*, size_t)':
mfea_proto_comm.cc:1521: error: cannot bind packed field `ip->ip::ip_src' to `in
_addr&'
mfea_proto_comm.cc:1522: error: cannot bind packed field `ip->ip::ip_dst' to `in
_addr&'
gmake[3]: *** [mfea_proto_comm.o] Error 1
gmake[3]: Leaving directory `/usr/local/sources/xorp-1.0/fea'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/local/sources/xorp-1.0/fea'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/local/sources/xorp-1.0'
gmake: *** [all] Error 2
--------------
on FreeBSD-5.3-BETA1 using gcc-3.4.2.


any clues ?



thanks !


-dikshie-

From alt@fr.clara.net  Mon Aug 23 13:04:14 2004
From: alt@fr.clara.net (Arnaud Le Taillanter)
Date: Mon, 23 Aug 2004 14:04:14 +0200
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <200408211029.i7LATWwK081832@possum.icir.org>
References: <200408211029.i7LATWwK081832@possum.icir.org>
Message-ID: <4129DD3E.6050801@fr.clara.net>

Pavlin Radoslavov wrote:

> P.S. BTW, can you verify that you have the following options enabled
> in your kernel config:
> 
> CONFIG_IP_MROUTE=y
> CONFIG_IP_PIMSM_V2=y

Hello,

Just out of curiosity, why is PIM kernel support necessary for the Xorp 
PIM daemon to operate?
I've successfully run XORP PIM on a FreeBSD box, I followed the 
documentation and enabled the kernel options MROUTING (fair :) and also
PIM, but I don't see why Xorp PIM would need PIM support from the 
kernel. Xorp BGP doesn't need BGP support from the kernel for example.

Arnaud


From bms@spc.org  Mon Aug 23 13:21:45 2004
From: bms@spc.org (Bruce M Simpson)
Date: Mon, 23 Aug 2004 05:21:45 -0700
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <4129DD3E.6050801@fr.clara.net>
References: <200408211029.i7LATWwK081832@possum.icir.org> <4129DD3E.6050801@fr.clara.net>
Message-ID: <20040823122144.GA1162@dhcp113.icir.org>

On Mon, Aug 23, 2004 at 02:04:14PM +0200, Arnaud Le Taillanter wrote:
> Just out of curiosity, why is PIM kernel support necessary for the Xorp 
> PIM daemon to operate?
> I've successfully run XORP PIM on a FreeBSD box, I followed the 
> documentation and enabled the kernel options MROUTING (fair :) and also
> PIM, but I don't see why Xorp PIM would need PIM support from the 
> kernel. Xorp BGP doesn't need BGP support from the kernel for example.

BGP lives entirely in userland; it only requires specific kernel support
in special circumstances (TCP-MD5).

PIM does not live entirely in userland. Multicast forwarding functions are
located within the kernel.

BMS

From darkoparic@net.hr  Mon Aug 23 13:47:12 2004
From: darkoparic@net.hr (Darko Paric)
Date: Mon, 23 Aug 2004 14:47:12 +0200
Subject: [Xorp-users] IPv6 multicast forwarding help needed
Message-ID: <4129e750.7938.0@net.hr>

>> here is our configuration:
>
>Typically, within "mld" and "pimsm6" you would enable both rl0 and rl1.
>

We have tried that also. It didn't work. PIMSM6 works (network sniffing
showed routers exchange PIM Hello packets). show pim6 neighbors and show
mld groups gave good result.

show mfea6 (interface address, dataflow) command gives nothing. could the
problem be there?

Also, we have noticed that MLD wont start unless default-system-config is
set. When we try configure fixed addresses in config file, log shows
invalid primary address during startup. When we set addresses manualy. and
configure default-system-config in interfaces section, router starts fine.

Best regards
       Darko

--
Sudjelujte u Iskon Bonus nagradnom programu i osvajajte nagrade.
Saznajte vi¹e na web adresi http://www.iskon.biz/bonus/

From crobson@cmf.nrl.navy.mil  Mon Aug 23 15:25:06 2004
From: crobson@cmf.nrl.navy.mil (Chris Robson)
Date: Mon, 23 Aug 2004 10:25:06 -0400
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <20040823122144.GA1162@dhcp113.icir.org>
References: <200408211029.i7LATWwK081832@possum.icir.org>
 <4129DD3E.6050801@fr.clara.net>
 <20040823122144.GA1162@dhcp113.icir.org>
Message-ID: <6.1.2.0.2.20040823102312.01ff3ce0@ginger.cmf.nrl.navy.mil>

--=======4A23800=======
Content-Type: text/plain; x-avg-checked=avg-ok-5ACDD44; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit


Bruce
Thanks for the comment and this is why the local concern here is the kernel 
multicast functions are not really working in Linux 2.6, therefore, any 
user apps (aka PIM) wont function correctly.

...chris

At 08:21 AM 8/23/2004, Bruce M Simpson wrote:

>On Mon, Aug 23, 2004 at 02:04:14PM +0200, Arnaud Le Taillanter wrote:
> > Just out of curiosity, why is PIM kernel support necessary for the Xorp
> > PIM daemon to operate?
> > I've successfully run XORP PIM on a FreeBSD box, I followed the
> > documentation and enabled the kernel options MROUTING (fair :) and also
> > PIM, but I don't see why Xorp PIM would need PIM support from the
> > kernel. Xorp BGP doesn't need BGP support from the kernel for example.
>
>BGP lives entirely in userland; it only requires specific kernel support
>in special circumstances (TCP-MD5).
>
>PIM does not live entirely in userland. Multicast forwarding functions are
>located within the kernel.
>
>BMS
>_______________________________________________
>Xorp-users mailing list
>Xorp-users@xorp.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004

--=======4A23800=======
Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-5ACDD44
Content-Disposition: inline


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004

--=======4A23800=======--


From alt@fr.clara.net  Mon Aug 23 15:45:51 2004
From: alt@fr.clara.net (Arnaud Le Taillanter)
Date: Mon, 23 Aug 2004 16:45:51 +0200
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <20040823122144.GA1162@dhcp113.icir.org>
References: <200408211029.i7LATWwK081832@possum.icir.org> <4129DD3E.6050801@fr.clara.net> <20040823122144.GA1162@dhcp113.icir.org>
Message-ID: <412A031F.1080906@fr.clara.net>

Bruce M Simpson wrote:
> On Mon, Aug 23, 2004 at 02:04:14PM +0200, Arnaud Le Taillanter wrote:
> 
>>Just out of curiosity, why is PIM kernel support necessary for the Xorp 
>>PIM daemon to operate?
>>I've successfully run XORP PIM on a FreeBSD box, I followed the 
>>documentation and enabled the kernel options MROUTING (fair :) and also
>>PIM, but I don't see why Xorp PIM would need PIM support from the 
>>kernel. Xorp BGP doesn't need BGP support from the kernel for example.
> 
> 
> BGP lives entirely in userland; it only requires specific kernel support
> in special circumstances (TCP-MD5).
> 
> PIM does not live entirely in userland. Multicast forwarding functions are
> located within the kernel.


Aren't the multicast forwarding functions being dealt with by the 
MROUTING (for FreeBSD) or CONFIG_IP_MROUTE (for Linux) kernel options?

In my thinking, the PIM XORP daemon then would only need to push out to 
the kernel the multicast routes it derived from its protocol activity, 
like BGP does with the unicast routes (via the forwarding engine 
abstraction). Perhaps PIM needs some information from the kernel about
multicast traffic coming through an interface (which may change the PIM
state)?

Arnaud


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


From adam@hiddennet.net  Mon Aug 23 15:51:32 2004
From: adam@hiddennet.net (Adam Greenhalgh)
Date: Mon, 23 Aug 2004 15:51:32 +0100
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <412A031F.1080906@fr.clara.net>
References: <200408211029.i7LATWwK081832@possum.icir.org>
 <4129DD3E.6050801@fr.clara.net> <20040823122144.GA1162@dhcp113.icir.org>
 <412A031F.1080906@fr.clara.net>
Message-ID: <1093272692.29069.24.camel@cellini.cs.ucl.ac.uk>

> Aren't the multicast forwarding functions being dealt with by the 
> MROUTING (for FreeBSD) or CONFIG_IP_MROUTE (for Linux) kernel options?
> 
> In my thinking, the PIM XORP daemon then would only need to push out to 
> the kernel the multicast routes it derived from its protocol activity, 
> like BGP does with the unicast routes (via the forwarding engine 
> abstraction). Perhaps PIM needs some information from the kernel about
> multicast traffic coming through an interface (which may change the PIM
> state)?

Perhaps it is worth documenting what is missing in linux to bring its
functionality up to that of freebsd, then push the list to the linux
network developers.

adam


From pavlin@icir.org  Mon Aug 23 18:05:28 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 23 Aug 2004 10:05:28 -0700
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: Message from Chris Robson <crobson@cmf.nrl.navy.mil>
 of "Mon, 23 Aug 2004 10:25:06 EDT." <6.1.2.0.2.20040823102312.01ff3ce0@ginger.cmf.nrl.navy.mil>
Message-ID: <200408231705.i7NH5SwK012175@possum.icir.org>

> Bruce
> Thanks for the comment and this is why the local concern here is the kernel 
> multicast functions are not really working in Linux 2.6, therefore, any 
> user apps (aka PIM) wont function correctly.
> 
> ...chris

Chris,

Based on my test results with a 2.6 kernel, I had no problems with
multicast forwarding, therefore to solve the problem faster I
would recommend that we try to isolate it by first looking somewhere
else.

Hence, can you do the following:

1. Make sure that you have the following options in you Linux-2.6
kernel configuration file:

CONFIG_IP_MULTICAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V2=y

[those options are mentioned in xorp/pim/README]

If you don't have the above options enabled, the results are
unpredictable.

2. For consistency, please get the lastest XORP code from the
   anonymous CVS repository.

3. Please answer my earlier question whether your PIM routers are
   directly connected to each other (e.g., via a physical LAN), or
   whether there is something between them. For example, do you have
   switches, do you use some tunnels (e.g., openvpn), etc.

4. Once you start XORP PIM on two neighbor routers, please run
   tcpdump on the neighboring interfaces on each router. E.g., in
   your topology you have:

Host <--> Core 2 (acting as edge router) <--> Core 2 (acting as backbone 
rtr) <--> Core 2 (edge rtr) <--> Host.

   In that case, please run tcpdump on the interface that connects
   the first edge router to the backbone router, and on the
   corresponding interface of the backbone router.

   In your previous email you said that each router is sending PIM
   Hello messages, but those messages are not received by the other
   routers. Hence, by running tcpdump can you confirm whether the
   PIM Hello messages originated by the backbone router reach the
   first edge router (and vice-versa). If tcpdump on the backbone
   router shows that the Hello messages are sent on that interface,
   but tcpdump on the first edge router does not see those Hello
   messages, then the Hellos have been lost somewhere between the
   routers (e.g., a switch in the middle may have filtered them, a
   virtual tunnel may have been misconfigured, etc). If tcpdump on
   the receiving side does see the Hellos, but PIM userland daemon
   doesn't see them, then the problem is within the router itself,
   and we can take additional steps to find it.

Once we have the above information, we can trace the problem
further. Otherwise, we will be just guessing...

Thanks,
Pavlin

> 
> At 08:21 AM 8/23/2004, Bruce M Simpson wrote:
> 
> >On Mon, Aug 23, 2004 at 02:04:14PM +0200, Arnaud Le Taillanter wrote:
> > > Just out of curiosity, why is PIM kernel support necessary for the Xorp
> > > PIM daemon to operate?
> > > I've successfully run XORP PIM on a FreeBSD box, I followed the
> > > documentation and enabled the kernel options MROUTING (fair :) and also
> > > PIM, but I don't see why Xorp PIM would need PIM support from the
> > > kernel. Xorp BGP doesn't need BGP support from the kernel for example.
> >
> >BGP lives entirely in userland; it only requires specific kernel support
> >in special circumstances (TCP-MD5).
> >
> >PIM does not live entirely in userland. Multicast forwarding functions are
> >located within the kernel.

From doesnotcount@hotmail.com  Mon Aug 23 18:57:24 2004
From: doesnotcount@hotmail.com (Nathan K)
Date: Mon, 23 Aug 2004 13:57:24 -0400
Subject: [Xorp-users] Peer error
Message-ID: <BAY19-F29UHHLAKowux0006cc07@hotmail.com>

It seems as though I want to make my own bgp daemon that uses the BGPPeer 
class without a peer handler as I'm not interested in the plumbing. I have 
two goals, send customized Update packets to routers where different routers 
get different update packets targeted to them. The second goal is to parse 
incoming update packets from routers to determine AS to Subnet mappings.

Is there any reason why I couldn't design a daemon that creates a list of 
BGPPeer objects and sends out specific updates to each BGPPeer object? And 
as well has these BGPPeer objects receiving updates from other routers and 
storing information about those routes?

Thanks.

-Nathan.


>From: Atanu Ghosh <atanu@ICSI.Berkeley.EDU>
>Reply-To: atanu@ICSI.Berkeley.EDU
>To: "Nathan K" <doesnotcount@hotmail.com>
>CC: xorp-users@xorp.org
>Subject: Re: [Xorp-users] Peer error Date: Fri, 20 Aug 2004 13:33:49 -0700
>
>The BGP protocol is totally stateful. It does not use periodic refreshes
>of state to synchronise BGP processes. A BGP speaker is therefore
>required to send all its winning routes when a new session is
>established.
>
>The XORP BGP will send all the winning routes when a new session is
>established.
>
>Take a look in bgp/harness/test_peering2.sh, it contains tests to verify
>that we handle sessions being brought up and taken down, it
>also demonstrates how to add peerings using XRLs.
>
>	Atanu.
>
> >>>>> "Nathan" == Nathan K <doesnotcount@hotmail.com> writes:
>
>     Nathan> I'm attempting to use the BGPD to take requests (most likely
>     Nathan> in the form of xrls) to take a router-ip, a host-ip and a
>     Nathan> nextHop-ip and send BGP Updates setting the nextHop of
>     Nathan> host-ip to nextHop-ip only on the bgp peer with the given
>     Nathan> router-ip. My question is this: if one of those bgp peer
>     Nathan> routers goes down and then comes back up, will the BGPD
>     Nathan> automatically resend those updates? If not, I may have to
>     Nathan> have the BGPD notify my process (most likely in the form of
>     Nathan> an xrl call) that the router has gone down and when the
>     Nathan> router comes back up, I'll have to reissue all those
>     Nathan> updates, but I'd rather not have to do this.
>
>     Nathan> -Nathan.
>
>     Nathan> 
>_________________________________________________________________
>     Nathan> Take advantage of powerful junk e-mail filters built on
>     Nathan> patented Microsoft® SmartScreen Technology.
>     Nathan> 
>http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines
>     Nathan> Start enjoying all the benefits of MSN® Premium right now
>     Nathan> and get the first two months FREE*.
>
>     Nathan> _______________________________________________ Xorp-users
>     Nathan> mailing list Xorp-users@xorp.org
>     Nathan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>_______________________________________________
>Xorp-users mailing list
>Xorp-users@xorp.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen 
Technology  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.


From pavlin@icir.org  Mon Aug 23 19:45:48 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 23 Aug 2004 11:45:48 -0700
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: Message from Arnaud Le Taillanter <alt@fr.clara.net>
 of "Mon, 23 Aug 2004 16:45:51 +0200." <412A031F.1080906@fr.clara.net>
Message-ID: <200408231845.i7NIjmwK012931@possum.icir.org>

> Bruce M Simpson wrote:
> > On Mon, Aug 23, 2004 at 02:04:14PM +0200, Arnaud Le Taillanter wrote:
> > 
> >>Just out of curiosity, why is PIM kernel support necessary for the Xorp 
> >>PIM daemon to operate?
> >>I've successfully run XORP PIM on a FreeBSD box, I followed the 
> >>documentation and enabled the kernel options MROUTING (fair :) and also
> >>PIM, but I don't see why Xorp PIM would need PIM support from the 
> >>kernel. Xorp BGP doesn't need BGP support from the kernel for example.
> > 
> > 
> > BGP lives entirely in userland; it only requires specific kernel support
> > in special circumstances (TCP-MD5).
> > 
> > PIM does not live entirely in userland. Multicast forwarding functions are
> > located within the kernel.
> 
> 
> Aren't the multicast forwarding functions being dealt with by the 
> MROUTING (for FreeBSD) or CONFIG_IP_MROUTE (for Linux) kernel options?
> 
> In my thinking, the PIM XORP daemon then would only need to push out to 
> the kernel the multicast routes it derived from its protocol activity, 
> like BGP does with the unicast routes (via the forwarding engine 
> abstraction). Perhaps PIM needs some information from the kernel about
> multicast traffic coming through an interface (which may change the PIM
> state)?

Ideally, yes, PIM should not need any additional support from the
kernel (beyond the generic multicast routing support). In reality,
you need a bit of extra support.

For example, each PIM router has the special PIM Register virtual
interface. That interface is used for sending and receiving of the
encapsulated PIM Register packets (from the DR to the RP).

At the DR, if the PIM Register vif is in the outgoing interface set
of a multicast forwarding entry, then this means that all data
packets that match on that entry have to be encapsulated as PIM
Register packets and unicast to the RP. Traditionally, this has been
done by sending the whole packet to userland (by a special
IGMPMSG_WHOLEPKT upcall to the application level daemon), where it
is encapsulated and sent to the RP. Such upcall was not needed for
the "vanilla" multicast forwarding support in the kernel (e.g., the
one that was done for DVMRP), but it was added later just for
PIM-SM.

At the RP, if an encapsulated data packet arrives on the PIM
Register vif, then if you want to decapsulate it within the kernel
(as both Linux and FreeBSD do) and forward it on the matching
multicast forwarding entry, the decapsulation itself requires a bit
of PIM knowlegde.

In addition, if a multicast data packet arrives on the wrong
incoming interface, the "vanilla" multicast forwarding will trigger
the IGMPMSG_VRONGVIF in some specific conditions (e.g., the
interface is in the outgoing interface set, the interface is not a
broadcast media, etc). In case of PIM, those conditions are
different. Hence, here again you need a special PIM support from the
kernel.

Regards,
Pavlin

From crobson@cmf.nrl.navy.mil  Mon Aug 23 21:58:33 2004
From: crobson@cmf.nrl.navy.mil (Chris Robson)
Date: Mon, 23 Aug 2004 16:58:33 -0400
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <200408231705.i7NH5SwK012175@possum.icir.org>
References: <200408231705.i7NH5SwK012175@possum.icir.org>
Message-ID: <6.1.2.0.2.20040823164545.01fb8930@ginger.cmf.nrl.navy.mil>

--=======763D54E8=======
Content-Type: text/plain; x-avg-checked=avg-ok-FCA79AB; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit


Pavlin

Sorry, I thought I said, all my linux boxes where directly connected to 
each other.  But anyway, you have asked for info whcih will take me a few 
days to collect, which I already have started doing, namely, updating all 
boxes in the cofnigure with the latest Fedora Core 2 updates (which 
includes a kernel update) and I did a CVS pull and rebuild.  One question 
however, when I do "make check" on the XORP build, it fails one of the 
tests (I'll have to get that info to you later), should I focus on making 
sure it passes all tests, or not worry about the check test.  Again the 
test config is .......

Host<---->Linux RTR<--->Linux RTR<--->Linux RTR<--->host

All RTRs are directly connected to each other, hosts will actually be 
connected to associated Linux RTR via a Linksys 
hub.  I.E.   Host<-->Linksys Hub<-->Linux RTR.  But the Linux RTR links are 
"not" thru the hub but RTR to RTR direct.

I'll need about a week to complete this, unfortunately I have a job that is 
getting in the way of fun stuff......

Well, U have ask me to collect some info so off I go.....

Thanks again for all the help........l8r....chris

At 01:05 PM 8/23/2004, Pavlin Radoslavov wrote:

> > Bruce
> > Thanks for the comment and this is why the local concern here is the 
> kernel
> > multicast functions are not really working in Linux 2.6, therefore, any
> > user apps (aka PIM) wont function correctly.
> >
> > ...chris
>
>Chris,
>
>Based on my test results with a 2.6 kernel, I had no problems with
>multicast forwarding, therefore to solve the problem faster I
>would recommend that we try to isolate it by first looking somewhere
>else.
>
>Hence, can you do the following:
>
>1. Make sure that you have the following options in you Linux-2.6
>kernel configuration file:
>
>CONFIG_IP_MULTICAST=y
>CONFIG_IP_MROUTE=y
>CONFIG_IP_PIMSM_V2=y
>
>[those options are mentioned in xorp/pim/README]
>
>If you don't have the above options enabled, the results are
>unpredictable.
>
>2. For consistency, please get the lastest XORP code from the
>    anonymous CVS repository.
>
>3. Please answer my earlier question whether your PIM routers are
>    directly connected to each other (e.g., via a physical LAN), or
>    whether there is something between them. For example, do you have
>    switches, do you use some tunnels (e.g., openvpn), etc.
>
>4. Once you start XORP PIM on two neighbor routers, please run
>    tcpdump on the neighboring interfaces on each router. E.g., in
>    your topology you have:
>
>Host <--> Core 2 (acting as edge router) <--> Core 2 (acting as backbone
>rtr) <--> Core 2 (edge rtr) <--> Host.
>
>    In that case, please run tcpdump on the interface that connects
>    the first edge router to the backbone router, and on the
>    corresponding interface of the backbone router.
>
>    In your previous email you said that each router is sending PIM
>    Hello messages, but those messages are not received by the other
>    routers. Hence, by running tcpdump can you confirm whether the
>    PIM Hello messages originated by the backbone router reach the
>    first edge router (and vice-versa). If tcpdump on the backbone
>    router shows that the Hello messages are sent on that interface,
>    but tcpdump on the first edge router does not see those Hello
>    messages, then the Hellos have been lost somewhere between the
>    routers (e.g., a switch in the middle may have filtered them, a
>    virtual tunnel may have been misconfigured, etc). If tcpdump on
>    the receiving side does see the Hellos, but PIM userland daemon
>    doesn't see them, then the problem is within the router itself,
>    and we can take additional steps to find it.
>
>Once we have the above information, we can trace the problem
>further. Otherwise, we will be just guessing...
>
>Thanks,
>Pavlin
>
> >
> > At 08:21 AM 8/23/2004, Bruce M Simpson wrote:
> >
> > >On Mon, Aug 23, 2004 at 02:04:14PM +0200, Arnaud Le Taillanter wrote:
> > > > Just out of curiosity, why is PIM kernel support necessary for the Xorp
> > > > PIM daemon to operate?
> > > > I've successfully run XORP PIM on a FreeBSD box, I followed the
> > > > documentation and enabled the kernel options MROUTING (fair :) and also
> > > > PIM, but I don't see why Xorp PIM would need PIM support from the
> > > > kernel. Xorp BGP doesn't need BGP support from the kernel for example.
> > >
> > >BGP lives entirely in userland; it only requires specific kernel support
> > >in special circumstances (TCP-MD5).
> > >
> > >PIM does not live entirely in userland. Multicast forwarding functions are
> > >located within the kernel.
>_______________________________________________
>Xorp-users mailing list
>Xorp-users@xorp.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004

--=======763D54E8=======
Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-FCA79AB
Content-Disposition: inline


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004

--=======763D54E8=======--


From pavlin@icir.org  Mon Aug 23 22:44:10 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 23 Aug 2004 14:44:10 -0700
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: Message from Chris Robson <crobson@cmf.nrl.navy.mil>
 of "Mon, 23 Aug 2004 16:58:33 EDT." <6.1.2.0.2.20040823164545.01fb8930@ginger.cmf.nrl.navy.mil>
Message-ID: <200408232144.i7NLiAwK013865@possum.icir.org>

> Sorry, I thought I said, all my linux boxes where directly connected to 
> each other.  But anyway, you have asked for info whcih will take me a few 

OK, that is good to know. I thought that there is some unusual
connectivity between them that would complicate the problem.

> days to collect, which I already have started doing, namely, updating all 
> boxes in the cofnigure with the latest Fedora Core 2 updates (which 
> includes a kernel update) and I did a CVS pull and rebuild.  One question 
> however, when I do "make check" on the XORP build, it fails one of the 
> tests (I'll have to get that info to you later), should I focus on making 
> sure it passes all tests, or not worry about the check test.  Again the 
> test config is .......
> 
> Host<---->Linux RTR<--->Linux RTR<--->Linux RTR<--->host
> 
> All RTRs are directly connected to each other, hosts will actually be 
> connected to associated Linux RTR via a Linksys 
> hub.  I.E.   Host<-->Linksys Hub<-->Linux RTR.  But the Linux RTR links are 
> "not" thru the hub but RTR to RTR direct.
> 
> I'll need about a week to complete this, unfortunately I have a job that is 
> getting in the way of fun stuff......

BTW, which particular test fails when you run "gmake check"?
For now I wouldn't worry about that particular test.
Anyway, after you have completed the update and have collected the
tcpdump info please let me know the result so we can take it from
there.

Thanks,
Pavlin

From atanu@ICSI.Berkeley.EDU  Mon Aug 23 23:55:03 2004
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 23 Aug 2004 15:55:03 -0700
Subject: [Xorp-users] Peer error
In-Reply-To: Message from "Nathan K" <doesnotcount@hotmail.com>
 of "Mon, 23 Aug 2004 13:57:24 EDT." <BAY19-F29UHHLAKowux0006cc07@hotmail.com>
Message-ID: <55821.1093301703@tigger.icir.org>

>>>>> "Nathan" == Nathan K <doesnotcount@hotmail.com> writes:

    Nathan> It seems as though I want to make my own bgp daemon that
    Nathan> uses the BGPPeer class without a peer handler as I'm not
    Nathan> interested in the plumbing. I have two goals, send
    Nathan> customized Update packets to routers where different routers
    Nathan> get different update packets targeted to them. The second
    Nathan> goal is to parse incoming update packets from routers to
    Nathan> determine AS to Subnet mappings.

    Nathan> Is there any reason why I couldn't design a daemon that
    Nathan> creates a list of BGPPeer objects and sends out specific
    Nathan> updates to each BGPPeer object? And as well has these
    Nathan> BGPPeer objects receiving updates from other routers and
    Nathan> storing information about those routes?

I don't see why this wouldn't work.

  Atanu.


From pavlin@icir.org  Wed Aug 25 07:30:46 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 24 Aug 2004 23:30:46 -0700
Subject: [Xorp-users] freebsd-5.3
In-Reply-To: Message from Dikshie <dikshie@lapi.itb.ac.id>
 of "Mon, 23 Aug 2004 14:12:26 +0700." <20040823071226.GA73575@lapi.itb.ac.id>
Message-ID: <200408250630.i7P6UkwK096693@possum.icir.org>

> dear all,
> I always get error messages:
> ------------
> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g  -W -Wall -Wwrite-strings -Wcast-qua
> l -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-20
> -c -o mfea_proto_comm.o `test -f mfea_proto_comm.cc || echo './'`mfea_proto_comm
> .cc
> mfea_proto_comm.cc: In member function `int ProtoComm::proto_socket_write(uint16
> _t, const IPvX&, const IPvX&, int, int, bool, const uint8_t*, size_t)':
> mfea_proto_comm.cc:1521: error: cannot bind packed field `ip->ip::ip_src' to `in
> _addr&'
> mfea_proto_comm.cc:1522: error: cannot bind packed field `ip->ip::ip_dst' to `in
> _addr&'
> gmake[3]: *** [mfea_proto_comm.o] Error 1
> gmake[3]: Leaving directory `/usr/local/sources/xorp-1.0/fea'
> gmake[2]: *** [all-recursive] Error 1
> gmake[2]: Leaving directory `/usr/local/sources/xorp-1.0/fea'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/usr/local/sources/xorp-1.0'
> gmake: *** [all] Error 2
> --------------
> on FreeBSD-5.3-BETA1 using gcc-3.4.2.
> 
> 
> any clues ?

Dikshie,

This appears to be an issue with the gcc compiler. E.g., recently
"struct ip" (inside <netinet/ip.h>) has been defined as __packed,
hence probably the above compilation error.

Nevertheless, I just commited a work-around fix in
mfea/mfea_proto_comm.cc rev 1.19 and pim/pim_proto_register.cc rev
1.16 (which also suffers from the same compilation problem), hence
please do "cvs update" and get the lastest code from the CVS
repository.

Regards,
Pavlin

From pavlin@icir.org  Wed Aug 25 10:40:45 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 25 Aug 2004 02:40:45 -0700
Subject: [Xorp-users] IPv6 multicast forwarding help needed
In-Reply-To: Message from "Darko Paric" <darkoparic@net.hr>
 of "Mon, 23 Aug 2004 14:47:12 +0200." <4129e750.7938.0@net.hr>
Message-ID: <200408250940.i7P9ejwK098384@possum.icir.org>

> >> here is our configuration:
> >
> >Typically, within "mld" and "pimsm6" you would enable both rl0 and rl1.
> >
> 
> We have tried that also. It didn't work. PIMSM6 works (network sniffing
> showed routers exchange PIM Hello packets). show pim6 neighbors and show
> mld groups gave good result.
> 
> show mfea6 (interface address, dataflow) command gives nothing. could the
> problem be there?
> 
> Also, we have noticed that MLD wont start unless default-system-config is
> set. When we try configure fixed addresses in config file, log shows
> invalid primary address during startup. When we set addresses manualy. and
> configure default-system-config in interfaces section, router
> >starts fine.

Darko,

I have fixed the xorpsh CLI problem (the mfea6 CLI output itself
wasn't enabled on startup). Also, I did a bit of refactoring of the
code related to updating the primary address, hence please get the
lastest code from CVS. Though, this fix shouldn't have impact on the
multicast forwarding problem you have.

However, I think that if you don't use the default-system-config
statement, then the problem you have with the primary address is
that you haven't specified the link-local address.

If you explicitly specify the IP addreses per interface, then you
should specify all addresses. At least, in case of IPv6 you should
specify the link-local address, and a domain-wide address. MLD and
PIM-SM use the link-local address to originate the control packets
that are multicast on that LAN.

FYI, I just tried PIM-SM (IPv6) on FreeBSD-4.9, and I didn't see
any problems.
Hence, could you send me your topology and the log output from each
XORP router (but make sure that in your config file(s) all
appropriate network interfaces are enabled inside the
interface/mfea6/mld/pimsm6 configuration blocks).
After looking into the log output I may ask you about some CLI
output as well.

Thanks,
Pavlin



From crobson@cmf.nrl.navy.mil  Sun Aug 29 12:28:08 2004
From: crobson@cmf.nrl.navy.mil (Chris Robson)
Date: Sun, 29 Aug 2004 07:28:08 -0400
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <200408232144.i7NLiAwK013865@possum.icir.org>
References: <200408232144.i7NLiAwK013865@possum.icir.org>
Message-ID: <6.1.2.0.2.20040829070455.01ef0bf8@ginger.cmf.nrl.navy.mil>

--=======17F8287C=======
Content-Type: text/plain; x-avg-checked=avg-ok-94017FD; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit


Pavlin

Sorry, its been a while, but as I said, work sometimes gets in the 
way.  Anyway, I have had some real success.  Rebuilt 4 machines as Fedora 
Core 2 with the latest Fedora updates (this took sometime in itself) and 
download the latest XORP CVS and built it into the machines.  Then put 
together the following network, note all connects where machine to machine 
with "no" ethernet hub or switch between them.

Linux 2.6 router <------> Linux 2.6 rtr <--------> Linux 2.6 rtr.

At first one of the edge routers was behaving strangely.  It would get into 
RIP query - response cycles.     Even before running XORP however I noticed 
the machine's behavior as strange in that it was very slow in responding to 
anything (aka painting windows, cursor movement, not a hacker problem cause 
the network is unaccessible from anything external).  Anyway, I replaced it 
with another machine.
So the bottom line is  XORP appears to work and things like PIM neighbor 
updates and rip routing seems to function.  Seeing PIM peers and what 
appears as good hello exchanges (tcpdump monitoring) is telling me I've 
gotten much further than my problems I first reported to you.
Now I have to wonder, was it the Fedora upgrade that fixed the problem or 
what.  I suspect it was the slow machine, because the original test 
environment (my systems at work) I also noticed that my backbone Linux box 
was behaving strangely slow as well.  Specifically, the hardware I was 
using was as follows.  One the edge where two Dell dual Xeon servers and 
the backbone router was a Dell single P4 processor server system.  During 
my tests at work I noticed doing things like tcpdump on the P4 was erratic 
at best, with the display output doing nothing at time when running traffic 
through the P4 Dell.  So I suspect either a bad built system or overloaded 
processor.  I'm going to re-architect my configuration at work, replacing 
the P4 for another dual Xeon system and retest.

I do have another question.  how does the "configuration" command work?  I 
have created a xorp account and even logged in as the xorp user but every 
time I try configuation command in xorpsh it tells me no permissions.

....chris

At 05:44 PM 8/23/2004, Pavlin Radoslavov wrote:

> > Sorry, I thought I said, all my linux boxes where directly connected to
> > each other.  But anyway, you have asked for info whcih will take me a few
>
>OK, that is good to know. I thought that there is some unusual
>connectivity between them that would complicate the problem.
>
> > days to collect, which I already have started doing, namely, updating all
> > boxes in the cofnigure with the latest Fedora Core 2 updates (which
> > includes a kernel update) and I did a CVS pull and rebuild.  One question
> > however, when I do "make check" on the XORP build, it fails one of the
> > tests (I'll have to get that info to you later), should I focus on making
> > sure it passes all tests, or not worry about the check test.  Again the
> > test config is .......
> >
> > Host<---->Linux RTR<--->Linux RTR<--->Linux RTR<--->host
> >
> > All RTRs are directly connected to each other, hosts will actually be
> > connected to associated Linux RTR via a Linksys
> > hub.  I.E.   Host<-->Linksys Hub<-->Linux RTR.  But the Linux RTR links 
> are
> > "not" thru the hub but RTR to RTR direct.
> >
> > I'll need about a week to complete this, unfortunately I have a job 
> that is
> > getting in the way of fun stuff......
>
>BTW, which particular test fails when you run "gmake check"?
>For now I wouldn't worry about that particular test.
>Anyway, after you have completed the update and have collected the
>tcpdump info please let me know the result so we can take it from
>there.
>
>Thanks,
>Pavlin
>_______________________________________________
>Xorp-users mailing list
>Xorp-users@xorp.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004

--=======17F8287C=======
Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-94017FD
Content-Disposition: inline


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.744 / Virus Database: 496 - Release Date: 8/24/2004

--=======17F8287C=======--


From a.greenhalgh@cs.ucl.ac.uk  Mon Aug 30 19:10:28 2004
From: a.greenhalgh@cs.ucl.ac.uk (Adam Greenhalgh)
Date: Mon, 30 Aug 2004 19:10:28 +0100
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <6.1.2.0.2.20040829070455.01ef0bf8@ginger.cmf.nrl.navy.mil>
References: <200408232144.i7NLiAwK013865@possum.icir.org> <6.1.2.0.2.20040829070455.01ef0bf8@ginger.cmf.nrl.navy.mil>
Message-ID: <4769af410408301110bb9c14e@mail.gmail.com>

You need to have a unix group "xorp" and your user "xorp" needs to be
a member of that group so that you have permissions to enter the
configuration mode.

XORP Guys : One for the FAQ.

Adam

On Sun, 29 Aug 2004 07:28:08 -0400, Chris Robson
<crobson@cmf.nrl.navy.mil> wrote:
> 
> Pavlin
> 
> Sorry, its been a while, but as I said, work sometimes gets in the
> way.  Anyway, I have had some real success.  Rebuilt 4 machines as Fedora
> Core 2 with the latest Fedora updates (this took sometime in itself) and
> download the latest XORP CVS and built it into the machines.  Then put
> together the following network, note all connects where machine to machine
> with "no" ethernet hub or switch between them.
> 
> Linux 2.6 router <------> Linux 2.6 rtr <--------> Linux 2.6 rtr.
> 
> At first one of the edge routers was behaving strangely.  It would get into
> RIP query - response cycles.     Even before running XORP however I noticed
> the machine's behavior as strange in that it was very slow in responding to
> anything (aka painting windows, cursor movement, not a hacker problem cause
> the network is unaccessible from anything external).  Anyway, I replaced it
> with another machine.
> So the bottom line is  XORP appears to work and things like PIM neighbor
> updates and rip routing seems to function.  Seeing PIM peers and what
> appears as good hello exchanges (tcpdump monitoring) is telling me I've
> gotten much further than my problems I first reported to you.
> Now I have to wonder, was it the Fedora upgrade that fixed the problem or
> what.  I suspect it was the slow machine, because the original test
> environment (my systems at work) I also noticed that my backbone Linux box
> was behaving strangely slow as well.  Specifically, the hardware I was
> using was as follows.  One the edge where two Dell dual Xeon servers and
> the backbone router was a Dell single P4 processor server system.  During
> my tests at work I noticed doing things like tcpdump on the P4 was erratic
> at best, with the display output doing nothing at time when running traffic
> through the P4 Dell.  So I suspect either a bad built system or overloaded
> processor.  I'm going to re-architect my configuration at work, replacing
> the P4 for another dual Xeon system and retest.
> 
> I do have another question.  how does the "configuration" command work?  I
> have created a xorp account and even logged in as the xorp user but every
> time I try configuation command in xorpsh it tells me no permissions.
> 
> ....chris
> 
> 
> 
> At 05:44 PM 8/23/2004, Pavlin Radoslavov wrote:
> 
> > > Sorry, I thought I said, all my linux boxes where directly connected to
> > > each other.  But anyway, you have asked for info whcih will take me a few
> >
> >OK, that is good to know. I thought that there is some unusual
> >connectivity between them that would complicate the problem.
> >
> > > days to collect, which I already have started doing, namely, updating all
> > > boxes in the cofnigure with the latest Fedora Core 2 updates (which
> > > includes a kernel update) and I did a CVS pull and rebuild.  One question
> > > however, when I do "make check" on the XORP build, it fails one of the
> > > tests (I'll have to get that info to you later), should I focus on making
> > > sure it passes all tests, or not worry about the check test.  Again the
> > > test config is .......
> > >
> > > Host<---->Linux RTR<--->Linux RTR<--->Linux RTR<--->host
> > >
> > > All RTRs are directly connected to each other, hosts will actually be
> > > connected to associated Linux RTR via a Linksys
> > > hub.  I.E.   Host<-->Linksys Hub<-->Linux RTR.  But the Linux RTR links
> > are
> > > "not" thru the hub but RTR to RTR direct.
> > >
> > > I'll need about a week to complete this, unfortunately I have a job
> > that is
> > > getting in the way of fun stuff......
> >
> >BTW, which particular test fails when you run "gmake check"?
> >For now I wouldn't worry about that particular test.
> >Anyway, after you have completed the update and have collected the
> >tcpdump info please let me know the result so we can take it from
> >there.
> >
> >Thanks,
> >Pavlin
> >_______________________________________________
> >Xorp-users mailing list
> >Xorp-users@xorp.org
> >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> >
> >
> >
> >---
> >Incoming mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004
> 
> 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.744 / Virus Database: 496 - Release Date: 8/24/2004
> 
>

From crobson@cmf.nrl.navy.mil  Mon Aug 30 22:06:06 2004
From: crobson@cmf.nrl.navy.mil (Chris Robson)
Date: Mon, 30 Aug 2004 17:06:06 -0400
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: <4769af410408301110bb9c14e@mail.gmail.com>
References: <200408232144.i7NLiAwK013865@possum.icir.org>
 <6.1.2.0.2.20040829070455.01ef0bf8@ginger.cmf.nrl.navy.mil>
 <4769af410408301110bb9c14e@mail.gmail.com>
Message-ID: <6.1.2.0.2.20040830170136.021560e0@ginger.cmf.nrl.navy.mil>

--=======33632A8=======
Content-Type: text/plain; x-avg-checked=avg-ok-13B52EEE; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit


Yes, I have that and it doesnt seem to work.  I created a xorp user and 
group.  Further I even logged into the box with that user and still it 
doesnt work.  Yet, xorp_rtrmgr woirks ok which also needs the xorp user/group.

At 02:10 PM 8/30/2004, Adam Greenhalgh wrote:

>You need to have a unix group "xorp" and your user "xorp" needs to be
>a member of that group so that you have permissions to enter the
>configuration mode.
>
>XORP Guys : One for the FAQ.
>
>Adam
>
>On Sun, 29 Aug 2004 07:28:08 -0400, Chris Robson
><crobson@cmf.nrl.navy.mil> wrote:
> >
> > Pavlin
> >
> > Sorry, its been a while, but as I said, work sometimes gets in the
> > way.  Anyway, I have had some real success.  Rebuilt 4 machines as Fedora
> > Core 2 with the latest Fedora updates (this took sometime in itself) and
> > download the latest XORP CVS and built it into the machines.  Then put
> > together the following network, note all connects where machine to machine
> > with "no" ethernet hub or switch between them.
> >
> > Linux 2.6 router <------> Linux 2.6 rtr <--------> Linux 2.6 rtr.
> >
> > At first one of the edge routers was behaving strangely.  It would get into
> > RIP query - response cycles.     Even before running XORP however I noticed
> > the machine's behavior as strange in that it was very slow in responding to
> > anything (aka painting windows, cursor movement, not a hacker problem cause
> > the network is unaccessible from anything external).  Anyway, I replaced it
> > with another machine.
> > So the bottom line is  XORP appears to work and things like PIM neighbor
> > updates and rip routing seems to function.  Seeing PIM peers and what
> > appears as good hello exchanges (tcpdump monitoring) is telling me I've
> > gotten much further than my problems I first reported to you.
> > Now I have to wonder, was it the Fedora upgrade that fixed the problem or
> > what.  I suspect it was the slow machine, because the original test
> > environment (my systems at work) I also noticed that my backbone Linux box
> > was behaving strangely slow as well.  Specifically, the hardware I was
> > using was as follows.  One the edge where two Dell dual Xeon servers and
> > the backbone router was a Dell single P4 processor server system.  During
> > my tests at work I noticed doing things like tcpdump on the P4 was erratic
> > at best, with the display output doing nothing at time when running traffic
> > through the P4 Dell.  So I suspect either a bad built system or overloaded
> > processor.  I'm going to re-architect my configuration at work, replacing
> > the P4 for another dual Xeon system and retest.
> >
> > I do have another question.  how does the "configuration" command work?  I
> > have created a xorp account and even logged in as the xorp user but every
> > time I try configuation command in xorpsh it tells me no permissions.
> >
> > ....chris
> >
> >
> >
> > At 05:44 PM 8/23/2004, Pavlin Radoslavov wrote:
> >
> > > > Sorry, I thought I said, all my linux boxes where directly connected to
> > > > each other.  But anyway, you have asked for info whcih will take me 
> a few
> > >
> > >OK, that is good to know. I thought that there is some unusual
> > >connectivity between them that would complicate the problem.
> > >
> > > > days to collect, which I already have started doing, namely, 
> updating all
> > > > boxes in the cofnigure with the latest Fedora Core 2 updates (which
> > > > includes a kernel update) and I did a CVS pull and rebuild.  One 
> question
> > > > however, when I do "make check" on the XORP build, it fails one of the
> > > > tests (I'll have to get that info to you later), should I focus on 
> making
> > > > sure it passes all tests, or not worry about the check test.  Again the
> > > > test config is .......
> > > >
> > > > Host<---->Linux RTR<--->Linux RTR<--->Linux RTR<--->host
> > > >
> > > > All RTRs are directly connected to each other, hosts will actually be
> > > > connected to associated Linux RTR via a Linksys
> > > > hub.  I.E.   Host<-->Linksys Hub<-->Linux RTR.  But the Linux RTR links
> > > are
> > > > "not" thru the hub but RTR to RTR direct.
> > > >
> > > > I'll need about a week to complete this, unfortunately I have a job
> > > that is
> > > > getting in the way of fun stuff......
> > >
> > >BTW, which particular test fails when you run "gmake check"?
> > >For now I wouldn't worry about that particular test.
> > >Anyway, after you have completed the update and have collected the
> > >tcpdump info please let me know the result so we can take it from
> > >there.
> > >
> > >Thanks,
> > >Pavlin
> > >_______________________________________________
> > >Xorp-users mailing list
> > >Xorp-users@xorp.org
> > >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> > >
> > >
> > >
> > >---
> > >Incoming mail is certified Virus Free.
> > >Checked by AVG anti-virus system (http://www.grisoft.com).
> > >Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004
> >
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.744 / Virus Database: 496 - Release Date: 8/24/2004
> >
> >
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.744 / Virus Database: 496 - Release Date: 8/24/2004

--=======33632A8=======
Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-13B52EEE
Content-Disposition: inline


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.744 / Virus Database: 496 - Release Date: 8/24/2004

--=======33632A8=======--


From pavlin@icir.org  Mon Aug 30 22:59:45 2004
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 30 Aug 2004 14:59:45 -0700
Subject: [Xorp-users] Linux 2.6 multicast issue using PIM
In-Reply-To: Message from Chris Robson <crobson@cmf.nrl.navy.mil>
 of "Mon, 30 Aug 2004 17:06:06 EDT." <6.1.2.0.2.20040830170136.021560e0@ginger.cmf.nrl.navy.mil>
Message-ID: <200408302159.i7ULxjwK049715@possum.icir.org>

Chris,

I am glad that the new setup is starting to work for you.
I don't know why the older machine has been behaving that way. It
could be a hardware problem (e.g., faulty network card), but it
could be something else.
I haven't followed the Linux kernel changes, so I don't know whether
older versions of the kernel had some problems that had been fixed
later.

Re. configuring XORP in general, in addition to the documentation
available from the web site, you can have a look in the
xorp/docs/user_manual/user_manual.{ps,pdf} document (though you need
to have Latex installed to compile it). That document is much more
detailed about the documents from the web site.

About the "configure" problem you have, can you send the relevant
error/log messages from the xorpsh and from the rtrmgr.

Regards,
Pavlin

> Yes, I have that and it doesnt seem to work.  I created a xorp user and 
> group.  Further I even logged into the box with that user and still it 
> doesnt work.  Yet, xorp_rtrmgr woirks ok which also needs the xorp user/group.
> 
> At 02:10 PM 8/30/2004, Adam Greenhalgh wrote:
> 
> >You need to have a unix group "xorp" and your user "xorp" needs to be
> >a member of that group so that you have permissions to enter the
> >configuration mode.
> >
> >XORP Guys : One for the FAQ.
> >
> >Adam
> >
> >On Sun, 29 Aug 2004 07:28:08 -0400, Chris Robson
> ><crobson@cmf.nrl.navy.mil> wrote:
> > >
> > > Pavlin
> > >
> > > Sorry, its been a while, but as I said, work sometimes gets in the
> > > way.  Anyway, I have had some real success.  Rebuilt 4 machines as Fedora
> > > Core 2 with the latest Fedora updates (this took sometime in itself) and
> > > download the latest XORP CVS and built it into the machines.  Then put
> > > together the following network, note all connects where machine to machine
> > > with "no" ethernet hub or switch between them.
> > >
> > > Linux 2.6 router <------> Linux 2.6 rtr <--------> Linux 2.6 rtr.
> > >
> > > At first one of the edge routers was behaving strangely.  It would get into
> > > RIP query - response cycles.     Even before running XORP however I noticed
> > > the machine's behavior as strange in that it was very slow in responding to
> > > anything (aka painting windows, cursor movement, not a hacker problem cause
> > > the network is unaccessible from anything external).  Anyway, I replaced it
> > > with another machine.
> > > So the bottom line is  XORP appears to work and things like PIM neighbor
> > > updates and rip routing seems to function.  Seeing PIM peers and what
> > > appears as good hello exchanges (tcpdump monitoring) is telling me I've
> > > gotten much further than my problems I first reported to you.
> > > Now I have to wonder, was it the Fedora upgrade that fixed the problem or
> > > what.  I suspect it was the slow machine, because the original test
> > > environment (my systems at work) I also noticed that my backbone Linux box
> > > was behaving strangely slow as well.  Specifically, the hardware I was
> > > using was as follows.  One the edge where two Dell dual Xeon servers and
> > > the backbone router was a Dell single P4 processor server system.  During
> > > my tests at work I noticed doing things like tcpdump on the P4 was erratic
> > > at best, with the display output doing nothing at time when running traffic
> > > through the P4 Dell.  So I suspect either a bad built system or overloaded
> > > processor.  I'm going to re-architect my configuration at work, replacing
> > > the P4 for another dual Xeon system and retest.
> > >
> > > I do have another question.  how does the "configuration" command work?  I
> > > have created a xorp account and even logged in as the xorp user but every
> > > time I try configuation command in xorpsh it tells me no permissions.