problems in multicast land

[Rogier, Gordon]

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