Re: multicast registration process

Ok here's my take

Your

R4 s1/1 ---- s1/1 R5 (where R5 is DR due to highest ip address)

So R4 cannot register the Join to the R5 lo0 RP

Hence why the source is unicasting the join as it's the DR of the segment and
the source, the reason it goes over s1/0 is twofold

You have OSPF running over both serials, so by the time the multicast is
encapsulated i.e

d:224.1.2.4 s:155.1.146.6
is then effectively tunneled to the RP as
s:155.1.146.6 d:150.1.5.5

Your using ip cef per destination as OSPF has two equal costs to lo0 R5

So it's unicasted over to RP before it's de-encapsulated, the RP build the SPT
via join messages back to the source when it receives native multicast packets
i.e d:224.1.2.4 s:155.1.146.6 it then see's that it hasn't got a (*,G) from
any receivers and send back a register-stop message to the source.

Good question on why the source cannot register its own multicast traffic with
the RP in this case it seems it is, a question for experts I've always seen
using "ip pim register-source" on say a loopback if the source is also the
FHR.

--
BR
Tony
Sent from my iPad
> On 9 Jan 2014, at 21:47, Imran Ali <immrccie_at_gmail.com> wrote:
>
> in my opinion:
>
> FOR  Register  message  RPF  checks  is only  performed by  DR  and not by
RP . unless the  their is no source route for RP.
>
> proof:  Right  now  R6  itself is  DR
>
> R6#show ip pim int fa0/0.146
>
> Address          Interface                Ver/   Nbr    Query  DR     DR
>                                           Mode   Count  Intvl  Prior
> 155.1.146.6      FastEthernet0/0.146      v2/SD  2      30     1
155.1.146.6
>
>
> how  come source  router becoming DR ? That  i  simply dont  know !!
>
> now  lets change  DR to  R4
>
> R4#CONF T
> Enter configuration commands, one per line.  End with CNTL/Z.
> R4(config)#int fa0/1
> R4(config-if)#ip pim dr-pr
> R4(config-if)#ip pim dr-priority 100
> R4(config-if)#
> PIM(0): Changing DR for FastEthernet0/1, from 155.1.146.6 to 155.1.146.4
(this system)
> %PIM-5-DRCHG: DR change from neighbor 155.1.146.6 to 155.1.146.4 on
interface FastEthernet0/1
>
>
> R6#clear ip mroute *
> R6#
>
> 5#clear ip mroute *
> R5#
>
> R4#clear ip mro
> R4#clear ip mroute *
> R4#
>
> R6#ping 224.1.2.4
>
> Type escape sequence to abort.
> Sending 1, 100-byte ICMP Echos to 224.1.2.4, timeout is 2 seconds:
> .
>
>
>  no  reply  here .......................
>
> now DR says
>
> IP(0): s=155.1.146.6 (FastEthernet0/1) d=224.1.2.4 id=44, ttl=254, prot=1,
len=114(100), RPF lookup failed for source or RP
>
> Question :  i  have  seen cases  where Registration fails  when source
router and  DR  are on same router. not sure why it  is successful here ??
>
> conclusion:  in my opinion only :    register messages are subjected to RPF
check only by DR and not  by  RP.  Unless their  is no  source route in RP
>
>
>
>
>
>
>> On Fri, Jan 10, 2014 at 12:37 AM, Imran Ali <immrccie_at_gmail.com> wrote:
>> R4
>>
>> interface Loopback0
>>  ip address 150.1.4.4 255.255.255.0
>> !
>> interface FastEthernet0/0
>>  ip address 204.12.1.4 255.255.255.0
>>  shutdown
>>  duplex auto
>>  speed auto
>> !
>> interface FastEthernet0/1
>>  ip address 155.1.146.4 255.255.255.0
>>  ip pim dr-priority 100
>>  ip pim sparse-dense-mode
>>  duplex auto
>>  speed auto
>> !
>> interface Serial1/0
>>  no ip address
>>  encapsulation frame-relay
>>  serial restart-delay 0
>> !
>> interface Serial1/0.1 point-to-point
>>  ip address 155.1.0.4 255.255.255.0
>>  ip ospf network non-broadcast
>>  ip ospf priority 0
>>  snmp trap link-status
>>  frame-relay interface-dlci 405
>> !
>> interface Serial1/1
>>  ip address 155.1.45.4 255.255.255.0
>>  ip pim sparse-dense-mode
>>  serial restart-delay 0
>>  clock rate 64000
>>
>>
>>
>> =====================
>>
>> R6
>>
>> !
>> interface Loopback0
>>  ip address 150.1.6.6 255.255.255.0
>> !
>> interface FastEthernet0/0
>>  no ip address
>>  duplex auto
>>  speed auto
>> !
>> interface FastEthernet0/0.67
>>  encapsulation dot1Q 67
>>  ip address 155.1.67.6 255.255.255.0
>> !
>> interface FastEthernet0/0.146
>>  encapsulation dot1Q 146
>>  ip address 155.1.146.6 255.255.255.0
>>  ip pim sparse-dense-mode
>>
>>
>>
>> R6#show ip mroute 224.1.2.4
>> IP Multicast Routing Table
>> Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
Connected,
>>        L - Local, P - Pruned, R - RP-bit set, F - Register flag,
>>        T - SPT-bit set, J - Join SPT, M - MSDP created entry,
>>        X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
>>        U - URD, I - Received Source Specific Host Report,
>>        Z - Multicast Tunnel, z - MDT-data group sender,
>>        Y - Joined MDT-data group, y - Sending to MDT-data group
>> Outgoing interface flags: H - Hardware switched, A - Assert winner
>>  Timers: Uptime/Expires
>>  Interface state: Interface, Next-Hop or VCD, State/Mode
>>
>> (*, 224.1.2.4), 00:00:14/stopped, RP 150.1.5.5, flags: SPF
>>   Incoming interface: FastEthernet0/0.146, RPF nbr 155.1.146.4
>>   Outgoing interface list: Null
>>
>> (155.1.146.6, 224.1.2.4), 00:00:14/00:02:51, flags: PFT
>>   Incoming interface: FastEthernet0/0.146, RPF nbr 0.0.0.0, Registering
>>   Outgoing interface list: Null
>>
>>
>> R6#ping 224.1.2.4
>>
>>
>> Type escape sequence to abort.
>> Sending 1, 100-byte ICMP Echos to 224.1.2.4, timeout is 2 seconds:
>>
>> Reply to request 0 from 155.1.108.10, 200 ms
>>
>>
>>
>>
>>
>>
>>> On Thu, Jan 9, 2014 at 11:51 PM, Tony Singh <mothafungla_at_gmail.com>
wrote:
>>> Can you post your interface configs on R4 and R6 and show ip mroute on R6
>>>
>>>
>>> --
>>> BR
>>>
>>> Tony
>>>
>>> Sent from my iPad
>>>
>>> > On 9 Jan 2014, at 16:06, Imran Ali <immrccie_at_gmail.com> wrote:
>>> >
>>> > debug in detail:
>>> >
>>> > start  pinging from R6
>>> >
>>> > *R6#ping 224.1.2.4*
>>> >
>>> > Type escape sequence to abort.
>>> > Sending 1, 100-byte ICMP Echos to 224.1.2.4, timeout is 2 seconds:
>>> >
>>> > *Reply to request 0 from 155.1.108.10, 236 ms*
>>> >
>>> >
>>> >
>>> > R5#debug ip mpacket
>>> > IP multicast packets debugging is on
>>> >
>>> >
>>> > R5#
>>> > *Mar  1 01:39:24.811: IP(0): s=155.1.146.6 (Serial1/1) *d=224.1.2.4
>>> > (FastEthernet0/0) id=8, ttl=253, prot=1, len=100(100), mforward*
>>> > *Mar  1 01:39:24.823: PIM(0): *Received v2 Register on Serial1/0 from
>>> > 155.1.146.6*
>>> > *Mar  1 01:39:24.827:      for 155.1.146.6, group 224.1.2.4
>>> > *Mar  1 01:39:24.831: PIM(0): *Send v2 Register-Stop to 155.1.146.6 for
>>> > 155.1.146.6, group 224.1.2.4*
>>> > *Mar  1 01:39:25.767: PIM(0): Received v2 Join/Prune on FastEthernet0/0
>>> > from 155.1.58.8, to us
>>> > *Mar  1 01:39:25.771: PIM(0): Join-list: (*, 224.1.2.4), RPT-bit set,
>>> > WC-bit set, S-bit set
>>> >
>>> >
>>> > debug shows  forward message first   data plane aciton
>>> >
>>> > next  it shows   successful  Registration process  coming in on S1/0
>>> >
>>> > Then it  builds  shared tree
>>> >
>>> > but   registration came in on non rpf interface ..if i   verify  route
back
>>> > to source it  says  S1/1
>>> >
>>> > R5#MTRACE 155.1.146.6
>>> > Type escape sequence to abort.
>>> > Mtrace from 155.1.146.6 to 155.1.45.5 via RPF
>>> > From source (?) to destination (?)
>>> > Querying full reverse path...
>>> > 0  155.1.45.5                ===============> s1/1
>>> > -1  155.1.45.5 PIM  [155.1.146.0/24]
>>> > -2  155.1.45.4 PIM  [155.1.146.0/24]
>>> > -3  155.1.146.6
>>> >
>>> > *R5#SHOW IP RPF 155.1.146.6*
>>> > RPF information for ? (155.1.146.6)
>>> >  RPF interface:* Serial1/1*
>>> >  RPF neighbor: ? (155.1.45.4)
>>> >  RPF route/mask: 155.1.146.0/24
>>> >  RPF type: unicast (eigrp 100)
>>> >  RPF recursion count: 0
>>> >  Doing distance-preferred lookups across tables
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >> On Thu, Jan 9, 2014 at 6:52 PM, Imran Ali <immrccie_at_gmail.com> wrote:
>>> >>
>>> >> Hi all
>>> >>
>>> >> R6==========R4=========R5
>>> >> source                                   RP
>>> >>
>>> >>
>>> >> R4 is connected to R5  with  two S1/1  and S1/0
>>> >>
>>> >> R6  registrations  are  coming in  non PIM enabled   interface
>>> >>
>>> >> *Mar  1 01:25:21.519: PIM(0): Received v2 Register on Serial1/0 from
>>> >> 155.1.146.6
>>> >> *Mar  1 01:25:21.523: PIM(0): Send v2 Register-Stop to 155.1.146.6 for
>>> >> 0.0.0.0, group 0.0.0.0
>>> >>
>>> >>
>>> >> R5#show ip pim interface
>>> >>
>>> >> Address          Interface                Ver/   Nbr    Query  DR
DR
>>> >>                                          Mode   Count  Intvl  Prior
>>> >> 150.1.5.5        Loopback0                v2/SD  0      30     1
>>> >> 150.1.5.5
>>> >> 155.1.58.5       FastEthernet0/0          v2/SD  1      30     1
>>> >> 155.1.58.8
>>> >> 155.1.45.5       Serial1/1                v2/SD  1      30     1
>>> >> 0.0.0.0
>>> >>
>>> >> pim  is not enabled on s1/0 , on which the register was received
>>> >>
>>> >> traceroute to source   goes  via s1/1 . ie shortest path back to source
is
>>> >> via s1/1
>>> >> R5#traceroute 155.1.146.6
>>> >>
>>> >> Type escape sequence to abort.
>>> >> Tracing the route to 155.1.146.6
>>> >>
>>> >>  1 155.1.45.4 60 msec 44 msec 4 msec
>>> >>  2 155.1.146.6 64 msec 88 msec 8 msec
>>> >>
>>> >>
>>> >>
>>> >> *Question*:  PIM  register messages are subjected  to RPF check . ie
>>> >> should land on interface , from which  router  sends  unicast traffic
back
>>> >> to source .
>>> >>
>>> >> here  routers  unicast path back is via 155.1.45.4    ie  s1/1
>>> >> R5#traceroute 155.1.146.6
>>> >>
>>> >> Type escape sequence to abort.
>>> >> Tracing the route to 155.1.146.6
>>> >>
>>> >>  1 155.1.45.4 60 msec 44 msec 4 msec
>>> >>  2 155.1.146.6 64 msec 88 msec 8 msec
>>> >>
>>> >> Register messages  come in via s1/0
>>> >>
>>> >> PIM(0): Received v2 Register on Serial1/0 from 155.1.146.6
>>> >>
>>> >> Register stop message was sent ....and  not  said  " NOT AN  RPF
interface
>>> >> "
>>> >>
>>> >> what  could be reason ?  ios  image exception ?
>>> >
>>> >
>>> > 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