From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Dec 08 2005 - 11:16:46 GMT-3
224.4.4.4 is pruned on R1. You can see that for those (S,G) pairs the OIL is Null. Try joining a different group on the non-RP spoke. Also check the "show ip pim rp" and "show ip pim rp mapping"; Are you sure the RP is properly assigned?
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: Schulz, Dave [mailto:DSchulz@dpsciences.com]
> Sent: Thursday, December 08, 2005 8:09 AM
> To: Brian McGahan; ccielab@groupstudy.com
> Subject: RE: Multicast sparse-mode issue
>
> Brian -
>
> Ok....the "no ip mroute-cache" command does work on my rev, but I went
> ahead and did the debug as you stated. Here was the response when I did
> the ping from R3.....
>
> *Mar 2 11:16:53.187: IP(0): s=172.16.1.3 (Serial0/0.1) d=224.4.4.4
> id=443, prot=1, len=104(100), mroute olist null
>
> Correct me if I'm wrong....but it appears that the ping is getting to this
> hub, but being directed to Null. Here is what is in the "show ip
> mroute".....which I can see by the 2nd, 3rd and 4th entries....but is this
> happening at the non-RP router? Could this be a software bug?
>
> R1#sh ip mroute
> IP Multicast Routing Table
> Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, 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,
> U - URD, I - Received Source Specific Host Report,
> Z - Multicast Tunnel, z - MDT-data group sender,
> Y - Joined MDT-data group, y - Sending to MDT-data group
> Outgoing interface flags: H - Hardware switched, A - Assert winner
> Timers: Uptime/Expires
> Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 224.4.4.4), 13:22:09/stopped, RP 1.1.1.1, flags: SPLF
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list: Null
>
> (3.3.3.3, 224.4.4.4), 00:00:31/00:02:28, flags: PL
> Incoming interface: Serial0/0.1, RPF nbr 172.16.1.3
> Outgoing interface list: Null
>
> (30.1.1.1, 224.4.4.4), 00:00:31/00:02:28, flags: PL
> Incoming interface: Serial0/0.1, RPF nbr 172.16.1.3
> Outgoing interface list: Null
>
> (172.16.1.3, 224.4.4.4), 00:03:32/00:02:46, flags: PLT
> Incoming interface: Serial0/0.1, RPF nbr 0.0.0.0
> Outgoing interface list: Null
>
> (*, 224.0.1.39), 15:49:08/stopped, RP 0.0.0.0, flags: DCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> FastEthernet0/0, Forward/Sparse, 12:09:37/00:00:00
> Serial0/0.1, Forward/Sparse, 13:18:55/00:00:00
> Loopback0, Forward/Sparse, 15:49:09/00:00:00
> Serial0/0.2, Forward/Sparse, 15:49:09/00:00:00
>
> (1.1.1.1, 224.0.1.39), 08:27:03/00:02:56, flags: LT
> Incoming interface: Loopback0, RPF nbr 0.0.0.0
> Outgoing interface list:
> Serial0/0.2, Forward/Sparse, 08:27:03/00:00:00
> Serial0/0.1, Forward/Sparse, 08:27:03/00:00:00
> FastEthernet0/0, Forward/Sparse, 08:27:03/00:00:00
>
> (*, 224.0.1.40), 15:49:09/stopped, RP 0.0.0.0, flags: DCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> FastEthernet0/0, Forward/Sparse, 12:08:39/00:00:00
> Serial0/0.1, Forward/Sparse, 13:18:55/00:00:00
> Loopback0, Forward/Sparse, 15:49:09/00:00:00
>
> (1.1.1.1, 224.0.1.40), 13:15:49/00:02:19, flags: LT
> Incoming interface: Loopback0, RPF nbr 0.0.0.0
> Outgoing interface list:
> FastEthernet0/0, Forward/Sparse, 12:08:39/00:00:00
> Serial0/0.1, Forward/Sparse, 13:15:50/00:00:00
>
> R1#
>
>
> Dave Schulz,
> Email: dschulz@dpsciences.com
>
>
>
> -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: Thursday, December 08, 2005 9:01 AM
> To: Schulz, Dave; ccielab@groupstudy.com
> Subject: RE: Multicast sparse-mode issue
>
> Issue the "no ip mroute-cache" command on the hub's subinterface and
> then "debug ip mpacket". Ping from R3 and see what the hub is doing with
> the traffic.
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
>
> > -----Original Message-----
> > From: Schulz, Dave [mailto:DSchulz@dpsciences.com]
> > Sent: Thursday, December 08, 2005 7:54 AM
> > To: Brian McGahan; ccielab@groupstudy.com
> > Subject: RE: Multicast sparse-mode issue
> >
> > It's already on the s0/0.1 interface....should it be removed from the
> > physical? Or, is there a difference between how the nmba performs when
> > using physical vs. logical. It also is quite strange that that the ping
> > from R2 (which is the RP), shows the ping response from R3. Yet the
> ping
> > from R3 does not even show the response from R2. I would think that the
> > location with the RP function should at least provide a ping response.
> >
> >
> > Dave Schulz
> > Email: dschulz@dpsciences.com
> >
> >
> > -----Original Message-----
> > From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> > Sent: Thursday, December 08, 2005 8:52 AM
> > To: Schulz, Dave; ccielab@groupstudy.com
> > Subject: RE: Multicast sparse-mode issue
> >
> > Put the nbma mode command on the interface with the IP address.
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> > ________________________________________
> > From: Schulz, Dave [mailto:DSchulz@dpsciences.com]
> > Sent: Thursday, December 08, 2005 12:04 AM
> > To: Brian McGahan; ccielab@groupstudy.com
> > Subject: RE: Multicast sparse-mode issue
> >
> > Brian -
> >
> > Thanks for taking a look at my question. I appreciate it. I do have the
> > hub already set in nbma mode (R1)....see below. Also, as you can see
> from
> > the pings....I can ping from R2 to R3, but not from R3 to R2. Is that
> not
> > strange? I don't quite understand why.
> >
> > Dave
> >
> > -----Original Message-----
> > From: Brian McGahan
> > To: Schulz, Dave; ccielab@groupstudy.com
> > Sent: 12/8/2005 12:45 AM
> > Subject: RE: Multicast sparse-mode issue
> >
> > It depends on what you define the "correct" behavior as. The
> > hub will not forward the traffic from one spoke to another, as the
> > outgoing interface cannot be the same as the incoming interface in the
> > multicast routing table. Based on this loop prevention behavior, yes it
> > is correct. If you want the spokes to be able to send multicast feeds
> > to each other you can either run PIM in NBMA mode on the hub, in which
> > the incoming interface and the outgoing interface are seen as next-hop
> > values, or you can tunnel multicast between the spokes using GRE or
> > IPIP. Assuming you already have auto-rp connectivity and everything is
> > in sparse mode the easiest way is just to run NBMA mode on the hub.
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of
> > > Schulz, Dave
> > > Sent: Wednesday, December 07, 2005 7:07 PM
> > > To: ccielab@groupstudy.com
> > > Subject: Multicast sparse-mode issue
> > >
> > > I set up three routers in the spoke network with R1 being the hub with
> > R2
> > > and
> > > R3 being the spokes. I am using Auto-RP, where the mapping agent is
> > R1,
> > > and
> > > R2 is configured as the only RP. I let all three routers join the
> > > 224.4.4.4
> > > group on each ethernet interface. When I ping the the group from each
> > > router,
> > > I get all the responses back from R1 and R2....but for R3 only the
> > local
> > > router and R1 respond to the pings. Is this the correct behaviour,
> > or, am
> > > I
> > > missing something?
> > >
> > > See below....
> > >
> > > R1.......
> > >
> > > ip multicast-routing
> > > !
> > > !
> > > interface Loopback0
> > > ip address 1.1.1.1 255.255.255.0
> > > ip pim sparse-mode
> > > !
> > > interface FastEthernet0/0
> > > ip address 10.1.1.1 255.255.255.0
> > > ip pim sparse-mode
> > > ip igmp join-group 224.4.4.4
> > > duplex auto
> > > speed auto
> > > !
> > > interface Serial0/0
> > > no ip address
> > > ip pim nbma-mode
> > > ip pim sparse-mode
> > > encapsulation frame-relay
> > > no frame-relay inverse-arp
> > > frame-relay lmi-type ansi
> > > !
> > > interface Serial0/0.1 multipoint
> > > ip address 172.16.1.1 255.255.255.0
> > > ip pim nbma-mode
> > > ip pim sparse-mode
> > > frame-relay map ip 172.16.1.3 103 broadcast
> > > frame-relay map ip 172.16.1.1 102
> > > frame-relay map ip 172.16.1.2 102 broadcast
> > > no frame-relay inverse-arp
> > > !
> > > router ospf 1
> > > router-id 255.255.255.255
> > > log-adjacency-changes
> > > network 172.16.1.0 0.0.0.255 area 0
> > > neighbor 172.16.1.2
> > > neighbor 172.16.1.3
> > > !
> > > ip pim autorp listener
> > > ip pim send-rp-discovery Loopback0 scope 16
> > > !
> > > !
> > >
> > > R2.....
> > >
> > > ip multicast-routing
> > > !
> > > !
> > > !
> > > interface Loopback0
> > > ip address 2.2.2.2 255.255.255.0
> > > ip pim sparse-mode
> > > !
> > > interface Ethernet0
> > > ip address 20.1.1.1 255.255.255.0
> > > ip pim sparse-mode
> > > ip igmp join-group 224.4.4.4
> > > !
> > > interface Serial0
> > > ip address 172.16.1.2 255.255.255.0
> > > ip pim sparse-mode
> > > encapsulation frame-relay
> > > ip ospf priority 0
> > > frame-relay map ip 172.16.1.3 201
> > > frame-relay map ip 172.16.1.1 201 broadcast
> > > frame-relay map ip 172.16.1.2 201
> > > no frame-relay inverse-arp
> > > !
> > > router ospf 1
> > > log-adjacency-changes
> > > redistribute connected subnets
> > > network 172.16.1.0 0.0.0.255 area 0
> > > !
> > > ip pim send-rp-announce Loopback0 scope 16
> > > !
> > >
> > > R3......
> > >
> > > ip multicast-routing
> > > !
> > > !
> > > !
> > > interface Loopback0
> > > ip address 3.3.3.3 255.255.255.0
> > > ip pim sparse-mode
> > > !
> > > interface Ethernet0
> > > ip address 30.1.1.1 255.255.255.0
> > > ip pim sparse-mode
> > > ip igmp join-group 224.4.4.4
> > > !
> > > interface Serial0
> > > ip address 172.16.1.3 255.255.255.0
> > > ip pim sparse-mode
> > > encapsulation frame-relay
> > > ip ospf priority 0
> > > frame-relay map ip 172.16.1.3 301
> > > frame-relay map ip 172.16.1.1 301 broadcast
> > > frame-relay map ip 172.16.1.2 301
> > > no frame-relay inverse-arp
> > > frame-relay lmi-type ansi
> > > !
> > > router ospf 1
> > > log-adjacency-changes
> > > redistribute connected subnets
> > > network 172.16.1.0 0.0.0.255 area 0
> > > network 192.168.1.0 0.0.0.255 area 10
> > >
> > > Here are the ping results.....
> > > R1#ping
> > > Protocol [ip]:
> > > Target IP address: 224.4.4.4
> > > Repeat count [1]:
> > > Datagram size [100]:
> > > Timeout in seconds [2]:
> > > Extended commands [n]:
> > > Sweep range of sizes [n]:
> > > Type escape sequence to abort.
> > > Sending 1, 100-byte ICMP Echos to 224.4.4.4, timeout is 2 seconds:
> > >
> > > Reply to request 0 from 10.1.1.1, 4 ms
> > > Reply to request 0 from 172.16.1.3, 116 ms
> > > Reply to request 0 from 172.16.1.2, 104 ms
> > > Reply to request 0 from 1.1.1.1, 4 ms
> > >
> > >
> > > R2#ping
> > > Protocol [ip]:
> > > Target IP address: 224.4.4.4
> > > Repeat count [1]:
> > > Datagram size [100]:
> > > Timeout in seconds [2]:
> > > Extended commands [n]:
> > > Sweep range of sizes [n]:
> > > Type escape sequence to abort.
> > > Sending 1, 100-byte ICMP Echos to 224.4.4.4, timeout is 2 seconds:
> > >
> > > Reply to request 0 from 20.1.1.1, 20 ms
> > > Reply to request 0 from 172.16.1.3, 192 ms
> > > Reply to request 0 from 172.16.1.1, 168 ms
> > > Reply to request 0 from 2.2.2.2, 24 ms
> > >
> > > R3#ping
> > > Protocol [ip]:
> > > Target IP address: 224.4.4.4
> > > Repeat count [1]:
> > > Datagram size [100]:
> > > Timeout in seconds [2]:
> > > Extended commands [n]:
> > > Sweep range of sizes [n]:
> > > Type escape sequence to abort.
> > > Sending 1, 100-byte ICMP Echos to 224.4.4.4, timeout is 2 seconds:
> > >
> > > Reply to request 0 from 30.1.1.1, 20 ms
> > > Reply to request 0 from 172.16.1.1, 120 ms
> > > Reply to request 0 from 3.3.3.3, 20 ms
> > >
> > > (no ping try to R2, of course, it didn't attempt the ping).
> > >
> > >
> > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:50 GMT-3