Skip to Content.
Sympa Menu

wg-multicast - RE: inter-domain MSDP peering without BGP FIRT

Subject: All things related to multicast

List archive

RE: inter-domain MSDP peering without BGP FIRT


Chronological Thread 
  • From: "Spurling, Shannon" <>
  • To: 'Zenon Mousmoulas' <>
  • Cc: wg-multicast <>
  • Subject: RE: inter-domain MSDP peering without BGP FIRT
  • Date: Mon, 14 Jun 2010 10:14:06 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

Yes, that is the main downfall. Mostly I used this with smaller installs with
a single RP. Once you get to multi-homed setups, which is a part of your
original note I glossed over, BGP really is required.

One of the nice things about mBGP is that you can send a default route for
only the multicast address family, and not have it influence their regular
unicast traffic. Can you originate a default just for the multicast address
family? Only problem is trying to weight it so that the proper path is the
default and the failover is available in case of failure on the main path.
That part can get tricky.

Shannon Spurling
WAN Engineer


-----Original Message-----
From: Zenon Mousmoulas
[mailto:]

Sent: Monday, June 14, 2010 12:36 AM
To: Spurling, Shannon
Cc: wg-multicast
Subject: Re: inter-domain MSDP peering without BGP FIRT

MSDP default peer would short-circuit any problem, but it would also
render the second MSDP peering useless. We have setup dual BGP and
MSDP peerings with different GRNET routers in order to provide
redundancy.

Thanks for the feedback!

Z.

On 11 Ιουν 2010, at 5:17 ΜΜ, Spurling, Shannon wrote:

> I am going to tell you of a solution I have used with Cisco routers
> with reasonable success. You have to be careful about this. I use it
> mainly with peers with their own PIM domains and no BGP, or the MSDP
> peer/PIM-RP being deep inside their network.
>
> Use MSDP default-peer and filter the heck out of the SA's, so that
> only SA's with their prefixes come from the site, and SA's without
> their prefixes go to the site.
>
>
> Shannon Spurling
> WAN Engineer
>
>
>
> -----Original Message-----
> From: Zenon Mousmoulas
> [mailto:]
> Sent: Thursday, June 10, 2010 12:57 PM
> To: wg-multicast
> Subject: inter-domain MSDP peering without BGP FIRT
>
> Dear all,
>
> We (GRNET) have a downstream network (let's call them U) who receive a
> partial routing table from us. U runs BGP and MSDP peerings on a
> single border router (RP in their PIM domain) with two distinct GRNET
> routers (anycast RPs in the GRNET domain, running full-mesh IBGP and
> MSDP). The BGP peerings are setup in a primary/backup scheme (using
> communities, local pref etc). BGP peerings carry both unicast and
> multicast NLRIs, but we use separate sessions for IPv4 and IPv6.
> Pretty standard stuff.
>
> Since U receive only a partial routing table, they rely on the
> "default network" mechanism for internet routing. This gateway of last
> resort is configured once and, AFAIK, can't be set separately per
> NLRI. Since IOS (12.2SXF in their case) performs RPF lookups across
> both the MRIB and the unicast RIB, it seems to work out fine: "show ip
> rpf" points to the default network when no prefix matches the source,
> with a "unicast" RPF type. However MSDP peer-RPF check fails: SA
> announcements are rejected when no prefix matches the RP/Originator,
> so the default network doesn't apply in this case, or so it seems.
>
> MSDP debug also logs messages like this:
>
> Jun 7 18:15:33: MSDP(0): <grnet-msdp-peer>: Peer RPF check failed for
> w.x.y.z, used IBGP route's peer 0.0.0.0
>
> which don't make much sense.
>
> Judging from the above, it looks like we effectively can not MSDP peer
> with a downstream network without announcing to them (the equivalent
> of) FIRT in MBGP. Of course this is not a big issue while the number
> of prefixes is low, however there are still practical reasons against
> this, namely avoiding incongruent routing.
>
> Have you ever noticed this? I have a feeling that enforcing compliance
> to RFC3618 (ip msdp rpf rfc3618) would affect this behavior, but I'm
> not even sure if their border router supports it.
>
> Thanks in advance,
> Z.
>




Archive powered by MHonArc 2.6.16.

Top of Page