Subject: mrouted 3.8 problem.

From: BARRERO MENDIZABAL Luis Marcel <[email-masked]>
Date: Wed, 26 Jun 1996 16:48:01 +0200

Hello,

 It's me again, thanks to Graeme Wood for his comment on my first question.
  Now that I have mrouted running in my SunOS box, another problem appears :-(

  First, here is the network where I'm working:

	+-----+					 +-----+
	| WS2 +-----+ Eth	      Eth +------+ WS1 |
	+-----+	    |			  | 	 +-----+
		    |                     |
	       +----+----+	      +---+---+
	       | Cisco7K |	      | Cisco |
	       +----+----+	      +---+---+
		    |        FDDI         |
		    +---------------------+

  WS1 Is running SunOS4.1.3_U1
  WS2 Is running Solaris 2.3
  Cisco7000 Is running IOS 11.0(9)

  What I want to do is create a tunnel between WS1 and Cisco7K. To do
this, I downloaded mrouted 3.8 and patched the SunOS kernel to add the
MC functions.
  I configured a tunnel between WS1 and Cisco7K:
    In WS1 (mrouted.conf):
	phynt <WS1 IP>
	tunnel <WS1 IP> <Cisco7K IP> metric 1	threshold 8
    In Cisco 7K :
	interface Tunnel0
	ip unnumbered Fddi1/0
	ip mtu 4328
	ip multicast ttl-threshold 8
	tunnel source <Cisco7K IP>
	tunnel destination <WS1 IP>
	tunnel mode dvmrp

   After configure the tunnel, to test if it works I started sd in both
(WS1 and WS2), and created a nv session (with a ttl of 16) in each computer
("UG nv Test 001" in WS1 and "UG nv Tesr 002" in WS2). In sd running on WS2,
I can see both nv announcements, but in the one running in WS1, only the
local one. 

  I started the nv emission in the two workstations, and see if they they
see something. In WS2, I receive very well the emission from WS1, but WS1
can't see anithing comming from WS2. 

  I started tcpdump to see if there were any encapsulated traffic from
the Cisco (tcpdump ip proto 4), and yes, there was a lot coming from the 
Cisco7000 IP, I looked for some multicast traffic (tcpdump ip multicast and
not broadcast), and I can see only some igmp traffic. (*)

  Conclusion: There is a problem with mrouted in WS1 as it does'n desencapsulate
the traffic from Cisco7000.

  As it is the first time I'm working with a Cisco as a tunnel end,
I tried to change the context:

  Using a tunnel between WS1 and WS2 (disabling MC routing in Cisco7000):

  The latest mrouted version I found for Solaris 2.3 is mrouted 2.3 

  I tried to do the same thing (a nv emission in both), and the same results:
WS2 can see WS1 emission, but WS1 can't see nothing from WS2 (not even the
anounce of the session!)

  In both configurations, I also tried an old mrouted (3.5), with the
