[Xorp-users] inter as multicast

Pavlin Radoslavov pavlin@icir.org
Mon, 27 Jun 2005 10:41:48 -0700


> The message is (S,G) I am sure of it. I have seen the unicast and multicast
> tables like you said so, and I ca see the network 192.10.20.0 in unicast
> tables but this network never appears in multicast tables.
> I see the join status in both xorp routers and I confirm that there is  one
> entry for my multicast group 224.30.30.30 in (S,G) mode. (Like you can see
> in file xorp1(show pim join).txt)
> 
> The only change I made in configuration is the group-prefix in the rp, now
> is 224.0.0.0/8.
> 
> My question is why don't xorp add a rote in the multicast table?

This is a very good question, because 192.10.20.0/24 is indeed
missing from the fib2mrib RIB table.

To debug the problem I'd suggest the following:
 1. Get the lastest XORP code from CVS
 2. Run only RIP on cisco1, and RIP and fib2mrib on xorp1, and
    verify that the 192.10.20.0/24 route is still missing from the
    xorp1's fib2mrib RIB table. Also, verify that the route is
    indeed in the kernel.
 3. Set XRLTRACE environmental variable in the window you run XORP,
    and run "route monitor -n" in another window. Restart XORP and
    look for the following:
    - One of the routing socket messages you see in the
      "route monitor -n" window should show the 192.10.20.0/24 route
      being added to the kernel.
    - Look for the XRLs in the rtrmgr window that have been sent
      between various modules. In particular, look for the
      add_route4 (and maybe replace_route4) XRLs that have been sent
      from the FEA to the fib2mrib module. Eventually, one of those
      XRLs should be to add the 192.10.20.0/24 route.
      Just in case, look for delete_route4 XRLs as well.
    - Look for the XRLs that have been sent from the fib2mrib module
      to the RIB module. In particular, look for XRLs like
      add_route4, replace_route4, add_interface_route4, and
      replace_interface_route4. Again, if everything is working
      normal, one of those XRLs should be for route 192.10.20.0/24
      Just in case, look for delete_route4 XRLs as well.

Hopefully, the above procedure would show where we have lost the
route.

Pavlin