All things related to multicast

[Caren Litvanyi <>]

On Sat, 31 Oct 2009, Havard Eidnes wrote:

> Hmm,
>
> looks like I'll have to retract at least parts of what I said -- there
> were apparently additional preconditions for the particular problem we
> observed which caused point 3) in the "peer rpf forwarding rules" to
> not apply in our case, but which would apply for direct physical
> external neigbors.  In our case, until we fixed it so that point 4)
> worked properly, the SA messages would be rejected as failing the RPF
> check.
>
> OK, but we still have no explanation why all the candidate MSDP SA
> messages related to 129.78.221.17 / 233.4.200.18 were rejected.

Well, we do actually, and you point to it correctly further below.
Internet2, through normal BGP best path selection, has chosen
a best path via AARnet back to 129.78.0.0/16.  Here it is (inet.2):

LOSA:
129.78.0.0/16      *[BGP/170] 3d 05:36:44, MED 8, localpref 100
                      AS path: 7575 23719 I
                    > to 207.231.241.4 via ge-3/1/0.776

In LOSA, it's easy to see why all the rejects - we have MBGP up with
AARnet advertising 129.78.0.0/16 with SAFI=3, yet we have no MSDP
session up.  Therefore, no MSDP peer is on the best path to the
originator. (I'm being a bit short here).

litvanyi@LOSA-re0>
 show msdp sa source 129.78.221.17
Group address   Source address  Peer address    Originator    Flags
233.4.200.18    129.78.221.17   134.55.3.1      129.78.255.8  Reject <- ESnet
                                137.164.26.145  129.78.255.8  Reject <- CalREN
                                207.231.240.133 129.78.255.8  Reject <- TWAREN

Are any of those peers going to match any of the selection
criteria in RFC 3618? -- No.  See the best path above.
Therefore they fall through and all are rejected.  As you say,
getting the MSDP sessions fixed between AARnet and Internet2
in Los Angeles would likely fix the problem, assuming we get the
SA in question across the sessions.  The above is why it is
generally a bad idea to configure MBGP passing SAFI={2|3} to
your peer without having MSDP configured. (Yes, there are valid
cases, but speaking generally.)

Seattle is a little more interesting (again from inet.2):

SEAT:
129.78.0.0/16      *[BGP/170] 3d 06:12:09, MED 8, localpref 100
                      AS path: 7575 23719 I
                    > to 207.231.240.4 via ge-3/0/0.706

Now, we have an MSDP session up to that peer:
207.231.240.4   207.231.240.8   Established  6d 20:45:52 ITN   10/442

But, I don't see that we're getting that SA from that peer:

litvanyi@SEAT-re1>
 show msdp sa source 129.78.221.17
Group address   Source address  Peer address    Originator    Flags
233.4.200.18    129.78.221.17   134.55.3.6      129.78.255.8  Reject <- ESnet
                                137.164.26.141  129.78.255.8  Reject <- CENIC
                                138.18.12.237   129.78.255.8  Reject <- DREN
                                207.231.240.2   129.78.255.8  Reject <- 
AARnet SEAT local med 813/prepend
                                207.231.240.21  129.78.255.8  Reject <- CA*net
                                207.231.241.149 129.78.255.8  Reject <- 
AARnet LA-intersite med 80
                                210.7.36.193    129.78.255.8  Reject <- REANNZ
                                210.7.36.194    129.78.255.8  Reject <- REANNZ

207.231.240.4 is not in the list.

I'd suggest getting the Los Angeles MSDP sessions between AARnet and
Internet2 fixed first, then looking into Seattle more later.



> Ah, the MSDP session between Internet2 and AARNet appears to be down
> (if I read the router proxy output correctly), and has been for quite
> some time (from the Los Angeles router):
>
> 207.231.241.4   207.231.241.131 Listen          34w2d13h ITN          0/0
>
> ...and all the other paths where the MSDP SA messages arrive via are
> most probably correctly rejected due to MSDP's RPF rules.  I'd guess
> "get AARNet to configure their end of the MSDP setup" would probably
> fix this particular issue.

I think you are on the right track now; the problem for me is untangling
all of AARnet's peerings with I2, and trying to figure out which, if any
in particular, is supposed to carry mcast traffic.  I have a feeling the
intention was to have MBGP and MSDP on all peerings, and have the unicast
and multicast paths match.

We'll see.  First step - getting these working:
litvanyi@LOSA-re0>
 show msdp
[...]
207.231.241.4   207.231.241.131 Listen           34w2d9h ITN          0/0
207.231.240.149 207.231.240.131 Inactive        00:00:04 ITN          0/0
[...]

One down and one flapping.  Ick.  At least the preferred peer-RPF
path would be via the one that is hard down.  Maybe that is a simple
config fix, and we can at least get things working for the current
state.

Anyone from AARnet on this list??
We (Internet2 NOC) have a ticket open on this, and an engineer will contact
them soon in any case.


> Regards,
>
> - Håvard (hoping I won't have to retract this one too... :)

I don't think so.  :-)

-- Caren
------------
Caren Litvanyi, network engineer
Internet2 NOC
Global Research NOC at Indiana University

o:812-961-3790  c:250-896-4369