From yindong1982 at gmail.com  Mon May  4 12:57:40 2009
From: yindong1982 at gmail.com (dong yin)
Date: Mon, 4 May 2009 15:57:40 -0400
Subject: [Xorp-hackers] Hi all, one simple question.
Message-ID: <fed972f50905041257v2e708058u3a696a5b77b9aa24@mail.gmail.com>

Hi,

I tried to run xorpsh command to configure but I can not run the command. I
installed the XORP1.6 followed the instruction online ./configure, make,
make check. Did I make any mistake? Thank you.

-- 
Best regards,
Dong

ECE Dept.
University of Massachusetts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090504/69884329/attachment.html 

From i at levsha.org.ua  Mon May  4 14:04:53 2009
From: i at levsha.org.ua (Mykola Dzham)
Date: Tue, 5 May 2009 00:04:53 +0300
Subject: [Xorp-hackers] 'unused parameter' error when build xorp on freebsd
	with	--disable-ipv6
Message-ID: <20090504210453.GA31065@expo.ukrweb.net>

Hi!
I try to build xorp-1.6 from ports on FreeBSD 8.0-CURRENT g++ (GCC)
4.2.1 20070719 and build stops:

/bin/sh ../../../libtool --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I. -I../../.. -I../../..    -Wno-uninitialized -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT firewall_get_ipfw2.lo -MD -MP -MF .deps/firewall_get_ipfw2.Tpo -c -o firewall_get_ipfw2.lo firewall_get_ipfw2.cc
 c++ -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -Wno-uninitialized -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT firewall_get_ipfw2.lo -MD -MP -MF .deps/firewall_get_ipfw2.Tpo -c firewall_get_ipfw2.cc  -fPIC -DPIC -o .libs/firewall_get_ipfw2.o
cc1plus: warnings being treated as errors
firewall_get_ipfw2.cc:143: warning: unused parameter 'firewall_entry_list'

I writed patch (attached), that fix build, but i not tested xorp
working. Can anyone confirm build problem and test this patch?
 
-- 
Mykola Dzham, LEFT-(UANIC|RIPE)
JID: levsha at jabber.net.ua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-no-ipv6-fw.patch
Type: text/x-diff
Size: 1185 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090505/9c95fe64/attachment.bin 

From syed.khalid at xorp.net  Mon May  4 15:27:41 2009
From: syed.khalid at xorp.net (Syed Khalid)
Date: Mon, 4 May 2009 15:27:41 -0700
Subject: [Xorp-hackers] Hi all, one simple question.
In-Reply-To: <fed972f50905041257v2e708058u3a696a5b77b9aa24@mail.gmail.com>
References: <fed972f50905041257v2e708058u3a696a5b77b9aa24@mail.gmail.com>
Message-ID: <c48427780905041527q50eb3a8fj71418be72d30e10f@mail.gmail.com>

Dong
  Can you open a bug on this? Please include OS, error messages,
configuration files, etc
Syed

On Mon, May 4, 2009 at 12:57 PM, dong yin <yindong1982 at gmail.com> wrote:

> Hi,
>
> I tried to run xorpsh command to configure but I can not run the command. I
> installed the XORP1.6 followed the instruction online ./configure, make,
> make check. Did I make any mistake? Thank you.
>
> --
> Best regards,
> Dong
>
> ECE Dept.
> University of Massachusetts.
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers<http://mailman.icsi.berkeley.edu/mailman/listinfo/xorp-hackers>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090504/0e1f34db/attachment.html 

From jjw0927 at 126.com  Sun May 10 21:13:01 2009
From: jjw0927 at 126.com (jjw0927)
Date: Mon, 11 May 2009 12:13:01 +0800 (CST)
Subject: [Xorp-hackers] How to Launching Net-SNMP via the router manager?
Message-ID: <20211432.166311242015181690.JavaMail.coremail@bj126app87.126.com>

Hi all,

I have installed XORP-1.6-RC and Net-SNMP-5.4.2.1. And Both of them have been compiled. 
I have configured the Net-snmp and XORP according the files of "${XORP}/mibs/snmpdscripts/README" and "XORP SNMP Agent 1.6.pdf".

