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

Petr, you are the legend ;)

K
Sent via my BlackBerry from Vodacom - let your email find you!

-----Original Message-----
From: Petr Lapukhov <petr_at_internetworkexpert.com>
Sender: nobody_at_groupstudy.com
Date: Mon, 1 Aug 2011 11:15:27
To: Joe Astorino<joeastorino1982_at_gmail.com>
Reply-To: Petr Lapukhov <petr_at_internetworkexpert.com>
Cc: imran ali<immrccie_at_gmail.com>; Cisco certification<ccielab_at_groupstudy.com>
Subject: Re: static mroute + MBGP + unicast route : which route is
  picked by RPF officer ?

Hi guys,

I need to add a correction, which I should fully verify later (I mentioned
that in the blog post already): it appears in all recent version of code the
static mroute table is looked up based on longest-match, not the "linear
order" as the documentation states. This could be validated using the "show
ip rpf" command, but I should verify this extensively. Fortunately or not,
it's not like we're using multiple overlapping mroutes often :)
2011/8/1 Joe Astorino <joeastorino1982_at_gmail.com>

> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
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
Blogs and organic groups at http://www.ccie.net