All things related to multicast

["Zenon Mousmoulas" <>]

11 Μαρ 2015, 22:08, ο/η "Leonard Giuliano" 
<>
 έγραψε:

> 
> You can always just put in filters that block SAs containing your sources 
> from coming in from external peers if you are sure they should never send 
> you those.  That would essentially be like anti-spoofing SA filters and 
> would block your SAs from coming in from all other bad originators, not 
> just this one.

Yes, that is what I had in mind. However when you have a considerable number 
of prefixes in your PIM domain it's not very practical to maintain such a 
filter using source-address-prefix to match all of them, especially when you 
already have those prefixes in various prefix lists used in other policy 
statements. Therefore in order to effectively implement such a mechanism it 
would really help if one could use such prefix lists to match one's own 
sources.

> But to be honest, having a few extra SAs floating around out there isn't 
> the worst thing in the world.  The thing to worry about is if the SAs 
> aren't making it out to the world (if indeed you want the world to see 
> them).  Having extra guys originating them isn't going to do any real harm 
> other than creating a little extra state.  And extra state isn't something 
> to lose sleep over unless it becomes a large amount- in which case the 
> per-source/per-peer/per-instance SA policers should protect you.

Since the SAs carry exactly the same information, regardless if it is 
originated by you or by someone else, I can agree to your point in the sense 
that it doesn't matter if some MSDP speaker across the internet accepts the 
"reflected" SAs and rejects yours. When it does matter however is where it 
can create state when there should be none. In the particular incident it 
caused the false assumption that multicast was working, while it actually 
wasn't (false negative); in our case that was due to misconfiguration, but it 
could also be a matter of policy: if our RP decides to stop accepting PIM 
register for a particular S,G, my impression is that by accepting reflected 
SAs such policy would be bypassed and state would be created for that S,G.

Z.

> On Wed, 11 Mar 2015, 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.
> | > | > | > | 
> | > | > |
> | > |
> |

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