And now I want to launch Net-SNMP via the router manager, but it failed. Below is the output when I run the command "sudo ./xorp_rtrmgr -b config.boot" in terminal:

[ 2009/05/11 09:27:59  INFO xorp_rtrmgr:3574 RTRMGR +249 master_conf_tree.cc
execute ] Changed modules: xorp_if_mib
[ 2009/05/11 09:27:59  INFO xorp_rtrmgr:3574 RTRMGR +101 module_manager.cc
execute ] Executing module: xorp_if_mib (mibs/snmpdscripts/startsnmp)
No log handling enabled - turning on stderr logging
registered debug token xorp_if_mib_module, 1
registered debug token dlmod, 1
registered debug token usmUser, 1
dlmod:
register mib
dlmod:
dlmod_path: /usr/local/lib/snmp/dlmod
dlmod:
dlmod_create_module
dlmod:
dlmod_load_module xorp_if_mib_module:
/usr/local/src/xorp-1.6-RC/mibs/.libs/xorp_if_mib_module.so
xorp_if_mib_module:
XorpIfMib created
xorp_if_mib_module:
Initialized...
Turning on AgentX master support.
NET-SNMP version 5.4.2.1
dlmod:
dlmod_create_module
dlmod:
dlmod_load_module bgp4_mib_1657: /usr/local/xorp/mibs/.libs/bgp4_mib_1657.so
[ 2009/05/11 09:28:01 WARNING snmpd XrlXorpIfMibTarget ] Handling method for
xorp_if_mib/0.1/load_mib failed: XrlCmdError 102 Command failed
[ 2009/05/11 09:28:01  ERROR xorp_rtrmgr:3574 RTRMGR +691 master_conf_tree.cc
commit_pass2_done ] Commit failed: 102 Command failed
[ 2009/05/11 09:28:01  ERROR xorp_rtrmgr:3574 RTRMGR +261 master_conf_tree.cc
config_done ] Configuration failed: 102 Command failed
[ 2009/05/11 09:28:01  INFO xorp_rtrmgr:3574 RTRMGR +2233 task.cc run_task ]
No more tasks to run
[ 2009/05/11 09:28:01  INFO xorp_rtrmgr:3574 RTRMGR +176 module_manager.cc
terminate ] Terminating module: xorp_if_mib
[ 2009/05/11 09:28:01  INFO xorp_rtrmgr:3574 RTRMGR +199 module_manager.cc
terminate ] Killing module: xorp_if_mib
Received TERM or STOP signal...  shutting down...
No log handling enabled - turning on stderr logging
xorp_if_mib_module:
Unloaded...
xorp_if_mib_module:
XorpIfMib destroyed
dlmod:
Module xorp_if_mib_module unloaded
[ 2009/05/11 09:28:01  ERROR xorp_rtrmgr:3574 RTRMGR +754 module_manager.cc
done_cb ]Command "/usr/local/src/xorp-1.6-RC/mibs/snmpdscripts/startsnmp":
terminated with signal 15.
[ 2009/05/11 09:28:01  INFO xorp_rtrmgr:3574 RTRMGR +287 module_manager.cc
module_exited ] Module killed during shutdown: xorp_if_mib 

And Below is the content of "config.boot" I used to run rtrmgr:

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

I do not know what is wrong in my configuration, your help is appreciated for me.

Thank you very much!

Best Regard
Jianwu Jin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090511/2a6531ea/attachment.html 

From pvenegas at gmail.com  Mon May 11 01:24:15 2009
From: pvenegas at gmail.com (pmv)
Date: Mon, 11 May 2009 16:24:15 +0800
Subject: [Xorp-hackers] vif indeces
In-Reply-To: <626e40340905110117t5512b26an25672366b7b22114@mail.gmail.com>
References: <626e40340905110117t5512b26an25672366b7b22114@mail.gmail.com>
Message-ID: <626e40340905110124n5f8e56dap40b0e24b3023db49@mail.gmail.com>

Good day.

