[Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop

[Pavlin Radoslavov]

> I am using XORP 1.3-Release for PIM-SMv6 and Zebra 0.95 for unicast
> routing on FreeBSD 6.1.
> The situations are:
> 1. xorpsh sometimes issues recursive malloc calls, causing segmentation fault.

Is the problem reproducible?
If "yes", can you provide detailed instructions how to trigger it.
If "no", can you send a backtrace of the coredump.

> 2. XORP doesn't update its nexthop vif on multicast routing table If
> Zebra updates a routing entry.
>     show route table ipv6 multicast fib2mrib shows that the nexthop
> vif is not  changed even though the nexthop address is.
>   I am not sure whether this problem is intermittent or not.

Can you trigger the same problem by using userland commands like
"route delete" and "route add". If "yes", could you provide the
sequence of those commands.

> 3. I am wondering if this is a bug or not. I set the
> switch-to-spt-threshold to a non-0 value, and my PIM RP never
> initiates a Register-Stop, i.e.:
>    a. The RP doesn't issue a Register-Stop when it receives PIM
> Register packets for multicast group without any Join state.
>    b. The RP doesn't issue a Register-Stop for PIM Register packets
> when there's a Join state but no oif (i.e. the last-hop router
> switched to SPT and the RP is not a router in the SPT).
>    c. The RP only issues a Register-Stop if it receives a Join(S,G) message.

Regarding (a) and (b):
In earlier versions of the PIM-SM spec, if the RP didn't have any
Join state (or if the Join state was with NULL oif set), the
Register-Stop was generated for the first PIM Register packet.
Later the spec was modified such that the Register-Stop is generated
only if the PIM Registers bandwidth is above the "switch-to-spt"
bandwidth threshold.
Hence, if you increase the sender's bandwidth, eventually the RP
would generate a Register-Stop. Note that the FreeBSD IPv6 multicast
forwarding support in the kernel doesn't support the multicast
bandwidth upcall mechanism, so it might take a while until the
userland mechanism (periodic polling) detects the high bandwidth
dataflow. The "show mfea6 dataflow" xorpsh command can be used as a
guide to tell you when the bandwidth threshold has been reached.

Regarding (c):
In this scenario eventually the data will start arriving on the
shortest-path, hence the RP will immediately send Register-Stop for
any PIM Register packets.

Regards,
Pavlin

> If it is a bug, I guess the below snippets are enough to make RP
> issues a Register-Stop.
> 
> %rcsdiff -u pim_proto_register.cc
> ===================================================================
> RCS file: RCS/pim_proto_register.cc,v
> retrieving revision 1.1
> diff -u -r1.1 pim_proto_register.cc
> --- pim_proto_register.cc       2006/08/14 09:21:51     1.1
> +++ pim_proto_register.cc       2006/08/14 10:27:40
> @@ -302,8 +302,7 @@
>      // messages reaches the configured threshold.
>      //
>      if (is_sptbit_set
> -       || (pim_mre->is_switch_to_spt_desired_sg(0, 0)
> -           && pim_mre->inherited_olist_sg().none())) {
> +        || pim_mre->inherited_olist_sg().none()) {
>         //
>         // "send Register-Stop(S,G) to outer.src"
>         //
> %rcsdiff -u pim_mre_data.cc
> ===================================================================
> RCS file: RCS/pim_mre_data.cc,v
> retrieving revision 1.1
> diff -u -r1.1 pim_mre_data.cc
> --- pim_mre_data.cc     2006/08/14 09:20:51     1.1
> +++ pim_mre_data.cc     2006/08/14 09:21:42
> @@ -101,6 +101,11 @@
>      if (! (is_wc() || is_sg() || is_sg_rpt()))
>         return (false);
> 
> +    //
> +    // RP SPT switch
> +    //
> +    if (i_am_rp())
> +      return (true);
>      mifs = pim_include_wc();
>      if (pim_mre_sg != NULL) {
>         mifs &= ~pim_mre_sg->pim_exclude_sg();
> 
> 
> regards,
> 
> -- 
> <husni>
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users