From ramu.avula at gmail.com  Tue Jul  4 08:14:31 2006
From: ramu.avula at gmail.com (Ramu k)
Date: Tue, 4 Jul 2006 20:44:31 +0530
Subject: [Xorp-users] Too many open files in system
Message-ID: <b8a6742f0607040814t60ade535k81f30b1bc60709d8@mail.gmail.com>

Hi ,

I am trying to run XORP with 40 VLANS . it is quitting  with the following
error.
i am runnig XORP on FC4. and also set ulimit to 65000 files.still it is
failing.

[ 2006/07/04 11:56:23  ERROR xorp_fea:28353 MFEA +967 mfea_mrouter.cc
add_multicast_vif ]
setsockopt(MRT_ADD_VIF, vif eth0.4) failed: Too many open files in system


Tahnks for any help.


Regards,
Ramu.K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060704/784d8aa8/attachment.html 

From nfenwick at cengen.com  Wed Jul  5 11:42:07 2006
From: nfenwick at cengen.com (Neil Fenwick)
Date: Wed, 05 Jul 2006 14:42:07 -0400
Subject: [Xorp-users] Redistributing the system kernel route table into
 OSPF
In-Reply-To: <200604111735.k3BHZl6r034075@possum.icir.org>
References: <200604111735.k3BHZl6r034075@possum.icir.org>
Message-ID: <44AC07FF.9010108@cengen.com>

An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060705/84f03d16/attachment.html 

From pavlin at icir.org  Wed Jul  5 14:02:13 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 05 Jul 2006 14:02:13 -0700
Subject: [Xorp-users] Redistributing the system kernel route table into
	OSPF
In-Reply-To: Message from Neil Fenwick <nfenwick@cengen.com> 
	of "Wed, 05 Jul 2006 14:42:07 EDT." <44AC07FF.9010108@cengen.com> 
Message-ID: <200607052102.k65L2DaI034887@possum.icir.org>

> I have been working in parallel with Frank to get Xorp to redistribute
> an injected route into OSPF.&nbsp; I have been able to introduce the route
> using the rip protocols and the "connected" and "static" policies;
> however as stated below the features are not sufficient.&nbsp; I have the
> latest CVS and the files have been updated with the patch.&nbsp; I must be
> missing a step but I am not sure what it is any help would be
> appreciated.&nbsp; Below is an error which comes up on the screen and my
> config.boot file.&nbsp; If there are any other trouble shooting step that
> you need from me please let me know.<br>

I believe the error you are referring to is:

