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