From: Joe Higgins (netsat@xxxxxxxxxxxxx)
Date: Thu Aug 15 2002 - 09:07:17 GMT-3
Frank,
I did not use auto-rp in my scenerio. I kept it as simple as possible and
used static rp mapping to the rp on rtr C. Also there was no (*,G) entry
for 226.0.6.6 on rtr A after I did pings from rtr A. I tried putting ip
pim nbma on the interfaces on rtr B with no success. When I changed the
connection from rtr A to trtr B to a point-to-point interface it works. It
must have something to do with frame psuedo interface broadcasts on the
physical multipoint frame interfaces on rtr B.
Frank B wrote:
> I wish you'd have shown the result of a sh ip mroute from rtrA...it
> should have a (*,G) entry for 226.0.6.6 as well. If so it should
> work...I answered a similar question last week. Except possibly...I
> noticed something weird...your entries on rtrB and rtrC for 224.0.1.40
> show the S flag...meaning it's a sparse mode group. It MUST be a dense
> mode group (along with 224.0.1.39)! I'd reload these boxes. If these
> groups were sparse how would you know where the rp was to join the
> shared tree toward in the begining? After all, you don't know the rp
> that's why you want auto-rp...right? You'd be stuck in the
> chicken-and-egg situation. Check the archives on that one.
>
> Also, I see some folks are recommending using ip pim nbma-mode. I don't
> believe that's the answer (I'm not even sure there's a problem.) Here's
> why, this command is designed for partial-mesh hub and spoke topologies
> where the hub and spokes are on the same subnet. If you try that
> topology sometime you'll notice just one entry in the outgoing interface
> list (OIL) for the frame/serial interface. After configuring ip pim
> nbma-mode multiple entries are in the OIL one for each spoke using PIM.
> Now you won't have one rtr send a prune and the hub router cutting off
> traffic...since without ip pim nbma-mode the spokes don't hear the prune
> and therefore won't send an override. I don't think it will hurt but I
> also don't think it's necessary.
>
> And just a note to set up the next comment...remember, ip igmp
> join-group 224.0.6.6 means "I want to be a receiver for traffic sent to
> group 224.0.6.6" On the other side of the coin, when you issue a ping
> to a multicast group address you're sending or "sourcing" packets from
> yourself to a mutlticast address--your're now a multicast traffic
> source!
>
> Anyway, back to your question...Did you ping "several" times? I set
> this up before and it takes about 8-12 pings before you get a response.
> This should work--I've seen it. It seems (read I'm not sure) to take
> some time to set up another path back to the source of the ping...maybe
> because the trees in PIM are unidirectional--I really don't know though.
> Not sure if the return packet is plain ole ICMP or not?...anyone else
> know? That last one's just a theory...I'm NOT a multicast expert...as
> always check it out for yourself. Your mileage may vary ;-)
>
> HTH...later, Frank
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Joe Higgins
> Sent: Wednesday, August 14, 2002 3:08 PM
> To: 'ccielab@groupstudy.com'
> Subject: [Fwd: multicasting sparse mode accross frame relay]
>
> Just to add that if I change serial 1 interface on both rtr A and rtr B
> to a subinterface point-to-point it works?
> Date: Wed, 14 Aug 2002 19:33:23 -0400
> From: Joe Higgins <netsat@optonline.net>
> Subject: multicasting sparse mode accross frame relay
> To: "'ccielab@groupstudy.com'" <ccielab@groupstudy.com>
> Message-id: <3D5AE8C2.91803F33@optonline.net>
> MIME-version: 1.0
> X-Mailer: Mozilla 4.5 [en] (Win98; I)
> Content-type: text/plain; charset=us-ascii
> Content-transfer-encoding: 7BIT
> X-Accept-Language: en
> X-Mozilla-Status2: 00000000
>
> I need some help on a multicasting problem:
> I have three routers in the following configuration:
>
> rtrA ser1 <--- > ser1 rtrb ser0 <--> ser0 rtrC
> All indicated physical interfaces are running frame relay
> rtr C has a 224.0.6.6 igmp join on loop 0
> all routers have sparse mode on the intefaces and point to rtr C as the
> RP
> I cannot ping 224.0.6.6 from rtr A but I can ping it from rtr B
> Rtr B sees rtr A as the source of the multicast but it does not have
> seria;l 0 as an outgoing interface.
>
> In summary it appears that I cannot route multicast on router B through
> its two physical frame relay interfaces.
>
> The following is the relavent configs and show commands after I cleared
> all mroutes and only tried pings from rtr A. Any help would be
> appreciated.
>
> A#sh ip pim rp
> Group: 224.0.1.40, RP: 1.9.12.2, v1, uptime 00:45:48, expires 00:04:17
>
> interface Serial1
> ip address 1.9.14.4 255.255.255.0
> ip pim sparse-mode
> encapsulation frame-relay
> ip ospf network point-to-multipoint
> clockrate 64000
> frame-relay map ip 1.9.14.1 200 broadcast
> A#p 224.0.6.6
>
> Type escape sequence to abort.
> Sending 1, 100-byte ICMP Echos to 224.0.6.6, timeout is 2 seconds:
> .
> A#p 224.0.6.6
>
> Type escape sequence to abort.
> Sending 1, 100-byte ICMP Echos to 224.0.6.6, timeout is 2 seconds:
> .
> ---------------------------------------
> router B
>
> B#sh ip pim rp
> Group: 224.0.1.40, RP: 1.9.12.2, v1, uptime 00:50:28, expires 00:04:13
> Group: 224.0.6.6, RP: 1.9.12.2, v2, uptime 00:06:36, expires never
>
> interface Serial0
> ip address 1.9.12.1 255.255.255.0
> ip pim sparse-mode
> encapsulation frame-relay
> ip ospf network point-to-multipoint
> no ip mroute-cache
> ipx network 12
> frame-relay map ip 1.9.12.2 108 broadcast
> no frame-relay inverse-arp
> !
> interface Serial1
> ip address 1.9.14.1 255.255.255.0
> ip pim sparse-mode
> encapsulation frame-relay
> ip ospf network point-to-multipoint
> no ip mroute-cache
> ipx network 14
> clockrate 64000
> frame-relay map ip 1.9.14.4 100 broadcast
> frame-relay interface-dlci 100
> no frame-relay inverse-arp
>
> B#sh 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 - Candidate for MSDP Advertisement
> Outgoing interface flags: H - Hardware switched
> Timers: Uptime/Expires
> Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 224.0.1.40), 00:00:27/00:00:00, RP 1.9.12.2, flags: SJCL
> Incoming interface: Serial0, RPF nbr 1.9.12.2
> Outgoing interface list:
> Loopback0, Forward/Sparse-Dense, 00:00:27/00:02:32
> Serial1, Forward/Sparse, 00:00:07/00:03:22
>
> (*, 224.0.6.6), 00:00:17/00:02:59, RP 1.9.12.2, flags: SP
> Incoming interface: Serial0, RPF nbr 1.9.12.2
> Outgoing interface list: Null
>
> (1.9.14.4, 224.0.6.6), 00:00:17/00:02:42, flags: PT
> Incoming interface: Serial1, RPF nbr 1.9.14.4
> Outgoing interface list: Null
>
> B#
>
> ------------------------------------------------------------------------
>
> C#sh ip pim rp
> Group: 224.0.1.40, RP: 1.9.12.2, v1, next RP-reachable in 00:01:27
> Group: 224.0.6.6, RP: 1.9.12.2, next RP-reachable in 00:01:27
>
> interface Loopback0
> ip address 139.9.2.2 255.255.255.0
> ip pim sparse
> ip ospf network point-to-point
> ip igmp join-group 224.0.6.6
>
> interface Serial0
> ip address 1.9.12.2 255.255.255.0
> ip pim sparse-mode
> encapsulation frame-relay
> ip ospf network point-to-multipoint
> frame-relay map ip 1.9.12.1 801 broadcast
> frame-relay map ip 139.9.12.1 801 broadcast
> no frame-relay inverse-arp
>
> C#sh 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 - Candidate for MSDP Advertisement
> Outgoing interface flags: H - Hardware switched
> Timers: Uptime/Expires
> Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 224.0.1.40), 00:11:40/00:00:00, RP 1.9.12.2, flags: SJCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> Serial0, Forward/Sparse, 00:10:46/00:03:01
> Loopback0, Forward/Sparse, 00:11:40/00:02:14
>
> (*, 224.0.6.6), 00:11:40/00:00:00, RP 1.9.12.2, flags: SJCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> Loopback0, Forward/Sparse, 00:11:40/00:02:18
>
> C#
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:26 GMT-3