I am currently writing an extension module to xorp for my own use.
Basically, I want to be informed by the IGMP module whenever membership
changes. I am currently doing this through the XRL interfaces. I have
however hit a bump. The following interface calls for a vif_index to be
passed.

    add_protocol4    ? xrl_sender_name:txt                \
            & protocol_name:txt & protocol_id:u32        \
            & vif_name:txt & vif_index:u32

I can get the list of interfaces and vifs using
finder://fea/ifmgr/0.1/get_configured_interface_names and
get_configured_vif_names, respectively, but fea_ifmgr (or any other targets)
does not seem to provide a way to retrieve the corresponding vif_index of
each. Is there a way to do this?

My current options are as follows
a) Implement my module as a full-fledged ProtoNode<V>, and have my own list
of vifs
b) Hack the IGMP module to locate the vif using only the vif_name, or add a
new XRL call to do this, since ProtoNode<V>::vif_find_by_name() is
available. I do not know why redundant vif identifiers are required anyway.
This would however require changes to xorp code.

Please let me know if there are better ways. Looking forward to your reply.

-- 
pmv
random hacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090511/1da09ef6/attachment.html 

From bms at incunabulum.net  Mon May 11 22:11:36 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue, 12 May 2009 06:11:36 +0100
Subject: [Xorp-hackers] 'unused parameter' error when build xorp on
 freebsd with	--disable-ipv6
In-Reply-To: <20090504210453.GA31065@expo.ukrweb.net>
References: <20090504210453.GA31065@expo.ukrweb.net>
Message-ID: <4A090508.8090302@incunabulum.net>

Thanks for this fix, it looks like it should go in.

regards,
BMS


From bms at incunabulum.net  Mon May 11 22:23:25 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue, 12 May 2009 06:23:25 +0100
Subject: [Xorp-hackers] vif indeces
In-Reply-To: <626e40340905110124n5f8e56dap40b0e24b3023db49@mail.gmail.com>
References: <626e40340905110117t5512b26an25672366b7b22114@mail.gmail.com>
	<626e40340905110124n5f8e56dap40b0e24b3023db49@mail.gmail.com>
Message-ID: <4A0907CD.2060103@incunabulum.net>

Hi,

Thanks for your question about VIF indexes.

If you are just trying to hook off the IGMP module to discover new 
multicast endpoints, you shouldn't need to implement a ProtoNode.

At the moment, b) is probably the cleanest solution overall. If it is a 
simple matter of looking up the MFEA VIF index based on a VIF name, then 
please feel free to submit a patch which exposes 
ProtoNode<V>::vif_find_by_name() via an XRL.

pmv wrote:
> ...
> I can get the list of interfaces and vifs using 
> finder://fea/ifmgr/0.1/get_configured_interface_names and 
> get_configured_vif_names, respectively, but fea_ifmgr (or any other 
> targets) does not seem to provide a way to retrieve the corresponding 
> vif_index of each. Is there a way to do this?
>
> My current options are as follows
> a) Implement my module as a full-fledged ProtoNode<V>, and have my own 
> list of vifs
> b) Hack the IGMP module to locate the vif using only the vif_name, or 
> add a new XRL call to do this, since ProtoNode<V>::vif_find_by_name() 
> is available. I do not know why redundant vif identifiers are required 
> anyway. This would however require changes to xorp code.

Some background information:
    The MFEA code is very tied to the BSD MROUTING kernel multicast 
forwarding code -- and the VIF indexes in the MFEA aren't directly 
related to the FEA's notion of a VIF; they aren't redundant, as such, 
they are different identifiers.
    In MROUTING, a VIF index is what's found in the 'struct mfcctl2' 
structure used to configure multicast forwarding, and I believe this is 
what the MFEA is dealing with internally.
    Linux largely follows MROUTING in its implementation, and there are 
weaknesses in this implementation; struct mfcctl2 contains a bitfield 
mask which is 32 bits wide. This means that multicast forwarding can't 
scale beyond 32 interfaces in either Linux or any of the BSDs.
    MROUTING was a research implementation in the beginning, and one of 
