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

From: Petr Lapukhov <petr_at_internetworkexpert.com>
Date: Sun, 31 Jul 2011 15:28:04 -0700

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
Received on Sun Jul 31 2011 - 15:28:04 ART

This archive was generated by hypermail 2.2.0 : Mon Aug 01 2011 - 06:30:06 ART