problems in multicast land
grogier at ukans.edu
Mon Jul 10 11:30:15 CDT 2000
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
188.8.131.52/24 nlri unicast origination. Now the KU routers are only seeing
the 184.108.40.206/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 220.127.116.11/23, but we can
not do a clean "show ip mbgp 18.104.22.168" 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 22.214.171.124/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 126.96.36.199 255.255.255.0".
>sh ip mbgp 188.8.131.52 255.255.255.0
BGP routing table entry for 184.108.40.206/24, version 694595
Paths: (0 available, no best path)
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 220.127.116.11/24, version 694595". (I have
compared this to another typical WAN set of entries for 18.104.22.168/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
More information about the ag-tech