the goals was to keep multicast forwarding separate from the unicast 
forwarding path. Whilst I've had discussions privately with Pavlin 
Radoslavov about how this limitation might be addressed, there hasn't 
been any demand from outside to fix it -- yet.

There are platforms (e.g. Windows) where the multicast forwarding plane 
is configured in a completely different way, and the MFEA wouldn't be 
suitable for driving it without significant code refactoring.

thanks,
BMS


From pvenegas at gmail.com  Mon May 11 23:19:34 2009
From: pvenegas at gmail.com (pmv)
Date: Tue, 12 May 2009 14:19:34 +0800
Subject: [Xorp-hackers] vif indeces
In-Reply-To: <4A0907CD.2060103@incunabulum.net>
References: <626e40340905110117t5512b26an25672366b7b22114@mail.gmail.com>
	<626e40340905110124n5f8e56dap40b0e24b3023db49@mail.gmail.com>
	<4A0907CD.2060103@incunabulum.net>
Message-ID: <626e40340905112319q3d269b5fi32743e80bc3d37db@mail.gmail.com>

Good day.


> At the moment, b) is probably the cleanest solution overall. If it is a
> simple matter of looking up the MFEA VIF index based on a VIF name, then
> please feel free to submit a patch which exposes
> ProtoNode<V>::vif_find_by_name() via an XRL.


Will do, thanks.

Another thing. Does an IGMP XRL client need to register with finder as a
target, or would adding XrlStdRouter handlers for
'mld6igmp_client/0.1/add_membership4' (and others) and calling
XrlMld6igmpV0p1Client::send_add_protocol4() be enough?


> Some background information:
>   The MFEA code is very tied to the BSD MROUTING kernel multicast
> forwarding code -- and the VIF indexes in the MFEA aren't directly related
> to the FEA's notion of a VIF; they aren't redundant, as such, they are
> different identifiers.


If that is the case, which should take precedence? Which should be authority
for vif indeces, or furthermore between vif names and indeces? Are there
specific situations in which this should be a consideration?


>
>   In MROUTING, a VIF index is what's found in the 'struct mfcctl2'
> structure used to configure multicast forwarding, and I believe this is what
> the MFEA is dealing with internally.
>   Linux largely follows MROUTING in its implementation, and there are
> weaknesses in this implementation; struct mfcctl2 contains a bitfield mask
> which is 32 bits wide. This means that multicast forwarding can't scale
> beyond 32 interfaces in either Linux or any of the BSDs.
>   MROUTING was a research implementation in the beginning, and one of the
> goals was to keep multicast forwarding separate from the unicast forwarding
> path. Whilst I've had discussions privately with Pavlin Radoslavov about how
> this limitation might be addressed, there hasn't been any demand from
> outside to fix it -- yet.
>
> There are platforms (e.g. Windows) where the multicast forwarding plane is
> configured in a completely different way, and the MFEA wouldn't be suitable
> for driving it without significant code refactoring.
>

So portability might be an issue then? I mostly work on FreeBSD exclusively.

Thanks for taking time to reply.

-- 
pmv
random hacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090512/d1b2535d/attachment.html 

From bms at incunabulum.net  Mon May 11 23:49:52 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue, 12 May 2009 07:49:52 +0100
Subject: [Xorp-hackers] vif indeces
In-Reply-To: <626e40340905112319q3d269b5fi32743e80bc3d37db@mail.gmail.com>
References: <626e40340905110117t5512b26an25672366b7b22114@mail.gmail.com>	
	<626e40340905110124n5f8e56dap40b0e24b3023db49@mail.gmail.com>	
	<4A0907CD.2060103@incunabulum.net>
	<626e40340905112319q3d269b5fi32743e80bc3d37db@mail.gmail.com>
Message-ID: <4A091C10.6020602@incunabulum.net>