same results :-(

  Voila!

  A little long, but I don't understand what is happening here. If
anybody can help me...

  Thank you very much in advace.

			Marcel BARRERO.

(*) I'm running tcpdump using the bpf devices, not NIT, so I can see
all the input and output traffic of my ethernet interface.

PS. Is there any problem today with the sauce.uio.no site? I can't reach him
    If there is another site where I can follow this list, thanks to send me
    the address.

---

From: "John M. Zwiebel" <[email-masked]>
Date: Wed, 26 Jun 1996 14:18:41 -0700

Marcel, 

There are a number of possibilities but most of the time the problem is
in doing RPF lookups.  I would guess that you are trying to experiment with
the DVMRP tunnel otherwise you would be running PIM natively on both of
your ciscos.  You might want to try that to see if that works.

I suggest you read ftp://ftpeng.cisco.com/ipmulitcast/DVMRP.metric.cmd which
explains how the cisco summarizes routes that are advertised to WS1.  Depending
on the ip addresses you are using, you may not be advertising the routes you
think you are.  "sh ip dvmrp route" on the cisco and "kill -USR1 <mrouted.pid>"
the output shows up in /tmp/mrouted.dump, on WS1.

mrouted 3.8 works just fine with IOS 11.0(9) so your problem is a routing
and/or configuration problem.

You might also want to try pinging rather than starting up nv.  Your problem
could be that nv isn't working on your workstations.

Other commands on the router to look at and understand include:
	sh ip mr -- are your sources showing up?
	sh ip mr count -- look for RPF failures
	sh ip rpf -- where does the router expect the source to be
	sh ip igmp gr -- is WS2 answering IGMP queries?  There's a rumor
				that Solaris doesn't.  You can work around
				this by having the router join the group.
	sh ip pim neigh -- are you running PIM on both cisco's?
	sh ip igmp int -- do you see a dvmrp neighbor
	sh ip mcache -- is fastswitching working.

z

---

From: "H. J. Shin" <[email-masked]>
Date: Thu, 27 Jun 1996 17:41:02 +0900 (KST)

We(Korea Telecom) have a same problem.
We have tried several network configuration.  
>   First, here is the network where I'm working:
Now we have same network except that WS1 & WS2 are running Solaris 2.5.
> 	tunnel destination <WS1 IP>

Our configuration is very similar upper.  

interface Tunnel7
 ip unnumbered Ethernet0/0
 ip mtu 4328
 ip pim dense-mode
 ip dvmrp unicast-routing
 ip sd listen
 tunnel source 168.126.58.254
 tunnel destination 168.126.63.9
 tunnel mode dvmrp
!
interface Ethernet0/0
 ip address 168.126.58.254 255.255.255.0
 ip pim dense-mode
 ip dvmrp unicast-routing
 ip sd listen
!

> ("UG nv Test 001" in WS1 aWe make a tunnel between WS1nd "UG nv Tesr 002" in WS2). In sd running on WS2,
We have same problem. 
When we did mtrace from WS1 to WS2, we have the result like as...
<-----
the ip of WS1 is 168.126.63.9 and the ip of WS2 168.126.58.4
mtrace 168.126.58.4
Mtrace from 168.126.58.4 to 168.126.63.9 via group 224.2.0.1
Querying full reverse path... 
  0  gopher.kornet.nm.kr (168.126.63.9)
 -1  gopher.kornet.nm.kr (168.126.63.9)  DVMRP  thresh^ 1  
 -2  ? (168.126.58.254)  DVMRP  thresh^ 0  Wrong interface
Round trip time 37 ms

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

  Source        Response Dest    Packet Statistics For     Only For Traffic
   * * *        168.126.63.9     All Multicast Traffic     From 168.126.58.4
     v       __/  rtt   19 ms    Lost/Sent = Pct  Rate       To 224.2.0.1
168.126.58.254  ?              Wrong interface
     v     ^      ttl    0        0/0    = --%   0 pps     0/0    = --%   0 pps
168.126.63.9    gopher.kornet.nm.kr 
     v      \__   ttl    1          5645       564 pps       0            0 pps
168.126.63.9    168.126.63.9
  Receiver      Query Source
---->
When we did mtrace from WS2 to WS1,  no problem. 
When we make a tunnel between WS1 and WS2, we have no problem.
We should solve this problem as soon as possible.
We tried almost configuration command for Cisco 7K.
Please, Help.
Thanks in advance. 

-- 
      //\\\         Internet Team 
     * o o *        Korea Telecom Multimedia Research Lab. 
       -           17 Woomyeon-dong, Seocho-ku, Seoul 137-140, KOREA     
 Shin, Hyo-Jeong    Voice: +82-2-526-6761    Fax: +82-2-526-6942

---

From: "H. J. Shin" <[email-masked]>
Date: Thu, 27 Jun 1996 21:22:21 +0900 (KST)

> and/or configuration problem.

I think this problem is due to IOS.
We(including me, KORNET network admin) have many experience regarding routing
and have tried almost configuration to Cisco router.
We wanna more concrete answer. 
Thanks.

---

From: dave pratt <[email-masked]>
Date: Thu, 27 Jun 1996 16:06:13 +0100 (BST)

Dear mone community,

I think we may be having similar problems, which may well be linked to the
statement below which was not addressed by John directly:

->  > Conclusion: There is a problem with mrouted in WS1 as it does'nt
->  > deencapsulate the traffic from Cisco7000.

We have a tunnel (which incidentally leads to a machine within our routed
domain so there are unicast routes) which can send but not recieve mcast
traffic. Yet show interface indicates mcast traffic IS going out to this
leaf Mrouted node, but not being recieved by the mrouted.

Cheers
-------- 
The views expressed here may or may not be my own.
WWW - doesn't that stand for "Wait a Week Word" ?
Dave Pratt      (tel: +44 1473 643840 )
[email-masked]

On Wed, 26 Jun 1996, John M. Zwiebel wrote:

->Date: Wed, 26 Jun 1996 14:18:41 -0700
->From: "John M. Zwiebel" <[email-masked]>
->To: BARRERO MENDIZABAL Luis Marcel <[email-masked]>
->Cc: [email-masked]
->Subject: Re: mrouted 3.8 problem.
->
->
->Marcel, 
->
->There are a number of possibilities but most of the time the problem is
->in doing RPF lookups.  I would guess that you are trying to experiment with
->the DVMRP tunnel otherwise you would be running PIM natively on both of
->your ciscos.  You might want to try that to see if that works.
->
->I suggest you read ftp://ftpeng.cisco.com/ipmulitcast/DVMRP.metric.cmd which
->explains how the cisco summarizes routes that are advertised to WS1.  Depending
->on the ip addresses you are using, you may not be advertising the routes you
->think you are.  "sh ip dvmrp route" on the cisco and "kill -USR1 <mrouted.pid>"
->the output shows up in /tmp/mrouted.dump, on WS1.
->
->mrouted 3.8 works just fine with IOS 11.0(9) so your problem is a routing
->and/or configuration problem.
->
->You might also want to try pinging rather than starting up nv.  Your problem
->could be that nv isn't working on your workstations.
->
->Other commands on the router to look at and understand include:
->	sh ip mr -- are your sources showing up?
->	sh ip mr count -- look for RPF failures
->	sh ip rpf -- where does the router expect the source to be
->	sh ip igmp gr -- is WS2 answering IGMP queries?  There's a rumor
->				that Solaris doesn't.  You can work around
->				this by having the router join the group.
->	sh ip pim neigh -- are you running PIM on both cisco's?
->	sh ip igmp int -- do you see a dvmrp neighbor
->	sh ip mcache -- is fastswitching working.
->
->z
->
->
->  >  Hello,
->  >
->  > It's me again, thanks to Graeme Wood for his comment on my first question.
->  >  Now that I have mrouted running in my SunOS box, another problem appears :
->-(
->  >
->  >  First, here is the network where I'm working:
->  >
->  >	+-----+					 +-----+
->  >	| WS2 +-----+ Eth	      Eth +------+ WS1 |
->  >	+-----+	    |			  | 	 +-----+
->  >		    |                     |
->  >	       +----+----+	      +---+---+
->  >	       | Cisco7K |	      | Cisco |
->  >	       +----+----+	      +---+---+
->  >		    |        FDDI         |
->  >		    +---------------------+
->  >
->  >  WS1 Is running SunOS4.1.3_U1
->  >  WS2 Is running Solaris 2.3
->  >  Cisco7000 Is running IOS 11.0(9)
->  >
->  >
->  >  What I want to do is create a tunnel between WS1 and Cisco7K. To do
->  >this, I downloaded mrouted 3.8 and patched the SunOS kernel to add the
->  >MC functions.
->  >  I configured a tunnel between WS1 and Cisco7K:
->  >    In WS1 (mrouted.conf):
->  >	phynt <WS1 IP>
->  >	tunnel <WS1 IP> <Cisco7K IP> metric 1	threshold 8
->  >    In Cisco 7K :
->  >	interface Tunnel0
->  >	ip unnumbered Fddi1/0
->  >	ip mtu 4328
->  >	ip multicast ttl-threshold 8
->  >	tunnel source <Cisco7K IP>
->  >	tunnel destination <WS1 IP>
->  >	tunnel mode dvmrp
->  >
->  >   After configure the tunnel, to test if it works I started sd in both
->  >(WS1 and WS2), and created a nv session (with a ttl of 16) in each computer
->  >("UG nv Test 001" in WS1 and "UG nv Tesr 002" in WS2). In sd running on WS2,
->  >I can see both nv announcements, but in the one running in WS1, only the
->  >local one. 
->  >
->  >  I started the nv emission in the two workstations, and see if they they
->  >see something. In WS2, I receive very well the emission from WS1, but WS1
->  >can't see anithing comming from WS2. 
->  >
->  >  I started tcpdump to see if there were any encapsulated traffic from
->  >the Cisco (tcpdump ip proto 4), and yes, there was a lot coming from the 
->  >Cisco7000 IP, I looked for some multicast traffic (tcpdump ip multicast and
->  >not broadcast), and I can see only some igmp traffic. (*)
->  >
->  >  Conclusion: There is a problem with mrouted in WS1 as it does'n desencapsu
->late
->  >the traffic from Cisco7000.
->  >
->  >  As it is the first time I'm working with a Cisco as a tunnel end,
->  >I tried to change the context:
->  >
->  >  Using a tunnel between WS1 and WS2 (disabling MC routing in Cisco7000):
->  >
->  >  The latest mrouted version I found for Solaris 2.3 is mrouted 2.3 
->  >
->  >  I tried to do the same thing (a nv emission in both), and the same results
->:
->  >WS2 can see WS1 emission, but WS1 can't see nothing from WS2 (not even the
->  >anounce of the session!)
->  >
->  >  In both configurations, I also tried an old mrouted (3.5), with the
->  >same results :-(
->  >
->  >  Voila!
->  >
->  >  A little long, but I don't understand what is happening here. If
->  >anybody can help me...
->  >
->  >  Thank you very much in advace.
->  >
->  >
->  >
->  >			Marcel BARRERO.
->  >
->  >
->  >(*) I'm running tcpdump using the bpf devices, not NIT, so I can see
->  >all the input and output traffic of my ethernet interface.
->  >
->  >PS. Is there any problem today with the sauce.uio.no site? I can't reach him
->  >    If there is another site where I can follow this list, thanks to send me
->  >    the address.
->

---

From: BARRERO MENDIZABAL Luis Marcel <[email-masked]>
Date: Thu, 27 Jun 1996 17:50:59 +0200

Hi,

  Thaks for your comments, 

:)There are a number of possibilities but most of the time the problem is
:)in doing RPF lookups.  I would guess that you are trying to experiment with
:)the DVMRP tunnel otherwise you would be running PIM natively on both of
:)your ciscos.  You might want to try that to see if that works.

 Using PIM in both of the CISCO routers, everything goes well, but as you say
