Hi everyone. This is the first time I am dealing with MSDP, have some questions any help will be appreciated!!   Scenario: Source---R1 200.1.---Dense mode--200.2 -R2----MSDP------R3--Listener   1)Above we R1 and R2 are running Dense mode, R2 is also running MSDP with R3. Normally Rp ( R2) will send SA to MSDP peer if it receives REGISTER. It does nothing if it receives stream from dense mode neighbor or more specifically from dense mode region. What is the minimum config needed  to make R2 just do that?   Ok after some research, I can use following on R2 to solve question1: ip msdp originator-id Loopback0 Where loopback 0 is MSDP IP R2 uses to peer with R2.     SCENARIO#2 Scenario: Listener---R1 200.1.---Dense mode--200.2 -R2----MSDP------R3--Source 1.1.1.1 236.1.1.1   I want R2 do following: If R2 receives SA for 236.1.1.1,1.1.1.1, I want R2 to flood it to dense mode neighbor R1 I noticed R2 will only do that if R2 is configured with IP IGMP STATIC JOIN under  interface facing R1, but not without it.   Thanks and have a nice day!!   ... View more

Hi everyone   I would like to hear your thoughts; Please consider the example below:   Lo:1.1.1.1 S1-10.10.10.1----10.2.2.2 R2(rp)<----MSDP----->R3(rp)----->R4 -Listener 235.1.1.1 H S1: Source R2:RP R3:Rp Assume everything is correctly configured. This is what I see: 1) If S1 sends multicast with SRC IP 10.10.10.1 , dst 235.1.1.1, R2 sends SA ( 10.10.10.1, 235.1.1.1) to R3 via MSDP. 2) If S1 sends multicast with SRC IP 1.1.1.1, dst 235.1.1.1, R2 does not send SA for 1.1.1.1, 235.1.1.1, there is no RPF issue, both R2/R3 knows 1.1.1.1 via RPF interface. When I look at RFC 3618 it does not say anything how the R2 should behave if it receives a multicast stream  directly i.e from the attached source but SRC IP is not within subnet used between SRC and R2. In our case this is  10.10.10.0/24 but SRC IP in the stream is 1.1.1.1 I see different behavior: Some old IOS just ignores it, some initiates SA. IOS that ignores it: #show version ( emulated GNS3) Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.2(4)S5, Cisco C870 ( not emulated) Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.4(24)T8, RELEASE SOFTWARE (fc1)     Thanks and have a nice weekend!! ... View more

Hi everyone,   Scenario#1 Source-10.10.10.10---10.10.10.1 f0/0 R1(rp)--------->rest of multicast network--Listener 235.1.1.1 Assumptions: R1 has IP sparse mode configured on f0/0, assume rest of multicast config is correct, R1 has ( *,235.1.1.1) in mtable. Source sends a multicast stream with SRC IP 1.1.1.1, 235.1.1.1 ( Source is sourcing it from an IP of loopback) Assume R1 and rest of Multicast network know 1.1.1.1 and rpf checks passes. With these assumptions in mind, focusing only on R1 ( rp): 1) What will R1 do upon receiving ( 1.1.1.1, 235.1.1.1), will it drop it because source IP is not in the same subnet ( i.e 10.10.10.10)? GNS3 shows very unpredictable behavior sometimes I see R1 passes the traffic, some time it does not so I do not what to believe, unfortunately I do have access to real routers at this time.     Thanks and have a nice day!!   ... View more

Hi everyone, Please consider the following set up:   ESW4 is both LHR/FHR.   This is what I see:   IP PIM DENSE /IP PIM SPARSE-DENSE/ IP PIM sparse commands on the interfaces facing SOURCE/LISTENERS have no impact on multicast forwarding when FHR/LHR is same router. Above Multicast forwarding refers to when source sends multicast 235.1.1.1, FHR/LHR simply forwards it to LISTENERS regardless of  IP PIM  mode  configured on the interfaces facing SOURCE/LISTENERS.   NOTE:  FHR/LHR will send REGISTER for 235.1.1.1 to RP but our focus is specifically on  multicast forwarding between INTERFACE facing SOURCE and  INTERFACE facing LISTENERS on FHR/LHR.   Configuring of IP PIM regardless of mode on interfaces connected to SOURCE/LISTENERS have no bearing how the PIM router will forward multicast stream to its PIM neighbors. However, the PIM mode configured on the interface connected to DOWN STREAM neighbor, will determine whether PIM router will use SPARSE logic or dense logic when forwarding stream to DOWN STREAM PIM neighbor.     CASE 1: WHEN INTERFACES FACING SOURCE/LISTENERS are SPARSE MODE:   1)  FHR/LHR all interfaces are is SPARSE MODE, FHR/LHR does send PIM JOIN towards RP upon receiving IGMP Report    about 235.1.1.1 from ESW3:   ESW4#show running-config interface s0/0 Building configuration...   Current configuration : 84 bytes ! interface Serial0/0  ip address 24.24.24.4 255.255.255.0  ip pim sparse-mode end   ESW4#show running-config interface s0/1 Building configuration...   Current configuration : 84 bytes ! interface Serial0/1  ip address 43.43.43.4 255.255.255.0  ip pim sparse-mode     Wireshark capture shows PIM JOIN BEING SENT TO RP:           Source generates pings at 235.1.1.1, capture between ESW4 and ESW3 shows , PINGS being forwarded:       2)When INTERFACES FACING SOURCE/LISTENRS are SPARSE -DENSE MODE   ESW4(config)#int s0/0   ESW4(config-if)#ip pim sparse-dense-mode ESW4(config-if)#int s0/3 ESW4(config-if)#ip pim sparse-dense-mode     No change in behavior, same results:     FHR/LHR still sends PIM JOIN 235.1.1.1 towards RP:     CASE 3: When  INTERFACES FACING SOURCE/LISTENERS are configured as DENSE NO change, same behavior, PIM JOIN ( *,235.1.1.1) is sent by ESW4 to RP:       Kindly share your thoughts.     Thanks and have a nice evening!! ... View more