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

Hi Petr,

I read the ECMP logic. I cant understand one thing . what is Polarization
concept which is used to load-split traffic.
They say that the CEF load splitting logic and Multicast Load Spliting are
identical.Can u explain me how it is identical?

On Tue, Aug 2, 2011 at 10:10 AM, <letjedilakopa_at_gmail.com> wrote:

> 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
>
> _______________________________________________________________________
> 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
>
>
>
>
>
>
>
>

-- 
Problems arise because we talk,problems are not solved because we don't talk
So good or bad talk to your affectionate one's freely.
Yours Friendly,
H P HEMANTH RAJ
CCIE#28593 (R&S)
Cisco Systems
Blogs and organic groups at http://www.ccie.net