Re: static mroute + MBGP + unicast route : which route is

Really nice write up Petr. Great stuff here.

On Sun, Jul 31, 2011 at 6:28 PM, Petr Lapukhov
<petr_at_internetworkexpert.com>wrote:

> Imran,
>
> To begin with, RPF check could be classified as either data-plane or
> control-plane. Data-plane RPF check is applied when router receives a
> multicast packet, to validate if the interface and upstream host match the
> RPF information. For data-plane multicast, the packet must be received from
> an active PIM neighbor, or RPF check would fail. Control-plane RPF check is
> performed when originating/receiving control-plane messages, such as
> sending
> PIM Join or receiving MSDP SA message. With PIM, RPF checks influences the
> actual multicast path selection, since it carves the route that PIM Join
> message would take. In both control and data-plane RPF check cases, the
> process is similar, and based on looking through all available RPF sources.
>
> The following is the list of possible RPF sources:
>
> 1) Unicast routes, static/dynamic (e.g. via OSPF)
> 2) Static mroutes, configured locally
> 3) Multicast extension routes, such as those learned via M-BGP
>
> The process of finding the RPF source information is different from unicast
> routing table lookup. It is not based on the longest-match rule, but rather
> the best source is selected based on the *best administrative distance*.
> The
> router selects best matching prefix from both unicast table (based on
> longest match) and static multicast routing table and compares their AD's,
> to select the best one. For mroute table, the order you configure static
> mroutes with is important - the FIRST matching route is selected, *not* the
> longest-matching one.
>
> By default, when you configure a static mroute, its distance is zero. Thus,
> for example, if you have a static default mroute "ip mroute 0.0.0.0
> 0.0.0.0"
> it will always be used over any longer-matching unicast prefix, since it
> matches everything and have the AD of zero. What if you want prefix
> 192.168.1.0/24 to be RPF checked again unicast table while the rest
> against
> the default mroute? You can configure something like this:
>
> ip mroute 192.168.1.0 255.255.255.0 null 0 255
> ip mroute 0.0.0.0 0.0.0.0 Serial 0/0/0.1
>
> Like mentioned before, the order of mroute statement is important here,
> since the FIRST matching static mroute is selected. What this configuration
> means, is that for sources in the range 192.168.1.0/24 the first matching
> static mroute has the AD of 255 and thus would be always *less* preferred
> as
> compared to unicast table. However, for all other sources, the default
> mroute with the distance of zero will be elected. If you put the static
> default mroute *ahead* of the specific mroute the trick will not work - the
> default mroute will always match anything.
>
> What if mroute and unicast route have the same admin distance? In this
> case,
> the static mroute wins, unless it is compared against directly attached
> route or *default route*. In the latter case, unicast direct or unicast
> default route would ace the mroute.
>
> Finally, what about M-BGP? M-BGP routes are treated the same way as static
> mroutes, but having distance of BGP process (110 or 20). However, when
> looking up for the best matching M-BGP prefix, a longest match is performed
> and selected for comparison, unlike linear ordering used for mroutes. Think
> of the following scenario: your router receives a unicast default route via
> OSPF and prefix 192.168.1.0/24 via M-iBGP session. A packet with the
> source
> address 192.168.1.100 arrives - what would be used for RPF check? It would
> be OSPF default route, because of OSPF's distance 110 and BGP's distance
> 200
> for iBGP. You can solve this problem by lowering BGP's distance or
> increasing OSPF's distance or resorting to static mroute for the source
> prefix.
>
> For the last question - what happens if router has multiple equal-cost
> paths
> to the source. Firstly, only those routes that point to the PIM neighbors
> would be used. Secondly, the router will use the entry with the higher PIM
> neighbor IP address. This will effectively eliminate uncertainty in RPF
> decision. However, it is possible to use equal-cost multicast splitting,
> which is a separate IOS feature:
>
>
> http://www.cisco.com/en/US/docs/ios/12_4t/ip_mcast/configuration/guide/mctlsplt.html#wp1070778
>
> This feature allows splitting multicast trees among different RPF paths and
> accept packets from multiple RPF sources. However, for the classic
> multicast, there is only one RPF interface.
>
> HTH
>
> --
> Petr Lapukhov, petr_at_INE.com
> CCIE #16379 (R&S/Security/SP/Voice)
> CCDE #20100007
>
> Internetwork Expert, Inc.
> http://www.INE.com
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
> 2011/7/31 imran ali <immrccie_at_gmail.com>
>
> > hi gurus
> >
> > 1) what is order of prefrence for RPF process if the router has all the
> > options
> >
> > * MBGP learned routes*
> >
> > * default static mroute point towards e0/0 (entered last) *
> > * /32 host Mroute of multicast server pointing towards e0/1*
> > * *
> > * unicast route pointing towards s0/0*
> > **
> > **
> > 2) how do i check the contents of MULTICAST TABLE which contains
> MULTICAST
> > BGP ROUTES OR STATIC MROUTES
> >
> > 3) IF There are two routes pointing to server (equal cost laod balancing
> )
> > then both of them is present in unicast routing table , the on what basis
> > on
> > route will be discarded and other will be selected as RPF neighbor.
> >
> >
> >
> > 4) TRUE OR FALSE : THE ROUTES LEARNED BY MULTICAST BGP ARE ONLY FOR
> > INFLUNCING RFP DECISIONS .....U STILL NEED A UNICAST ROUTE FOR
> RECHABILITY
> > .
> > TO THE SOURCE .... MBGP ROTUES CANNOT INFLUENCE EIHTER MULTICAST OR
> UNICAST
> > FLOW
> >
> > thanks
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Regards,
Joe Astorino
CCIE #24347
Blog: http://astorinonetworks.com
"He not busy being born is busy dying" - Dylan
Blogs and organic groups at http://www.ccie.net