Re: multicast registration process

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.146Address Interface
Ver/ Nbr Query DR DR
Mode Count Intvl Prior155.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 mroR4#clear ip
mroute *R4#R6#ping 224.1.2.4Type 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
Received on Fri Jan 10 2014 - 00:47:39 ART