Subject: [MBONED] MBGP/MSDP path selection question

From: Antonio Querubin <[email-masked]>
Date: Fri, 21 Aug 2009 09:28:55 -1000 (HST)

I'm trying to get a better handle on how PIM works with MSDP.

Assume in the diagram below the links denote MBGP peering links.  AS4 
wants to receive multicast traffic sourced by AS1.

AS1 ---- AS2 ---- AS3 --- AS4
  |                 |
  --- AS5 --- AS6 ---

AS1 announces its prefixes to AS2 and AS5 which in turn announce to AS3 
and AS6.  AS3 announces to AS4.  Further assume that the unicast 
connectivity/peering topology is similar.

Suppose however due to internal policy AS2 will not allow multicast 
transit between AS1 and AS3 and either

1) blocks MSDP SAs received from AS1 from reaching AS3 (and vice versa)

or

2) allows MSDP SAs to reach AS3 but blocks multicast traffic from AS1 to 
AS3.

In case #1, will MSDP at AS3 accept the SAs from AS6 or will it reject 
them because it still sees AS2 as the RPF peer due to the shorter MBGP 
path?  If the SAs are accepted from AS6, will PIM Joins/Prunes from a 
router in AS4 attempting to join the SPT for a source in AS1 follow the 
AS5/AS6 path back to AS1 or will they follow AS2?  Ie. will the SPT from 
AS1 to AS4 be built through AS2 or through AS5/AS6 or not at all?

In case #2, don't we have an outright blackhole situation?

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  [email-masked]

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 21 Aug 2009 13:40:50 -0700

Antonio,

MSDP peer-RPF and pim RPF checks are orthoginal.  In this case, AS3 should 
accept the SAs from AS2 since AS2 is in the last AS in the AS path to the 
originating RP in AS1.  So in both cases, I would expect blackholing.  In 
case 1, AS3 would never get any SAs since they are blocked an AS2 and 
rejected from AS6.  In case 2, he gets the SAs but the PIM joins try to go 
through AS2 since that is the RPF path.

This situation should easily be resolved by MBGP.  If AS2 doesn't want to 
allow multicast transit between AS1 and AS3, that's fine.  They simply 
shouldn't advertise AS1 routes to AS3 in MBGP.  Since PIM and MSDP can be 
told to use MBGP for their RPF, they will choose the AS5-6 path, and 
accept the SAs from AS6 and send joins that way.

If AS2 doesn't want AS3 to reach AS1 through it, they shouldn't announce 
reachability to AS1.  AS3, of course, can also use inbound MBGP policy to 
prefer the AS6 path.

Hope this helps,
Lenny

On Fri, 21 Aug 2009, Antonio Querubin wrote:

-) I'm trying to get a better handle on how PIM works with MSDP.
-) 
-) Assume in the diagram below the links denote MBGP peering links.  AS4 wants
-) to receive multicast traffic sourced by AS1.
-) 
-) AS1 ---- AS2 ---- AS3 --- AS4
-)  |                 |
-)  --- AS5 --- AS6 ---
-) 
-) AS1 announces its prefixes to AS2 and AS5 which in turn announce to AS3 and
-) AS6.  AS3 announces to AS4.  Further assume that the unicast
-) connectivity/peering topology is similar.
-) 
-) Suppose however due to internal policy AS2 will not allow multicast transit
-) between AS1 and AS3 and either
-) 
-) 1) blocks MSDP SAs received from AS1 from reaching AS3 (and vice versa)
-) 
-) or
-) 
-) 2) allows MSDP SAs to reach AS3 but blocks multicast traffic from AS1 to AS3.
-) 
-) In case #1, will MSDP at AS3 accept the SAs from AS6 or will it reject them
-) because it still sees AS2 as the RPF peer due to the shorter MBGP path?  If
-) the SAs are accepted from AS6, will PIM Joins/Prunes from a router in AS4
-) attempting to join the SPT for a source in AS1 follow the AS5/AS6 path back
-) to AS1 or will they follow AS2?  Ie. will the SPT from AS1 to AS4 be built
-) through AS2 or through AS5/AS6 or not at all?
-) 
-) In case #2, don't we have an outright blackhole situation?
-) 
-) 
-) Antonio Querubin
-) 808-545-5282 x3003
-) e-mail/xmpp:  [email-masked]
-) _______________________________________________
-) MBONED mailing list
-) [email-masked]
-) https://www.ietf.org/mailman/listinfo/mboned
-)

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 21 Aug 2009 11:35:45 -1000 (HST)

> Hope this helps,

It does and confirms what I already suspected but needed some more expert 
verification.  Now to convince AS2 to fix their MBGP outbound filters to 
match their transit policy...

Antonio Querubin
808-545-5282 x3003