problems in multicast land

[Linda Winkler]

ST behavior modified
lw

At 12:02 PM 7/7/2000 -0500, Bill Nickless wrote:

>Gordon,
>
>I'll be happy to call you in about an hour when I get into my office.
>
>Linda Winkler,
>
>could you please look at Gordon's note below and see if you can verify
>that STARTAP is originating a unicast route for 192.5.170.0/24?  I don't
>think STARTAP (AS 10764) should be originating that /24.  That might could
>explain the problems that Gordon is seeing.
>
>Thank you,
>   Bill Nickless
>
>On Fri, 7 Jul 2000, Rogier, Gordon wrote:
>
> > ok... this is targeted primarily at bill nickless.
> >
> > nickless, i would really like to discuss this verbally on the phone with
> > you... please call me at 785-550-4468 to discuss further.  i would like to
> > request that ANL changes their mcast source network origination of
> > "192.5.170.0/23 nlri multicast" into two separate "192.5.170.0/24 nlri
> > multicast" & "192.5.170.1/24 nlri multicast" origination configuration
> > statements ---or--- eliminate the STARTAP origination of "192.5.170.0/24".
> >
> > the actually problem (i am convinced) is a bug in the 12.1(2) ios level
> > [which i expect to report to Cisco for correct resolution] being used 
> at ku.
> > ku _can_ work around this problem, but i am concerned that other mcast 
> sites
> > interacting with ANL may need/be running a 12.1() ios level.  it may be 
> more
> > desirable for nickless to wholelisticly provide a "work-around" to this
> > problem as per my request here.
> >
> > nickless, ku is running a 12.1(2) ios level (and we just recently upgraded
> > to it).  yes we have to have 12.1() ios to get those lovely lan protocols
> > like atalk, decnet, ipx, etc.; we can not run 12.0()S train on campus.
> >
> > now, it has been appearing to me for a while that 12.1() operates a little
> > different with regards to how the RPF check against the MBGP and BGP 
> tables.
> > in this case, this is specifically effecting MSDP "peer-RPF" checks.  the
> > bottom line problem appears that the look up in the MBGP table is performed
> > by 12.1(2), it does not seem to want to find a _superset_ mbgp route entry,
> > when a unicast bgp more detailed (and possibly classed) route entry exists.
> > this problem exists for the MSDP "peer-RPF" check against the ANL RP of
> > 192.5.170.2.
> >
> > when checking against the ANL RP of 192.5.170.2, at the remote (eg. ku end)
> > the following is the result of the "peer-RPF" agains 192.5.170.2 and the
> > routes exist that relate:
> >
> > >show ip rpf 192.5.170.2
> >   RPF information for kiwi-loop.anchor.anl.gov (192.5.170.2)
> >     RPF interface: ATM5/0.733
> >     RPF neighbor: ks-2-a10-52.r.greatplains.net (164.113.234.206)
> >     RPF route/mask: 192.5.170.0/24
> >     RPF type: unicast (bgp 2496)
> >     RPF recursion count: 1
> >     Doing distance-preferred lookups across tables
> >
> > note, this match against the "unicast" type route will cause the MSDP SA
> > messages to be dropped; MSDP requires a "peer-RPF" check to match up 
> against
> > an MBGP type route.  why is it not finding the MBGP route??? good, question
> > and here is my speculation for that question... to me, it clearly 
> appears to
> > be a bug in the MBGP code.
> >
> > >show ip bgp  [filtered by hand not IOS command line]
> >   *> 192.5.170.0      164.113.234.206                        0 11317 11537
> > 10764 ?
> >   *> 192.5.170.0/23   164.113.234.206                        0 11317 11537
> > 683 i
> >
> > >show ip bgp 192.6.170.2    [works just fine]
> >   BGP routing table entry for 192.5.170.0/24, version 223740
> >   Paths: (1 available, best #1, table Default-IP-Routing-Table)
> >     Not advertised to any peer
> >     11317 11537 10764
> >       164.113.234.206 from 164.113.234.206 (164.113.238.101)
> >         Origin incomplete, localpref 100, valid, external, best
> >
> > >show ip mbgp  [filtered by hand not IOS command line]
> >   *> 192.5.170.0/23   164.113.234.206                        0 11317 11537
> > 683 i
> >
> > >show ip mbgp 192.6.170.2   [does not work  ??? clearly a bug... notice it
> > is trying to
> >                                do a "classed" network match of /24]
> >
> > clearly this MBGP command should resolve, but it does not... i think 
> this is
> > the ios bug that is causing us some growing pains.  i will report this to
> > cisco shortly.
> >
> > now, i tried to do some extensive comparitive rpf checks on other network
> > addresses that were non-congruent in the MBGP table vs the BGP 
> table.  i had
> > a lot of trouble finding another network with this exact same type of
> > non-congruencies in the route tables.
> >
> > i believe that in this specific case, the best "work-around" is to get the
> > unicast and mcast bgp table reasonably congruent starting at ANL (and/or
> > STARTAP).  reason, others may need to work around this issue if they are
> > running the 12.1() ios levels.
> >
> > what do you think nickless???
> >
> >