problems in multicast land

[Rogier, Gordon]

This morning KU was able to flush the erroneous "192.5.170.0/24" ghost route
from it's routers.  KU is now back to using internal RP points for multicast
and it all appears to be working fine.

Again my thanks to Nickless and Winkler on this issue.

:grogier.

> -----Original Message-----
> From: Rogier, Gordon [mailto:grogier at UKANS.EDU]
> Sent: Monday, July 10, 2000 11:30 AM
> To: ag-tech at mcs.anl.gov
> Cc: Linda Winkler
> Subject: RE: problems in multicast land
> 
> 
> 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
>