From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Dec 08 2005 - 10:51:59 GMT-3
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).
>
>
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:50 GMT-3