pmv wrote:
> Good day.
>  
>
>     At the moment, b) is probably the cleanest solution overall. If it
>     is a simple matter of looking up the MFEA VIF index based on a VIF
>     name, then please feel free to submit a patch which exposes
>     ProtoNode<V>::vif_find_by_name() via an XRL.
>
>
> Will do, thanks.
>
> Another thing. Does an IGMP XRL client need to register with finder as 
> a target, or would adding XrlStdRouter handlers for 
> 'mld6igmp_client/0.1/add_membership4' (and others) and calling 
> XrlMld6igmpV0p1Client::send_add_protocol4() be enough?

You need to do a bit more work in a XORP process to implement an XRL 
target instead of just sending XRLs. An XrlStdRouter instance is enough 
to send XRLs, but not to receive them. For an example, look at the OLSR 
code:
    
http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/xorp_olsr.cc?rev=1.4

...here, in OLSR's main() function, the XrlStdRouter instance is created 
before the XrlOlsr4Target instance, because its constructor needs to see 
an XrlRouter instance. The XrlOlsr4Target class is a proxy which glues 
the implementation to the XRL layer. It is automatically generated from 
the xrl/targets/olsr4.tgt file.

    Assuming you write a .tgt file for your process's XRL target, and 
add handlers for the mld6igmp_client XIF, as with any other XORP 
component, the Finder should be notified of the registration when your 
process starts. Feel free to use the contrib/olsr code as a reference.

    One of the shortcomings of using the GNU Autotools build system is 
that you cannot implement new XRL targets without actually adding them 
to the top level xrl/ directory. I managed to overcome this limitation 
in Jam and Boost.Build when developing OLSR, but that is not officially 
supported, and it is likely the Jamfiles will go away in future. My 
understanding is that we plan to switch to a new Python-based build 
tool, SCons, which should eliminate this tedious and inconvenient step.

    If you want to build your application using XORP 1.6, then you will 
need to add your .tgt and .xif files to the global xrl/ directory, 
together with the relevant entries in Makefile.am.  It is entirely 
likely that XRL may change greatly in future for this and other reasons.

>  
>
>     Some background information:
>       The MFEA code is very tied to the BSD MROUTING kernel multicast
>     forwarding code -- and the VIF indexes in the MFEA aren't directly
>     related to the FEA's notion of a VIF; they aren't redundant, as
>     such, they are different identifiers.
>
>
> If that is the case, which should take precedence? Which should be 
> authority for vif indeces, or furthermore between vif names and 
> indeces? Are there specific situations in which this should be a 
> consideration?

I would rely on the MFEA for this mapping.

XORP client processes should never use interface indexes directly; MFEA 
VIF indexes are entirely separate from any other notion of interface 
names or indexes, only the MFEA knows about them.

Unfortunately, in extending IGMP, you've found a weak spot in the API 
where the MFEA VIF index has to be exposed for the XRLs to be useful. Up 
until now, this hasn't been an issue, because normally only PIM and IGMP 
interact with the MFEA directly.

>  
>
>
>       In MROUTING, a VIF index is what's found in the 'struct mfcctl2'
>     structure used to configure multicast forwarding, and I believe
>     this is what the MFEA is dealing with internally
>
...
>
>     There are platforms (e.g. Windows) where the multicast forwarding
>     plane is configured in a completely different way, and the MFEA
>     wouldn't be suitable for driving it without significant code
>     refactoring.
>
>
> So portability might be an issue then? I mostly work on FreeBSD 
> exclusively.

I wouldn't worry about it for now, although it is a hairy issue for the 
future which needs to be carefully considered.

It is something we would need to revisit if the MFEA is refactored to 
support multicast forwarding planes other than MROUTING, but it 
shouldn't impact ongoing work with XORP on FreeBSD, as Linux suffers 
from the same issue.

You can regard the multicast forwarding plane on FreeBSD and Linux as 
working more or less identically. Even though the Linux code is not 
directly derived from the 4.4BSD implementation (it is a clean-room 
GPLv2 re-implementation), it is functionally identical, and the kernel 
APIs are more or less identical.

thanks,
BMS


