From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Thu Dec 08 2005 - 11:08:48 GMT-3
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