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

[Pavlin Radoslavov]

Daniel Paquet <daniel.paquet at gmail.com> wrote:

> On 10/31/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
> >
> > > show pim neighbors :
> > >
> > > Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
> > > tun0                  1 10.254.0.13     2 Sparse      105     100
> >
> > OK, that's good. The problem then with the RP RPF information is
> > probably somewhere else.
> > Could you send the output of "show pim mrib" and
> > "show route table ipv4 multicast all".
> 
> 
> output of 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      0.0.0.0         tun0    1               254  65535
> 10.254.0.12/30     10.254.0.14     tun0    1                 0      0

> 
> output of show route table ipv4 multicast all :
> 
> The all option dont exist in the xorp version im running (1.4) so I did show
> route table ipv4 multicast final :

Yes, sorry, it was a typo.

> 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   [fib2mrib(254)/65535]
>                 > to 0.0.0.0 via tun0/tun0
> 10.254.0.12/30  [connected(0)/0]
>                 > via tun0/tun0

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
        }
        ...
    }
}

Regards,
Pavlin