From pvenegas at gmail.com  Tue May 12 00:15:50 2009
From: pvenegas at gmail.com (pmv)
Date: Tue, 12 May 2009 15:15:50 +0800
Subject: [Xorp-hackers] vif indeces
In-Reply-To: <4A091C10.6020602@incunabulum.net>
References: <626e40340905110117t5512b26an25672366b7b22114@mail.gmail.com>
	<626e40340905110124n5f8e56dap40b0e24b3023db49@mail.gmail.com>
	<4A0907CD.2060103@incunabulum.net>
	<626e40340905112319q3d269b5fi32743e80bc3d37db@mail.gmail.com>
	<4A091C10.6020602@incunabulum.net>
Message-ID: <626e40340905120015p48193bb4if2fe89f7d67a2e6@mail.gmail.com>

Thank you very much. This information is very helpful. Kudos on the
excellent high-level and devel documentation as well. All open source
projects should aim to be as developer-friendly (even though it is in C++).
:)

On Tue, May 12, 2009 at 2:49 PM, Bruce Simpson <bms at incunabulum.net> wrote:

> pmv wrote:
>
>> Good day.
>>
>>    At the moment, b) is probably the cleanest solution overall. If it
>>    is a simple matter of looking up the MFEA VIF index based on a VIF
>>    name, then please feel free to submit a patch which exposes
>>    ProtoNode<V>::vif_find_by_name() via an XRL.
>>
>>
>> Will do, thanks.
>>
>> Another thing. Does an IGMP XRL client need to register with finder as a
>> target, or would adding XrlStdRouter handlers for
>> 'mld6igmp_client/0.1/add_membership4' (and others) and calling
>> XrlMld6igmpV0p1Client::send_add_protocol4() be enough?
>>
>
> You need to do a bit more work in a XORP process to implement an XRL target
> instead of just sending XRLs. An XrlStdRouter instance is enough to send
> XRLs, but not to receive them. For an example, look at the OLSR code:
>
> http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/xorp_olsr.cc?rev=1.4
>
> ...here, in OLSR's main() function, the XrlStdRouter instance is created
> before the XrlOlsr4Target instance, because its constructor needs to see an
> XrlRouter instance. The XrlOlsr4Target class is a proxy which glues the
> implementation to the XRL layer. It is automatically generated from the
> xrl/targets/olsr4.tgt file.
>
>   Assuming you write a .tgt file for your process's XRL target, and add
> handlers for the mld6igmp_client XIF, as with any other XORP component, the
> Finder should be notified of the registration when your process starts. Feel
> free to use the contrib/olsr code as a reference.
>
>   One of the shortcomings of using the GNU Autotools build system is that
> you cannot implement new XRL targets without actually adding them to the top
> level xrl/ directory. I managed to overcome this limitation in Jam and
> Boost.Build when developing OLSR, but that is not officially supported, and
> it is likely the Jamfiles will go away in future. My understanding is that
> we plan to switch to a new Python-based build tool, SCons, which should
> eliminate this tedious and inconvenient step.
>
>   If you want to build your application using XORP 1.6, then you will need
> to add your .tgt and .xif files to the global xrl/ directory, together with
> the relevant entries in Makefile.am.  It is entirely likely that XRL may
> change greatly in future for this and other reasons.
>
>
>>    Some background information:
>>      The MFEA code is very tied to the BSD MROUTING kernel multicast
>>    forwarding code -- and the VIF indexes in the MFEA aren't directly
>>    related to the FEA's notion of a VIF; they aren't redundant, as
>>    such, they are different identifiers.
>>
>>
>> If that is the case, which should take precedence? Which should be
>> authority for vif indeces, or furthermore between vif names and indeces? Are
>> there specific situations in which this should be a consideration?
>>
>
> I would rely on the MFEA for this mapping.
>
> XORP client processes should never use interface indexes directly; MFEA VIF
> indexes are entirely separate from any other notion of interface names or
> indexes, only the MFEA knows about them.
>
> Unfortunately, in extending IGMP, you've found a weak spot in the API where
> the MFEA VIF index has to be exposed for the XRLs to be useful. Up until
> now, this hasn't been an issue, because normally only PIM and IGMP interact
> with the MFEA directly.
>
>
>>
>>      In MROUTING, a VIF index is what's found in the 'struct mfcctl2'
>>    structure used to configure multicast forwarding, and I believe
>>    this is what the MFEA is dealing with internally
>>
>>  ...
>
>>
>>    There are platforms (e.g. Windows) where the multicast forwarding
>>    plane is configured in a completely different way, and the MFEA
>>    wouldn't be suitable for driving it without significant code
>>    refactoring.
>>
>>
>> So portability might be an issue then? I mostly work on FreeBSD
>> exclusively.
>>
>
> I wouldn't worry about it for now, although it is a hairy issue for the
> future which needs to be carefully considered.
>
> It is something we would need to revisit if the MFEA is refactored to
> support multicast forwarding planes other than MROUTING, but it shouldn't
> impact ongoing work with XORP on FreeBSD, as Linux suffers from the same
> issue.
>
> You can regard the multicast forwarding plane on FreeBSD and Linux as
> working more or less identically. Even though the Linux code is not directly
> derived from the 4.4BSD implementation (it is a clean-room GPLv2
> re-implementation), it is functionally identical, and the kernel APIs are
> more or less identical.
>
> thanks,
> BMS
>