[ 2006/07/05 02:02:40&nbsp; WARNING xorp_rtrmgr:3707 XrlFinderTarget +406
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
failed Xrl does not resolve:
finder://ospfv2/policy_redist6/0.1/add_route6<br>
[ 2006/07/05 02:02:40 WARNING xorp_rib RIB ] Unable to complete XRL:
add_route6 for ospfv2 route: Dst: fe80::/64 Vif: eth0 NextHop: NH:::
Metric: 256 Protocol: fib2mrib PolicyTags: 0<br>

The reason for this error is because all fib2mrib routes (IPv4 and
IPv6) are exported to OSPF, but currently OSPF doesn't support IPv6
(yet).
The simplest thing to do is to ignore those warnings. By looking
into the source code, it appears they should be harmless, and
everything else (IPv4) should continue working.
If you find them annoying, then you can modify your policy so it
doesn't redistribute the IPv6 routes to OSPF. E.g.:

policy {
    policy-statement export_fib2mrib {
        term export {
            from {
                protocol: "fib2mrib"
		network4 <= 0.0.0.0/0
            }
        }
    }
}

If you still don't see the fib2mrib routes introduced into OSPF,
then the problem is somewhere else. Please let us know if this is
the case.

Pavlin

> <br>
> [root at localhost rtrmgr]# ./xorp_rtrmgr -b config.boot<br>
> [ 2006/07/05 02:02:20&nbsp; INFO xorp_rtrmgr:3707 RTRMGR +240
> master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib,
> policy, fib2mrib, ospf4<br>
> [ 2006/07/05 02:02:20&nbsp; INFO xorp_rtrmgr:3707 RTRMGR +99
> module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea)<br>
> [ 2006/07/05 02:02:21 INFO xorp_fea MFEA ] MFEA enabled<br>
> [ 2006/07/05 02:02:21 INFO xorp_fea MFEA ] CLI enabled<br>
> [ 2006/07/05 02:02:21 INFO xorp_fea MFEA ] CLI started<br>
> [ 2006/07/05 02:02:21 INFO xorp_fea MFEA ] MFEA enabled<br>
> [ 2006/07/05 02:02:21 INFO xorp_fea MFEA ] CLI enabled<br>
> [ 2006/07/05 02:02:21 INFO xorp_fea MFEA ] CLI started<br>
> [ 2006/07/05 02:02:22&nbsp; INFO xorp_rtrmgr:3707 RTRMGR +99
> module_manager.cc execute ] Executing module: fea (fea/xorp_fea)<br>
> [ 2006/07/05 02:02:28&nbsp; INFO xorp_rtrmgr:3707 RTRMGR +99
> module_manager.cc execute ] Executing module: rib (rib/xorp_rib)<br>
> [ 2006/07/05 02:02:30&nbsp; INFO xorp_rtrmgr:3707 RTRMGR +99
> module_manager.cc execute ] Executing module: policy
> (policy/xorp_policy)<br>
> [ 2006/07/05 02:02:32&nbsp; INFO xorp_rtrmgr:3707 RTRMGR +99
> module_manager.cc execute ] Executing module: fib2mrib
> (fib2mrib/xorp_fib2mrib)<br>
> [ 2006/07/05 02:02:34&nbsp; INFO xorp_rtrmgr:3707 RTRMGR +99
> module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2)<br>
> [ 2006/07/05 02:02:36&nbsp; INFO xorp_rtrmgr:3707 RTRMGR +2228 task.cc
> run_task ] No more tasks to run<br>
> [ 2006/07/05 02:02:40&nbsp; WARNING xorp_rtrmgr:3707 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> failed Xrl does not resolve:
> finder://ospfv2/policy_redist6/0.1/add_route6<br>
> [ 2006/07/05 02:02:40 WARNING xorp_rib RIB ] Unable to complete XRL:
> add_route6 for ospfv2 route: Dst: fe80::/64 Vif: eth0 NextHop: NH:::
> Metric: 256 Protocol: fib2mrib PolicyTags: 0<br>
> [ 2006/07/05 02:02:40&nbsp; WARNING xorp_rtrmgr:3707 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> failed Xrl does not resolve:
> finder://ospfv2/policy_redist6/0.1/delete_route6<br>
> [ 2006/07/05 02:02:40 WARNING xorp_rib RIB ] Unable to complete XRL:
> del_route6 for ospfv2 route: Dst: fe80::/64 Vif: eth0 NextHop: NH:::
> Metric: 256 Protocol: fib2mrib PolicyTags: 0<br>
> [ 2006/07/05 02:02:40&nbsp; WARNING xorp_rtrmgr:3707 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command
> failed Xrl does not resolve:
> finder://ospfv2/policy_redist6/0.1/add_route6<br>
> [ 2006/07/05 02:02:40 WARNING xorp_rib RIB ] Unable to complete XRL:
> add_route6 for ospfv2 route: Dst: fe80::/64 Vif: ath0 NextHop: NH:::
> Metric: 256 Protocol: fib2mrib PolicyTags: 0<br>
> <br>
> /* $XORP: xorp/rtrmgr/config.boot 2006/06 use xorp to be a gateway
> computer */<br>
> <br>
> interfaces {<br>
> &nbsp;&nbsp;&nbsp; interface eth0 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; description: "wired side"<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; vif eth0 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; address 172.25.2.34 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; prefix-length: 28<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; broadcast: 172.25.2.47<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; disable: false<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; interface ath0 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; description: "wireless"<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; vif ath0 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; address 172.26.2.252 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; prefix-length: 24<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; broadcast: 172.26.2.255<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; disable: false<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; }<br>
> }<br>
> <br>
> fea {<br>
> &nbsp;&nbsp;&nbsp; unicast-forwarding4 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; disable: false<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
> }<br>
> <br>
> protocols {<br>
> &nbsp;&nbsp;&nbsp; fib2mrib {<br>
> &nbsp;&nbsp;&nbsp; disable: false<br>
> &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; ospf4 {<br>
> &nbsp;&nbsp;&nbsp; export: "export_fib2mrib"<br>
> &nbsp;&nbsp;&nbsp; router-id: 172.25.2.34<br>
> &nbsp;&nbsp;&nbsp; ip-router-alert: false<br>
> &nbsp;&nbsp;&nbsp; area 0.0.0.0 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; area-type: "normal"<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; interface eth0 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; vif eth0 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; address 172.25.2.34 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; priority: 128<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; hello-interval: 10<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; router-dead-interval: 40<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; interface-cost: 1<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; retransmit-interval: 5<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; transit-delay: 1<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; passive: false<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; neighbor 172.25.2.33 {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; router-id 172.25.2.33<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; disable: false<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; }<br>
> &nbsp; }<br>
> }<br>
> <br>
> policy {<br>
> &nbsp;&nbsp;&nbsp; policy-statement export_fib2mrib {<br>
> &nbsp;&nbsp;&nbsp; term export {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; from {<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; protocol: "fib2mrib"<br>
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; }<br>
> }<br>
> <br>
> Thank you for your time<br>
> Neil Fenwick<br>
> <br>
> Pavlin Radoslavov wrote:
> <blockquote cite="mid200604111735.k3BHZl6r034075 at possum.icir.org"
>  type="cite">
>   <blockquote type="cite">
>     <pre wrap="">I am a new user to XORP and I am attempting to redistribute the system
> kernel route table into XORP OSPF.  I see redistribution support for
> connected and static routes, but not for the kernel route table, as is
> available in Quagga.  In my case, the system kernel route table is being
> written by another routing protocol (Optimized Link State Routing) into
> which XORP has no visibility.  The "connected" and "static" features are not
> sufficient to satisfy my objectives.
>     </pre>
>   </blockquote>
>   <pre wrap=""><!---->
> You won't be able to do this out-of-the-box, but there is a
> semi-hackish way around it. The basic idea is to use the fib2mrib
> module in XORP.
> That module typically is used to snoop the unicast routes from the
> kernel so they can be used for multicast purpose (the Reverse Path
> Forwarding check in PIM-SM). In your case you will redistribute them
> to OSPF.
> 
> 1. Get the latest XORP code from the anonymous CVS, and make sure
>    that file xrl/targets/fib2mrib_base.hh is ref. 1.12 (at least).
>    The instructions for the anonymous CVS access are available from
>    <a class="moz-txt-link-freetext" href="http://www.xorp.org/cvs.html">http://www.xorp.org/cvs.html</a>
> 
> 2. Apply the patch at the end of this email to the checked-out code.
>    Basically, this patch adds the necessary hooks to the
>    etc/templates/policy.tp and etc/templats/fib2mrib.tp so fib2mrib
>    can be used as part of the policy framework.
>    Also, it adds a hack to ospf/xrl_target.cc so OSPF will accept
>    the routes that would come from fib2mrib. If you want to export
>    the fib2mrib routes to some other protocol (BGP or RIP), then you
>    may have to apply a similar hack to the particular protocol.
> 
> 3. You can export the fib2mrib routes by using the following in your
>    XORP configuration:
> 
> policy {
>     policy-statement export_fib2mrib {
>         term export {
>             from {
>                 protocol: "fib2mrib"
>             }
>         }
>     }
> }
> 
> protocols {
>     ospf4 {
>         export: "export_fib2mrib"
> 	....
>     }
> }
> 
> protocols {
>     fib2mrib {
>         disable: false
>     }
> }
> 
> FYI, I tried the above mechanism, and it appears to work for me, but
> please let me know if you run into some issues.
> 
> Pavlin
> 
> Index: etc/templates/fib2mrib.tp
> ===================================================================
> RCS file: /usr/local/share/doc/apache/cvs/xorp/etc/templates/fib2mrib.tp,v
> retrieving revision 1.10
> diff -u -p -r1.10 fib2mrib.tp
> --- etc/templates/fib2mrib.tp	22 Feb 2006 02:26:10 -0000	1.10
> +++ etc/templates/fib2mrib.tp	11 Apr 2006 17:10:58 -0000
> @@ -8,11 +8,22 @@ protocols {
>      }
>  }
>  
> +policy {
> +    policy-statement @: txt {
> +	term @: txt {
> +	    from {
> +		metric: u32range;
> +	    }
> +	}
> +    }
> +}
> +
>  protocols {
>      fib2mrib {
>  	%help:		short		"Configure the FIB2MRIB module";
>  	%modinfo:	provides	fib2mrib;
>  	%modinfo:	depends		rib;
> +	%modinfo:	depends		policy;
>  	%modinfo:	path		"fib2mrib/xorp_fib2mrib";
>  	%modinfo:	default_targetname "fib2mrib";
>  	%modinfo:	status_method	xrl "$(fib2mrib.targetname)/common/0.1/get_status-&gt;status:u32&amp;reason:txt";
> @@ -43,3 +54,21 @@ protocols {
>  	}
>      }
>  }
> +
> +policy {
> +    %create: xrl "$(policy.targetname)/policy/0.1/set_proto_target?protocol:txt=fib2mrib&amp;target:txt=fib2mrib";
> +    %create: xrl "$(policy.targetname)/policy/0.1/add_varmap?protocol:txt=fib2mrib&amp;variable:txt=network4&amp;type:txt=ipv4net&amp;access:txt=r&amp;id:u32=10";
> +    %create: xrl "$(policy.targetname)/policy/0.1/add_varmap?protocol:txt=fib2mrib&amp;variable:txt=metric&amp;type:txt=u32&amp;access:txt=rw&amp;id:u32=14";
> +
> +    policy-statement @: txt {
> +	term @: txt {
> +	    from {
> +		metric {
> +		    %help: short "Set the metric value";
> +		    %set: xrl "$(policy.targetname)/policy/0.1/update_term_block?policy:txt=$(policy-statement.@)&amp;term:txt=$(term.@)&amp;block:u32=0&amp;order:txt=$(#)&amp;statement:txt=metric $(&lt;&gt;) $(@);";
> +		    %delete: xrl <a class="moz-txt-link-rfc2396E" href="mailto:$(policy.targetname)/policy/0.1/update_term_block?policy:txt=$(policy-statement.@)&term:txt=$(term.@)&block:u32=0&order:txt=$(#)&statement:txt=">"$(policy.targetname)/policy/0.1/update_term_block?policy:txt=$(policy-statement.@)&amp;term:txt=$(term.@)&amp;block:u32=0&amp;order:txt=$(#)&amp;statement:txt="</a>;
> +		}
> +	    }
> +	}
> +    }
> +}
> Index: etc/templates/policy.tp
> ===================================================================
> RCS file: /usr/local/share/doc/apache/cvs/xorp/etc/templates/policy.tp,v
> retrieving revision 1.20
> diff -u -p -r1.20 policy.tp
> --- etc/templates/policy.tp	3 Apr 2006 23:35:14 -0000	1.20
> +++ etc/templates/policy.tp	11 Apr 2006 17:10:58 -0000
> @@ -73,6 +73,7 @@ policy {
>  		    %help: short "Protocol from which route was learned";
>  		    %allow: $(@) "bgp" %help: "BGP routes";
>  		    %allow: $(@) "connected" %help: "Directly connected sub-network routes";
> +		    %allow: $(@) "fib2mrib" %help: "FIB2MRIB routes";
>  		    %allow: $(@) "ospf4" %help: "OSPF IPv4 routes";
>  		    %allow: $(@) "rip" %help: "RIP routes";
>  		    %allow: $(@) "ripng" %help: "RIPng routes";
> Index: ospf/xrl_target.cc
> ===================================================================
> RCS file: /usr/local/share/doc/apache/cvs/xorp/ospf/xrl_target.cc,v
> retrieving revision 1.36
> diff -u -p -r1.36 xrl_target.cc
> --- ospf/xrl_target.cc	28 Mar 2006 03:06:55 -0000	1.36
> +++ ospf/xrl_target.cc	11 Apr 2006 17:10:59 -0000
> @@ -278,8 +278,10 @@ XrlOspfV2Target::policy_redist4_0_1_add_
>  	      cstring(network), cstring(nexthop), pb(unicast), pb(multicast),
>  	      metric);
>  
> +#if 0
>      if (!unicast)
>  	return XrlCmdError::OKAY();
> +#endif
>  
>      if (!_ospf.originate_route(network, nexthop, metric, policytags)) {
>  	return XrlCmdError::COMMAND_FAILED("Network: " + network.str());
> @@ -296,8 +298,10 @@ XrlOspfV2Target::policy_redist4_0_1_dele
>      debug_msg("Net: %s Unicast: %s Multicast %s\n",
>  	      cstring(network), pb(unicast), pb(multicast));
>  
> +#if 0
>      if (!unicast)
>  	return XrlCmdError::OKAY();
> +#endif
>  
>      if (!_ospf.withdraw_route(network)) {
>  	return XrlCmdError::COMMAND_FAILED("Network: " + network.str());
> 
> _______________________________________________
> Xorp-users mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:Xorp-users at xorp.org">Xorp-users at xorp.org</a>
> <a class="moz-txt-link-freetext" href="http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users">http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users</a>
> 
> 
>   </pre>
> </blockquote>
> </body>
> </html>
> 
> 
> --===============2002765754==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> 
> --===============2002765754==--


From pavlin at icir.org  Wed Jul  5 14:55:02 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 05 Jul 2006 14:55:02 -0700
Subject: [Xorp-users] Too many open files in system
In-Reply-To: Message from "Ramu k" <ramu.avula@gmail.com> of "Tue,
	04 Jul 2006 20:44:31 +0530."
	<b8a6742f0607040814t60ade535k81f30b1bc60709d8@mail.gmail.com> 
Message-ID: <200607052155.k65Lt2U5057403@possum.icir.org>

> I am trying to run XORP with 40 VLANS . it is quitting  with the following
> error.
> i am runnig XORP on FC4. and also set ulimit to 65000 files.still it is
> failing.
> 
> [ 2006/07/04 11:56:23  ERROR xorp_fea:28353 MFEA +967 mfea_mrouter.cc
> add_multicast_vif ]
> setsockopt(MRT_ADD_VIF, vif eth0.4) failed: Too many open files in system

I believe you are hitting the MAXVIFS limit in the kernel, i.e., the
maximum number of interfaces that can be enabled for multicast
forwarding, which is set by default to 32.

You would have to increase the MAXVIFS value (e.g., to 50 or so in
your case). Don't make it too large, because it will increase the
memory usage in the kernel and in XORP, but make sure that there is
one extra available for the PIM Register vif.

For that purpose you need to edit the "include/linux/mroute.h" Linux
kernel file and then recompile your kernel.

Then, you need to edit the mrt/max_vifs.h XORP file and redefine the
value of MAX_VIFS. E.g., the simplest way to do it is to add
somewhere at the end:

#undef MAX_VIFS
#define MAX_VIFS 50

After that recompile XORP as well.


You should have in mind that you will be entering territory that
hasn't been explored, so no guarantee it will really work.

Please let us know how it goes.

Thanks,
Pavlin


From ramu.avula at gmail.com  Thu Jul  6 05:53:00 2006
From: ramu.avula at gmail.com (Ramu k)
Date: Thu, 6 Jul 2006 18:23:00 +0530
Subject: [Xorp-users] Too many open files in system
In-Reply-To: <200607052155.k65Lt2U5057403@possum.icir.org>
References: <ramu.avula@gmail.com>
	<b8a6742f0607040814t60ade535k81f30b1bc60709d8@mail.gmail.com>
	<200607052155.k65Lt2U5057403@possum.icir.org>
Message-ID: <b8a6742f0607060553w250c75fbg665c65d1d275d018@mail.gmail.com>

Hi Pavlin,

i changed MAX_VIFS to 150 and recompiled my kernel and XORP . now its
working
fine for 50 VLAN interfaces. we need to change MAX_VIFS limit in
mroute.hfile also.


thank you for ur support.

Ramu K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060706/132cc46e/attachment.html 

From pavlin at icir.org  Thu Jul  6 13:24:04 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 06 Jul 2006 13:24:04 -0700
Subject: [Xorp-users] Too many open files in system
In-Reply-To: Message from "Ramu k" <ramu.avula@gmail.com> of "Thu,
	06 Jul 2006 18:23:00 +0530."
	<b8a6742f0607060553w250c75fbg665c65d1d275d018@mail.gmail.com> 
Message-ID: <200607062024.k66KO4cC025186@possum.icir.org>

> i changed MAX_VIFS to 150 and recompiled my kernel and XORP . now its
> working
> fine for 50 VLAN interfaces. we need to change MAX_VIFS limit in
> mroute.hfile also.

Thank you for the info. I just added an ERRATA entry about the issue
and the solution.

Regards,
Pavlin


From ben at layer8.net  Fri Jul  7 11:22:09 2006
From: ben at layer8.net (Benjamin Black)
Date: Fri, 7 Jul 2006 11:22:09 -0700
Subject: [Xorp-users] FreeBSD port package for 1.2
Message-ID: <B8EB5C03-C09D-4CA4-BBC9-FF22A82842E5@layer8.net>

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

i've put together a freebsd port for xorp 1.2 that might be useful to  
folks.

info here: http://infinitesecond.blogspot.com/2006/07/xorp-port-for- 
freebsd.html
port here: http://layer8.net/~ben/code/xorp.tar.gz


bb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (Darwin)

iD8DBQFErqZWNGhGGgVakhcRAvYzAJwLZPi/Vn7w98/T59m/I9e0U0RAswCg98t6
SiLSgS9IcgNpC57C3hrxzHw=
=dksW
-----END PGP SIGNATURE-----


From hill at tvk.rwth-aachen.de  Mon Jul 10 02:41:00 2006
From: hill at tvk.rwth-aachen.de (Christian Hill)
Date: Mon, 10 Jul 2006 11:41:00 +0200
Subject: [Xorp-users] problem starting xorp-1.2
Message-ID: <op.tcgvumvji92oyq@buhmann>

Hello!

We have a problem with a Debian 2.4 Router:
Our Xorp1.2 won't start. We have TCP/IP-Tunneling & Multicasting,
Multicast Routing and the PIM-SM1/2 protocols compiled into the Kernel.
The config.boot is afaik correctly configured (see below).
Everything works quite fine except routing Multicast.
btw, sorry for my bad english :)
Does anyone know how to fix that problem?


The log after trying to start xorp_rtrmgr is as follows:


[ 2006/07/10 11:27:19  INFO xorp_rtrmgr:24600 RTRMGR +240
master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4,
rib, fib2mrib, igmp, pimsm4
[ 2006/07/10 11:27:19  INFO xorp_rtrmgr:24600 RTRMGR +99 module_manager.cc
execute ] Executing module: interfaces (fea/xorp_fea)
[ 2006/07/10 11:27:19 INFO xorp_fea MFEA ] MFEA enabled
[ 2006/07/10 11:27:19 INFO xorp_fea MFEA ] CLI enabled
[ 2006/07/10 11:27:19 INFO xorp_fea MFEA ] CLI started
[ 2006/07/10 11:27:21  INFO xorp_rtrmgr:24600 RTRMGR +99 module_manager.cc
execute ] Executing module: fea (fea/xorp_fea)
[ 2006/07/10 11:27:27  INFO xorp_rtrmgr:24600 RTRMGR +99 module_manager.cc
execute ] Executing module: mfea4 (fea/xorp_fea)
[ 2006/07/10 11:27:27  ERROR xorp_fea:24601 MFEA +564 mfea_mrouter.cc
start_mrt ] setsockopt(MRT_INIT, 1) failed: Protocol not available
[ 2006/07/10 11:27:27 INFO xorp_fea MFEA ] Interface added: Vif[eth0]
pif_index: 3 vif_index: 0 addr: 137.226.118.244 subnet: 137.226.118.240/28
broadcast: 137.226.118.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP
[ 2006/07/10 11:27:27 INFO xorp_fea MFEA ] MFEA started
[ 2006/07/10 11:27:28 INFO xorp_fea MFEA ] Interface enabled Vif[eth0]
pif_index: 3 vif_index: 0 addr: 137.226.118.244 subnet: 137.226.118.240/28
broadcast: 137.226.118.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP DOWN IPv4 ENABLED
[ 2006/07/10 11:27:28  ERROR xorp_fea:24601 MFEA +967 mfea_mrouter.cc
add_multicast_vif ] setsockopt(MRT_ADD_VIF, vif eth0) failed: Protocol not
available
[ 2006/07/10 11:27:28  ERROR xorp_fea:24601 MFEA +908 mfea_node.cc
start_vif ] Cannot start vif eth0: cannot add the multicast vif to the
kernel
[ 2006/07/10 11:27:28 WARNING xorp_fea XrlMfeaTarget ] Handling method for
mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif
eth0: cannot add the multicast vif to the kernel
[ 2006/07/10 11:27:28  ERROR xorp_rtrmgr:24600 RTRMGR +671
master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed
Cannot start vif eth0: cannot add the multicast vif to the kernel
[ 2006/07/10 11:27:28  ERROR xorp_rtrmgr:24600 RTRMGR +252
master_conf_tree.cc config_done ] Configuration failed: 102 Command failed
Cannot start vif eth0: cannot add the multicast vif to the kernel
[ 2006/07/10 11:27:28  INFO xorp_rtrmgr:24600 RTRMGR +2228 task.cc
run_task ] No more tasks to run
[ 2006/07/10 11:27:28  INFO xorp_rtrmgr:24600 RTRMGR +174
module_manager.cc terminate ] Terminating module: fea
[ 2006/07/10 11:27:28  INFO xorp_rtrmgr:24600 RTRMGR +174
module_manager.cc terminate ] Terminating module: interfaces
[ 2006/07/10 11:27:28  INFO xorp_rtrmgr:24600 RTRMGR +174
module_manager.cc terminate ] Terminating module: mfea4
[ 2006/07/10 11:27:28  INFO xorp_rtrmgr:24600 RTRMGR +197
module_manager.cc terminate ] Killing module: mfea4
[ 2006/07/10 11:27:28  ERROR xorp_rtrmgr:24600 RTRMGR +747
module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea":
terminated with signal 15.
[ 2006/07/10 11:27:28  INFO xorp_rtrmgr:24600 RTRMGR +285
module_manager.cc module_exited ] Module killed during shutdown: mfea4








interfaces {
      interface eth0 {
          default-system-config
          disable: false
          discard: false
          description: ""
      }
      targetname: "fea"
      restore-original-config-on-shutdown: false
}
fea {
      unicast-forwarding4 {
          disable: false
      }
      targetname: "fea"
}
plumbing {
      mfea4 {
          interface eth0 {
              vif eth0 {
                  disable: false
              }
          }
          interface "register_vif" {
              vif "register_vif" {
                  disable: false
              }
          }
          targetname: "MFEA_4"
          disable: false
      }
}
protocols {
      igmp {
          interface eth0 {
              vif eth0 {
                  disable: false
                  version: 2
                  enable-ip-router-alert-option-check: false
                  query-interval: 125
                  query-last-member-interval: 1
                  query-response-interval: 10
                  robust-count: 2
              }
          }
          targetname: "IGMP"
          disable: false
      }
      pimsm4 {
          interface eth0 {
              vif eth0 {
                  disable: false
                  enable-ip-router-alert-option-check: false
                  dr-priority: 1
                  hello-period: 30
                  hello-triggered-delay: 5
              }
          }
          interface "register_vif" {
              vif "register_vif" {
                  disable: false
                  enable-ip-router-alert-option-check: false
                  dr-priority: 1
                  hello-period: 30
                  hello-triggered-delay: 5
              }
          }
          switch-to-spt-threshold {
              disable: false
              interval-sec: 100
              bytes: 102400
          }
          targetname: "PIMSM_4"
          disable: false
      }
      fib2mrib {
          disable: false
          targetname: "fib2mrib"
      }
}


From pavlin at icir.org  Mon Jul 10 08:55:10 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 10 Jul 2006 08:55:10 -0700
Subject: [Xorp-users] problem starting xorp-1.2
In-Reply-To: Message from Christian Hill <hill@tvk.rwth-aachen.de> 
	of "Mon, 10 Jul 2006 11:41:00 +0200." <op.tcgvumvji92oyq@buhmann> 
Message-ID: <200607101555.k6AFtAtB078534@possum.icir.org>

> We have a problem with a Debian 2.4 Router:
> Our Xorp1.2 won't start. We have TCP/IP-Tunneling & Multicasting,
> Multicast Routing and the PIM-SM1/2 protocols compiled into the Kernel.
> The config.boot is afaik correctly configured (see below).
> Everything works quite fine except routing Multicast.
> btw, sorry for my bad english :)
> Does anyone know how to fix that problem?
> 
> 
> The log after trying to start xorp_rtrmgr is as follows:

<DEL>

> [ 2006/07/10 11:27:27  ERROR xorp_fea:24601 MFEA +564 mfea_mrouter.cc
> start_mrt ] setsockopt(MRT_INIT, 1) failed: Protocol not available

<DEL>

> [ 2006/07/10 11:27:28  ERROR xorp_fea:24601 MFEA +967 mfea_mrouter.cc
> add_multicast_vif ] setsockopt(MRT_ADD_VIF, vif eth0) failed: Protocol not
> available

Could you double-check that you have the following options enabled
in your kernel as specified in the user manual (in the PIM-SM chapter):

CONFIG_IP_MULTICAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V2=y

E.g., if you don't have CONFIG_IP_MROUTE enabled, then you could get
the ENOPROTOOPT error "Protocol not available".

If the above options are fine, please tell the kernel version.

Pavlin


From pavlin at icir.org  Mon Jul 10 12:02:13 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 10 Jul 2006 12:02:13 -0700
Subject: [Xorp-users] FreeBSD port package for 1.2
In-Reply-To: Message from Benjamin Black <ben@layer8.net> of "Fri,
	07 Jul 2006 11:22:09 PDT."
	<B8EB5C03-C09D-4CA4-BBC9-FF22A82842E5@layer8.net> 
Message-ID: <200607101902.k6AJ2DDR079918@possum.icir.org>

> i've put together a freebsd port for xorp 1.2 that might be useful to  
> folks.
> 
> info here: http://infinitesecond.blogspot.com/2006/07/xorp-port-for- 
> freebsd.html
> port here: http://layer8.net/~ben/code/xorp.tar.gz

Benjamin,

The port entry looks very thoughtfully and carefully done, so I will
recommend that you contact the FreeBSD folks for possible addition
to the FreeBSD ports tree.
Please let us know if you need assistance with that.

My only comment/recommendation is to change the "COMMENT" entry in
the Makefile to "The eXtensible Open Router Platform" so it is
consistent with the corresponding NetBSD and OpenBSD entries.

Thanks,
Pavlin


From pavlin at icir.org  Mon Jul 10 13:02:07 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 10 Jul 2006 13:02:07 -0700
Subject: [Xorp-users] XORP IGMPv3/MLDv2 implementation is completed
Message-ID: <200607102002.k6AK274P080686@possum.icir.org>

[A number of people had asked in the past for IGMPv3/MLDv2 support,
so here it is]

This is a prerelease (unofficial) announcement that as of July 10,
2006, the XORP CVS repository contains a dual IGMPv3/MLDv2
implementation that will be also in the forthcoming XORP-1.3
release.

The code can be accessed from the anonymous CVS repository
(http://www.xorp.org/cvs.html).

For the time being, the default IGMP and MLD versions will continue
to be 2 and 1 respectively.

To enable the IGMPv3 support, only the "version" statement must be
set to "3":

protocols {
    igmp {
        interface eth0 {
            vif eth0 {
                version: 3
            }
        }
        ...
    }
}

Enabling the MLDv2 support is similar:

protocols {
    mld {
        interface eth0 {
            vif eth0 {
                version: 2
            }
        }
        ...
    }
}


The code should be reasonably stable, but it could benefit from
additional (and independent) testing.
Hence, please let us know if you run into any issues.
Note that the OS kernel must have IGMPv3 or MLDv2 support to run
host SSM application, but this kernel support is not required to run
the router-side only of IGMPv3/MLDv2 (such as in XORP).

Special thanks to Guillaume Leclanche <guillaume AT leclanche.net>
who did an initial IGMPv3 implementation for XORP approximately 1
year ago. A number of ideas in the final implementation came from
his implementation.

Pavlin


From vladgalu at gmail.com  Tue Jul 11 09:09:20 2006
From: vladgalu at gmail.com (Vlad GALU)
Date: Tue, 11 Jul 2006 19:09:20 +0300
Subject: [Xorp-users] FreeBSD port package for 1.2
In-Reply-To: <200607101902.k6AJ2DDR079918@possum.icir.org>
References: <ben@layer8.net> <B8EB5C03-C09D-4CA4-BBC9-FF22A82842E5@layer8.net>
	<200607101902.k6AJ2DDR079918@possum.icir.org>
Message-ID: <79722fad0607110909o32fc2b6by9bee2aabf41faef7@mail.gmail.com>

On 7/10/06, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > i've put together a freebsd port for xorp 1.2 that might be useful to
> > folks.
> >
> > info here: http://infinitesecond.blogspot.com/2006/07/xorp-port-for-
> > freebsd.html
> > port here: http://layer8.net/~ben/code/xorp.tar.gz
>
> Benjamin,
>
> The port entry looks very thoughtfully and carefully done, so I will
> recommend that you contact the FreeBSD folks for possible addition
> to the FreeBSD ports tree.
> Please let us know if you need assistance with that.

   If I may suggest, submit it to Ion-Mihai Tetcu <itetcu at freebsd.org>
(he's a newly appointed ports commiter and hence he's *very* active
:).

>
> My only comment/recommendation is to change the "COMMENT" entry in
> the Makefile to "The eXtensible Open Router Platform" so it is
> consistent with the corresponding NetBSD and OpenBSD entries.
>
> Thanks,
> Pavlin
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>


-- 
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.


From toha at ltrgm.ee.itb.ac.id  Fri Jul 14 11:08:47 2006
From: toha at ltrgm.ee.itb.ac.id (toha at ltrgm.ee.itb.ac.id)
Date: Fri, 14 Jul 2006 18:08:47 -0000 (UTC)
Subject: [Xorp-users] rip failed
Message-ID: <1159.167.205.64.171.1152900527.squirrel@radar.ee.itb.ac.id>

i used protocols rip for testing xorp in my testbed, and i got error
message like this :

[ 2006/07/14 16:42:40 WARNING xorp_fea XrlSocketServerTarget ] Handling
method for socket4/0.1/send_from_multicast_if failed: XrlCmdError 102
Command failed Network is unreachable
[ 2006/07/14 16:42:40  ERROR xorp_rip:544 RIP +557 port.cc
port_io_send_completion ] Send failed
[ 2006/07/14 16:42:40 WARNING xorp_fea XrlSocketServerTarget ] Handling
method for
socket4/0.1/send_from_multicast_if failed: XrlCmdError 102 Command failed
Network is unreachable
[ 2006/07/14 16:42:40  ERROR xorp_rip:544 RIP +557 port.cc
port_io_send_completion ] Send failed
[ 2006/07/14 16:42:40  WARNING xorp_policy:542 XrlPolicyTarget +513
policy_base.cc handle_policy_0_1_export ] Handling method for
policy/0.1/export failed: XrlCmdError 102 Command failed Export of rip
failed: exports: Protocol rip unknown
[ 2006/07/14 16:42:40  ERROR xorp_rtrmgr:536 RTRMGR +671
master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed
Export of rip failed: exports: Protocol rip unknown
[ 2006/07/14 16:42:40  ERROR xorp_rtrmgr:536 RTRMGR +252
master_conf_tree.cc config_done ] Configuration failed: 102 Command failed
Export of rip failed: exports: Protocol rip unknown

how should i solve this problem?
thx


From pavlin at icir.org  Fri Jul 14 10:56:27 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 14 Jul 2006 10:56:27 -0700
Subject: [Xorp-users] rip failed
In-Reply-To: Message from toha@ltrgm.ee.itb.ac.id of "Fri,
	14 Jul 2006 18:08:47 -0000."
	<1159.167.205.64.171.1152900527.squirrel@radar.ee.itb.ac.id> 
Message-ID: <200607141756.k6EHuR0O077847@possum.icir.org>

> i used protocols rip for testing xorp in my testbed, and i got error
> message like this :

What OS are you using?
Also, do you have a 0.0.0.0/0 (default) or 224.0.0.0/4 route in your
kernel before starting XORP (netstat -rn)?

Regards,
Pavlin

> [ 2006/07/14 16:42:40 WARNING xorp_fea XrlSocketServerTarget ] Handling
> method for socket4/0.1/send_from_multicast_if failed: XrlCmdError 102
> Command failed Network is unreachable
> [ 2006/07/14 16:42:40  ERROR xorp_rip:544 RIP +557 port.cc
> port_io_send_completion ] Send failed
> [ 2006/07/14 16:42:40 WARNING xorp_fea XrlSocketServerTarget ] Handling
> method for
> socket4/0.1/send_from_multicast_if failed: XrlCmdError 102 Command failed
> Network is unreachable
> [ 2006/07/14 16:42:40  ERROR xorp_rip:544 RIP +557 port.cc
> port_io_send_completion ] Send failed
> [ 2006/07/14 16:42:40  WARNING xorp_policy:542 XrlPolicyTarget +513
> policy_base.cc handle_policy_0_1_export ] Handling method for
> policy/0.1/export failed: XrlCmdError 102 Command failed Export of rip
> failed: exports: Protocol rip unknown
> [ 2006/07/14 16:42:40  ERROR xorp_rtrmgr:536 RTRMGR +671
> master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed
> Export of rip failed: exports: Protocol rip unknown
> [ 2006/07/14 16:42:40  ERROR xorp_rtrmgr:536 RTRMGR +252
> master_conf_tree.cc config_done ] Configuration failed: 102 Command failed
> Export of rip failed: exports: Protocol rip unknown


From vkaul at research.telcordia.com  Sun Jul 16 19:58:29 2006
From: vkaul at research.telcordia.com (Vikram KAUL)
Date: Sun, 16 Jul 2006 22:58:29 -0400 (Eastern Standard Time)
Subject: [Xorp-users] IGMP/PIM question ?
Message-ID: <Pine.WNT.4.60.0607162230100.492@vkaul-laptop>



FOlks,

  A follow up on an old thread (see below). I am still having trouble 
getting something accomplished which I thought would be fairly 
straightforward. Here goes..

  In essence, I want to be able to run PIM (however ineffective it might 
be) in an ad-hoc network where each router is a host as well. As a simple 
setup, consider R1, R2, R3, R4 and R5 in a simple chain

  The config.boot is fairly simple on all 5 nodes, (it is the same 
actually) with PIM and IGMP running on the single interface.

  R4 is configured statically as the RP and XORP is running on all nodes.

  I have made a couple of changes in the XORP mld6igmp module code :

- Only local IGMP messages are handled in mld6igmp_process()
- Do NOT ignore self queries in mld6igmp_membership_query_recv

   This enables the router to act as the primary responder to receiver 
applications

  A couple of changes in xorp PIM module code:

- Always return 'false' so that router is DR in pim_dr_is_better()
- Only send PIM register if source is self in signal_message_wholepkt_recv

What the two sets of changes should allow is that when a 
receiver-application is started on R1, it should send a PIM join towards 
R4.
When a sender-application is started on R1, only it should send a PIM 
register towards R4

When the receiver application is started, it adds MFC entry (S,G) for 
itself, but does not send a PIM Join towards R4 for which it has a unicast 
path available and ready. Subsequent kill and restarts of the 
receiver-applications merely add_memberships and delete_memberships, but 
no PIM joins are initiated from R1 towards R4 via R2 and R3

There are issues with the register as well, but let me resolve this one 
issue at a time.

If someone needs, I could send in logs, etc of the debug statements and 
outputs of "show pim mfc" etc

Please advise

regards..
vikram





---------- Forwarded message ----------
Date: Tue, 23 May 2006 11:58:43 -0700
From: Pavlin Radoslavov <pavlin at icir.org>
To: Vikram KAUL <vkaul at research.telcordia.com>
Cc: Pavlin Radoslavov <pavlin at icir.org>, xorp-users at xorp.org
Subject: Re: [Xorp-users] IGMP/PIM question ?

> pavlin>However, if I understand correctly your question, you want to
> pavlin>influence the choice of which router reacts to IGMP Join messages,
> pavlin>and this choice should be a function of the receiver's address.
> pavlin>This is not how the IGMP and PIM-SM protocols operate, so most
> pavlin>likely you won't be able to do it even with source code modification
> pavlin>(the answer depends on the details about what exactlty you need to
> pavlin>achieve).
>
> I took a cursory look at the code. Specifically,
>
> In igmp_proto.cc   in   Mld6igmpVif::igmp_process(...)
>
> If right away, a check for source address is done as follows...
>
>    // Only accept my own queries, neglect all others
>
>     if (!(mld6igmp_node().is_my_addr(src)))
> 	return (XORP_ERROR);
>
> then all IGMP messages from other nodes/routers can be neglected. Of
> course this is not what the protocol is supposed to do, but I am merely
> looking at all alternatives. Because if this check, the procedures for
> selecting/electing IGMP Queriers will not happen and all nodes will be
> IGMP Queriers only responding and taking care of 'themselves'

Yes, modifying the above code will have impact on accepting the IGMP
control messages by XORP.

However, this modification won't have impact on the IGMP host-side
implementation inside the kernel. This is where the IGMP Join
suppression happens. Hence, even if you reject the IGMP Queries and
Membership Report inside XORP, they will still be processed inside the
kernel. The processing of the IGMP Membership Report messages inside
the kernel may trigger the IGMP Membership Report suppression (if
there are 2+ receivers on the same LAN).
As a result, you may never see the IGMP Join event by multicast
application running on the local host.

> Similarly,
>
> In pim_proto_hello.cc   in    static bool pim_dr_is_better(...)
>
> could be made to return "false" all the time so the initial selection of
> this node/router as the designated router for PIM Join/Leaves is
> maintained.

Yes, the above modification inside PIM can make each PIM-SM router
believe it is the DR, but then you have to be very careful if there
is a sender with 2+ PIM-SM routers on same LAN. Each of the routers
will think it is the DR and will eccapsulate same multicast data
packet in PIM Registers and unicast it to the RP.
As a result, you will see duplicated packets from the sender.

> These two mods, in essence, should make each node/router
>
> A) An IGMP Querier taking care of only itself
> B) A Designated Router taking care of only itself
>
> It is almost like reverting back to old times when Quering and DR was
> shared by the same router.. except this is much more drastic
>
> pavlin>
> pavlin>Below are the issues with IGMP and PIM-SM reacting as a function of
> pavlin>the receiver's address:
> pavlin>
> pavlin> * In case of IGMP, the adjacent routers need to elect the IGMP
> pavlin>   Querier. The Querier is elected per LAN and the router with the
> pavlin>   lowest IP address on the LAN is the winner. Though, from PIM-SM
> pavlin>   perspective you shouldn't care which router is the IGMP Querier, so
> pavlin>   the IGMP Querier choice shouldn't impact you.
>
>  See above
>
> pavlin>
> pavlin> * In case of PIM-SM, the adjacent routers need to elect the
> pavlin>   Designated Router. The DR is elected per LAN, and the election is
> pavlin>   a function of the routers' IP addresses and their DR priority
> pavlin>   (configurable by the PIM-SM dr-priority configuration
> pavlin>   option). Only if a PIM-SM router is the DR for the LAN, it will
> pavlin>   take into account the IGMP Join event to initiate the PIM-SM Join
> pavlin>   message.
>
> Once the IGMP messages from any other node/router other than self have
> been neglected (above hack in igmp_proto.cc), then the DR will look at
> IGMP Join events from itself alone.
>
> pavlin>
> pavlin>   The fundamental problem here is that the IGMP and PIM-SM
> pavlin>   protocols do not track the IP address of the multicast
> pavlin>   receiver. In other words, IGMP and PIM-SM care only if there is
> pavlin>   a multicast receiver for a particular multicast group, but they
> pavlin>   don't care about the particular IP address of the receiver.
> pavlin>   Hence, when the IGMP module detects an IGMP Join event, it tells the
> pavlin>   PIM-SM module about the joined multicast group, but it doesn't
> pavlin>   tell anything about the receiver's address.
>
> I understand the functionality of the protocols as they are supposed to be
> used. I am merely experimenting with them and was wondering if I could use
> the current implementations in XORP (of course, after some mods) to
> achieve my objectives.
>
> pavlin>   One of the reasons IGMP and PIM-SM cannot track the receivers'
> pavlin>   addresses is because the IGMP host protocol uses IGMP Join
> pavlin>   suppression: if there are two or more receivers on a LAN for the
> pavlin>   same multicast group, only one of the hosts originates IGMP Join
> pavlin>   messages.
> pavlin>
>
> Unfortunately, the above mods will eliminate that supression. But I am
> willing to give something to get something in return. Of course, a more
> careful look into the implementation could guide me into making (or at
> least think of making) other mods which have minimal impact on the
> protocols.

Unfortunately, those mods won't eliminate the suppression problem,
because as I mentioned above it happens inside the kernel, and you
cannot disable it by userland programs.

Also, they won't eliminate the PIM Register encapsulation issue.
Though, if you always switch to the shortest path (to the sender)
after the first data packet, then the PIM Register duplicated packet
will happen only when a new sender becomes active (until the SPT
switch to that sender is completed).

Pavlin


From vkaul at research.telcordia.com  Mon Jul 17 14:37:02 2006
From: vkaul at research.telcordia.com (Vikram KAUL)
Date: Mon, 17 Jul 2006 17:37:02 -0400 (Eastern Standard Time)
Subject: [Xorp-users] FATAL xorp_fea ERROR
Message-ID: <Pine.WNT.4.60.0607171728300.632@vkaul-1.dte.telcordia.com>


Folks,

  I had sent an earlier email about trying to get PIM working on 
single-interface machines to see if and how PIM works in an ad-hoc setup.

Notwithstanding the fact that the only thing I have gotten it to do is 
send PIM Registers from the Node/Router to the RP, I get a crash in the 
fea . Additionally, the MFC entry addition events do not trigger jp_timer 
events which would ordinarily have sent a PIM join.

I have attached the log on the offending machine which was running a 
sender as well as a receiver

Why does the fea error occur ?

Why does the first mention of the join only occur after this fatal crash ?

[ 2006/07/17 16:01:32 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP 192.168.100.21 for group 224.5.6.7: not found
[ 2006/07/17 16:01:32 WARNING xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for source 192.168.100.14 and group 224.5.6.7: not found

Why does joining the group not create an immediate PIM Join when the 
router/node has been configured to act on only IGMP messages from itself 
and each router/node is a DR ? This should ordinarily have worked in 
sending a PIM join towards the next upstream router in direction of the RP 
?

Any help will be welcome

regards..
Vikram
-------------- next part --------------
[ 2006/07/17 16:01:30 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 vif_index = 1 src = 192.168.100.14 dst = 224.5.6.7
[ 2006/07/17 16:01:30 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 1 src = 192.168.100.14 dst = 224.5.6.7 len = 49
[ 2006/07/17 16:01:30 TRACE xorp_pimsm4 PIM ] TX PIM_REGISTER from 192.168.100.14 to 192.168.100.21 on vif register_vif
[ 2006/07/17 16:01:31 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 vif_index = 1 src = 192.168.100.14 dst = 224.5.6.7
[ 2006/07/17 16:01:31 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 1 src = 192.168.100.14 dst = 224.5.6.7 len = 49
[ 2006/07/17 16:01:31 TRACE xorp_pimsm4 PIM ] TX PIM_REGISTER from 192.168.100.14 to 192.168.100.21 on vif register_vif

[ 2006/07/17 16:01:32  FATAL xorp_fea:14932 FEA +298 netlink_socket_utils.cc nlm_get_to_fte_cfg ] Could not find interface corresponding to index 17

[ 2006/07/17 16:01:32 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 192.168.100.14 to 224.0.0.2 on vif vf0
[ 2006/07/17 16:01:32 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.100.14 to 224.5.6.7
[ 2006/07/17 16:01:32 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 192.168.100.14 to 224.0.0.2 on vif vf0
[ 2006/07/17 16:01:32 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.100.14 to 224.0.0.13

[ 2006/07/17 16:01:32  ERROR xorp_fib2mrib:14980 FIB2MRIB +1569 xrl_fib2mrib_node.cc finder_event_observer_0_1_xrl_target_death ] FEA (instance fea-5fec59042f3942eaebcc96b857a25b9e at 127.0.0.1) has died, shutting down.
[ 2006/07/17 16:01:32  ERROR xorp_rtrmgr:14921 RTRMGR +750 module_manager.cc done_cb ] Command "/extra/xorp/fea/xorp_fea": terminated with signal 6.
[ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +297 module_manager.cc module_exited ] Module abnormally killed: fea
[ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +297 module_manager.cc module_exited ] Module abnormally killed: interfaces
[ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +297 module_manager.cc module_exited ] Module abnormally killed: mfea4
[ 2006/07/17 16:01:32  ERROR xorp_fib2mrib:14980 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104
[ 2006/07/17 16:01:32  ERROR xorp_fib2mrib:14980 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104)
[ 2006/07/17 16:01:32  ERROR xorp_fib2mrib:14980 XRL +339 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +783 xrl_pf_stcp.cc read_event ] Read failed (error = 104)
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 MLD6IGMP +1534 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 210 Transport failed
[ 2006/07/17 16:01:32 INFO xorp_igmp XRL ] Sender died (protocol = "stcp", address = "127.0.0.1:33162")
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104)
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +339 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 LIBXORP +213 buffered_asyncio.cc io_event ] read error 111
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +783 xrl_pf_stcp.cc read_event ] Read failed (error = 111)
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 MLD6IGMP +1534 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 210 Transport failed
[ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +278 module_manager.cc module_exited ] Module normal exit: fib2mrib
[ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 MLD6IGMP +1834 xrl_mld6igmp_node.cc finder_event_observer_0_1_xrl_target_death ] MFEA (instance MFEA_4-1eda973b04dd50efd6db560643e10159 at 127.0.0.1) has died, shutting down.
[ 2006/07/17 16:01:32 INFO xorp_igmp MLD6IGMP ] Interface stopped: Vif[vf0] pif_index: 0 vif_index: 0 addr: 192.168.100.14 subnet: 192.168.100.0/24 broadcast: 192.168.100.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED
[ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 PIM +2949 xrl_pim_node.cc finder_event_observer_0_1_xrl_target_death ] MFEA (instance MFEA_4-1eda973b04dd50efd6db560643e10159 at 127.0.0.1) has died, shutting down.

[ 2006/07/17 16:01:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.14 to 224.0.0.13 on vif vf0
[ 2006/07/17 16:01:32 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP 192.168.100.21 for group 224.5.6.7: not found
[ 2006/07/17 16:01:32 WARNING xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for source 192.168.100.14 and group 224.5.6.7: not found
[ 2006/07/17 16:01:32 TRACE xorp_pimsm4 PIM ] Delete MFC entry: (192.168.100.14, 224.5.6.7) iif = 0 olist = .O
[ 2006/07/17 16:01:32 INFO xorp_pimsm4 PIM ] Interface stopped: Vif[register_vif] pif_index: 0 vif_index: 1 addr: 192.168.100.14 subnet: 192.168.100.14/32 broadcast: 192.168.100.14 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP DOWN IPv4 ENABLED
[ 2006/07/17 16:01:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.14 to 224.0.0.13 on vif vf0
[ 2006/07/17 16:01:32 INFO xorp_pimsm4 PIM ] Interface stopped: Vif[vf0] pif_index: 0 vif_index: 0 addr: 192.168.100.14 subnet: 192.168.100.0/24 broadcast: 192.168.100.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED

[ 2006/07/17 16:01:32  WARNING xorp_rtrmgr:14921 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MFEA_4" does not exist or is not enabled.
[ 2006/07/17 16:01:32 INFO xorp_igmp MLD6IGMP ] CLI stopped
[ 2006/07/17 16:01:32 INFO xorp_igmp MLD6IGMP ] CLI stopped
[ 2006/07/17 16:01:32 INFO xorp_igmp MLD6IGMP ] Interface deleted: vf0
[ 2006/07/17 16:01:32 INFO xorp_pimsm4 XRL ] Sender died (protocol = "stcp", address = "127.0.0.1:33192")
[ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 LIBXORP +213 buffered_asyncio.cc io_event ] read error 111
[ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 XRL +783 xrl_pf_stcp.cc read_event ] Read failed (error = 111)
[ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error
[ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +278 module_manager.cc module_exited ] Module normal exit: igmp
[ 2006/07/17 16:01:32  WARNING xorp_rtrmgr:14921 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MFEA_4" does not exist or is not enabled.
[ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 PIM +2638 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed
[ 2006/07/17 16:01:32  WARNING xorp_rtrmgr:14921 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MFEA_4" does not exist or is not enabled.
[ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 PIM +1868 xrl_pim_node.cc mfea_client_send_add_delete_mfc_cb ] XRL communication error: 201 Resolve failed


From pavlin at icir.org  Mon Jul 17 15:16:44 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 17 Jul 2006 15:16:44 -0700
Subject: [Xorp-users] IGMP/PIM question ?
In-Reply-To: Message from Vikram KAUL <vkaul@research.telcordia.com> of "Sun,
	16 Jul 2006 22:58:29 EDT."
	<Pine.WNT.4.60.0607162230100.492@vkaul-laptop> 
Message-ID: <200607172216.k6HMGids076537@possum.icir.org>

>   A follow up on an old thread (see below). I am still having trouble 
> getting something accomplished which I thought would be fairly 
> straightforward. Here goes..
> 
>   In essence, I want to be able to run PIM (however ineffective it might 
> be) in an ad-hoc network where each router is a host as well. As a simple 
> setup, consider R1, R2, R3, R4 and R5 in a simple chain
> 
>   The config.boot is fairly simple on all 5 nodes, (it is the same 
> actually) with PIM and IGMP running on the single interface.

When you say "PIM ... running on the single interface", do
you mean that you have configured PIM-SM only on a single interface
on each router?

You cannot use PIM-SM for any effective multicast forwarding with a
single network interface. For example, every multicast forwarding
entry (as installed in the kernel) has an incoming interface, and a
set of outgoing interfaces. An incoming interface is automatically
excluded from the oifs set. Hence, with a single enabled interface
the oifs set is always empty.

>   R4 is configured statically as the RP and XORP is running on all nodes.
> 
>   I have made a couple of changes in the XORP mld6igmp module code :
> 
> - Only local IGMP messages are handled in mld6igmp_process()
> - Do NOT ignore self queries in mld6igmp_membership_query_recv
> 
>    This enables the router to act as the primary responder to receiver 
> applications
> 
>   A couple of changes in xorp PIM module code:
> 
> - Always return 'false' so that router is DR in pim_dr_is_better()
> - Only send PIM register if source is self in signal_message_wholepkt_recv
> 
> What the two sets of changes should allow is that when a 
> receiver-application is started on R1, it should send a PIM join towards 
> R4.
> When a sender-application is started on R1, only it should send a PIM 
> register towards R4
> 
> When the receiver application is started, it adds MFC entry (S,G) for 
> itself, but does not send a PIM Join towards R4 for which it has a unicast 

Are you using Linux?
There is a bug in the Linux kernel such that when you start a local
receiver on the multicast router, a bogus (S,G) upcall message
(NOCACHE?) is generared to userland (XORP), and this triggers the
generation of a (S,G) routing entry. This entry should be harmless,
but its generation/existence could be confusing, because such
upcalls should be generated only when there is data traffic.

A PIM Join toward the RP (R4) should have been generated
though. Could you send the output of the following commands:

 show pim join
 show pim mrib
 show pim interface
 show pim neighbors
 show pim rps
 show igmp group

Regards,
Pavlin

> path available and ready. Subsequent kill and restarts of the 
> receiver-applications merely add_memberships and delete_memberships, but 
> no PIM joins are initiated from R1 towards R4 via R2 and R3
> 
> There are issues with the register as well, but let me resolve this one 
> issue at a time.
> 
> If someone needs, I could send in logs, etc of the debug statements and 
> outputs of "show pim mfc" etc
> 
> Please advise
> 
> regards..
> vikram


From pavlin at icir.org  Mon Jul 17 15:38:14 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 17 Jul 2006 15:38:14 -0700
Subject: [Xorp-users] FATAL xorp_fea ERROR
In-Reply-To: Message from Vikram KAUL <vkaul@research.telcordia.com> of "Mon,
	17 Jul 2006 17:37:02 EDT."
	<Pine.WNT.4.60.0607171728300.632@vkaul-1.dte.telcordia.com> 
Message-ID: <200607172238.k6HMcEEV077291@possum.icir.org>

>   I had sent an earlier email about trying to get PIM working on
> single-interface machines to see if and how PIM works in an ad-hoc setup.
> 
> Notwithstanding the fact that the only thing I have gotten it to do is send
> PIM Registers from the Node/Router to the RP, I get a crash in the fea
> . Additionally, the MFC entry addition events do not trigger jp_timer events
> which would ordinarily have sent a PIM join.

The MFC entry addition is probably bogus (see my reply to your
earlier email). The real issue is why the PIM-SM Join message wasn't
generated when the receiver joined.

> I have attached the log on the offending machine which was running a sender as
> well as a receiver
> 
> Why does the fea error occur ?

First, could you double-check that HAVE_IF_INDEXTONAME inside
xorp/config.h is defined:

/* Define to 1 if you have the `if_indextoname' function. */
#define HAVE_IF_INDEXTONAME 1


If yes, could you send the output of the following programs (after
XORP is started):

UNIX:   cat /proc/net/ip_mr_vif 
Xorpsh: show interfaces
        show mfea interface
        show pim interface

Also, do you always get this XLOG_FATAL() message right after the
PIM Register message is transmitted:

[ 2006/07/17 16:01:31 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 1 src = 192.168.100.14 dst = 224.5.6.7 len = 49
[ 2006/07/17 16:01:31 TRACE xorp_pimsm4 PIM ] TX PIM_REGISTER from 192.168.100.14 to 192.168.100.21 on vif register_vif

[ 2006/07/17 16:01:32  FATAL xorp_fea:14932 FEA +298 netlink_socket_utils.cc nlm_get_to_fte_cfg ] Could not find interface corresponding to index 17


> Why does the first mention of the join only occur after this fatal crash ?
> 
> [ 2006/07/17 16:01:32 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP 192.168.100.21 for group 224.5.6.7: not found
> [ 2006/07/17 16:01:32 WARNING xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for source 192.168.100.14 and group 224.5.6.7: not found

For some reason, XORP probably wanted to send Prune messages
toward the RP and toward S, but it couldn't because there was no
upstream PIM-SM neighor router. Given that those messages were
generated right after the FEA crashed, all bets are off about which
particular event triggered them.

> Why does joining the group not create an immediate PIM Join when the
> router/node has been configured to act on only IGMP messages from itself and
> each router/node is a DR ? This should ordinarily have worked in sending a PIM
> join towards the next upstream router in direction of the RP ?

This is the question we need to answer. Hopefully, the debug info I
asked about in my earlier email will help us finding the answer.

Regards,
Pavlin

> 
> Any help will be welcome
> 
> regards..
> Vikram
> [ 2006/07/17 16:01:30 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 vif_index = 1 src = 192.168.100.14 dst = 224.5.6.7
> [ 2006/07/17 16:01:30 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 1 src = 192.168.100.14 dst = 224.5.6.7 len = 49
> [ 2006/07/17 16:01:30 TRACE xorp_pimsm4 PIM ] TX PIM_REGISTER from 192.168.100.14 to 192.168.100.21 on vif register_vif
> [ 2006/07/17 16:01:31 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 vif_index = 1 src = 192.168.100.14 dst = 224.5.6.7
> [ 2006/07/17 16:01:31 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 1 src = 192.168.100.14 dst = 224.5.6.7 len = 49
> [ 2006/07/17 16:01:31 TRACE xorp_pimsm4 PIM ] TX PIM_REGISTER from 192.168.100.14 to 192.168.100.21 on vif register_vif
> 
> [ 2006/07/17 16:01:32  FATAL xorp_fea:14932 FEA +298 netlink_socket_utils.cc nlm_get_to_fte_cfg ] Could not find interface corresponding to index 17
> 
> [ 2006/07/17 16:01:32 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 192.168.100.14 to 224.0.0.2 on vif vf0
> [ 2006/07/17 16:01:32 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.100.14 to 224.5.6.7
> [ 2006/07/17 16:01:32 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 192.168.100.14 to 224.0.0.2 on vif vf0
> [ 2006/07/17 16:01:32 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.100.14 to 224.0.0.13
> 
> [ 2006/07/17 16:01:32  ERROR xorp_fib2mrib:14980 FIB2MRIB +1569 xrl_fib2mrib_node.cc finder_event_observer_0_1_xrl_target_death ] FEA (instance fea-5fec59042f3942eaebcc96b857a25b9e at 127.0.0.1) has died, shutting down.
> [ 2006/07/17 16:01:32  ERROR xorp_rtrmgr:14921 RTRMGR +750 module_manager.cc done_cb ] Command "/extra/xorp/fea/xorp_fea": terminated with signal 6.
> [ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +297 module_manager.cc module_exited ] Module abnormally killed: fea
> [ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +297 module_manager.cc module_exited ] Module abnormally killed: interfaces
> [ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +297 module_manager.cc module_exited ] Module abnormally killed: mfea4
> [ 2006/07/17 16:01:32  ERROR xorp_fib2mrib:14980 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104
> [ 2006/07/17 16:01:32  ERROR xorp_fib2mrib:14980 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104)
> [ 2006/07/17 16:01:32  ERROR xorp_fib2mrib:14980 XRL +339 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +783 xrl_pf_stcp.cc read_event ] Read failed (error = 104)
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 MLD6IGMP +1534 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 210 Transport failed
> [ 2006/07/17 16:01:32 INFO xorp_igmp XRL ] Sender died (protocol = "stcp", address = "127.0.0.1:33162")
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +159 xrl_pf_stcp.cc read_event ] Read failed (error = 104)
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +339 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 LIBXORP +213 buffered_asyncio.cc io_event ] read error 111
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +783 xrl_pf_stcp.cc read_event ] Read failed (error = 111)
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 MLD6IGMP +1534 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 210 Transport failed
> [ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +278 module_manager.cc module_exited ] Module normal exit: fib2mrib
> [ 2006/07/17 16:01:32  ERROR xorp_igmp:14989 MLD6IGMP +1834 xrl_mld6igmp_node.cc finder_event_observer_0_1_xrl_target_death ] MFEA (instance MFEA_4-1eda973b04dd50efd6db560643e10159 at 127.0.0.1) has died, shutting down.
> [ 2006/07/17 16:01:32 INFO xorp_igmp MLD6IGMP ] Interface stopped: Vif[vf0] pif_index: 0 vif_index: 0 addr: 192.168.100.14 subnet: 192.168.100.0/24 broadcast: 192.168.100.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED
> [ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 PIM +2949 xrl_pim_node.cc finder_event_observer_0_1_xrl_target_death ] MFEA (instance MFEA_4-1eda973b04dd50efd6db560643e10159 at 127.0.0.1) has died, shutting down.
> 
> [ 2006/07/17 16:01:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.14 to 224.0.0.13 on vif vf0
> [ 2006/07/17 16:01:32 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP 192.168.100.21 for group 224.5.6.7: not found
> [ 2006/07/17 16:01:32 WARNING xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for source 192.168.100.14 and group 224.5.6.7: not found
> [ 2006/07/17 16:01:32 TRACE xorp_pimsm4 PIM ] Delete MFC entry: (192.168.100.14, 224.5.6.7) iif = 0 olist = .O
> [ 2006/07/17 16:01:32 INFO xorp_pimsm4 PIM ] Interface stopped: Vif[register_vif] pif_index: 0 vif_index: 1 addr: 192.168.100.14 subnet: 192.168.100.14/32 broadcast: 192.168.100.14 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP DOWN IPv4 ENABLED
> [ 2006/07/17 16:01:32 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.14 to 224.0.0.13 on vif vf0
> [ 2006/07/17 16:01:32 INFO xorp_pimsm4 PIM ] Interface stopped: Vif[vf0] pif_index: 0 vif_index: 0 addr: 192.168.100.14 subnet: 192.168.100.0/24 broadcast: 192.168.100.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED
> 
> [ 2006/07/17 16:01:32  WARNING xorp_rtrmgr:14921 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MFEA_4" does not exist or is not enabled.
> [ 2006/07/17 16:01:32 INFO xorp_igmp MLD6IGMP ] CLI stopped
> [ 2006/07/17 16:01:32 INFO xorp_igmp MLD6IGMP ] CLI stopped
> [ 2006/07/17 16:01:32 INFO xorp_igmp MLD6IGMP ] Interface deleted: vf0
> [ 2006/07/17 16:01:32 INFO xorp_pimsm4 XRL ] Sender died (protocol = "stcp", address = "127.0.0.1:33192")
> [ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 LIBXORP +213 buffered_asyncio.cc io_event ] read error 111
> [ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 XRL +783 xrl_pf_stcp.cc read_event ] Read failed (error = 111)
> [ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 XRL +636 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error
> [ 2006/07/17 16:01:32  INFO xorp_rtrmgr:14921 RTRMGR +278 module_manager.cc module_exited ] Module normal exit: igmp
> [ 2006/07/17 16:01:32  WARNING xorp_rtrmgr:14921 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MFEA_4" does not exist or is not enabled.
> [ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 PIM +2638 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 201 Resolve failed
> [ 2006/07/17 16:01:32  WARNING xorp_rtrmgr:14921 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "MFEA_4" does not exist or is not enabled.
> [ 2006/07/17 16:01:32  ERROR xorp_pimsm4:15069 PIM +1868 xrl_pim_node.cc mfea_client_send_add_delete_mfc_cb ] XRL communication error: 201 Resolve failed
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From vkaul at research.telcordia.com  Tue Jul 18 08:55:22 2006
From: vkaul at research.telcordia.com (Vikram KAUL)
Date: Tue, 18 Jul 2006 11:55:22 -0400 (Eastern Standard Time)
Subject: [Xorp-users] IGMP/PIM question ?
In-Reply-To: <200607172216.k6HMGids076537@possum.icir.org>
References: <200607172216.k6HMGids076537@possum.icir.org>
Message-ID: <Pine.WNT.4.60.0607181045410.632@vkaul-1.dte.telcordia.com>


Thanks for the responses. My comments interspersed...

pavlin>>   In essence, I want to be able to run PIM (however ineffective it might 
pavlin>> be) in an ad-hoc network where each router is a host as well. As a simple 
pavlin>> setup, consider R1, R2, R3, R4 and R5 in a simple chain
pavlin>> 
pavlin>>   The config.boot is fairly simple on all 5 nodes, (it is the same 
pavlin>> actually) with PIM and IGMP running on the single interface.
pavlin>
pavlin>When you say "PIM ... running on the single interface", do
pavlin>you mean that you have configured PIM-SM only on a single interface
pavlin>on each router?

Nope. I mean there exists only one interface and that is the interface on 
which I have enabled PIM.

pavlin>
pavlin>You cannot use PIM-SM for any effective multicast forwarding with a
pavlin>single network interface. For example, every multicast forwarding
pavlin>entry (as installed in the kernel) has an incoming interface, and a
pavlin>set of outgoing interfaces. An incoming interface is automatically
pavlin>excluded from the oifs set. Hence, with a single enabled interface
pavlin>the oifs set is always empty.
pavlin>

But is that not controlled by the "oifs_ttl" in the MfeaNode::add_mfc() 
function which first sets all oifs_ttl to ZERO and then after performing a 
test on oiflist   (oiflist.test(i)) mask, sets the TTL to MINTTL of 1. 
And then the MfeaRouter::add_mfc() function is called to actually 
implements the setsockopt() to tell the kernel about it.

In MfeaRouter::add_mfc() the first thing that is done is 

    oifs_ttl[iif_vif_index] = 0;  // Pre-caution

This precludes the kernel from using the iff as one of the legitimate 
interfaces for output. 

What I wonder is if this "Pre-caution" statement were commented, would 
that be sufficient for the kernel to use the iff as one of the oif ??

Or is it more compilcated where I have to look into the 

XrlPimNode::add_mfc_to_kernel()
which invokes

XrlPimNode::send_add_delete_mfc()
which invokes

XrlMfeaNode::mfea_0_1_add_mfc4()

Essentially, where exactly is the first step where the iff_vif_index is 
set to disable in the oiflist

Any pointers in this direction ?


pavlin>
pavlin>Are you using Linux?
pavlin>There is a bug in the Linux kernel such that when you start a local
pavlin>receiver on the multicast router, a bogus (S,G) upcall message
pavlin>(NOCACHE?) is generared to userland (XORP), and this triggers the
pavlin>generation of a (S,G) routing entry. This entry should be harmless,
pavlin>but its generation/existence could be confusing, because such
pavlin>upcalls should be generated only when there is data traffic.

Yes I am using Linux Kernel 2.6.9. I know it is relatively old, but that 
is what I have to work with. Alright, I will not concentrate on this bogus 
(S,G) entry from now on.

pavlin>
pavlin>A PIM Join toward the RP (R4) should have been generated
pavlin>though. Could you send the output of the following commands:
pavlin>
pavlin> show pim join
pavlin> show pim mrib
pavlin> show pim interface
pavlin> show pim neighbors
pavlin> show pim rps
pavlin> show igmp group

I have attached the following txt files:

xorpsh_before_receiver-app-started.txt 
  xorp_after_receiver-app-started.txt
xorpsh_after_receiver-app-started.txt
  xorp_after_receiver-app-stopped.txt
xorpsh_after_receiver-app-stopped.txt

regards..
Vikram

pavlin>
pavlin>Regards,
pavlin>Pavlin
pavlin>
pavlin>> path available and ready. Subsequent kill and restarts of the 
pavlin>> receiver-applications merely add_memberships and delete_memberships, but 
pavlin>> no PIM joins are initiated from R1 towards R4 via R2 and R3
pavlin>> 
pavlin>> There are issues with the register as well, but let me resolve this one 
pavlin>> issue at a time.
pavlin>> 
pavlin>> If someone needs, I could send in logs, etc of the debug statements and 
pavlin>> outputs of "show pim mfc" etc
pavlin>> 
pavlin>> Please advise
pavlin>> 
pavlin>> regards..
pavlin>> vikram
pavlin>
-------------- next part --------------
root at mobile17>
root at mobile17> show pim interface
Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
vf0          UP       Sparse 2 NotDR           1 192.168.100.21          1
register_vif UP       Sparse 2 DR              1 192.168.100.17          0

root at mobile17> show pim neighbors
Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
vf0                   1 192.168.100.21  2 Sparse      105      80

root at mobile17> show pim rps
RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
192.168.100.21  static    192       -1      -1            0 224.0.0.0/4

root at mobile17> show igmp group
Interface    Group           Source          LastReported Timeout
vf0          224.0.0.2       0.0.0.0         192.168.100.17     240
vf0          224.0.0.13      0.0.0.0         192.168.100.17     236

root at mobile17> show pim mrib
DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
0.0.0.0/0          192.168.100.254 vf0     0               254  65535
192.168.100.0/24   192.168.100.17  vf0     0                 0      0
192.168.100.17/32  0.0.0.0         vf0     0               254  65535
192.168.100.21/32  0.0.0.0         vf0     0               254  65535

root at mobile17> show pim join
Group           Source          RP              Flags

root at mobile17>


-------------- next part --------------

root at mobile17> show igmp group
Interface    Group           Source          LastReported Timeout
vf0          224.0.0.2       0.0.0.0         192.168.100.17     147
vf0          224.0.0.13      0.0.0.0         192.168.100.17     142
root at mobile17>
root at mobile17>

root at mobile17> show pim mfc
Group           Source          RP
224.5.6.7       192.168.100.17  192.168.100.21
    Incoming interface :      vf0
    Outgoing interfaces:      ..
root at mobile17>


root at mobile17> show pim join
Group           Source          RP              Flags
224.5.6.7       192.168.100.17  192.168.100.21  SG DirectlyConnectedS
    Upstream interface (S):    vf0
    Upstream interface (RP):   vf0
    Upstream MRIB next hop (RP): 192.168.100.21
    Upstream MRIB next hop (S):  UNKNOWN
    Upstream RPF'(S,G):        UNKNOWN
    Upstream state:            NotJoined
    Register state:            RegisterNoinfo RegisterNotCouldRegister
    Join timer:                -1
    KAT(S,G) running:          true
    Local receiver include WC: ..
    Local receiver include SG: ..
    Local receiver exclude SG: ..
    Joins RP:                  ..
    Joins WC:                  ..
    Joins SG:                  ..
    Join state:                ..
    Prune state:               ..
    Prune pending state:       ..
    I am assert winner state:  ..
    I am assert loser state:   ..
    Assert winner WC:          ..
    Assert winner SG:          ..
    Assert lost WC:            ..
    Assert lost SG:            ..
    Assert lost SG_RPT:        ..
    Assert tracking SG:        ..
    Could assert WC:           ..
    Could assert SG:           ..
    I am DR:                   .O
    Immediate olist RP:        ..
    Immediate olist WC:        ..
    Immediate olist SG:        ..
    Inherited olist SG:        ..
    Inherited olist SG_RPT:    ..
    PIM include WC:            ..
    PIM include SG:            ..
    PIM exclude SG:            ..
root at mobile17>
root at mobile17>



-------------- next part --------------


root at mobile17>
root at mobile17> show pim interface
Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
vf0          UP       Sparse 2 NotDR           1 192.168.100.21          1
register_vif UP       Sparse 2 DR              1 192.168.100.17          0

root at mobile17>
root at mobile17>
root at mobile17> show pim neighbors
Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
vf0                   1 192.168.100.21  2 Sparse      105      88

root at mobile17>
root at mobile17> show pim rps
RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
192.168.100.21  static    192       -1      -1            1 224.0.0.0/4

root at mobile17>
root at mobile17> show igmp group
Interface    Group           Source          LastReported Timeout
vf0          224.0.0.2       0.0.0.0         192.168.100.17     173
vf0          224.0.0.13      0.0.0.0         192.168.100.17      48
vf0          224.5.6.7       0.0.0.0         192.168.100.17     181
root at mobile17>

root at mobile17>
root at mobile17> show pim mrib
DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
0.0.0.0/0          192.168.100.254 vf0     0               254  65535
192.168.100.0/24   192.168.100.17  vf0     0                 0      0
192.168.100.17/32  0.0.0.0         vf0     0               254  65535
192.168.100.21/32  0.0.0.0         vf0     0               254  65535
root at mobile17>

root at mobile17>
root at mobile17> show pim mfc
Group           Source          RP
224.5.6.7       192.168.100.17  192.168.100.21
    Incoming interface :      vf0
    Outgoing interfaces:      ..
root at mobile17>

root at mobile17> show pim join
Group           Source          RP              Flags
224.5.6.7       0.0.0.0         192.168.100.21  WC
    Upstream interface (RP):   vf0
    Upstream MRIB next hop (RP): 192.168.100.21
    Upstream RPF'(*,G):        192.168.100.21
    Upstream state:            NotJoined
    Join timer:                -1
    Local receiver include WC: O.
    Joins RP:                  ..
    Joins WC:                  ..
    Join state:                ..
    Prune state:               ..
    Prune pending state:       ..
    I am assert winner state:  ..
    I am assert loser state:   ..
    Assert winner WC:          ..
    Assert lost WC:            ..
    Assert tracking WC:        ..
    Could assert WC:           ..
    I am DR:                   .O
    Immediate olist RP:        ..
    Immediate olist WC:        ..
    Inherited olist SG:        ..
    Inherited olist SG_RPT:    ..
    PIM include WC:            ..
224.5.6.7       192.168.100.17  192.168.100.21  SG DirectlyConnectedS
    Upstream interface (S):    vf0
    Upstream interface (RP):   vf0
    Upstream MRIB next hop (RP): 192.168.100.21
    Upstream MRIB next hop (S):  UNKNOWN
    Upstream RPF'(S,G):        UNKNOWN
    Upstream state:            NotJoined
    Register state:            RegisterNoinfo RegisterNotCouldRegister
    Join timer:                -1
    KAT(S,G) running:          true
    Local receiver include WC: O.
    Local receiver include SG: ..
    Local receiver exclude SG: ..
    Joins RP:                  ..
    Joins WC:                  ..
    Joins SG:                  ..
    Join state:                ..
    Prune state:               ..
    Prune pending state:       ..
    I am assert winner state:  ..
    I am assert loser state:   ..
    Assert winner WC:          ..
    Assert winner SG:          ..
    Assert lost WC:            ..
    Assert lost SG:            ..
    Assert lost SG_RPT:        ..
    Assert tracking SG:        ..
    Could assert WC:           ..
    Could assert SG:           ..
    I am DR:                   .O
    Immediate olist RP:        ..
    Immediate olist WC:        ..
    Immediate olist SG:        ..
    Inherited olist SG:        ..
    Inherited olist SG_RPT:    ..
    PIM include WC:            ..
    PIM include SG:            ..
    PIM exclude SG:            ..
root at mobile17>






-------------- next part --------------
[ 2006/07/18 11:42:06 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 192.168.100.17 to 224.5.6.7 on vif vf0
[ 2006/07/18 11:42:07 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.100.17 to 224.5.6.7
[ 2006/07/18 11:42:07 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 192.168.100.17 to 224.5.6.7 on vif vf0
[ 2006/07/18 11:42:08 TRACE xorp_pimsm4 PIM ] Delete membership for (0.0.0.0, 224.5.6.7) on vif vf0
[ 2006/07/18 11:42:11 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:42:14 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:42:41 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:42:44 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:43:11 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:43:14 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:43:31 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.100.17 to 224.0.0.1
[ 2006/07/18 11:43:31 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 192.168.100.17 to 224.0.0.1 on vif vf0
[ 2006/07/18 11:43:34 WARNING xorp_fea MFEA ] proto_socket_read() failed: RX packet from 192.168.100.21 to 224.0.0.1: no vif found
[ 2006/07/18 11:43:41 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:43:44 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:44:11 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:44:14 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:44:41 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:44:44 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:45:11 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:45:14 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:45:24 TRACE xorp_fea MFEA ] RX dataflow message: src = 192.168.100.17 dst = 224.5.6.7
[ 2006/07/18 11:45:24 TRACE xorp_pimsm4 PIM ] RX DATAFLOW signal: source = 192.168.100.17 group = 224.5.6.7 threshold_interval_sec = 210 thr    eshold_interval_usec = 0 measured_interval_sec = 210 measured_interval_usec = 0 threshold_packets = 0 threshold_bytes = 0 measured_packets =     0 measured_bytes = 0 is_threshold_in_packets = 1 is_threshold_in_bytes = 0 is_geq_upcall = 0 is_leq_upcall = 1
[ 2006/07/18 11:45:24 TRACE xorp_pimsm4 PIM ] Delete MFC entry: (192.168.100.17, 224.5.6.7) iif = 0 olist = ..
[ 2006/07/18 11:45:24 TRACE xorp_fea MFEA ] Delete MFC entry: (192.168.100.17, 224.5.6.7)
[ 2006/07/18 11:45:36 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.100.17 to 224.0.0.1
[ 2006/07/18 11:45:36 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 192.168.100.17 to 224.0.0.1 on vif vf0
[ 2006/07/18 11:45:39 WARNING xorp_fea MFEA ] proto_socket_read() failed: RX packet from 192.168.100.21 to 224.0.0.1: no vif found
[ 2006/07/18 11:45:41 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:45:44 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:46:11 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:46:14 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
-------------- next part --------------

[ 2006/07/18 11:35:44 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:36:11 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:36:14 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:36:39 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 192.168.100.17 dst = 224.5.6.7
[ 2006/07/18 11:36:39 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.100.17 to 224.5.6.7 on vif vf0
[ 2006/07/18 11:36:39 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal from MFEA_4: vif_index = 0 src = 192.168.100.17 dst = 224.5.6.7
[ 2006/07/18 11:36:39 TRACE xorp_pimsm4 PIM ] Add MFC entry: (192.168.100.17, 224.5.6.7) iif = 0 olist = .. olist_disable_wrongvif = OO
[ 2006/07/18 11:36:39 TRACE xorp_pimsm4 PIM ] Add dataflow monitor: source = 192.168.100.17 group = 224.5.6.7 threshold_interval_sec = 210 t    hreshold_interval_usec = 0 threshold_packets = 0 threshold_bytes = 0 is_threshold_in_packets = 1 is_threshold_in_bytes = 0 is_geq_upcall = 0     is_leq_upcall = 1
[ 2006/07/18 11:36:39 TRACE xorp_pimsm4 PIM ] Add membership for (0.0.0.0, 224.5.6.7) on vif vf0
[ 2006/07/18 11:36:39 TRACE xorp_fea MFEA ] Add MFC entry: (192.168.100.17, 224.5.6.7) iif = 0 olist = ..
[ 2006/07/18 11:36:41 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:36:44 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:36:48 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.100.17 to 224.5.6.7 on vif vf0
[ 2006/07/18 11:36:56 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.100.17 to 224.5.6.7 on vif vf0
[ 2006/07/18 11:37:11 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:37:14 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:37:16 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.100.17 to 224.0.0.1
[ 2006/07/18 11:37:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 192.168.100.17 to 224.0.0.1 on vif vf0
[ 2006/07/18 11:37:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.100.17 to 224.0.0.2 on vif vf0
[ 2006/07/18 11:37:19 WARNING xorp_fea MFEA ] proto_socket_read() failed: RX packet from 192.168.100.21 to 224.0.0.1: no vif found
[ 2006/07/18 11:37:25 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.100.17 to 224.5.6.7 on vif vf0
[ 2006/07/18 11:37:41 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 192.168.100.17 to 224.0.0.13 on vif vf0
[ 2006/07/18 11:37:44 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.100.21 to 224.0.0.13 on vif vf0



From vkaul at research.telcordia.com  Tue Jul 18 09:07:57 2006
From: vkaul at research.telcordia.com (Vikram KAUL)
Date: Tue, 18 Jul 2006 12:07:57 -0400 (Eastern Standard Time)
Subject: [Xorp-users] FATAL xorp_fea ERROR
In-Reply-To: <200607172238.k6HMcEEV077291@possum.icir.org>
References: <200607172238.k6HMcEEV077291@possum.icir.org>
Message-ID: <Pine.WNT.4.60.0607181158540.632@vkaul-1.dte.telcordia.com>


Thanks for the replies. My comments interspersed..

pavlin>The MFC entry addition is probably bogus (see my reply to your
pavlin>earlier email). The real issue is why the PIM-SM Join message wasn't
pavlin>generated when the receiver joined.

I have sent a detailed email, along with log and xorpsh outputs detailing 
that issue. Thanks again for the pointer on the bogus entry.

pavlin>> Why does the fea error occur ?
pavlin>First, could you double-check that HAVE_IF_INDEXTONAME inside
pavlin>xorp/config.h is defined:
pavlin>/* Define to 1 if you have the `if_indextoname' function. */
pavlin>#define HAVE_IF_INDEXTONAME 1

Yes. It is set to 1

pavlin>
pavlin>
pavlin>If yes, could you send the output of the following programs (after
pavlin>XORP is started):
pavlin>
pavlin>UNIX:   cat /proc/net/ip_mr_vif 
pavlin>Xorpsh: show interfaces
pavlin>        show mfea interface
pavlin>        show pim interface


[root at mobile17 ~]# cat /proc/net/ip_mr_vif
Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
 0 vf0             480      15         0       0 00000 1164A8C0 00000000
 1 pimreg            0       0         0       0 00004 1164A8C0 00000000

[root at mobile17 ~]# cat /proc/net/ip_mr_cache
Group    Origin   Iif     Pkts    Bytes    Wrong Oifs


root at mobile17> show interfaces
vf0/vf0: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500
        inet6 fe80::4c52:4cff:fe63:6a91 prefixlen 64
        inet 192.168.100.17 subnet 192.168.100.0/24 broadcast 192.168.100.255
        physical index 21
        ether 4e:52:4c:63:6a:91

root at mobile17> show pim interface
Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
vf0          UP       Sparse 2 NotDR           1 192.168.100.21          1
register_vif UP       Sparse 2 DR              1 192.168.100.17          0

root at mobile17> show mfea interface
Interface    State    Vif/PifIndex Addr            Flags
vf0          UP               0/21 192.168.100.17  MULTICAST BROADCAST KERN_UP
register_vif UP               1/21 192.168.100.17  PIM_REGISTER KERN_UP



pavlin>
pavlin>Also, do you always get this XLOG_FATAL() message right after the
pavlin>PIM Register message is transmitted:

Nope. After a bunch of PIM REGISTERS. Probably, they were running for 10 
minutes, before the error occured

pavlin>For some reason, XORP probably wanted to send Prune messages
pavlin>toward the RP and toward S, but it couldn't because there was no
pavlin>upstream PIM-SM neighor router. Given that those messages were
pavlin>generated right after the FEA crashed, all bets are off about which
pavlin>particular event triggered them.

Alright. Let me approach these problems one at a time. :-)

pavlin>
pavlin>> Why does joining the group not create an immediate PIM Join when the
pavlin>> router/node has been configured to act on only IGMP messages from itself and
pavlin>> each router/node is a DR ? This should ordinarily have worked in sending a PIM
pavlin>> join towards the next upstream router in direction of the RP ?
pavlin>
pavlin>This is the question we need to answer. Hopefully, the debug info I
pavlin>asked about in my earlier email will help us finding the answer.

I have sent that one. Thanks for the help

regards
Vikram


From aidan at wires3.net  Wed Jul 19 04:01:21 2006
From: aidan at wires3.net (Aidan Walton)
Date: Wed, 19 Jul 2006 12:01:21 +0100
Subject: [Xorp-users] RIB does not seem to import routes from OSPF
Message-ID: <1153306881.5504.48.camel@localhost>

Hi Folks,

I like to say first, I'm a newbie to the group in terms of mailing in,
but thankyou for your efforts with XORP, it's just a great piece of
code.

I do however have the following situation occurring, I have seen this
occur several times over the past couple of months, typically after a
neighbour has been repeatedly connected and disconnected. Unless I'm
mistaken, which is quite possible :), this does not seem correct. I'm
running XORP over wireless links and after the wireless link has bounced
a couple of times the following problem occurs. I have an OSPF neighbour
that becomes locked in the init state. It refused to go any further
until I enabled traceoptions, as soon as I did this the neighbour
exchanged as follows and moved to 'full'. I have attached the log.  Note
the gap between the timestamps 9.17am and 10.56am represent the period
while the OSPF neighbours got locked in 'init':

Back in xorpsh the situation looks like this:



root at testnode# run show route table ipv4 unicast final
0.0.0.0/0       [static(1)/30]
                > to 10.0.0.1 via eth0/eth0
10.0.0.0/24     [connected(0)/0]
                > via eth0/eth0
192.168.0.0/30  [connected(0)/0]
                > via ath0/ath0
192.168.255.251/32      [connected(0)/0]
                > via lo/lo
root at testnode# run show ospf4 database
   OSPF link state database, Area 0.0.0.0
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
Len
Router  *192.168.255.251  192.168.255.251  0x8000002d   850  0x2  0xbe35
60
ASExt-2 *0.0.0.0          192.168.255.251  0x80000019  1431  0x2  0x68c3
36
Router   192.168.255.253  192.168.255.253  0x8000008d   846  0x2  0xe4c1
48
Network *192.168.0.1      192.168.255.251  0x80000004   851  0x2  0x2895
32
Network  192.168.0.2      192.168.255.253  0x80000001   851  0x2  0x209d
32
ASExt-2  172.16.0.0       192.168.255.253  0x80000037   258  0x2  0x50c
36
root at testnode# run show ospf4 neighbor
  Address         Interface             State      ID              Pri
Dead
192.168.0.2      ath0/ath0              Full      192.168.255.253  128
33


As you can see the OSPF LSDB has routes that should make it to the RIB
but they don't seem to. I have also attached the detailed lsdb output.
Do you think there is a problem?

After disabling and enabling the interface under ospf the neighbour
comes up exchanges and the route table and detailed lsdb is fully
populated, as below:


root at testnode# run show route table ipv4 unicast final
0.0.0.0/0       [static(1)/30]
                > to 10.0.0.1 via eth0/eth0
10.0.0.0/24     [connected(0)/0]
                > via eth0/eth0
172.16.0.0/24   [ospf(110)/2]
                > to 192.168.0.2 via ath0/ath0
192.168.0.0/30  [connected(0)/0]
                > via ath0/ath0
192.168.255.251/32      [connected(0)/0]
                > via lo/lo
192.168.255.253/32      [ospf(110)/2]
                > to 192.168.0.2 via ath0/ath0

root at testnode# run show ospf4 database
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
Len
Router  *192.168.255.251  192.168.255.251  0x80000030   378  0x2  0xc22d
60
ASExt-2 *0.0.0.0          192.168.255.251  0x8000001b   553  0x2  0x64c5
36
Router   192.168.255.253  192.168.255.253  0x80000090   374  0x2  0xdec4
48
Network  192.168.0.2      192.168.255.253  0x80000003   374  0x2  0x1c9f
32
ASExt-2  172.16.0.0       192.168.255.253  0x80000038  1179  0x2  0x30d
36




The log file has had this appended:


[ 2006/07/19 11:48:45  WARNING xorp_ospfv2:5666 OSPF +1529 peer.cc
event_neighbour_change ] Unexpected state Down
[ 2006/07/19 11:48:45  WARNING xorp_ospfv2:5666 OSPF +314 peer.cc
receive ] Packet arrived while peer is not running
[ 2006/07/19 11:48:45  WARNING xorp_ospfv2:5666 OSPF +314 peer.cc
receive ] Packet arrived while peer is not running
[ 2006/07/19 11:49:40  INFO xorp_ospfv2:5666 OSPF +4042 peer.cc
link_state_update_received ] Same LSA
Network-LSA:
LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 192.168.0.2 Advertising Router 192.168.255.253 LS sequence
number 0x80000002 LS checksum 0x1e9e length 32
        Network Mask 0xfffffffc
        Attached Router 192.168.255.251
        Attached Router 192.168.255.253
Network-LSA:
LS age    6 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 192.168.0.2 Advertising Router 192.168.255.253 LS sequence
number 0x80000003 LS checksum 0x1c9f length 32
        Network Mask 0xfffffffc
        Attached Router 192.168.255.251
        Attached Router 192.168.255.253



I have attached also the detailed lsdb ouput after the interface has
come back up. All seems ok again!


Any help would be appreciated.

Thanks
Aidan 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorp_log_19th_July_06.log
Type: text/x-log
Size: 10222 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060719/8156df33/attachment.bin 
-------------- next part --------------
root at testnode# run show ospf4 database detail
   OSPF link state database, Area 0.0.0.0
Router-LSA:
LS age  407 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 192.168.255.251 Advertising Router 192.168.255.251 LS sequence number 0x8000002e LS checksum 0xbc36 length 60
        Nt-bit false
        V-bit false
        E-bit true
        B-bit false
        Type 2 Transit network IP address of Designated router 192.168.0.1 Routers interface address 192.168.0.1 Metric 1
        Type 3 Stub network Subnet number 10.0.0.0 Mask 255.255.255.0 Metric 1
        Type 3 Stub network Subnet number 192.168.255.251 Mask 255.255.255.255 Metric 1
As-External-LSA:
LS age  988 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link State ID 0.0.0.0 Advertising Router 192.168.255.251 LS sequence number 0x8000001a LS checksum 0x66c4 length 36
        Network Mask 0
        E-bit true
        Metric 30 0x1e
        Forwarding address 10.0.0.1
        External Route Tag 0
Router-LSA:
LS age  408 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 192.168.255.253 Advertising Router 192.168.255.253 LS sequence number 0x8000008e LS checksum 0xe2c2 length 48
        Nt-bit false
        V-bit false
        E-bit true
        B-bit false
        Type 2 Transit network IP address of Designated router 192.168.0.2 Routers interface address 192.168.0.2 Metric 1
        Type 3 Stub network Subnet number 192.168.255.253 Mask 255.255.255.255 Metric 1
Network-LSA:
LS age  407 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 192.168.0.1 Advertising Router 192.168.255.251 LS sequence number 0x80000005 LS checksum 0x2696 length 32
        Network Mask 0xfffffffc
        Attached Router 192.168.255.253
        Attached Router 192.168.255.251
Network-LSA:
LS age  408 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 192.168.0.2 Advertising Router 192.168.255.253 LS sequence number 0x80000002 LS checksum 0x1e9e length 32
        Network Mask 0xfffffffc
        Attached Router 192.168.255.251
        Attached Router 192.168.255.253
As-External-LSA:
LS age 1614 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link State ID 172.16.0.0 Advertising Router 192.168.255.253 LS sequence number 0x80000037 LS checksum 0x50c length 36
        Network Mask 0xffffff00
        E-bit true
        Metric 0 0
        Forwarding address 192.168.255.253
        External Route Tag 0
-------------- next part --------------
root at testnode# run show ospf4 database detail
   OSPF link state database, Area 0.0.0.0
Router-LSA:
LS age  273 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 192.168.255.251 Advertising Router 192.168.255.251 LS sequence number 0x80000030 LS checksum 0xc22d length 60
        Nt-bit false
        V-bit false
        E-bit true
        B-bit false
        Type 2 Transit network IP address of Designated router 192.168.0.2 Routers interface address 192.168.0.1 Metric 1
        Type 3 Stub network Subnet number 10.0.0.0 Mask 255.255.255.0 Metric 1
        Type 3 Stub network Subnet number 192.168.255.251 Mask 255.255.255.255 Metric 1
As-External-LSA:
LS age  448 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link State ID 0.0.0.0 Advertising Router 192.168.255.251 LS sequence number 0x8000001b LS checksum 0x64c5 length 36
        Network Mask 0
        E-bit true
        Metric 30 0x1e
        Forwarding address 10.0.0.1
        External Route Tag 0
Router-LSA:
LS age  269 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 192.168.255.253 Advertising Router 192.168.255.253 LS sequence number 0x80000090 LS checksum 0xdec4 length 48
        Nt-bit false
        V-bit false
        E-bit true
        B-bit false
        Type 2 Transit network IP address of Designated router 192.168.0.2 Routers interface address 192.168.0.2 Metric 1
        Type 3 Stub network Subnet number 192.168.255.253 Mask 255.255.255.255 Metric 1
Network-LSA:
LS age  269 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 192.168.0.2 Advertising Router 192.168.255.253 LS sequence number 0x80000003 LS checksum 0x1c9f length 32
        Network Mask 0xfffffffc
        Attached Router 192.168.255.251
        Attached Router 192.168.255.253
As-External-LSA:
LS age 1074 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x5 Link State ID 172.16.0.0 Advertising Router 192.168.255.253 LS sequence number 0x80000038 LS checksum 0x30d length 36
        Network Mask 0xffffff00
        E-bit true
        Metric 0 0
        Forwarding address 192.168.255.253
        External Route Tag 0

From pavlin at icir.org  Wed Jul 19 10:28:30 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 19 Jul 2006 10:28:30 -0700
Subject: [Xorp-users] IGMP/PIM question ?
In-Reply-To: Message from Vikram KAUL <vkaul@research.telcordia.com> of "Tue,
	18 Jul 2006 11:55:22 EDT."
	<Pine.WNT.4.60.0607181045410.632@vkaul-1.dte.telcordia.com> 
Message-ID: <200607191728.k6JHSU2K097734@possum.icir.org>

> Nope. I mean there exists only one interface and that is the interface on 
> which I have enabled PIM.
> 
> pavlin>
> pavlin>You cannot use PIM-SM for any effective multicast forwarding with a
> pavlin>single network interface. For example, every multicast forwarding
> pavlin>entry (as installed in the kernel) has an incoming interface, and a
> pavlin>set of outgoing interfaces. An incoming interface is automatically
> pavlin>excluded from the oifs set. Hence, with a single enabled interface
> pavlin>the oifs set is always empty.
> pavlin>
> 
> But is that not controlled by the "oifs_ttl" in the MfeaNode::add_mfc() 
> function which first sets all oifs_ttl to ZERO and then after performing a 
> test on oiflist   (oiflist.test(i)) mask, sets the TTL to MINTTL of 1. 
> And then the MfeaRouter::add_mfc() function is called to actually 
> implements the setsockopt() to tell the kernel about it.
> 
> In MfeaRouter::add_mfc() the first thing that is done is 
> 
>     oifs_ttl[iif_vif_index] = 0;  // Pre-caution
> 
> This precludes the kernel from using the iff as one of the legitimate 
> interfaces for output. 

The PIM-SM spec <draft-ietf-pim-sm-v2-new-12.txt, Section 4.2.  Data
Packet Forwarding Rules) mandates that the iif is always excluded
from the oiflist:

<QUOTE>
On receipt of data from S to G on interface iif:
...
 oiflist = oiflist (-) iif
 forward packet on all interfaces in oiflist
</QUOTE>

The reason for excluding the iif from the oiflist is because
forwarding multcast data back on the interface it came from can
result in multicast loops, and such loops can bring down a whole
network.

In addition, if we take into account the PIM assert mechanism,
then the iif might be excluded anyway from the oiflist.

> What I wonder is if this "Pre-caution" statement were commented, would 
> that be sufficient for the kernel to use the iff as one of the oif ??

You might be able to create such entry in the kernel, but this could
create various problems (see above).

> pavlin>A PIM Join toward the RP (R4) should have been generated
> pavlin>though. Could you send the output of the following commands:
> pavlin>
> pavlin> show pim join
> pavlin> show pim mrib
> pavlin> show pim interface
> pavlin> show pim neighbors
> pavlin> show pim rps
> pavlin> show igmp group
> 
> I have attached the following txt files:
> 
> xorpsh_before_receiver-app-started.txt 
>   xorp_after_receiver-app-started.txt
> xorpsh_after_receiver-app-started.txt
>   xorp_after_receiver-app-stopped.txt
> xorpsh_after_receiver-app-stopped.txt

I will have a look at the output an will reply in a separate email.

Regards,
Pavlin


From vkaul at research.telcordia.com  Wed Jul 19 10:51:37 2006
From: vkaul at research.telcordia.com (Vikram KAUL)
Date: Wed, 19 Jul 2006 13:51:37 -0400 (Eastern Standard Time)
Subject: [Xorp-users] IGMP/PIM question ?
In-Reply-To: <200607191728.k6JHSU2K097734@possum.icir.org>
References: <200607191728.k6JHSU2K097734@possum.icir.org>
Message-ID: <Pine.WNT.4.60.0607191344240.3104@vkaul-1.dte.telcordia.com>


Thanks for the reply. My comments interspersed...


pavlin>The PIM-SM spec <draft-ietf-pim-sm-v2-new-12.txt, Section 4.2.  Data
pavlin>Packet Forwarding Rules) mandates that the iif is always excluded
pavlin>from the oiflist:
pavlin>
pavlin><QUOTE>
pavlin>On receipt of data from S to G on interface iif:
pavlin>...
pavlin> oiflist = oiflist (-) iif
pavlin> forward packet on all interfaces in oiflist
pavlin></QUOTE>
pavlin>
pavlin>The reason for excluding the iif from the oiflist is because
pavlin>forwarding multcast data back on the interface it came from can
pavlin>result in multicast loops, and such loops can bring down a whole
pavlin>network.

Loops and duplicates can be avoided with filtering based on the IP ID 
field for UDP packets and maintaining a state for either a two-tuple 
(Source, ID) or a three-tuple (Source, DestGroup, ID). Of course, the IP 
ID has been designed for for support of packet fragmentation, so one has 
to be careful
Several multicast ad-hoc implementations use IP ID. I intend to insert 
the mechanism as a module in the kernel or as part of the kernel itself. 

pavlin>
pavlin>In addition, if we take into account the PIM assert mechanism,
pavlin>then the iif might be excluded anyway from the oiflist.
pavlin>

Is there some more information you (or anyone else) can give me about 
this. 

Thanks again for the help

regards..
Vikram


From pavlin at icir.org  Wed Jul 19 11:09:05 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 19 Jul 2006 11:09:05 -0700
Subject: [Xorp-users] IGMP/PIM question ?
In-Reply-To: Message from Vikram KAUL <vkaul@research.telcordia.com> of "Tue,
	18 Jul 2006 11:55:22 EDT."
	<Pine.WNT.4.60.0607181045410.632@vkaul-1.dte.telcordia.com> 
Message-ID: <200607191809.k6JI95uW098078@possum.icir.org>

> pavlin>A PIM Join toward the RP (R4) should have been generated
> pavlin>though. Could you send the output of the following commands:
> pavlin>
> pavlin> show pim join
> pavlin> show pim mrib
> pavlin> show pim interface
> pavlin> show pim neighbors
> pavlin> show pim rps
> pavlin> show igmp group
> 
> I have attached the following txt files:
> 
> xorpsh_before_receiver-app-started.txt 
>   xorp_after_receiver-app-started.txt
> xorpsh_after_receiver-app-started.txt
>   xorp_after_receiver-app-stopped.txt
> xorpsh_after_receiver-app-stopped.txt

The reason the PIM Join is not generated is because the (*,G)
routing entry's upstream state is not in Joined state:

root at mobile17> show pim join
Group           Source          RP              Flags
224.5.6.7       0.0.0.0         192.168.100.21  WC
    Upstream interface (RP):   vf0
    Upstream MRIB next hop (RP): 192.168.100.21
    Upstream RPF'(*,G):        192.168.100.21
    Upstream state:            NotJoined
    Join timer:                -1
    Local receiver include WC: O.
    Joins RP:                  ..
    Joins WC:                  ..
    Join state:                ..
    Prune state:               ..
    Prune pending state:       ..
    I am assert winner state:  ..
    I am assert loser state:   ..
    Assert winner WC:          ..
    Assert lost WC:            ..
    Assert tracking WC:        ..
    Could assert WC:           ..
    I am DR:                   .O
    Immediate olist RP:        ..
    Immediate olist WC:        ..
    Inherited olist SG:        ..
    Inherited olist SG_RPT:    ..
    PIM include WC:            ..

The (*,G) upstream state is controlled by the JoinDesired(*,G)
macro, which in your case would be true if
immediate_olist(*,G) != NULL
(see draft-ietf-pim-sm-v2-new-12.txt, Section 4.5.6.  Sending (*,G)
Join/Prune Messages).

Note that in the above "show pim join" output we see the state for
two interfaces: vf0 and register_vif. In case of (*,G) entry in
an non-RP router, the register_vif is not used, hence
immediate_olist(*,G) can be non-NULL only if vf0 was included in
that set.

The immediate_olist(*,G) is defined as:

immediate_olist(*,G) =
    joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)

There are no PIM Joins, hence joins(*,G) is NULL.
However, pim_include(*,G) is also NULL, because:

pim_include(*,G) =
   { all interfaces I such that:
     ( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
      OR AssertWinner(*,G,I) == me )
     AND  local_receiver_include(*,G,I) }


The Assert mechanism hasn't been activated for this group, and this
router is not the DR on the vf0 interface (see the
"show pim interface" output), hence pim_include(*,G) is indeed NULL.

In other words, this router won't send the (*,G) Join message toward
the RP. The Join must be sent by the DR for that LAN, unless there
are other reasons to prevent it from that (e.g., lost Assert).

Regards,
Pavlin


From atanu at ICSI.Berkeley.EDU  Wed Jul 19 12:13:51 2006
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 19 Jul 2006 12:13:51 -0700
Subject: [Xorp-users] Announcing XORP Release Candidate 1.3
Message-ID: <35211.1153336431@tigger.icir.org>

On behalf of the entire XORP team, I'm delighted to announce the XORP
1.3 Release Candidate, which is now available from <http://www.xorp.org>.

Once the release candidate has proven to be stable, the actual 1.3
release will be prepared. This is planned to occur in the next two
weeks. In the intervening period we will be fixing minor problems and
updating the documentation.

There are still a number of non-critical bugs that we know about which
will not be addressed until the 1.4 release; these are documented in
the errata section below.

In general, to test XORP, we run automated regression tests on a daily
basis with various operating systems and compilers. We also run a
number of PCs as XORP routers. We have enabled as many protocols as
feasible on those routers to test protocol interactions (for example a
BGP IPv6 multicast feed being used by PIM-SM). In addition, automated
scripts are run to externally toggle BGP peerings. Finally, we have
automated scripts that interact directly with the xorpsh to change the
configuration settings.

We have put significant effort into testing but obviously we have not
found all the problems. This is where you can help us to make XORP
more stable, by downloading and using it!

As always we'd welcome your comments - xorp-users at xorp.org is the
right place for general discussion, and private feedback to the XORP
core team can be sent to feedback at xorp.org.

 - The XORP Team

P.S.
Release notes and errata are included below.

------------------------------------------------------------------
		XORP RELEASE NOTES

Release 1.3-RC (2006/07/19)
=========================
  ALL:
    - Numerous improvements, bug fixes and cleanup.

    - XORP now builds on Linux Fedora Core5, DragonFlyBSD-1.4,
      FreeBSD-6.1.

    - Implementation of IGMPv3 (RFC 3376) and MLDv2 (RFC 3810).
      Those are necessary to complete the Source-Specific Multicast
      support.

  CONFIGURATION:
    - Addition of new OSPF configuration statement as part of the MD5
      keys:

      * max-time-drift: u32 (default to 3600, i.e., 1 hour)

      It is used to set the maximum time drift (in seconds) among all
      OSPF routers. The allowed values are in the range [0--65535]. If
      the value is 65535, the time drift is unlimited.

    - The following statements for configuring static routes have been
      deprecated:
      route4, route6, interface-route4, interface-route6, mrib-route4,
      mrib-route6, mrib-interface-route4, mrib-interface-route6.

      The new replacement statements are:
      route, interface-route, mrib-route, mrib-interface-route.

      Each of the new statements can be used to configure either IPv4Net
      or IPv6Net route.

    - The following statements for configuring RIP and RIPng have been
      renamed:

      * route-expiry-secs -> route-timeout

      * route-deletion-secs -> deletion-delay

      * table-request-secs -> request-interval

      * interpacket-delay-msecs -> interpacket-delay

    - The following statements for configuring RIP and RIPng random
      intervals have been replaced:

      * triggered-update-min-secs and triggered-update-max-secs with
        triggered-delay and triggered-jitter

      * table-announce-min-secs and table-announce-max-secs with
        update-interval and update-jitter

      Previously, each interval was specified as [foo-min, foo-max].
      Now each interval is specified as
      [foo - foo * jitter / 100, foo + foo * jitter / 100]
      where "jitter" is specified as a percentage (an integer in the
      interval [0, 100]) of the value of "foo".

    - The "version" statement for configuring an IGMP interface/vif
      allows values in the range [1-3]. Previously, the allowed range
      was [1-2].

    - The "version" statement for configuring a MLD interface/vif allows
      values in the range [1-3]. Previously, the allowed range was [1-1].

    - The following statement for configuring PIM-SM (pimsm4 and pimsm6)
      has been renamed:

      interval-sec -> interval

    - If a "then" policy block contains "accept" or "reject" statement,
      now all statements inside the "then" block are evaluated
      regardless of their position.

    - Addition of a new "exit" operational mode command that is
      equivalent to the "quit" operational mode command.

    - The "create" and "set" configuration commands are merged, so now
      the new "set" command can be used for setting values and for
      creating new configuration nodes. For backward compatibility,
      the obsoleted "create" command is preserved as an alias for the
      new "set" command, though it may be removed in the future.

  LIBXORP:
    - Few bug fixes in the RefTrie implementation.

  LIBXIPC:
    - Minor improvement in parsing XRL requests.

  LIBFEACLIENT:
    - No significant changes.

  XRL:
    - No significant changes.

  RTRMGR:
    - Various bug fixes.

  XORPSH:
    - Previously, the "commit" command was not available in
      configuration mode if there were no pending configuration changes.
      Now the "commit" command is always available, but the following
      message will be printed instead:
        "No configuration changes to commit."

    - Various bug fixes.

  POLICY:
    - Various bug fixes.

  FEA/MFEA:
    - Bug fix in transmitting large packets on Linux when using IP raw
      sockets.

    - Linux-related netlink socket code refactoring and bug fix.

    - Bug fix in obtaining the incoming interface for raw packets
      (in case of *BSD).

    - Bug fix in parsing the ancillary data from recvmsg().

    - Accept zeroed source addresses of raw packets, because of
      protocols like IGMPv3.

  RIB:
    - Several bug fixes and improvements.

  RIP:
    - Various bug fixes in the MD5 authentication support.

    - Remove route flap when applying/deleting RIP-related import
      policies.

    - Fix an issue with INFINITY cost routes that might be bounced
      indefinitely between two XORP routers.

  OSPF:
    - Various bug fixes in the MD5 authentication support.

  BGP:
    - Prefix limits on a per peer basis.

    - Various bug fixes.

  STATIC_ROUTES:
    - No significant changes.

  MLD/IGMP:
    - Implementation of IGMPv3 (RFC 3376) and MLDv2 (RFC 3810).

    - Unification of the IGMP and MLD execution path.

  PIM-SM:
    - Bug fix related to the SPT switch (the bug is *BSD specific).

    - Use the RPF interface toward the BSR when transmitting a Cand-RP
      Advertisement message. Previously the first interface that is UP
      was chosen.

    - Use the RPF interface toward the RP when transmitting PIM Register
      messages toward the RP. Previously the interface of the directly
      connected source was chosen.

  FIB2MRIB:
    - No significant changes.

  CLI:
    - No significant changes.

  SNMP:
    - No significant changes.

------------------------------------------------------------------
		XORP ERRATA

  ALL:
    - Parallel building (e.g., "gmake -j 4") may fail on multi-CPU
      machines. The simplest work-around is to rerun gmake or not to use
      the -j flag.

    - The following compiler is known to be buggy, and should not be used
      to compile XORP:
        gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD]
      A newer compiler such as the following should be used instead:
        gcc34 (GCC) 3.4.2 20040827 (prerelease) [FreeBSD]

    - If you run BGP, RIB, FIB2MRIB, and PIM-SM at the same time,
      the propagation latency for the BGP routes to reach the kernel
      is increased. We are investigating the problem.

  LIBXORP:
    - No known issues.

  LIBXIPC:
    - No known issues.

  LIBFEACLIENT:
    - No known issues.

  XRL:
    - No known issues.

  RTRMGR:
    - There are several known issues, but none of them is considered
      critical. The list of known issues is available from:

        http://www.xorp.org/bugzilla/query.cgi

    - Using the rtrmgr "-r" command-line option to restart processes
      that have failed does not work if a process fails while being
      reconfigured via xorpsh. If that happens, the rtrmgr itself may
      coredump. Therefore, using the "-r" command-line option is not
      recommended! Also, note that a process that has been killed by
      SIGTERM or SIGKILL will not be restarted (this is a feature rather
      than a bug). Ideally, we want to monitor the processes status
      using the finder rather than the forked children process status,
      therefore in the future when we have a more robust implementation
      the "-r" switch will be removed and will be enabled by default.

  XORPSH:
    - There are several known issues, but none of them is considered
      critical. The list of known issues is available from:

        http://www.xorp.org/bugzilla/query.cgi

  FEA/MFEA:
    - On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel
      2.6.5-1.358), some of the tests may fail (with or without an error
      message), but no coredump image. Some of those failures can be
      contributed to a kernel problem. E.g., running "dmesg" can show
      kernel "Oops" messages like:

        Unable to handle kernel NULL pointer dereference at virtual
        address 00000000 printing eip:
        ...

      This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME)
      which itself is called by if_indextoname(3). Currently, there 
      is no known solution, but it appears the problem may have been
      fixed for more recent Linux kernel versions:

        https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697

    - On Linux with kernel older than linux-2.6.15-rc7 there is a
      kernel bug that prevents the FEA to receive netlink(7) notifications
      about added/deleted IPv6 network addresses and routes:

        http://www.uwsg.indiana.edu/hypermail/linux/kernel/0512.2/2121.html

      Typically, this could be an issue only if someone is running
      IPv6 PIM-SM on Linux, and only if the unicast routes may be modified
      while XORP is running. In that case the fix would be to replace
      "RTMGRP_IPV6_IFADDR" with "(RTMGRP_IPV6_IFADDR >> 1)" inside
      fea/ifconfig_observer_netlink.cc, and to replace "RTMGRP_IPV6_ROUTE"
      with "(RTMGRP_IPV6_ROUTE >> 1)" inside
      fticonfig_entry_observer_netlink.cc and
      fticonfig_table_observer_netlink.cc.

    - On Linux, adding and deleting multiple IPv4 addresses per interface
      may trigger an error: typically, if the primary IPv4 address
      is deleted, the kernel automatically deletes all secondary IPv4
      addresses on that interface. In Linux kernel 2.6.12 and later,
      enabling the new sysctl net.ipv4.conf.all.promote_secondaries
      (or one of the interface specific variants) can be used to
      automatically promote one of the secondary addresses to become
      the new primary address.

    - The mechanism for tracking the network interface link status
      may not work for the following OS-es because the kernel for those
      systems does not provide a mechanism for asynchronous notification
      of userland programs when the link status changes: FreeBSD-5.2 and
      earlier and MacOS X (note: if the Windows kernel supports this
      feature, it is not used yet in XORP). Though, for those systems
      the link status should be read properly on startup.

  RIB:
    - In some rare cases, the RIB may fail to delete an existing route:

        http://www.xorp.org/bugzilla/show_bug.cgi?id=62

      We are aware of the issue and will attempt to fix it in the
      future.

  RIP:
    - No known issues.

  OSPF:
    - There are several known issues, but none of them is considered
      critical. The list of known issues is available from:

        http://www.xorp.org/bugzilla/query.cgi

  BGP:
    - If the RIB bug above (failure to delete an existing route) is
      triggered by BGP, then the deletion failure error received by
      BGP from the RIB is considered by BGP as a fatal error. This is
      not a BGP problem, but a RIB problem that will be fixed in the
      future.

    - The BGP configuration mandates that an IPv4 nexthop must be
      supplied. Unfortunately it is necessary to provide an IPv4 nexthop
      even for an IPv6 only peering. Even more unfortunately it is not
      possible to force the IPv6 nexthop.

    - It is *essential* for an IPv6 peering that an IPv6 nexthop is
      provided. Unfortunately the configuration does not enforce this
      requrement. This will be fixed in the future.

  STATIC_ROUTES:
    - No known issues.
      
  MLD/IGMP:
    - If MLD/IGMP is started on Linux with a relatively large number of
      interfaces (e.g., on the order of 10), then it may fail with the
      following error:

        [ 2004/06/14 12:58:56  ERROR test_pim:16548 MFEA +666
        mfea_proto_comm.cc join_multicast_group ] Cannot join group
        224.0.0.2 on vif eth8: No buffer space available

      The solution is to increase the multicast group membership limit.
      E.g., to increase the value from 20 (the default) to 200, run as a
      root:

        echo 200 > /proc/sys/net/ipv4/igmp_max_memberships

  PIM-SM:
    - If the kernel does not support PIM-SM, or if PIM-SM is not enabled
      in the kernel, then running PIM-SM will fail with the following
      error message:

        [ 2004/06/12 10:26:41  ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc
        start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported

    - On Linux, if the unicast Reverse Path Forwarding information is
      different from the multicast Reverse Path Forwarding information,
      the Reverse Path Filtering should be disabled. E.g., as root:

        echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

      OR

        echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
        echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
        ...

      Otherwise, the router will ignore packets if they don't arrive on
      the reverse-path interface. For more information about Reverse
      Path Filtering see:

        http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html

    - Currently, the PIM-SM implementation does not support unnumbered
      point-to-point links. Furthermore, even on numbered point-to-point
      links the next-hop information in the routing entries should use
      an IP address instead of an interface name. For example,
      if there is a GRE tunnel on Linux and if we want to add a route
      that uses that tunnel, we should use a command like:

        route add -net <target> gw <IP address of other side of GRE tunnel>

      instead of:

        route add -net <target> <GRE interface name>

    - If PIM-SM is configured to run over a large number of interfaces
      (e.g., more than 31 VLANs), it might fail with the following error:

      [ 2006/07/04 11:56:23  ERROR xorp_fea:28353 MFEA +967 mfea_mrouter.cc
      add_multicast_vif ]
      setsockopt(MRT_ADD_VIF, vif eth0.4) failed: Too many open files in system

      The reason for that error is that by default majority of the UNIX
      kernels cannot support more than 32 interfaces enabled for multicast
      forwarding (one interface is always used as the internal PIM Register
      virtual interface).

      The solution is to increase the MAXVIFS limit in the kernel
      (typically defined in the "netinet/ip_mroute.h" (BSD) or the
      "include/linux/mroute.h" (Linux) kernel file), and recompile the
      kernel. It should be increased also in the corresponding system
      header file as well: <netinet/ip_mroute.h> or <linux/mroute.h>.
      After that XORP should be recompiled to take into account the
      MAXVIFS increase. If modifying the system header files is not
      acceptable, then the following should be added toward the end of
      file "xorp/mrt/max_vifs.h" before recompiling XORP:

      #undef MAX_VIFS
      #define MAX_VIFS 50

  FIB2MRIB:
    - No known issues.

  CLI:
    - No known issues.

  SNMP:
    - On some versions of Linux, there are some bugs in net-snmp
      versions 5.0.8 and 5.0.9, which prevent dynamic loading from
      working. See the following URL for links to the net-snmp
      patches that solve the problems:

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

    - Version 5.1 of net-snmp requires a simple modification, otherwise
      XORP will fail to compile.
      See the following URL for a link to the net-snmp patch that solves
      the problems:

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


From pavlin at icir.org  Wed Jul 19 15:32:15 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 19 Jul 2006 15:32:15 -0700
Subject: [Xorp-users] FATAL xorp_fea ERROR
In-Reply-To: Message from Vikram KAUL <vkaul@research.telcordia.com> of "Tue,
	18 Jul 2006 12:07:57 EDT."
	<Pine.WNT.4.60.0607181158540.632@vkaul-1.dte.telcordia.com> 
Message-ID: <200607192232.k6JMWFWu001254@possum.icir.org>

> root at mobile17> show interfaces
> vf0/vf0: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500
>         inet6 fe80::4c52:4cff:fe63:6a91 prefixlen 64
>         inet 192.168.100.17 subnet 192.168.100.0/24 broadcast 192.168.100.255
>         physical index 21
>         ether 4e:52:4c:63:6a:91

It appears that XORP is configured to use only the interface with
physical index 21, but the fatal error message was about an
interface with physical index 17:

[ 2006/07/17 16:01:32  FATAL xorp_fea:14932 FEA +298 netlink_socket_utils.cc nlm_get_to_fte_cfg ] Could not find interface corresponding to index 17

I guess this has been triggered by some route being added to the
kernel (or by internal route manipulations by the kernel itself).

To find the real reason for the failure, could you run the following
command in parallel with XORP:
"ip monitor all"
Try to point the entry that is printed right before the FEA crashes.

In addition, after the crash there should be a coredump file.
Please send the backtrace for that file, and some of the values:

gdb xorp_fea -c your_corefile
bt
frame 3		# Try a different number to get into
                # NlmUtils::nlm_get_to_fte_cfg()
p rtmsg->rtm_type
p *rtmsg


Thanks,
Pavlin


From pavlin at icir.org  Wed Jul 19 16:36:31 2006
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 19 Jul 2006 16:36:31 -0700
Subject: [Xorp-users] IGMP/PIM question ?
In-Reply-To: Message from Vikram KAUL <vkaul@research.telcordia.com> of "Wed,
	19 Jul 2006 13:51:37 EDT."
	<Pine.WNT.4.60.0607191344240.3104@vkaul-1.dte.telcordia.com> 
Message-ID: <200607192336.k6JNaVI4008345@possum.icir.org>

> pavlin>The PIM-SM spec <draft-ietf-pim-sm-v2-new-12.txt, Section 4.2.  Data
> pavlin>Packet Forwarding Rules) mandates that the iif is always excluded
> pavlin>from the oiflist:
> pavlin>
> pavlin><QUOTE>
> pavlin>On receipt of data from S to G on interface iif:
> pavlin>...
> pavlin> oiflist = oiflist (-) iif
> pavlin> forward packet on all interfaces in oiflist
> pavlin></QUOTE>
> pavlin>
> pavlin>The reason for excluding the iif from the oiflist is because
> pavlin>forwarding multcast data back on the interface it came from can
> pavlin>result in multicast loops, and such loops can bring down a whole
> pavlin>network.
> 
> Loops and duplicates can be avoided with filtering based on the IP ID 
> field for UDP packets and maintaining a state for either a two-tuple 
> (Source, ID) or a three-tuple (Source, DestGroup, ID). Of course, the IP 
> ID has been designed for for support of packet fragmentation, so one has 
> to be careful
> Several multicast ad-hoc implementations use IP ID. I intend to insert 
> the mechanism as a module in the kernel or as part of the kernel itself. 

PIM-SM has been designed to avoid loops, duplicates and blackholes
at the tree construction level, and for that purpose it uses a
number of mechanisms: RPF checks, the Assert mechanism, etc.

All those mechanisms are tightly coupled, so removing some of them
requires very detailed understanding of the the PIM-SM protocol
internals. E.g., see the Bidir-PIM proposal that removes the Asserts
and few other mechanisms:

http://www.ietf.org/internet-drafts/draft-ietf-pim-bidir-08.txt

What you describe is quite different mechanism for doing multicast
routing, and I doubt you can easily reuse the PIM-SM machinery for
that purpose.

> pavlin>
> pavlin>In addition, if we take into account the PIM assert mechanism,
> pavlin>then the iif might be excluded anyway from the oiflist.
> pavlin>
> 
> Is there some more information you (or anyone else) can give me about 
> this. 

The PIM-SM spec itself is the best source of information about how
the Assert mechanism works. See also the Bidir-PIM I-D cited above
that describes a solution without the Assert mechanism.

On the subject of ad-hoc multicast routing itself.
PIM-SM hasn't been designed with ad-hoc routing in mind, so most
likely you would need a very different protocol/solution.
A quick search for ad-hoc multicast routing reveals a number of
publications about various solutions.

E.g., the following URL contains such list:

http://en.wikipedia.org/wiki/Ad_hoc_routing_protocol_list#Multicast


Regards,
Pavlin


From ashwinc at ittc.ku.edu  Mon Jul 24 06:29:07 2006
From: ashwinc at ittc.ku.edu (Ashwin Chimata)
Date: Mon, 24 Jul 2006 08:29:07 -0500
Subject: [Xorp-users] iBGP peering issue
Message-ID: <e07db30e0607240629q263498e7ib955ddd77fd09de4@mail.gmail.com>

Hi,
       I am relatively new to XORP and have a question regarding how to set
up
IBGP peering using XORP.  The following is my set up

      router1 (AS 65001)
     ----------
     interface eth1 -> 172.16.1.2  (connected to eBGP peer 172.16.1.1 in AS
65002)
     interface eth2 -> 10.1.0.2   (want to conect to iBGP peer 10.3.0.1 )

     I have "ospf" setup on router 1 and with other internal routers in AS
65001, and am redistributing the
OSPF and connected routes into BGP. However, I want these routes to be
redistributed only to my eBGP
peer and not to my iBGP peer.

     The following is my BGP configuration:

protocols {
        bgp {
                bgp-id: 172.16.1.2
                local-as: 65001
                export: "routes_to_export"

                peer 172.16.1.1 {   /* eBGP peering */
                        local-ip: 172.16.1.2
                        as: 65002
                        next-hop: 172.16.1.2
                        holdtime: 120
                        ipv4-unicast: true
                }
                peer 10.3.0.1 {    /* iBGP peering */
                        local-ip: 10.1.0.2
                        as: 65001
                        next-hop: 10.1.0.2
                        holdtime: 120
                        ipv4-unicast: true
                }
        }
}

and this is the policy statement I am using for redistributing the connected
and OSPF routes:

policy {
        policy-statement "routes_to_export" {
                term "export-ospf" {
                        from {
                                protocol: "ospf4"
                        }
                }
                term "export-connected" {
                        from {
                                protocol: "connected"
                        }
                }
 }
}

   These are the questions I have:

 1) Is my iBGP peering configuration with the iBGP peer 10.3.0.1 correct in
the config file ?
 2) How to allow routes to be redistributed only to all eBGP peers and to
none of iBGP peers ?
 3) Is there any other way to advertise networks to BGP peers other than
using export policies ?
because using export policy causes internal routes to be advertised to iBGP
peers too.

     When I tried setting up the iBGP and eBGP peering, as in the above
config file,
router1's connected routes were sent through both ospf and iBGP updates, and
there was route flapping

     Any help in this regard would be greatly appreciated.

Thanks in advance,
Ashwin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060724/5949cd16/attachment.html