problems in multicast land

[Rogier, Gordon]

This is primarily for Bill Nickless and Linda Winkler, but others (esp. at
KU) may want to know this for reference.  I believe that KU should have more
consistent [with other AG nodes] mcast application operation now.

KU has reconfigured to temporarily (most likely just for this week) to use
the upstream Great Plains Network I2 router for it's RP point.  The KU
border is a little happier, thanks to STARTAP removing the suspect
172.5.170.0/24 nlri unicast origination.  Now the KU routers are only seeing
the 192.5.170.0/23 in both unicast and multicast bgp, but there is still a
little quark in the local KU border router.

It basically looks like we are correctly seeing 192.5.170.0/23, but we can
not do a clean "show ip mbgp 192.5.170.2" and get a match up to this /23...
the router just does not seem to like to look it up.  I did some more
detailed 'stabs in the dark'...  it appears to me that the KU router has a
"ghost" of 192.5.170.0/24 tucked so deep in the routing tables (and I can
not get it to come out with clear router commands).  It is not in the "sh ip
bgp" or "sh ip mbgp" overview, but I get kind-of a ghost if I do a "show ip
mbgp 192.5.170.0 255.255.255.0".

  >sh ip mbgp 192.5.170.0 255.255.255.0
  BGP routing table entry for 192.5.170.0/24, version 694595
  Paths: (0 available, no best path)
  Flag: 0x208
    Not advertised to any peer

Note, it really does not find a route match ["0 available, no best path"],
but it does have some anomolous referrence to an earlier BGP table update of
"BGP routing table entry for 192.5.170.0/24, version 694595".  (I have
compared this to another typical WAN set of entries for 192.5.206.0/23).
Now I can not find a why to non-intrusively clear out this "version 694595"
set of information... I think I am going to have to schedule a removal of
the BGP process and reinstantiate it (or maybe even a reload of the router
in question) to be able to clear out this information.

So, for now, I do not think that changing the /23 into two /24s will make
any improvement.  I do believe that the earlier /24 from STARTAP sparked a
possible bug senario for me.

thanks to nickless and winkler for their quick help on this....

--
Gordon Rogier, grogier at ukans.edu, 785-864-0381
Network Design Specialist
NTS, University of Kansas, 1736 Engel Road, Lawrence, KS  66045-3843