[Xorp-users] How to work with a bridge (br0)? (corrected version)

Pavlin Radoslavov pavlin@icir.org
Wed, 23 Nov 2005 16:45:34 -0800


> I noticed some (not several, but more than one) crashes in the last few
> hours. xorp_rtrmgr does not react on ctrl+c and multicast routing is
> stopped (I can't see any entries in my SAP list). Any ideas?

Do you see the crashes (coredumps?) during normal operation or only
when you use Ctrl-C?

If the former please send a backtrace of the crashed process.
If the latter, then please submit a bugzilla entry with the log
messages before and after you used Ctrl-C.

> On Wed, Nov 23, 2005 at 01:12:55PM -0800, Pavlin Radoslavov wrote:
> > Before doing anything, first double-check that the TTL of the data
> > is large enough, because the default multicast TTL is 1.
> 
> Everything is set to 7. The university admin assured that the router in
> question (next hop) drops packets with TTL < 8 on their way out into the
> rest of the university and inside this router (to other dorms)
> everything should work. PS: I doublechecked :)
> 
> > Then check the MFC entries ("show pim mfc") whether there is a
> > matching entry for your PC/sender and the group address for the
> > data that is missing. You could double-check by running the UNIX
> > "cat /proc/net/ip_mr_cache" command to see what exactly is installed
> > in the kernel.
> 
> 224.2.127.254   134.130.49.253  193.174.74.254=20
>     Incoming interface :      eth0
>     Outgoing interfaces:      ..O
> 
> 233.4.251.3     134.130.49.253  193.174.74.254=20
>     Incoming interface :      eth0
>     Outgoing interfaces:      ..O
> 
> FE7F02E0 FD318286 0     408531 74844745        0  2:1 =20
> 03FB04E9 FD318286 0     572670 769668480        0  2:1 =20

The MFC entries look fine (I presume that eth0 is the interface
toward your source). It seems that the special register_vif is
the only oif. This is normal, and all data packets will be
encapsulated and unicast inside PIM Register messages to the RP.
Once the RP receives the Registers, it will decapsulate them and
send them natively (multicast) downstream to all receivers.

> 
>  0 eth0       -16448096 115388480  1249002710  890200 00000 0300120A 000000=
> 00
>  1 eth1       1249701440  895632         0       0 00000 7277E289 00000000
>  2 pimreg            0       0  -846962008 9313618 00004 0300120A 00000000
> 
> So I think FE...E0 which is sap.mcast.net should get routed to eth1,
> which is the external network. Same with my data.

Only if there is PIM Join message (or IGMP Join message) received on
eth1, then the XORP router should forward the data packets on eth1.

> > If there is an entry, check that the iif and the oifs are
> > correct. If they are correct, then run tcpdump on one of the
> > expected outgoing interface and see whether the data is coming out
> > on that interface.
> 
> This is a snippet of typical mcast traffic on the external network. All the=
> se
> 233.4.251.x are streaming (wildly) in the internal network. I requested
> 233.4.251.1 some seconds before that (from the external network).

If you tcpdump all PIM traffic (including unicast), then you should
see the PIM Register messages with your encapsulated data packet.

Then the next thing do check is whether both the SAP announcements
and the application's data are sent by PIM Registers to the (same)
RP, and why only the SAP PIM Registers make it to the RP and down to
the receivers.

<DEL>

> > If there is no MFC entry, then use the "show pim join" command to
> > check what is the status of the corresponding (S,G) entry for this
> > directly connected source.
> 
> All groups in question are in MFC, but some more lines cannot hurt I hope.

Did you have the directly connected sender running when you took the
snapshot below. If yes, then you should have a sender-specific SG
entry as well.

Pavlin

> 
> 224.2.127.254   0.0.0.0         193.174.74.254  WC  =20
>     Upstream interface (RP):   eth1
>     Upstream MRIB next hop (RP): 137.226.119.113
>     Upstream RPF'(*,G):        137.226.119.113
>     Upstream state:            Joined=20
>     Join timer:                39
>     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:        OO.
>     Could assert WC:           O..
>     I am DR:                   OOO
>     Immediate olist RP:        ...
>     Immediate olist WC:        O..
>     Inherited olist SG:        O..
>     Inherited olist SG_RPT:    O..
>     PIM include WC:            O..
> 233.4.251.1     0.0.0.0         193.174.74.254  WC  =20
>     Upstream interface (RP):   eth1
>     Upstream MRIB next hop (RP): 137.226.119.113
>     Upstream RPF'(*,G):        137.226.119.113
>     Upstream state:            Joined=20
>     Join timer:                39
>     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:        OO.
>     Could assert WC:           O..
>     I am DR:                   OOO
>     Immediate olist RP:        ...
>     Immediate olist WC:        O..
>     Inherited olist SG:        O..
>     Inherited olist SG_RPT:    O..
>     PIM include WC:            O..