-- 
pmv
PGP keyID 0xEA5EB160
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090512/974ae303/attachment-0001.html 

From xuhao_hank at yahoo.com.cn  Tue May 19 01:33:35 2009
From: xuhao_hank at yahoo.com.cn (hao xu)
Date: Tue, 19 May 2009 16:33:35 +0800 (CST)
Subject: [Xorp-hackers] how can xorp send routing table to other computer
Message-ID: <536684.75538.qm@web15002.mail.cnb.yahoo.com>

Hi Bruce, 
?
I read the message?which is ?how fea interact with underlying forwarding plane?? and the message you answer it. You said that it is not possible separate fea and forwarding engine. 
Actually I want to separate fea and forwarding engine system, which means that I will let a lot of computer which is connected with Ethernet switch and the computers will be the data plane. And I will let another computer work as control plane which is also connected with the switch. 
?
?
?
?? (card1)?????????????????????????????????????????????????????? ???(card2)???? (card3)
PC1-------------------- Ethernet switch----------PC2 (click) ----------
(Xorp+click)??????????????????????????? ?|?????????????????????????? 
???????????????????????????????????? ??????????? |------------------PC3(click)------------
??????????????????????????????????????????????? ?|------------------PC4(click)-----------
?
PC1 has only one network card which is connected with the switch
PC2 has two network cards. One is connected with the switch and another is connected with external network.
PC3 and PC4 are the same as PC2.
?
PC1 will send the route table to other computers. so, every ip package from external network can know where is the destination. ?
?
This descript my main idea. And I wander how can I send route table from PC1 to PC2 and PC3. What is the direction. I have read a lot about fea, but I still do not know how the fea work with click.
?
thanks and best wishes.


      ___________________________________________________________ 
  ????????????????? 
http://card.mail.cn.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090519/bab4754e/attachment.html 

From bms at incunabulum.net  Tue May 19 02:34:33 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue, 19 May 2009 10:34:33 +0100
Subject: [Xorp-hackers] how can xorp send routing table to other computer
In-Reply-To: <536684.75538.qm@web15002.mail.cnb.yahoo.com>
References: <536684.75538.qm@web15002.mail.cnb.yahoo.com>
Message-ID: <4A127D29.7020500@incunabulum.net>

Hello,

hao xu wrote:
>
>
> I read the message which is ?how fea interact with underlying 
> forwarding plane?? and the message you answer it. You said that it is 
> not possible separate fea and forwarding engine.
>
> Actually I want to separate fea and forwarding engine system, which 
> means that I will let a lot of computer which is connected with 
> Ethernet switch and the computers will be the data plane. And I will 
> let another computer work as control plane which is also connected 
> with the switch. 
>
> ...
>
> This descript my main idea. And I wander how can I send route table 
> from PC1 to PC2 and PC3. What is the direction. I have read a lot 
> about fea, but I still do not know how the fea work with click.
>

