All things related to multicast

[Chuck Anderson <>]

Has anyone tried contacting them?

% Abuse contact for '194.82.152.0 - 194.82.154.255' is 
''

inetnum:        194.82.152.0 - 194.82.154.255
netname:        CXWEST-3
descr:          Imperial College of Science, Technology and Medicine
descr:          Core network infrastructure
descr:          Was CXWMS which became part of Imperial College in 1997
country:        GB
admin-c:        ICH1-RIPE
tech-c:         ICH1-RIPE
remarks:        trouble: Please contact 

 for abuse problems
status:         ASSIGNED PA
mnt-by:         JANET-HOSTMASTER
source:         RIPE # Filtered


On Wed, Mar 11, 2015 at 04:35:13PM +0200, 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.