i got few unicast replies and already clarified now ......but not sure the response was not as expected .
Agreed the topic is little bit difficult but every one must be aware of it inside out On Fri, Jan 10, 2014 at 4:51 PM, Imran Ali <[email protected]> wrote: > Soldiers of ccie battle ! > > i have a basic question on multicast registration process. > > how rpf check is done on unicasted register messages on RP ?? > > *topology * > 23.0.0.0 > 34.0.0.0 > R1============ R2 [ fa0/1----------------- fa0/1] R3 [f0/0 > ==============f0/0] R4 > 12.0.0.0 s0/1------------------ s0/1 > 34.0.0.0 > > > R1 > > > > > > > > > *interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ip pim > dr-priority 100!router eigrp 100 network 0.0.0.0 no auto-summary* > R2 > > > > > > > > > > > > > > *interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ip pim > sparse-mode! interface FastEthernet0/1 ip address 23.0.0.2 255.255.255.0 ip > pim sparse-mode!router eigrp 100 network 0.0.0.0 no auto-summary* > R3 > > > > > > > > > > > > > *interface Loopback0 ip address 150.1.3.3 255.255.255.0 ip pim > sparse-mode!interface FastEthernet0/0 ip address 34.0.0.3 255.255.255.0 ip > pim sparse-mode!interface FastEthernet0/1 ip address 23.0.0.3 > 255.255.255.0 ip pim sparse-mode* > ! > > > *interface Serial1/0 ip address 32.0.0.3 255.255.255.0 serial > restart-delay 0* > > !! pim is not running on s1/0 to understand RPF behavior of register > message!! > > R4: > > > > > > > > > > > *interface FastEthernet0/0 ip address 34.0.0.4 255.255.255.0 ip igmp > join-group 224.1.1.1!router eigrp 100 network 0.0.0.0 no auto-summary* > > Multicast info: > > we will switch DR between R1 and R2 . > R3 is the RP. > > RP assignment is static > > > > case 1 : > when R1 is source and DR at same time. > > R1#show ip pim interface fa0/0 > > Address Interface Ver/ Nbr Query DR DR > Mode Count Intvl Prior > 12.0.0.1 FastEthernet0/0 v2/S 1 30 100 > 12.0.0.1 > > > > > on R2 lets add a static route to make traffic arrive on non rpf > interface > > R2(config)#ip route 150.1.3.3 255.255.255.255 Serial1/0 > > > lets trace from R1 > R1#traceroute 150.1.3.3 > > Type escape sequence to abort. > Tracing the route to 150.1.3.3 > > 1 12.0.0.2 28 msec 32 msec 8 msec > 2 32.0.0.3 28 msec 36 msec 4 msec ==.>s1/0 > > > > *intention here is to make register messages on RP come in a NON-RPF > interface. * > on RP ie R3 lets check RPF neighbor for multicast source > > R3#show ip rpf 12.0.0.1 > RPF information for ? (12.0.0.1) > RPF interface: *FastEthernet0/1* > RPF neighbor: ? (23.0.0.2) > RPF route/mask: 12.0.0.0/24 > > > it is fa0/1 > > *now the Reigstarion process:* > > R1#ping 224.1.1.1 > > Type escape sequence to abort. > Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds: > > *Reply to request 0 from 34.0.0.4, 188 ms* > > *Mar 1 00:10:50.583: PIM(0): Received v2 Register *on Serial1/0* from > 12.0.0.1 > *Mar 1 00:10:50.583: for 12.0.0.1, group 224.1.1.1 > *Mar 1 00:10:50.587: PIM(0): Insert (12.0.0.1,224.1.1.1) join in nbr > 23.0.0.2's queue > *Mar 1 00:10:50.591: PIM(0): Forward decapsulated data packet for > 224.1.1.1 on > > > though their is a disconnect from the rpf neighbor and where the > messages > are coming in , but still no rfp failure > > > > > case 2: switch DR to R2 > > R1(config-if)#no ip pim dr-priority 100 > *Mar 1 01:05:26.571: %PIM-5-DRCHG: DR change from neighbor 12.0.0.1 to > 12.0.0.2 on interface FastEthernet0/0 > > > R1#show ip pim int fa0/0 > > Address Interface Ver/ Nbr Query DR DR > Mode Count Intvl Prior > 12.0.0.1 FastEthernet0/0 v2/S 1 30 1 > *12.0.0.2* > > > clearing all states > > R1#clear ip mroute * > R2#clear ip mroute * > R3#clear ip mroute * > > on DR ie on R2 NOW > > R2# > *Mar 1 01:07:42.747: IP(0): s=12.0.0.1 (FastEthernet0/0) d=224.1.1.1 > id=26, ttl=254, prot=1, len=114(100),* RPF lookup failed for source or RP* > > > > CONCLUSION : > > *it is not RP who is checking RPF for register message, but DR. > unless their is no source route for mutlicast source on RP * > > > *Also the register message is unicast at the end. on RP . * > > *Please appreciate your replies to understand the process better !!* > > *i did not find any solid reference even on rfc 4061 * > > > _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