what I want to do is to know better how does the tunnel work, and later ask
for a MBONE tunnel to the Cisco7000. For this test, I'm working in a "Multicast
closed" environment.

:)
:)I suggest you read ftp://ftpeng.cisco.com/ipmulitcast/DVMRP.metric.cmd which

  I tried, but maybe they changed the place of the document. Even the
ipmulticast directory is not there. (At least with an anonymous ftp). 

  But the problem (as I explained in the second half of my mail), is that
WS1 doesn't see any multicast traffic even if in it's Ethernet we
can see the encapsulated trafic from WS2 over the tunnel (with tcpdump).
 
  So, as we can see with tcpdump the encapsulated traffic in the WS1
ethernet, I don't think that it's a RPF problem. As far as I see, the Cisco
works as expected, it's the mrouted in WS1 that have a problem. Could it be
a RPF problem in mrouted? As the encapsulated comes from le0, mrouted doesn't
feed this output interface...

:)explains how the cisco summarizes routes that are advertised to WS1.  Depending
:)on the ip addresses you are using, you may not be advertising the routes you
:)think you are.  "sh ip dvmrp route" on the cisco and "kill -USR1 <mrouted.pid>"
:)the output shows up in /tmp/mrouted.dump, on WS1.

 In the mrouted.dump file of WS1 (mrouted3.8), I can see that there are 
