Subject: [Q] Priority Scheme in Mrouted

From: Sanku Jo <[email-masked]>
Date: Sat, 13 Dec 1997 00:04:00 -0600 (CST)

Howdy !

I have used the priority scheme in mrouted using different port numbers 
according the medium type of session.

I am now testing the performance of priority scheme in mrouted.
And I hope to try to hack this function.
But, I have not found any detail referece.
Is there anyone who has some technical information about it ?

Any comment will be very appreciated.

Thank you !

Best regards,
Jo, SanKu

PS. I am now using moruted in FreeBSD box.

---

From: Alfonso Gazo <[email-masked]>
Date: Mon, 15 Dec 1997 18:43:07 +0100

Hello all,

        I'm trying to stablish a local multicast tunnel between two subnets connected through unicast routers.

        This is my scheme:

        +-----+------------------+-------+   158.49.135.0
             |                  |
          +--+--+          +----+---+
          |     |          |puesto19| 158.49.135.20
          +--+--+          +--------+
             |
       +-----+--------------------------+   158.49.133.0
             |
          +--+--+
          |     |
          +--+--+
             |
       +-----+------------------+-------+   158.49.137.0
                                |
                             +--+--+
                             |aula | 158.49.137.74
                             +-----+

        I'm trying to stablish a tunnel between 'puesto19' and 'aula'. They're both running RedHat 4.2, kernel 2.0.30, mrouted 3.8.

        This is the result of mtrace 158.49.137.74 on 'puest19':

Mtrace from 158.49.137.74 to 158.49.135.20 via group 224.2.0.1
Querying full reverse path...
  0  puesto19.unex.es (158.49.135.20)
 -1  puesto19.unex.es (158.49.135.20)  DVMRP  thresh^ 1
 -2  ? (158.49.137.74)  DVMRP  thresh^ 1
 -3  ? (158.49.137.74)
Round trip time 4 ms

Waiting to accumulate statistics... Results after 10 seconds:

  Source        Response Dest    Packet Statistics For     Only For Traffic
158.49.137.74   158.49.135.20    All Multicast Traffic     From 158.49.137.74
     v       __/  rtt    3 ms    Lost/Sent = Pct  Rate       To 224.2.0.1
158.49.137.74   ?
     v     ^      ttl    1
158.49.135.20   puesto19.unex.es
     v      \__   ttl    2
158.49.135.20   158.49.135.20
  Receiver      Query Source

        This is the result of mtrace 158.49.137.74 on 'aula':

Mtrace from 158.49.135.20 to 158.49.137.74 via group 224.2.0.1
Querying full reverse path...
  0  aula.unex.es (158.49.137.74)
 -1  aula.unex.es (158.49.137.74)  DVMRP  thresh^ 1
 -2  puesto19.unex.es (158.49.135.20)  DVMRP  thresh^ 1
 -3  puesto19.unex.es (158.49.135.20)
Round trip time 3 ms

Waiting to accumulate statistics... Results after 10 seconds:

  Source        Response Dest    Packet Statistics For     Only For Traffic
158.49.135.20   158.49.137.74    All Multicast Traffic     From 158.49.135.20
     v       __/  rtt   27 ms    Lost/Sent = Pct  Rate       To 224.2.0.1
158.49.135.20   puesto19.unex.es
     v     ^      ttl    1
158.49.137.74   aula.unex.es
     v      \__   ttl    2
158.49.137.74   158.49.137.74
  Receiver      Query Source

        I think that all seems to be right, but when I can't see SDR sessions created on 'aula' from 'puesto19', and viceversa. SDR works right on the local nets (i.e. on the machines connected to the subnet), but the tunnels don't seem to work.

        What could I do? Could I do some other tests?

        Thanks in advance,

_______________________________________________________________

  Alfonso Gazo

  (HTML Mail)
  mailto:[email-masked]
  mailto:[email-masked]

  Home Phone: 34-27-241987
  Work Phone: 34-27-236653
_______________________________________________________________

---

From: Bill Fenner <[email-masked]>
Date: Fri, 19 Dec 1997 09:09:34 PST

Alfonso Gazo <[email-masked]> wrote:
>        I think that all seems to be right, but when I can't see SDR sessions 
>  created on 'aula' from 'puesto19', and viceversa. SDR works right on the loc
>  al nets (i.e. on the machines connected to the subnet), but the tunnels don'
>  t seem to work.
>

I've heard many complaints like this, so I downloaded the 2.1.72 Linux
kernel and checked it out.  I didn't have time to try to understand the
whole architecture, so I might be way off base, but it looks like packets
output by a multicast router might only be forwarded over the tunnel if
IP_MULTICAST_LOOP is set.  Most of the existing MBone applications turn it
off, which could explain why you're not seeing anything happen over the
tunnel.

In order to test out this theory, the easiest thing is to use "vat" in
the following way:

- Put the following in ~/.vat.tcl on each system
proc user_hook {} {
	global V
	$V(ctrl-net) loopback 1
	$V(data-net) loopback 1
}
- Run "vat -t 2 224.2.0.1/23456" on each system, and see if you see both
systems in the participant listing.

vat won't work very well with these values set, but the participant window
will work.  If this fixes it, then it probably makes sense to report the
bug to the Linux networking team.

  Bill