All things related to multicast

[Robert Beverly <>]

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]