From: Shamin (ccie.xpert@gmail.com)
Date: Thu Apr 20 2006 - 04:12:57 GMT-3
Chris,
I wonder how I will master this topic on multicast.
Now something interesting happened, In the process of doin what you
had requested, just as a trial and error method i enabled "ip pim
sparse-mode" on the loopback 1 interface of BB1. And i was able to get
a reply.
I will paste the output of sh ip mroute on R6
Rack1R6#sh ip mroute
IP Multicast Routing Table
(*, 228.28.28.28), 00:04:49/stopped, RP 150.1.2.2, flags: SP
Incoming interface: Ethernet0/0.26, RPF nbr 132.1.26.2
Outgoing interface list: Null
(54.1.2.254, 228.28.28.28), 00:04:49/00:01:17, flags: PT
Incoming interface: Serial0/0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(200.1.1.1, 228.28.28.28), 00:04:49/00:01:47, flags: T
Incoming interface: Serial0/0, RPF nbr 54.1.2.254
Outgoing interface list:
Ethernet0/0.26, Forward/Sparse, 00:04:50/00:02:36
(*, 224.0.1.40), 00:07:51/00:02:57, RP 150.1.2.2, flags: SJCL
Incoming interface: Ethernet0/0.26, RPF nbr 132.1.26.2
Outgoing interface list:
Serial0/0, Forward/Sparse, 00:07:28/00:03:00
*****************************X******************************X*******************************
Multicast routing table on BB1:
BB1#sh ip mroute
IP Multicast Routing Table
(*, 224.0.1.40), 00:44:11/00:00:00, RP 150.1.2.2, flags: SJPCL
Incoming interface: Serial0, RPF nbr 54.1.2.6
Outgoing interface list: Null
(*, 228.28.28.28), 00:04:36/00:02:59, RP 150.1.2.2, flags: SPF
Incoming interface: Serial0, RPF nbr 54.1.2.6
Outgoing interface list: Null
(200.1.1.1, 228.28.28.28), 00:04:36/00:01:51, flags: FT
Incoming interface: Loopback1, RPF nbr 0.0.0.0, Registering
Outgoing interface list:
Serial0, Forward/Sparse, 00:04:36/00:02:50
**********************************X******************************X**********************
Ping output on BB1:-
BB1#ping 228.28.28.28
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 228.28.28.28, timeout is 2 seconds:
Reply to request 0 from 132.1.0.3, 160 ms
Reply to request 0 from 132.1.17.7, 264 ms
Reply to request 0 from 132.1.0.3, 220 ms
Reply to request 0 from 132.1.17.7, 176 ms
This is turning out to be very confusing. Why do I get a reply when i
enable "Ip pim sparse-mode" on another interface. Another point to
note is, All the routers i pinged from and on which i got reply from
the multicast group had more than 1 interfaces which had "Ip pim
sparse-mode" enabled. But on BB1 i had it enabled only on the
interface which was connected to R6. When I enabled a second interface
on sparse-mode, it started working. Well, I cant really get to reason
why this happened.
Any inputs?
regards
shamin
**********************************X**********************************X**********************
On 4/20/06, Chris Lewis <chrlewiscsco@gmail.com> wrote:
> Mohammed,
>
> Good, so you tried one thing and saw that it fixed the problem, so the next
> thing to figure out is why.
>
> The initial problem is the olist on R6 was empty. Putting the join on the
> ethernet of R2 sends a join directly to R6 and creates an entry in the
> olist, so it is no longer empty and BB1 can get it packets forwarded
> through
> R6. Using the igmp helper from the R3 side of R2 achieves much the same
> thing, in terms of getting an entry in the olist of R6.
>
> However, these are workarounds, they are not fixing what is really broken
> with the setup you have.
>
> When a source starts sending, the first multicast router to receive that
> mutlicast packet in a sparse mode network will encapsulate the multicast
> packet with a unicast header addressed to the RP. This process is known as
> the PIM register process.
>
> If you get rid of the extra joins and helpers and get back to the original
> configuration when BB1 cannot ping the group, you should see that taking
> PIM
> off the BB1 interface enables pings to happen, now the question is why? Why
> can R6 now register the source with the RP? Think about which router can
> send the register packets on the multi-access network between BB1 and R6?
> You see this by looking at the output of the sho ip pim neighbor command on
> BB1 or R6. Then think about why that router is not sending a register
> packet. If you can answer this, you'll know why the setup was not working
> originally and how you can get it working.
>
> Let us know how your investigation goes.
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:58 GMT-3