[Xorp-users] New to this multcast - Can this work with xorp?

[Pavlin Radoslavov]

> On 10/31/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
> >
> > Daniel Paquet <daniel.paquet at gmail.com> wrote:
> >
> > The longest-prefix match for the RP address (10.254.0.1) is
> > 10.254.0.0/30, and the next-hop address toward this destination
> > appears as 0.0.0.0 (instead of the other side of the tunnel:
> > 10.254.0.13).
> > This is an artifact of how the route appears inside the Linux kernel
> > (and snooped back by the fib2mrib via the FEA).
> >
> > To get around this problem, you might want to add an explicit
> > (better) static route that covers the RP. E.g.:
> >
> > protocols {
> >     static {
> >         mrib-route 10.254.0.0/30 {
> >             next-hop: 10.254.0.13
> >         }
> >         ...
> >     }
> > }
> 
> 
> Okay ive added this route, I had the 0.0.0.0 route in  as I read the xorp
> doc and stated that this is better to use this with tunnels. So now I added
> this other mrib-route below the 0.0.0.0 in my config.

Yes, you might need both of them. The newer 10.254.0.0/30 is needed
because the default 0.0.0.0/0 loses when it comes to the
longest-prefix match for the RP address 10.254.0.1.

> So now
> 
> show pim mrib :
> DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
> 0.0.0.0/0          10.254.0.13     tun0    1                 1      1
> 10.132.3.0/24      10.132.3.20     eth0    0                 0      0
> 10.254.0.0/30      10.254.0.13     tun0    1                 1      1
> 10.254.0.12/30     10.254.0.14     tun0    1                 0      0
> 
> and show route table ipv4 multicast final :
> 
> 0.0.0.0/0       [static(1)/1]
>                 > to 10.254.0.13 via tun0/tun0
> 10.132.3.0/24   [connected(0)/0]
>                 > via eth0/eth0
> 10.254.0.0/30   [static(1)/1]
>                 > to 10.254.0.13 via tun0/tun0
> 10.254.0.12/30  [connected(0)/0]
>                 > via tun0/tun0
> 
> After this well, it's kind of the same thing, the linux box join no
> multicast group.

It still won't work yet because of the IGMP Join issue.

What is the output of "show pim join all"?
The purpose of the new static route is to solve the RPF issue for
the RP.

Regards,
Pavlin