some MC pkts. going outside the interface, but no one comming inside. Same
numbers in the tunnel vif:

Virtual Interface Table
Vif  Name  Local-Address                               M  Thr  Rate   Flags
 0    le0  129.194.89.101  subnet: 129.194.88/22       1   1      0   querier leaf
                           groups: 224.2.127.255  
                                   224.2.251.116  
                         pkts in : 0
                         pkts out: 328

 1    le0  129.194.89.101  tunnel: 192.80.31.130       1   8    500   leaf
                            peers: 192.80.31.130 (2.2) (0x0)
                         pkts in : 0
                         pkts out: 328

Multicast Routing Table (2 entries)
 Origin-Subnet      From-Gateway    Metric Tmr In-Vif  Out-Vifs
 192.80.31.128/26   192.80.31.130      2     0   1    0*
 129.194.88/22                         1   165   0    1 

  The mrouted.dump file on WS2 (mrouted 2.3), doesn't show me the number of
pkts. But i can see:

Virtual Interface Table
 Vif  Local-Address                           Metric  Thresh  Flags
  0   192.80.31.130   subnet: 192.80.31.128      1       1    querier
                      groups: 224.2.251.116  
                              224.2.127.255  
  1   192.80.31.130   tunnel: 129.194.89.101     1       8   
                      peers : 129.194.89.101 