It sounds like what you are trying to do is more specific to Click than 
it is to XORP. In the XORP model, the FEA process must run on the node 
which is forwarding.

It may well be possible to run Click on a separate node from the FEA 
process itself, but I can't offer any support on how to do this, nor 
offer any advice. Perhaps someone on the Click mailing list can better 
help you with your question?

thanks,
BMS


From itsme_neo1 at yahoo.co.in  Fri May 22 12:22:31 2009
From: itsme_neo1 at yahoo.co.in (neo reeves)
Date: Sat, 23 May 2009 00:52:31 +0530 (IST)
Subject: [Xorp-hackers] Please help me out in multicast routing(PIM-SM4)
	setup
Message-ID: <462111.13065.qm@web94001.mail.in2.yahoo.com>

Hi All,

    Since from few days I am working on XORP for setting up multicast routing(PIM-SM4) on a Fedora 8 system. It compiled easily without any problems and today I executed it with proper(i think ;) ) configuration and it's running. 

Now I have few doubts and they are:

	* How to cross-check that my XORP installation was running properly?
	* What is "static-rps" and what's the use of this in multicast routing(PIM-SM4)?
Here I am listing out my fedora 8 system configuration and the XORP configuration(i.e. config.boot).

OS: fedora 8
Ethernet interface: eth0(ipv4, 172.22.22.200 --> intel 82566DC, gigabit card) 

 ==>start of config.boot:

/* $XORP: xorp/rtrmgr/config/multicast4.boot,v 1.1 2007/08/29 06:49:43 pavlin Exp $ */

interfaces {
    interface eth0 {
        default-system-config
    }
}

fea {
    unicast-forwarding4 {
        disable: false
    }
}

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

protocols {
    igmp {
        interface eth0 {
            vif eth0 {
                disable: false
            }
        }
        traceoptions {
            flag all {
                disable: false
            }
        }
    }
}

protocols {
    pimsm4 {
        interface eth0 {
            vif eth0 {
                disable: false
            }
        }
        interface register_vif {
            vif register_vif {
                /* Note: this vif should be always enabled */
                disable: false
            }
        }
        static-rps {
            rp 193.191.0.254 {
                group-prefix 224.0.0.0/4 {
                    rp-priority: 192
                    hash-mask-len: 30
                }
            }
        }
        switch-to-spt-threshold {
            disable: false
            interval: 100
            bytes: 102400
        }
        traceoptions {
            flag all {
                disable: false
            }
        }
    }
}

protocols {
    fib2mrib {
        disable: false
    }
}

==>End of config.boot

I am newbie to this XORP and multicast routing. Any help is greatly appreciated.

Thanks in advance,
Suman



      Cricket on your mind? Visit the ultimate cricket website. Enter http://beta.cricket.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090523/be3324bc/attachment.html 

From bms at incunabulum.net  Thu May 28 08:30:22 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu, 28 May 2009 16:30:22 +0100
Subject: [Xorp-hackers] Please help me out in multicast routing(PIM-SM4)
 setup
In-Reply-To: <462111.13065.qm@web94001.mail.in2.yahoo.com>
References: <462111.13065.qm@web94001.mail.in2.yahoo.com>
Message-ID: <4A1EAE0E.70505@incunabulum.net>

neo reeves wrote:
> Since from few days I am working on XORP for setting up multicast 
> routing(PIM-SM4) on a Fedora 8 system. It compiled easily without any 
> problems and today I executed it with proper(i think ;) ) 
> configuration and it's running.
>
> Now I have few doubts and they are:
>
>     * How to cross-check that my XORP installation was running properly?
>     * What is "static-rps" and what's the use of this in multicast
>       routing(PIM-SM4)?
>
> Here I am listing out my fedora 8 system configuration and the XORP 
> configuration(i.e. config.boot).

Your config looks fine. Please refer to the xorp-users@ mailing list as 
a submitter recently had a very similar set of questions. You may want 
to pick up a copy of the book "Interdomain Multicast Routing" if you're 
new to multicast routing.

thanks,
BMS