All things related to multicast

["Zenon Mousmoulas" <>]

Not yet, unfortunately. But may I ask if anyone else has observed such 
behavior for their own SAs?

11 Μαρ 2015, 16:51, ο/η "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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature