From: Jonathan Greenwood II (gwood83@gmail.com)
Date: Thu Jan 15 2009 - 03:47:06 ARST
Agreed on not being a problem solver unless being asked for in the exam of
course but more as a feature to optimize your PIM SM domain in my opinion
based upon certain requirements or specifications.
HTH
Jonathan
On Wed, Jan 14, 2009 at 9:23 PM, Hobbs <deadheadblues@gmail.com> wrote:
> Thanks Jonathon. What I am trying to do is find a scenario where PIM-SIM
> doesn't work and BIDIR PIM fixes it. But maybe BIDIR PIM isn't a problem
> solver, just a design method...
>
>
> On Wed, Jan 14, 2009 at 10:18 PM, Jonathan Greenwood II <gwood83@gmail.com
> > wrote:
>
>> I don't think bidirectional PIM is based upon the topology but more so
>> what are you trying to achieve like whether or not to allow certain
>> routers/switches to be able to install S,G entries from a particular source
>> or to prevent unicast PIM register messages being sent to a router/switch
>> from a particular source. In regards to your statement in relation to PIM
>> SM this is direct from the DocCD
>>
>> "For packets that are forwarded downstream from the RP toward receivers,
>> there are no fundamental differences between bidir-PIM and PIM-SM. Bidir-PIM
>> deviates substantially from PIM-SM for traffic that is passed from sources
>> upstream toward the RP. "
>>
>>
>> http://cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_basic_cfg_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1054929
>>
>> HTH
>>
>> Jonathan
>>
>> On Wed, Jan 14, 2009 at 2:50 PM, Hobbs <deadheadblues@gmail.com> wrote:
>>
>>> hello,
>>>
>>> I am trying to learn more about bidirectional PIM but no matter what type
>>> of
>>> lab topology I come up with, multicast works anyway. Anyone know a good
>>> topology I can configure where multicast would fail unless you enable
>>> bidir
>>> pim?
>>>
>>> The topology I use right now has this (copied from doccd config guide)
>>>
>>> R1 (Receiver) ---- R2 ---- R3 (RP) ----- R4 ----- R5 ----- R6 (Sender)
>>> |
>>> |
>>> R7----- R8
>>> (Receiver)
>>>
>>> If you cant see the topology correctly R4 is where the split to R7
>>> happens.
>>> R1 and R8 are receivers
>>> R3 is the RP
>>> R6 is the sender.
>>> All interfaces are PIM-SM, Autorp listener everywhere
>>>
>>> Even with this setup, R4 will accept (S,G) incoming from R5, forward it
>>> to
>>> R3, then accept (*,G) on that same interface from R3 to forward it out
>>> R7/R8. I always thought this could not happen. I have disabled the
>>> SPT-switchover (ip pim spt-threshold infinity).
>>>
>>> R4#sho ip mroute 225.0.0.1 | begin \(\*
>>> (*, 225.0.0.1), 00:12:10/00:03:08, RP 3.3.3.3, flags: S
>>> Incoming interface: Serial1/0, RPF nbr 192.168.34.3
>>> Outgoing interface list:
>>> Serial1/1, Forward/Sparse, 00:12:10/00:03:08
>>>
>>> (192.168.56.6, 225.0.0.1), 00:00:22/00:03:21, flags: T
>>> Incoming interface: Serial1/2, RPF nbr 192.168.45.5
>>> Outgoing interface list:
>>> Serial1/0, Forward/Sparse, 00:00:22/00:03:09, A
>>> Serial1/1, Forward/Sparse, 00:00:22/00:03:08
>>>
>>> On R4:
>>>
>>> s1/0 = R3
>>> s1/1 = R7
>>> s1/2 = R5
>>>
>>> thanks,
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:38 ARST