From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Dec 08 2005 - 11:00:31 GMT-3
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