All things related to multicast

[Chuck Anderson <>]

Normal anti-spoofing filters won't work, since the packets are
forwarded hop-by-hop by each MSDP speaker.  Perhaps Leonard can put in
a Juniper Enhancement PR to request the ability to filter on
originator...

On Wed, Mar 11, 2015 at 05:42:45PM +0200, Zenon Mousmoulas wrote:
> I will check the logs once more just to be absolutely sure, but yes I am 
> fairly certain that no RP leakage etc. was involved -- the DR was sending 
> PIM register to our RP, for which it has a static mapping, and it had no 
> knowledge of other RPs.
> 
> The thing is, if this speaker is indeed breaking the laws of MSDP, what can 
> other routers do to protect their networks from the unintended consequences 
> of that speaker's actions (such as input case), other than perhaps 
> "anti-spoofing" filters.
> 
> 11 Μαρ 2015, 17:10, ο/η "Leonard Giuliano" 
> <>
>  έγραψε:
> 
> > 
> > If 194.82.152.254 is originating SAs for which it hasn't received PIM 
> > registers, then it is breaking the laws of MSDP.
> > 
> > Are you certain that it is not receiving registers, though?  Could a bad 
> > RP mapping misconfig or leaked BSR/AutoRP msg be making it to the DR for
> > 62.217.124.105 such that it really is sending registers to 194.82.152.254?
> > 
> > 
> > On Wed, 11 Mar 2015, Zenon Mousmoulas wrote:
> > 
> > | Yes, that router appears to be originating SAs while it is practically 
> > | certain that it is not the RP or the DR for the particular S,Gs and it 
> > | has just discovered them via MSDP. So it appears to be reflecting a 
> > | large portion of the SAs it is originating (which added up to 590 the 
> > | last time I checked). I can't think of any case where such a behavior 
> > | would make sense; it rather seems like misconfiguration or a bug. What 
> > | do you think?
> > | 
> > | 10 Μαρ 2015, 17:03, ο/η "Leonard Giuliano" 
> > <>
> >  έγραψε:
> > | 
> > | > 
> > | > Hmm, what do you mean by "reflector"?  A router should only originate 
> > an 
> > | > SA if it is the local RP and receives a PIM register for the source 
> > (or 
> > | > the source is directly connected and the router is the RP and DR on 
> > that 
> > | > interface).  If the router is not the local RP, it should not 
> > originate 
> > | > the SAs.  From RFC 3618:
> > | > 
> > | > 6. Intermediate MSDP Peers
> > | > 
> > | >   Intermediate MSDP speakers do not originate periodic SA messages on
> > | >   behalf of sources in other domains.  In general, an RP MUST only
> > | >   originate an SA for a source which would register to it, and ONLY 
> > RPs
> > | >   may originate SA messages.  Intermediate MSDP speakers MAY forward 
> > SA
> > | >   messages received from other domains.
> > | > 
> > | > 
> > | > On Tue, 10 Mar 2015, Zenon Mousmoulas wrote:
> > | > 
> > | > | Hi Leonard,
> > | > | 
> > | > | thanks, yes I figured out that a) I can't filter based on 
> > originator (not that it would make much sense in general) and b) peer-rpf 
> > check does not consider SA source. They are accepted, perhaps even before 
> > rule 4, because the peer is indeed the next hop to the originator. So, to 
> > catch such cases, one would need to write MSDP import policies that would 
> > reject SAs for sources within one's own address space, which in general 
> > should not appear outside one's own PIM domain.
> > | > | 
> > | > | What I didn't understand however is why that MSDP originator would 
> > act as a "reflector", i.e. if there would be any legitimate explanation 
> > for such a behavior.
> > | > | 
> > | > | Thanks for your insight,
> > | > | Z.
> > | > | 
> > | > | 9 Μαρ 2015, 23:33, ο/η "Leonard Giuliano" 
> > <>
> >  έγραψε:
> > | > | 
> > | > | > Zenon,
> > | > | > 
> > | > | > You can filter SAs based on source, group or peer, but not 
> > originator.
> > | > | > 
> > | > | > As to the question of whether they should pass peer-rpf, do a 
> > "show route 
> > | > | > detail" on the peer (62.40.124.89) as well as the originator 
> > | > | > (194.82.152.254).  The results can then be compared against the 
> > rpf rules 
> > | > | > in sect 10.1.3 in RFC 3618.  You'll probably see it accepted bc 
> > of rule 
> > | > | > iv: 62.40.124.89 resides in the AS path in the best path for 
> > | > | > 194.82.152.254.  
> > | > | > 
> > | > | > MSDP peer-rpf doesn't care about the source; rather, it only 
> > cares about 
> > | > | > the peer with respect to the originator.  Put another way, MSDP 
> > will NOT 
> > | > | > decide if it's OK for 194.82.152.254 to originate an SA with 
> > source 
> > | > | > 233.21.32.32; it WILL decide if 62.40.124.89 is the peer who 
> > should be 
> > | > | > allowed to advertise SAs with the originator of 194.82.152.254.
> > | > | > 
> > | > | > 
> > | > | > Hope this helps,
> > | > | > Lenny
> > | > | > 
> > | > | > On Sat, 28 Feb 2015, Zenon Mousmoulas wrote:
> > | > | > 
> > | > | > | While investigating an issue with PIM register messages being 
> > dropped by 
> > | > | > | our RP routers (due to misconfiguration), I noticed that some 
> > S,G state 
> > | > | > | for local sources was mysteriously still present on the RP, 
> > even though 
> > | > | > | register messages were being dropped. I then realized this 
> > state was 
> > | > | > | triggered by MSDP SAs such as the following, which seem to be 
> > originated 
> > | > | > | by some system in the UK. I can't think of a valid scenario 
> > where it 
> > | > | > | could be an originator for what is certainly a foreign (in 
> > terms of a 
> > | > | > | PIM domain) S,G. Such SAs are being accepted by the router -- 
> > I'm not 
> > | > | > | sure at this stage if they should pass peer-rpf-check or not.
> > | > | > | 
> > | > | > | Group address   Source address  Peer address    Originator      
> > Flags
> > | > | > | 233.21.32.32    62.217.124.105  62.40.124.89    194.82.152.254  
> > Accept
> > | > | > | 233.21.32.234   62.217.124.105  62.40.124.89    194.82.152.254  
> > Accept
> > | > | > | 
> > | > | > | Given these oddities about 194.82.152.254, which seems to act 
> > as a MSDP 
> > | > | > | reflector (currently for up to 590 SAs), I wanted to see if I 
> > could drop 
> > | > | > | such SAs in the MSDP import policy statement. However there 
> > doesn't seem 
> > | > | > | to be a match condition for originator, at least not on JunOS 
> > 13.3. I 
> > | > | > | wonder if there is any other way to do this?
> > | > | > | 
> > | > | > | Regards,
> > | > | > | Z.