[AG-TECH] Beacon enhancement

Marty Hoag Marty_Hoag at NDSU.NODAK.EDU
Fri Mar 23 16:45:42 CST 2001

   We were reminded again today that while the beacon is very good at
giving an overall picture of multicast availability, it has some blind
spots.  The one we ran into was the fact that the beacon, once it is
going, doesn't test joins.  The group has mostly persistent sources and
traffic which means that state is kept in all the various routers even
if MSDP has failed.

   This morning we ran into this when the UKy porta-node wasn't getting
Source Announcements out to Abilene.  The beacon looked fine but those
of us who had left the venue last night couldn't receive video from UKy
because we couldn't get the source information.

   Since Don Morton has been touting UTC (Universal Coordinated Time in
English - or did I transpose the letters?) it got me thinking.  At first
I thought maybe the beacons should pick the last octet of the group to
use based on the UTC/GMT hour of the day.  But then I realized we really
could do this with two groups - specify an even group for even UTC hours
and use an odd one for odd hours.  That way the various beacons would
have to join a new group each hour and that would force end-to-end tests
of join/PIM register/SA propogration, etc.  Maybe by convention the even
group would be indicated in config and the beacon would simply add 1 for
odd hours.

   I realize this would probably cause problems with unsynced hosts (but
then Lisa might like it if people paid attention to that), get messy on
the hour boundaries, and maybe make long term tracking somewhat
confusing.  But it would allow more constant data (I had once thought
about every beacon stopping for 10 minutes each hour or something) and
it would exercise join/PIM/MSDP stuff each hour. 


More information about the ag-tech mailing list