problems in multicast land

Bill Nickless nickless at mcs.anl.gov
Fri Jul 7 12:02:59 CDT 2000


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




More information about the ag-tech mailing list