Subject: Configuring mcast on ciscos w/multiple unicast ISPs

From: "Christopher J. Tengi" <[email-masked]>
Date: Thu, 20 Nov 1997 08:40:34 -0500

We currently have 2 ISP connections for unicast traffic (where routing is 
managed with BGP on a DMZ ethernet), with one of them providing an MBone 
connection using PIM on another ethernet segment:

	----------		----------
	|  GES   |		|  TCG   |
	----------		----------
	 |    |		DMZ	    |
	 |  ============================
	 |	     |
	 |	 ----------
	 |	 | vgate1 |
	 |	 ----------
	 |	     |
	 |        ========= Campus Backbone
	 | MBone   /
	========  /
	    |    /
	----------
	| csgate |
	----------
	 |  |  |
	 /  |  \
	/   |   \
      ===  ===  ===
	CS Subnets

GES is providing our MBone connection via PIM dense-mode on our "MBone" subnet. 
csgate is currently configured with a "router rip" distance sub-command to 
believe default more from the GES router than from vgate1, so that reverse 
paths work.  'ip pim dense-mode' is on for every interface of csgate except 
the campus backbone connection (as we are not yet doing multicast campus-wide).
Dense-mode is also being used on the GES router interface to the "MBone" 
subnet.

What I would *like* to do, is have csgate configured to route unicast packets 
over the campus backbone, so that vgate1, and the 2 ISP routers can figure out 
the best path.  I would also like to have IP multicast traffic flow 
exclusively over the "MBone" subnet, from csgate to the GES router.  Can 
anyone suggest a configuration to try?  I am having some trouble getting to 
the cisco web site right now, so I can't look at the multicast stuff there.

Below are the important bits of the csgate config file.

					/Chris

ip multicast-routing
ip dvmrp route-limit 7000

...

interface Ethernet0/3
 ip address 128.112.200.144 255.255.252.0
 no ip directed-broadcast
 ip pim dense-mode

...

router rip
 network 128.112.0.0
 distribute-list 10 out
 distance 100 128.112.200.254 0.0.0.0 9

...

access-list 9 permit 0.0.0.0
access-list 9 deny   any
access-list 10 permit 0.0.0.0
access-list 10 permit 128.112.168.0
access-list 10 permit 128.112.152.0
access-list 10 permit 128.112.136.0
access-list 10 permit 128.112.104.0
access-list 10 permit 128.112.92.0
access-list 10 permit 128.112.40.0
access-list 10 permit 128.112.4.0

---

From: Beau Williamson <[email-masked]>
Date: Thu, 20 Nov 1997 09:13:30 -0600

Christopher,

It appears that you want to make use of some static "mroutes" on the csgate
router.  Using static mroutes you can tell csgate to RPF to the MBone
interface  for all multicast traffic coming from outside your network and
to RPF using the normal unicast paths for all multicast traffic inside your
network.  This would allow you to remove the administrative distance trick
from your "router rip" (are you really still running RIP???!!) command to
allow your unicast traffic to take optimal paths out.

Check out the write up on static mroutes at:

	ftp://ftp-eng/ipmulticast/Mroutes

Example 3 is pretty close to what you want which is:

        ip mroute 0.0.0.0 0.0.0.0 ospf 109 null0 255
        ip mroute 0.0.0.0 0.0.0.0 tunnel 0

In this example, we assume your cs network is running ospf (process 109) on
"csgate" and the connection to the MBone from "csgate" is via "tunnel 0".
Ordering is important on mroutes so in this case the first line would match
for any sources in your local ospf network and says the RPF interface is
"null0" with a distance of "255".  However, the RPF process would also
check the unicast routing table and also find a match for the source as an
OSPF route with a distance less than "255".  Therefore, the RPF process
would use the OSPF route info to RPF for your source inside your network.
Sources outside your network would fall through and match on the second
line above and RPF to the "tunnel 0" interface.

In your case, you will need to modify the first line to use RIP and the
second to point toward the MBone interface.

Hope this helps.

Beau Williamson

---

From: [email-masked] (Jeremy Hall)
Date: Thu, 20 Nov 1997 10:46:27 -0500 (EST)

If you enable ``ip dvmrp unicast-routing''
on the interfaces, and disable rip, I think you will get better results.
This way, the unicast and multicast routing tables can be different.

In adition, it is important you don't have sources trying to RPF to an
interface that isn't multicast enabled.

_J

---

From: "John M. Zwiebel" <[email-masked]>
Date: Thu, 20 Nov 1997 13:42:06 -0800

If you do this vs Beau's suggestion, you need to be aware of the routes that
will be advertised by default via cisco's DVMRP and also look into how
to generate DVMRP default.

    > connection using PIM on another ethernet segment:

------------------------------------------------------------------------------
	John Zwiebel                       Phone: 408-526-5303
	Cisco Systems Inc.                 
	Multimedia Group                   

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
	Life is sexually transmitted.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=