All things related to multicast

[Havard Eidnes <>]

> Let me bring this up again.  The AG beacon is not really very useful right
> now, but actually quite few of the problems there are actual problems.
>
> Let's take for example *.edu.au sites.  Very few of them are seen by R&E
> sites on Internet2 and GEANT.
>
> If you examine source 129.78.221.17 for example, on the I2 core router
> proxy in SEAT gives the following MSDP SA rejects.  Ok, quite a few of
> these are rejects due to MSDP RPF mechanism, but there should still be at
> least one accept:
>
> 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
>                                 137.164.26.141  129.78.255.8    Reject
>                                 138.18.12.237   129.78.255.8    Reject
>                                 207.231.240.2   129.78.255.8    Reject
>                                 207.231.240.21  129.78.255.8    Reject
>                                 207.231.241.149 129.78.255.8    Reject
>                                 210.7.36.193    129.78.255.8    Reject
>                                 210.7.36.194    129.78.255.8    Reject
>
> Maybe someone with better knowledge of AU - I2 multicast interconnection
> could take a look at this ?
>
> [1] http://routerproxy.grnoc.iu.edu/internet2/

Hmm, this brings back memories of an MSDP failure mode we have
experience with first-hand in our network.


There appears to be some advice which is going around which basically
says "you should use the same MSDP endpoint addresses as you use for
your external BGP peer sessions".  I think this advice is dead wrong,
and the reason can be found in the MSDP "peer RPF" rules.

It is normal for external neighbors to use the interface addresses of
the physical interconnection link as eBGP peer addresses, and that's
all fine and dandy -- you get proper fate-sharing between the eBGP
peer session and the physical connectivity.

If the same is done for MSDP, the routing process on both ends will
use the directly connected route when determining "which AS does the
MSDP neighbor's IP address reside in".  This route is of course
internal to its own AS, not to that of the neighbor.  This wrecks
havoc when this particular rule which is part of the MSDP peer-RPF
rules is applied:

   (iv).   N resides in the closest AS in the best path towards R.  If
           multiple MSDP peers reside in the closest AS, the peer with
           the highest IP address is the rpf-peer.

(Quoted from RFC 3618, section 10.1.3.)

In this case, N refers to the MSDP neighbor, and because it is on a
directly connected subnet, it ends up being interpreted as *not* being
inside the closest AS on the path towards the originator of the MSDP
message, but instead as being an MSDP neighbor internal to the local
AS!  If I've understood correctly, this is a certain recipe for peer-
RPF failures for all SA messages received across the MSDP peering.

We find instances of this sort of configuration in the Los Angeles
Internet2 router:

Peer address    Local address   State       Last up/down Peer-Group   SA Count
137.164.26.145  137.164.26.146  Established   00:08:16 CONNECTOR  
374284/375309

Here the "local address" and "peer address" are obviously on the same
subnet, most probably triggering these MSDP "peer RPF" failures.

It is my advice that instead of using the identical IP addresses as
used for the eBGP peering, MSDP should use an IP address which in all
instances will be interpreted as residing wholly within the given AS
when looking at the fully resolved routing table of your immediate
neighbor, for instance by using a Loopback addresses on both sides.


In our particular case we were lucky, in that we on our side used a
loopback interface buried far within our network as the MSDP endpoint,
and when our peer started doing this stupidly (using the same MSDP
peer address on their side as for the eBGP sessions), all we had to do
was stop announcing the particular external link in our IGP (we had
the moral equivalent of "redistribute connected" enabled, and we do
set next-hop-self on our iBGP sessions, so we didn't actually *need*
that particular route in our IGP), and the MSDP peer-RPF failures
triggered on our MSDP-speaker by the failure of it to properly detect
which AS the MSDP peer address resided in went away.


I'll admit that I'm not 100% certain that this is what is causing
these failures in this case, but it is at least worth investigating
further.  If this indeed turns out to be the problem, I'd like to
know, so that I can apply some back-pressure against those who
recommended this sort of configuration to our particular peer (some
people at a certain vendor's TAC, if I've understood correctly).


Just my US 0.02.

Best regards,

- Håvard