All things related to multicast

["Zenon Mousmoulas" <>]

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