Multicast Routing Table (2 entries)
 Origin-Subnet   From-Gateway    Metric  In-Vif  Out-Vifs
 129.194.88      129.194.89.101     2       1    0*
 192.80.31.128                      1       0    1 

  An execution of mrinfo in WS1:
127.0.0.1 (localhost.unige.ch) [version 3.8,prune,genid,mtrace]:
  129.194.89.101 -> 0.0.0.0 (local) [1/1/querier/leaf]
  129.194.89.101 -> 192.80.31.130 (192.80.31.130) [1/8/tunnel/leaf]

  An execution of mrinfo in WS2:
127.0.0.1 (localhost) [version 2.2]:
  192.80.31.130 -> 0.0.0.0 (local) [1/1/querier]
  192.80.31.130 -> 129.194.89.101 (mbonesun1.unige.ch) [1/8/tunnel]

:)
:)mrouted 3.8 works just fine with IOS 11.0(9) so your problem is a routing
:)and/or configuration problem.

  It's maybe a config error, but where? I'm not using the Cisco7000. Before
to go to the Cisco I want to have my tunnel end in WS1 working ok. So I'm
just working with a tunnel between WS1 and WS2. (Without using MC properties
of both of our Ciscos).
 
:)
:)You might also want to try pinging rather than starting up nv.  Your problem
:)could be that nv isn't working on your workstations.

  Yes, nv is working well. In both WS I begin a nv emission. WS1 can
see it's own emission (normal), and WS2 can see both: the one he is sending
and the on e coming from WS1. So nv works properly.

:)
:)Other commands on the router to look at and understand include:
:)	sh ip mr -- are your sources showing up?
:)	sh ip mr count -- look for RPF failures
:)	sh ip rpf -- where does the router expect the source to be
:)	sh ip igmp gr -- is WS2 answering IGMP queries?  There's a rumor
:)				that Solaris doesn't.  You can work around
:)				this by having the router join the group.
:)	sh ip pim neigh -- are you running PIM on both cisco's?
:)	sh ip igmp int -- do you see a dvmrp neighbor
:)	sh ip mcache -- is fastswitching working.
:)

  This are Cisco commands. I'll see them, but as the problem remains there
when the Cisco7000 is used as a normal unicast router (without a tunnel
configured on), I don't think it will help in solving my problem :-(
 
  But, re there some similar commands to see what's happening with mrouted?

   Thanks again....

				Marcel BARRERO.

PS. I tried with mrouted binaires I found in the net, and I also tried
    with binairies compiled by myself.

---

From: "John M. Zwiebel" <[email-masked]>
Date: Thu, 27 Jun 1996 11:20:40 -0700

>We wanna more concrete answer. 

	We would be happy to provide one.  However, this map and the
	configurations that were provided are not adequate for giving
	an answer that will explain what is going on.

	IOS to mrouted tunnels are working in too many locations to
	arbitrarily say that either one is at fault.  I believe there
	is some important configuration and topology information that is 
	not being included in the problem descriptions.

	Please direct these questions to "[email-masked]".

	There is a lot of documentation on PIM and DVMRP available at
	ftp://ftp/ipmulticast.html

	Note that the file "Quickstart-dvmrp" assumes a very simple
	topology where a PIM cloud is a stub off of the MBONE.  Most of
	the problems that have been directed to this list seem to require
	transit of DVMRP routes through a PIM cloud or having the 
	DVMRP tunnel terminate inside the PIM cloud rather than on the
	boundry so you are guaranteed to have RPF lookup failures.

	Also, when an RPF check is done on a cisco, it looks in the DVMRP
	table _and_ in the unicast routing table.  Which RPF wins depends
	on the configuration you place on the cisco.  DVMRP will win by
	default. 

	z

---

From: Bill Fenner <[email-masked]>
Date: Thu, 27 Jun 1996 12:26:09 PDT

>->  > deencapsulate the traffic from Cisco7000.

