From: Michael Zuo (mzuo@ixiacom.com)
Date: Tue Nov 21 2006 - 03:16:50 ART
Thank you all :)
-----Original Message-----
From: Alexei Monastyrnyi [mailto:alexeim@orcsoftware.com]
Sent: Friday, November 17, 2006 1:41 AM
To: Michael Zuo
Cc: ccielab@groupstudy.com
Subject: Re: mroute needed for dense mode?
Hi.
1.
Configuring mroutes makes sense if you have underlaying unicast
IGP/static route pointing to different interface towards your mcast
source host rather than path through your multicast-enabled interfaces.
A kind of good example would be to set up two static defaults on R1 and
R2 pointing to each other and use mtrace on R2 to actually check RPF.
R1(config-if)#ip route 0.0.0.0 0.0.0.0 150.1.12.2
R2(config-if)#ip route 0.0.0.0 0.0.0.0 150.1.12.1
R2#mtrace 150.1.23.2 150.1.14.1 239.1.1.1
Type escape sequence to abort.
Mtrace from 150.1.23.2 to 150.1.14.1 via group 239.1.1.1
From source (?) to destination (?)
Querying full reverse path...
0 150.1.14.1
-1 10.0.0.1 None No route
R1(config)#ip mroute 0.0.0.0 0.0.0.0 tu 0
R2#mtrace 150.1.23.2 150.1.14.1 239.1.1.1
Type escape sequence to abort.
Mtrace from 150.1.23.2 to 150.1.14.1 via group 239.1.1.1
From source (?) to destination (?)
Querying full reverse path...
0 150.1.14.1
-1 10.0.0.1 PIM/Static [default]
-2 10.0.0.2 PIM [150.1.23.0/24]
-3 150.1.23.2
2.
I think it is always a nearest PIM-enabled interface which responds. It
is PIM join-prone communications happening here, they are all TTL=1
(link-local), so your R1 e0/1 has no chances to show up there.
When pinging you will see this entry on R1, with no signs of source
interface you set in your ping request.
(10.0.0.2, 239.1.1.1), 00:00:04/00:02:55, flags: LT
Incoming interface: Tunnel0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Dense, 00:00:05/00:00:00
HTH
A.
Michael Zuo wrote:
> Hi Group,
>
>
>
> I have a couple of possible stupid questions: if I have:
>
>
>
> R1--------------------------------------------------------R2
>
>
>
> e0/1 e0/0 150.1.12.x/24 e0/0 e0/1
>
>
>
>
>
>
>
> R1:
>
>
>
> interface Tunnel0
>
> ip address 10.0.0.1 255.0.0.0
>
> ip pim dense-mode
>
> tunnel source Ethernet0/0
>
> tunnel destination 150.1.12.2
>
> !
>
> interface Ethernet0/0
>
> ip address 150.1.12.1 255.255.255.0
>
> !
>
> interface Ethernet0/1
>
> ip address 150.1.14.1 255.255.255.0
>
> ip pim dense-mode
>
> ip igmp join-group 239.1.1.1
>
>
>
>
>
> R2:
>
>
>
> interface Tunnel0
>
> ip address 10.0.0.2 255.0.0.0
>
> ip pim dense-mode
>
> tunnel source Ethernet0/0
>
> tunnel destination 150.1.12.1
>
> !
>
> interface Ethernet0/0
>
> ip address 150.1.12.2 255.255.255.0
>
> !
>
> interface Ethernet0/1
>
> ip address 150.1.23.2 255.255.255.0
>
> ip pim dense-mode
>
>
>
>
>
> Rack1R2(config-if)#do ping 239.1.1.1 source e0/1
>
>
>
> Type escape sequence to abort.
>
> Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
>
> Packet sent with a source address of 150.1.23.2
>
>
>
> Reply to request 0 from 10.0.0.1, 108 ms
>
>
>
> My questions are:
>
> 1. for R1's e0/1 to talk to R2's e0/1 via multicast dense mode, do I
> need "ip mroute 0.0.0.0 0.0.0.0 tunnel 0" configured on both routers?
> (ie, does dense mode do RPF checks. In my mind, it should not because
> the router should just forward dense mode packets to all the
interfaces
> that it did not come in on)
>
> 2. how come 10.0.0.1 is responding but not e0/1 on R1?
>
>
>
>
>
> Thanks for your help...
>
>
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART