Subject: Re: mrouted 3.8 problem.

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

I changed some cofiguration and I experienced another problem.
> 
> 
> We(Korea Telecom) have a same problem.
> We have tried several network configuration.  
> > 
> >   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)
> Now we have same network except that WS1 & WS2 are running Solaris 2.5.
> > 
> > 
> >   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
> 
> 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
> !
> 
> 

our new  configuration

interface Tunnel3
 ip unnumbered Ethernet0/0
 ip mtu 4328
 ip pim dense-mode
 ip dvmrp unicast-routing
 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
!

> > 
> >    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 aWe make a tunnel between WS1nd "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. 
> 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. 

we got another result from mtrace 

./mtrace 203.234.254.4
Mtrace from 203.234.254.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  ? (203.234.254.254)  DVMRP  thresh^ 0  Prune sent upstream
Round trip time 12 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 203.234.254.4
     v       __/  rtt   31 ms    Lost/Sent = Pct  Rate       To 224.2.0.1
203.234.254.254 ?              Prune sent upstream
     v     ^      ttl    0        0/0    = --%   0 pps     0/0    = --%   0 pps
168.126.63.9    gopher.kornet.nm.kr 
     v      \__   ttl    1          868         86 pps       0            0 pps
168.126.63.9    168.126.63.9
  Receiver      Query Source

We experience WS1 get data from WS2 temporarily and date disappear. 

> 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. 
> > 
> >   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.
> > 
> 
> 
> -- 
>       //\\\         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
> 
> 

-- 
      //\\\         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: Bill Fenner <[email-masked]>
Date: Thu, 27 Jun 1996 12:29:53 PDT

>>  -2  ? (168.126.58.254)  DVMRP  thresh^ 0  Wrong interface

This looks like an RPF problem on the Cisco; perhaps it
is configured to use the wrong routing table to RPF to.

> -2  ? (203.234.254.254)  DVMRP  thresh^ 0  Prune sent upstream

This is a bug in Cisco's mtrace implementation; it claimed to have sent
a prune upstream but also claimed that it was the last-hop router for the
source, in which case there's no upstream to send a prune to!

  Bill