I think that problems like this are usually related to insufficient routing
information being provided by the Cisco.  In two of the situations that
wre recently posted, it sounds like people are trying to have a DVMRP/mrouted
stub off of a PIM cloud.  If your DVMRP cloud (or single machine) will be
a *stub* and has no other connections to the MBone, you want to use the

ip dvmrp default-information originate only

command on the tunnel to your mrouted, and make sure that the mrouted is
version 3.8 .  If the mrouted has no routes, then it will decapsulate
traffic and then drop it on the floor, so you have to get your Cisco to
supply it with routes.  The default route works well in this situation.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 27 Jun 1996 12:34:37 PDT

>				this by having the router join the group.

Spreading rumors like this doesn't help anyone.  You should either
find out from an authoritative source that it is true or stop
spreading the rumor.

I have personally seen an IGMP report generated by a Solaris box, so I
can state that the generalization above is definitely not true.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 27 Jun 1996 14:47:11 PDT

In message <1094*/S=barrero/OU=cui/O=unige/PRMD=switch/ADMD=400net/C=ch/@MHS> y

If you do a "kill -USR1 `cat /etc/mrouted.pid`" on both WS1 and WS2, do
you see the tunnel as being up in the top section of the /usr/tmp/mrouted.dump
file?  Do you see the same routes in the second section of both 
/usr/tmp/mrouted.dump files?  If you "kill -USR2 `cat /etc/mrouted.pid`" on WS1
(2.2 doesn't support USR2) do you see any entries that look like they
apply to the traffic you are sourcing from WS2?  If you run "netstat -Ms",
do any of the error counters look high?

Did you fully patch the SunOS kernel?  If you missed the patch for
in_proto.c, encapsulated packets will just get ignored.  I've seen this
at least once before.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 27 Jun 1996 14:54:39 PDT

Apologies for missing the fact that you had posted more info -- I'm reading
email from the IETF without my usual pretty GUI =)

In message <1096*/S=barrero/OU=cui/O=unige/PRMD=switch/ADMD=400net/C=ch/@MHS> y
> 0    le0  129.194.89.101  subnet: 129.194.88/22       1   1      0   querier 

The "pkts in: 0" on the tunnel when you see packets when using tcpdump means
either one of two things:

- The tunnel is misconfigured in some way, in which case netstat -Ms will
have a very high number of "datagrams with malformed tunnel options"
- The kernel patching failed as I described in my last message, in which
case netstat -Ms will probably print out mostly zeros and you should
check your kernel.

  Bill

---

From: "H. J. Shin" <[email-masked]>
Date: Sat, 29 Jun 1996 10:46:38 +0900 (KST)

We successfully set MBONE on cisco 7000 and Workstations. 
My fellow(Kim hyungsuk, [email-masked]) make original setting and 
cisco engineer helped us.    
I will explain our configuration.

WS1 : running Solaris 2.4 
WS2 : running Solaris 2.5
Cisco 7000 : running IOS 11.0(9)

Our previous configutaion...
>  ip address 168.126.58.254 255.255.255.0

Our new configuation...

interface Tunnel3
 ip unnumbered Ethernet0/0
 ip mtu 4328
 ip pim dense-mode
 ip dvmrp metric 1                  * newly inserted
 ip dvmrp accept-filter 79 210      * newly inserted
 bandwidth 500                      * newly inserted
 tunnel source Ethernet0/0
 tunnel destination 168.126.63.9
 tunnel mode dvmrp
!
interface Ethernet0/0
 ip address 203.234.255.193 255.255.255.224 secondary
 ip address 203.234.254.254 255.255.255.0
 ip pim dense-mode
 ip sd listen

ip mroute 0.0.0.0 0.0.0.0 Tunnel3 2               * newly inserted
ip mroute 168.126.63.0 255.255.255.0 Tunnel3      * newly inserted
access-list 79 deny   0.0.0.0
access-list 79 permit any

And...
We make a tunnel between WS1(168.128.63.9) and Ehternet0/0 of Cisco 7000.
That's all and our configuration works well.

But....
We have two question.
1. currently WS2 has no channel but WS2 or Cisco 7000 will connect Internet 1996
World Exposition. In that case, how do we configure 'ip mroute' ?    

2. Perfomance
We thought If we use 'router' for setting MBONE then we get better performance 
(for example video & audio quality ...)compared with using 'only hosts'.  
Now, we can't find any difference between two.  

thanks.