From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Wed Feb 14 2007 - 11:03:03 ART
If PIM is not enabled on the interface then multicast routing is
not enabled on the interface. This means that if non link-local
multicasts are received (ie not OSPF/EIGRP/RIP) they will simply be
dropped. If multicast routing is enabled, but the RPF check fails,
traffic will be dropped as well.
Try this out on the IOS and look at the "debug ip mpacket"
output. If you don't have access to physical equipment look into
running Dynamips:
http://www.internetworkexpert.com/resources/iosonpc.htm.
HTH,
Brian McGahan, CCIE #8593 (R&S/SP)
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Navin MS
Sent: Tuesday, February 13, 2007 9:48 PM
To: ccielab@groupstudy.com
Subject: RPF check for Dense mode
Hello Folks,
After staying low for sometime, I just picked up working for the Lab
again. While doing one of the
IE Tech Lab exercises, I got confused on the Multicast RPF Failure
Scenario. Can some plz help
3 routers R1, R5 and R6 connected via FastEth
Source----R1--------R5-------R6----Client
Except for the interface on R5 connecting to R1, ALL others are PIM
dense-mode enabled. This
brings me to 2 important Qs.
(1) This may be silly, but is RPF check necessary for Dense-mode
flooding too ?
(2) Since R1 floods the multicast feed regardless of whether R5 is
interested or not, R5 is going
to receive the feed. Now, will the traffic be dropped at R5 or will R5
do an RPF check and flood
again ?
In short, if the incoming multicast interface is not PIM dense-mode
enabled .. but if it still
receives multicast feed, will further flooding happen (assuming RPF
check succeeds) ?
I don't have racktime to test it on .. Appreciate if anybody can help.
Thanks,
Naveen.
This archive was generated by hypermail 2.1.4 : Thu Mar 01 2007 - 07:38:46 ART