All things related to multicast

[Amel Caldwell <>]

I think we finally got this problem resolved.

In our initial setup, we had an MSDP peering session established on either end
of an OC3 connecting this customer.  Both interfaces on the routers had 'ip
pim bsr-border' and multicast boundaries defined.  The customer had his RP on
the Fast Ethernet interface on the same router, but was not able to generate
SA announcments.

After several gyrations and setting up a simulation, we resolved the problem
by moving the MSDP peering to be between the OC3 interface on my router and
the Fast Ethernet interface on the customer router (which was also the RP).
My only guess is that the multicast boundary was interfering and making it
impossible for the RP to propagate SAs to MSDP.

Thanks for all the input on this earlier.

Amel

On Thu, 31 May 2001, Marshall Eubanks wrote:

>Amel Caldwell wrote:
>
>> Hello all--
>>
>> I have a customer who I have been working with to get multicast working.  
>> They
>> are running 2 beacons (phantomworks.org) and can receive fine, the two can
>> send and recieve to/from each other, but cannot send to anyone else.
>>
>> This customer is part of our Gigapop AS, but runs their own RP.  We have 
>> MSDP
>> set up and the appropriate boundaries and pim bsr-border interface on their
>> link.  I have even tried putting in static mroutes and asking them to put 
>> in a
>> static default mroute to no avail.
>>
>> When I look at the router on my side, I see appropriate RPF info, the MSDP
>> session is up, but I don't see any entries in my sa-cache or my mcache.  I
>> have checked Abilene Core routers and University of Washington routers and
>> they see the IP address space via MBGP as I would expect.
>>
>> I asked my customer for some info from their router.
>>
>> sho ip pim rp
>> Group: 239.255.255.255, RP: 198.107.145.1, v2, v1, next RP-reachable in
>> 00:00:59
>> Group: 233.2.171.1, RP: 198.107.145.1, v2, v1, next RP-reachable in 
>> 00:00:39
>> Group: 224.2.127.254, RP: 198.107.145.1, v2, v1, next RP-reachable in 
>> 00:00:59
>>
>> THis is as it should be, although I am not sure why v1 also appears.
>>
>> sho ip pim int
>>
>> Address          Interface          Version/Mode    Nbr   Query     DR
>>                                                     Count Intvl
>> 198.107.145.1    FastEthernet1/0    v2/Sparse        0    30     
>> 198.107.145.1
>> 198.107.144.2    POS2/0             v2/Sparse        1    30     0.0.0.0
>>
>> sho ip pim neig
>> PIM Neighbor Table
>> Neighbor Address  Interface          Uptime    Expires   Ver  Mode
>> 198.107.144.1     POS2/0             3w3d      00:01:30  v2
>>
>> Both look okay.
>>
>> Here is where I think the problem is coming from:
>>
>> sho ip mcache
>> IP Multicast Fast-Switching Cache
>>
>> MSDP SA caching disabled
>>
>> sho ip mroute
>> IP Multicast Routing Table
>> Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
>>        R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
>>        M - MSDP created entry, X - Proxy Join Timer Running
>>        A - Advertised via MSDP
>> Outgoing interface flags: H - Hardware switched
>> Timers: Uptime/Expires
>> Interface state: Interface, Next-Hop or VCD, State/Mode
>>
>> [....SNIP....]
>>
>> (198.49.215.4, 233.2.171.1), 03:42:18/00:02:59, flags: CMT
>>   Incoming interface: POS2/0, RPF nbr 198.107.144.1, Mroute
>>   Outgoing interface list:
>>     FastEthernet1/0, Forward/Sparse, 03:42:18/00:02:37
>>
>> (198.107.145.4, 233.2.171.1), 00:00:31/00:02:28, flags: PCTA
>>   Incoming interface: FastEthernet1/0, RPF nbr 0.0.0.0
>>   Outgoing interface list: Null
>>
>> (198.107.145.5, 233.2.171.1), 00:01:22/00:01:37, flags: PCTA
>>   Incoming interface: FastEthernet1/0, RPF nbr 0.0.0.0
>>   Outgoing interface list: Null
>>
>> (198.124.224.24, 233.2.171.1), 03:43:00/00:02:59, flags: CMT
>>   Incoming interface: POS2/0, RPF nbr 198.107.144.1, Mroute
>>   Outgoing interface list:
>>     FastEthernet1/0, Forward/Sparse, 03:43:00/00:02:37
>>
>> [....SNIP....]
>>
>> The middle two entries are for their clients and the Outgoing interface is
>> NULL, which makes me think their router does not realize there are other
>> active sources for this group.
>>
>> I have asked them to be sure that 'msdp cache-sa-state' is enabled and that
>> mroute caching is enabled, but have not heard that they have enabled it.
>>
>> Does anyone else have any ideas on this?
>>
>> Thanks in advance
>>
>> Amel Caldwell
>>
>> UW NDC Network Engineering Services
>> phone: 206-685-6205  fax: 206-685-4044
>> email: 
>> 
>
>Well, you (Washington.edu) can hear us, as apparently can phantomworks.org.  
>You should have them try and
>mtrace to us.
>
>They (phantomworks.org) can hear much of the outside world according to 
>accessgrid. This says that they
>are getting MSDP from outside and processing it properly, so I do not see 
>why they shouldn't be able to talk to
>each other. You do not need msdp caching for this to work, although I 
>recommend it.
>
>Here are my mtraces :
>
>multicasttech-2>show ip mbgp 198.107.145.12
>BGP routing table entry for 198.107.145.0/27, version 5028
>Paths: (1 available, best #1, table NULL)
>Flag: 0x208
>  Not advertised to any peer
>  145 11537 101
>    204.147.129.89 from 204.147.129.89 (204.147.128.136)
>      Origin IGP, localpref 100, valid, external, best
>      Community: 6622136 6622236 6622336 9503719 756089782
>
>So we have mbgp routing to you.
>
>multicasttech-2>mtrace
>Source address or name: 198.107.145.12
>Destination address or name: 63.105.122.1
>Group address or name: 233.2.171.1
>Multicast request TTL [64]:
>Response address for mtrace:
>Type escape sequence to abort.
>Mtrace from 198.107.145.12 to 63.105.122.1 via group 233.2.171.1
>From source (?) to destination (dmz-mct2.multicasttech.com)
>Querying full reverse path... * switching to hop-by-hop:
> 0  dmz-mct2.multicasttech.com (63.105.122.1)
>-1  * * * Timed out receiving responses
>Perhaps no local router has a route for source, the receiver is not
>a member of the multicast group or the multicast ttl is too low.
>
>multicasttech-2>
>multicasttech-2>mtrace
>Source address or name: 128.208.140.202
>Destination address or name: 63.105.122.1
>Group address or name: 233.2.171.1
>Multicast request TTL [64]:
>Response address for mtrace:
>Type escape sequence to abort.
>Mtrace from 128.208.140.202 to 63.105.122.1 via group 233.2.171.1
>From source (D-128-208-140-202.dhcp3.washington.EDU) to destination 
>(dmz-mct2.multicasttech.com)
>Querying full reverse path...
> 0  dmz-mct2.multicasttech.com (63.105.122.1)
>-1  dmz-mct2.multicasttech.com (63.105.122.1) PIM/MBGP Reached RP/Core 
>[128.208.128.0/19]
>-2  sl-gw5-rly-9-0-0-TS19.sprintlink.net (160.81.38.225) [AS 1239] PIM/MBGP  
>[128.208.128.0/19]
>-3  sl-bb21-rly-0-0.sprintlink.net (144.232.25.244) [AS 1239] PIM/MBGP  
>[128.208.128.0/19]
>-4  sl-bb22-sj-6-0.sprintlink.net (144.232.9.125) [AS 1239] PIM/MBGP  
>[128.208.128.0/19]
>-5  sl-bb21-stk-13-0.sprintlink.net (144.232.9.170) [AS 1239] PIM/MBGP  
>[128.208.128.0/19]
>-6  sl-bb22-stk-15-0.sprintlink.net (144.232.4.242) [AS 1239] PIM/MBGP  
>[128.208.128.0/19]
>-7  sl-w1-mae-1-0-0.sprintlink.net (144.232.8.1) [AS 1239] PIM/MBGP Reached 
>RP/Core [128.208.128.0/19]
>-8  198.9.201.205 [AS 24] PIM/MBGP Reached RP/Core [128.208.128.0/19]
>-9  198.32.8.73 [AS 11537] PIM/MBGP Reached RP/Core [128.208.128.0/19]
>-10 scrm-snva.abilene.ucaid.edu (198.32.8.70) [AS 11537] PIM/MBGP Reached 
>RP/Core [128.208.128.0/19]
>-11 sttl-scrm.abilene.ucaid.edu (198.32.8.9) [AS 11537] PIM/MBGP Reached 
>RP/Core [128.208.128.0/19]
>-12 westincar2-S5-0-0.pnw-gigapop.net (198.48.91.77) [AS 73] PIM  
>[128.208.128.0/19]
>-13 uwbr3-GE0-0.cac.washington.edu (198.32.170.14) [AS 73] PIM Reached 
>RP/Core [128.208.140.0/24]
>-14 fusion-GE2-1.cac.washington.edu (128.208.129.5) [AS 73] PIM  
>[128.208.140.0/24]
>multicasttech-2>
>
>So I can mtrace to washington state but not the new location.
>
>Questions : Could there be RPF failures outbound ? Is the routing 
>assymmetric ? Are there multiple
>routes going out ?
>
>Look in the logs of the first hop router outside their domain. Does it
>show RPF failures coming from them ? Are SA messages being rejected ?
>
>You also might get them to do
>
>show ip msdp count
>show ip msdp sum
>
>and an mtrace to us or to you.
>--
>                                 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
>
>
>