All things related to multicast

[Robert Beverly <>]

Hitesh,

So your RPF check is broken.  You should be RPF checking against 
your MBGP table rather than building static multicast routes.
Please remember that I speak for the vBNS (AS145) and simply
picked AS7050 as an example, so your notion of "adding a 
static route to u" is probably misguided.  If you want to
know active sources in AS7050, please look at your MSDP SA
cache which we (vBNS) are sending to you.    

We're looking forward to seeing the correct data from your
MSDP comparison application.  If you'd like further help
from the vBNS, let's continue this discussion off-list.  

Thanks,

rob

On Fri, Jun 15, 2001 at 03:20:20PM -0400, Hitesh Ruparel wrote:
> hi rob..
> 
> when i say sh ip rpf 129.89.5.3 i get
>  RPF interface: Serial 3/2:1 which is our sprint link but it
> is supposed to show Serial3/2:0 which is vbns since the
> entire as path from u to us is 7050 11537 145(vbns)....
> 
> so i intend to add a static route to u and force the rpf
> interface to Serial 3/2:0...so if u could provide me with
> one of your active sources ip and multicast group address
> that should help me..
> 
> rgds
> hitesh
> 
> On Thu, 14 Jun 2001 16:48:19 -0400
>  Robert Beverly 
> <>
>  wrote:
> > 
> > Marshall,
> > 
> > To address some of the specifics you mention, I randomly
> > chose an 
> > AS you reach via the vBNS that you are having trouble
> > with (from your http://www.multicasttech.com/status/map.msdp
> > page):
> > 
> > AS   7050  UW-MILWAUKEE-AS1                :    UNKNOWN :
> > 3 hops : as path   145 11537  7050
> > 
> > Looking at our MSDP session with Abilene, I see us
> > actively receiving and 
> > accepting SAs from this AS:
> > 
> > Jun 14 20:03:10.494: MSDP: 204.147.128.14: Received
> > 920-byte msg 30110803 from peer
> > Jun 14 20:03:10.494: MSDP: 204.147.128.14: SA TLV, len:
> > 920, ec: 1, RP: 129.89.5.3, with data
> > Jun 14 20:03:10.494: MSDP: 204.147.128.14: Peer RPF check
> > passed for 129.89.5.3, used EMBGP peer
> > Jun 14 20:03:10.494: MSDP: (129.89.125.91/32,
> > 224.2.127.254/32), accepted
> > 
> > Looking at all of the SAs originating from this AS, I see
> > 5 sources in
> > total:
> > 
> > cs.dng#sh ip msdp sa-cache 7050
> > MSDP Source-Active Cache - 2074 entries
> > (129.89.125.91, 224.2.225.67), RP 129.89.5.3, MBGP/AS
> > 7050, 11:41:15/00:05:25
> > (129.89.125.91, 224.2.229.193), RP 129.89.5.3, MBGP/AS
> > 7050, 11:41:15/00:05:25
> > (129.89.143.200, 224.0.14.1), RP 129.89.5.3, MBGP/AS
> > 7050, 05:41:43/00:05:25
> > (129.89.143.200, 224.0.14.1), RP 129.89.5.2, MBGP/AS
> > 7050, 00:41:33/00:02:37
> > (129.89.125.91, 224.2.127.254), RP 129.89.5.3, MBGP/AS
> > 7050, 11:41:15/00:05:25
> > 
> > Debugging our MSDP session with you, I see us sending you
> > these same SAs:
> > 
> > Jun 14 19:28:31.986: MSDP: Forward decapsulated SA data
> > for (129.89.125.91, 224.2.127.254) on ATM1/0/0.2
> > 
> > We currently have 2087 entries in our MSDP cache on the
> > RP that peers
> > with you.  
> > 
> > We are sending you a MBGP route for this prefix with AS
> > PATH
> > 145 (vbns), 11537 (abilene), 7050 (umn):
> > 
> > >
> >  show route advertising-protocol bgp
> > 204.147.129.90 
> > range 129.89/16 table inet.2           
> > 
> > inet.2: 4831 destinations, 4831 routes (4831 active, 0
> > holddown, 0 hidden)
> > Prefix             Nexthop                MED    Lclpref
> > AS path
> > 129.89.0.0/16      Self
> > 11537 7050 I
> > 
> > In summary, taking this single AS as an example, you
> > should be seeing
> > SAs for AS7050 "locally" and it should not be listed in
> > your list of
> > "sources seen remotely but not in local MSDP." The other
> > ASes in 
> > this list you should also be seeing.
> > 
> > Since MSDP floods SAs, it depends on RPF checks in order
> > to select the
> > best SA.  Depending on your other peering sessions, you
> > may still be
> > receiving our SAs, but not accepting them (section 14.2
> > of the ietf msdp
> > draft details the peer RPF rules).  Indeed there are a
> > number of ASes
> > in your list that transit the vBNS AS145 that are,
> > according to your
> > list, "working."  See AS25, AS1257, AS1706, AS5078, etc.
> > 
> > It appears that we are sending you all of the expected
> > informatino and
> > we see no evidence of a problem.  We tried contacting you
> > by phone and
> > but were not able to get ahold of you.  Please feel free
> > to contact me
> > or any of the other vBNS engineers offline if you would
> > like to discuss
> > this further.  Best regards,
> > 
> > rob
> > 
> > On Wed, Jun 13, 2001 at 04:37:39PM -0400, Marshall
> > Eubanks wrote:
> > > Hello;
> > > 
> > >    I would like to introduce both Hitesh Ruparel
> > <>,
> >  our new summer
> > > Intern (and a grad student at U. Missouri Kansas City)
> > and our new MSDP monitoring project. The basic idea
> > > is
> > > 
> > > 1.) At a location, take the MBGP tables and the
> > received MSDP SA messages and form a map of the tree from
> > the local AS (in our case, 16517) to
> > > everywhere else. This is located at
> > > 
> > > http://www.multicasttech.com/status/map.msdp
> > > 
> > > (The status ID's are
> > > 
> > >  SOURCE  - MSDP SA are seen locally
> > >  GOOD    - A transit AS for MSDP SA seen locally
> > >  UNKNOWN - No MSDP SA are seen locally for this AS,
> > directly or in transit )
> > > 
> > > 2.) Take MSDP lists from elsewhere, and compare the
> > sources seen from remote locations to what's seen
> > locally.
> > > This comparison is shown at
> > > 
> > > http://www.multicasttech.com/status/compare.msdp
> > > 
> > > and uses msdp info kindly provided from Bill Fenner
> > (for FIXW), Bill Nickless (at mcs.anl.gov) and Tim
> > > Winders (at SPC.cc.tx.us).
> > > 
> > > The following information is available
> > > 
> > > 1.) A list of ASN with multicast sources that  do not
> > appear in our MBGP tables. This indicates a problem with
> > MBGP
> > > convergance.
> > > 
> > > 2.) A list of ASN with sources that we see, but were
> > seen by NONE of the remote sites.
> > > 
> > > 3.) A list of ASN with sources that we did NOT see, but
> > were seen by at least one remote site.
> > > 
> > > AND, there are two lists of inferred problems :
> > > 
> > > 4.) A list of possible "black holes" for us, ASN
> > through which we see NO sources, even though we should
> > have.
> > > 
> > > 5.) A list of seeming inconsistencies, sources that we
> > see sources in transit through, but that have a source we
> > do not
> > > see or are directly attached to an ASN  with a source
> > we do not see.
> > > 
> > > >From this I have found that the biggest problems seem
> > to be associated with inconsistent routes. Look at our
> > MBGP for
> > > AS 11537 - Abilene -
> > > 
> > > for 11537 : as path   145    24   11537
> > > 
> > > for some ASN, transit through  11537  goes through
> > Sprint  - AS 1239 :
> > >  AS     32  STANFORD                        :
> > SOURCE :   4 hops : as path  1239 11537 11423    32
> > >  AS    557  UMAINE-SYS-AS                   :
> > SOURCE :   4 hops : as path  1239 11537 10578   557
> > >  AS   3506  FSU-SCRI                        :
> > SOURCE :   4 hops : as path  1239 11537  2553  3506
> > >  AS   5739  UCSC                            :
> > UNKNOWN :   4 hops : as path  1239 11537 11423  5739
> > >  AS   6200  UIC-AS                          :
> > SOURCE :   3 hops : as path  1239 11537  6200
> > >  AS   6366  PDXNET                          :
> > UNKNOWN :   5 hops : as path  1239 11537   101 14262
> > 6366
> > > 
> > > 
> > > for a long list of ASN, the transit is directly through
> > 11537 and vBNS
> > >  AS      3  MIT-GATEWAYS                    :
> > UNKNOWN :   4 hops : as path   145 11537 10578     3
> > >  AS      9  CMU-ROUTER                      :
> > UNKNOWN :   4 hops : as path   145 11537  5050     9
> > >  AS     17  PURDUE                          :
> > UNKNOWN :   3 hops : as path   145 11537    17
> > >  AS     38  UIUC                            :
> > UNKNOWN :   4 hops : as path   145 11537  1224    38
> > >  AS     59  WISC-MADISON-AS                 :
> > UNKNOWN :   3 hops : as path   145 11537    59
> > >  AS     70  NLM-GW                          :
> > UNKNOWN :   4 hops : as path   145 11537 10886    70
> > >  AS     73  WASHINGTON-AS                   :
> > UNKNOWN :   4 hops : as path   145 11537   101    73
> > >  AS     81  CONCERT                         :
> > UNKNOWN :   3 hops : as path   145 11537    81
> > >  AS     87  INDIANA-AS                      :
> > UNKNOWN :   4 hops : as path   145 11537 10680    87
> > >  AS    104  COLORADO-AS                     :
> > UNKNOWN :   3 hops : as path   145 11537   104
> > >  AS    111  BOSTONU-AS                      :
> > UNKNOWN :   4 hops : as path   145 11537 10578   111
> > >  AS    131  UCSB-NET-AS                     :
> > UNKNOWN :   4 hops : as path   145 11537 11422   131
> > >  AS    159  SONNET-AS                       :
> > UNKNOWN :   4 hops : as path   145 11537  3112   159
> > >  AS    160  U-CHICAGO-AS                    :
> > UNKNOWN :   3 hops : as path   145 11537   160
> > >  AS    194  USAN-AS                         :
> > UNKNOWN :   3 hops : as path   145 11537   194
> > >  AS    210  WEST-NET-WEST                   :
> > UNKNOWN :   3 hops : as path   145 11537   210
> > >  AS    225  VIRGINIA-AS                     :
> > UNKNOWN :   3 hops : as path   145 11537   225
> > > etc
> > > 
> > > We seem to have no problems with MSDP transiting
> > through  Sprint - but NONE of the sources transiting
> > through
> > > AS 145 made it through. This might be as simple a
> > problem as RPF failures in vBNS.
> > > 
> > > At any rate, I would like to call for people to help
> > Hitesh and me get this project rolling.
> > > We would like to encourage people to set up an
> > automatic e-mailing of the results of
> > > 
> > > show ip msdp count
> > > 
> > > (for Cisco routers - I would be glad to parse similar
> > information from other routers) to
> > > us at 
> > > 
> > >  .
> > > 
> > > I think that it would be good to do this 4 times per
> > day, at the "cannonical measurement times"
> > > of 0, 6, 12 and 18 UTC.
> > > (That's 28, 14 and 20 hours EDT.)
> > > 
> > > If anyone would like to get the code to run this, they
> > are welcomed to it. Please contact me.
> > > 
> > > We plan to start contacting the relevant NOCs and
> > network admins soon to FIX some of these problems.You've
> > > been warned !
> > > 
> > >                                  Regards
> > >                                  Marshall Eubanks
> > > 
> > > 
> > > 
> > > T.M. Eubanks
> > > Multicast Technologies, Inc
> > > 10301 Democracy Lane, Suite 410
> > > Fairfax, Virginia 22030
> > > Phone : 703-293-9624       Fax     : 703-293-9609
> > > e-mail : 
> > > 
> > > http://www.on-the-i.com
> > > 
> > > Test your network for multicast :
> > http://www.multicasttech.com/mt/
> > >  Check the status of multicast in real time :
> > >  http://www.multicasttech.com/status/index.html
> > > 
> > 
> > -- 
> > Robert Beverly 
> > <>
> > Worldcom Advanced Internet Technology
> > (703)886-1919 [Office] / (703)886-0049 [Fax]
> 

-- 
Robert Beverly 
<>
Worldcom Advanced Internet Technology
(703)886-1919 [Office] / (703)886-0049 [Fax]