narkive

unknown

1970-01-01 00:00:00 UTC

--000e0ce0d66a4f8bd6047941c34b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable <div>Hi Everton,</div> <div>�</div> <div>Thanks for the bug fix. We're currently running the latest code from the git repository. I notice that�each of the nodes recognizes the other one as a neighbor and the "rfail" counter for "show ip�pim hello" is 0 - which is much better behavior than before.</div> <div>�</div> <div>However�still unable to pass multicast traffic. The command "show ip igmp sources" on each node returns nothing.�The command "show ip igmp groups" on node 2 lists "239.255.255.250" as a group - which is good. However the same command on node1 returns nothing.</div> <div>�</div> <div>Is there some configuration missing here ?</div> <div>�</div> <div>The network setup and the configuration files are same as stated in the top of the thread before. Any hints or help will be highly appreciated.</div> <div>�</div> <div>Regards,</div> <div>Pravin </div> <div class="gmail_quote">On Mon, Nov 23, 2009 at 8:28 AM, Everton Marques <<a href="mailto:***@gmail.com">***@gmail.com</a>> wrote: 
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hi Yoda, Just to let you know, I think you spotted a byte-ordering bug in qpimd while converting 32-bit values from host to network. 
 I suppose you are running on a 64-bit cpu? I think it is fixed by now in the git repository, but I was unable to spare time for testing it. I hope to be able to test it properly by the next week. Cheers, 
Everton On Thu, Nov 19, 2009 at 10:36 AM, Everton Marques <div> <div></div> <div class="h5"><<a href="mailto:***@gmail.com">***@gmail.com</a>> wrote: > Yoda, > > I am looking at this. > > Thanks a lot, > Everton > > On Tue, Nov 17, 2009 at 5:23 AM, Yoda geek <<a href="mailto:***@gmail.com">***@gmail.com</a>> wrote: 
>> Hi Everton, >> >> Seems like the PIM packet options length exceeds what is permitted according >> to the code and the error log. The pimd.log is full of the following >> messages: 
>> >> >> ***@OpenWrt:~# tail -f /usr/local/logs/pimd.log >> >> 2009/08/24 04:02:54.996722 warnings: PIM: pim_hello_recv: long PIM hello TLV >> type=20 length=43780 > max=4 from 192.168.3.10 on interface ra_ap0 
>> >> 2009/08/24 04:02:55.001093 warnings: PIM: pim_hello_recv: long PIM hello TLV >> type=20 length=43780 > max=4 from 192.168.3.10 on interface ra_sta0 >> >> 2009/08/24 04:03:24.996542 warnings: PIM: pim_hello_recv: long PIM hello TLV 
>> type=20 length=43780 > max=4 from 192.168.3.10 on interface ra_ap0 >> >> 2009/08/24 04:03:25.001374 warnings: PIM: pim_hello_recv: long PIM hello TLV >> type=20 length=43780 > max=4 from 192.168.3.10 on interface ra_sta0 
>> >> Also - Below are the contents of the PIMV2 packet captured by wireshark. >> Please note that I have stripped off the IP and other headers. Just the PIM >> protocol packet and the offsets from wireshark: 
>> >> 0000 20 00 f6 56 00 01 00 02 00 69 00 02 00 04 01 f4 >> 0010 09 c4 00 13 00 04 00 01 00 00 00 14 ab 04 32 4e >> 0020 00 00 >> >> Thanks again for all your help. 
>> >> Regards, >> >> Yoda >> >> >> On Mon, Nov 16, 2009 at 3:28 AM, Everton Marques <<a href="mailto:***@gmail.com">***@gmail.com</a>> 
>> wrote: >>> >>> Hi Yoda, >>> >>> Thanks. >>> >>> Yes, I am looking for the reason why the Rfail counter is increasing. >>> >>> When PIM_CHECK_RECV_IFINDEX_SANITY is defined in pimd/Makefile.am, 
>>> Rfail may increment silently. However, now you undefined >>> PIM_CHECK_RECV_IFINDEX_SANITY, any increment in Rfail should >>> have a related log message. >>> >>> Can you see if you locate any meaningful message in your pimd logs? 
>>> >>> If you send me your pimd logs I can try to find something as well. >>> >>> Thanks a lot, >>> Everton >>> >>> >>> >>> On Sun, Nov 15, 2009 at 5:23 AM, Yoda geek <<a href="mailto:***@gmail.com">***@gmail.com</a>> 
>>> wrote: >>> > Hi Everton, >>> > >>> > I followed the exact directions as you suggested and ran the rebuilt >>> > quagga >>> > on the nodes. However I don't see any difference in behavior. Is there 
>>> > anything in particular you're looking for after these changes ? >>> > Below is the output from pimd running on both nodes: >>> > >>> > >>> > Trying 192.168.1.1... 
>>> > >>> > Connected to 192.168.1.1. >>> > >>> > Escape character is '^]'. >>> > >>> > Hello, this is Quagga 0.99.15 pimd 0.158 
>>> > >>> > Copyright 1996-2005 Kunihiro Ishiguro, et al. >>> > >>> > >>> > >>> > User Access Verification >>> > >>> > Password: 
>>> > >>> > node1> enable >>> > >>> > Password: >>> > >>> > node1# show ip pim neighbor >>> > >>> > Recv flags: H=holdtime L=lan_prune_delay P=dr_priority G=generation_id 
>>> > A=address_list >>> > >>> > T=can_disable_join_suppression >>> > >>> > Interface Address Neighbor Uptime Timer Holdt DrPri GenId Recv >>> > 
>>> > node1# show ip pim hello >>> > >>> > Interface Address Period Timer StatStart Recv Rfail Send Sfail >>> > >>> > ra_ap0 192.168.4.20 00:30 00:16 00:10:19 20 20 21 0 
>>> > >>> > ra_sta0 192.168.3.20 00:30 00:14 00:10:19 20 20 21 0 >>> > >>> > node1# q >>> > >>> > Connection closed by foreign host. 
>>> > >>> > Trying 192.168.3.10... >>> > >>> > Connected to 192.168.3.10. >>> > >>> > Escape character is '^]'. >>> > 
>>> > Hello, this is Quagga 0.99.15 pimd 0.158 >>> > >>> > Copyright 1996-2005 Kunihiro Ishiguro, et al. >>> > >>> > >>> > >>> > User Access Verification 
>>> > >>> > Password: >>> > >>> > node2> enable >>> > >>> > Password: >>> > >>> > node2# show ip pim neighbor 
>>> > >>> > Recv flags: H=holdtime L=lan_prune_delay P=dr_priority G=generation_id >>> > A=address_list >>> > >>> > T=can_disable_join_suppression 
>>> > >>> > Interface Address Neighbor Uptime Timer Holdt DrPri GenId Recv >>> > >>> > node2# show ip pim hello >>> > >>> > Interface Address Period Timer StatStart Recv Rfail Send Sfail 
>>> > >>> > ra_ap0 192.168.5.10 00:30 00:08 00:11:26 23 23 23 0 >>> > >>> > ra_sta0 192.168.3.10 00:30 00:05 00:11:26 23 23 23 0 >>> > >>> > node2# q 
>>> > >>> > Connection closed by foreign host. >>> > >>> > >>> > >>> > Thanks, >>> > >>> > Yoda >>> > 
>>> > >>> > On Fri, Nov 13, 2009 at 4:16 AM, Everton Marques >>> > <<a href="mailto:***@gmail.com">***@gmail.com</a>> >>> > wrote: 
>>> >> >>> >> Hi Yoda, >>> >> >>> >> Based on the Rfail counter you spotted, I suspect the code under >>> >> PIM_CHECK_RECV_IFINDEX_SANITY may be discarding hello packets. 
>>> >> >>> >> Can you experiment with commenting out the following line: >>> >> >>> >> PIM_DEFS += -DPIM_CHECK_RECV_IFINDEX_SANITY >>> >> 
>>> >> from pimd/Makefile.am ? >>> >> >>> >> Then you will need to bootstrap autotools with: >>> >> >>> >> autoreconf -i --force >>> >> 
>>> >> And finally to rebuild quagga. >>> >> >>> >> I know this test may be cumbersome since it requires the whole >>> >> autotools >>> >> suit present on your system, but it could help to identify why pimd is 
>>> >> missing the hello packets. >>> >> >>> >> Thanks, >>> >> Everton >>> >> >>> >> >>> >> On Fri, Nov 13, 2009 at 7:30 AM, Yoda geek <<a href="mailto:***@gmail.com">***@gmail.com</a>> 
>>> >> wrote: >>> >> > Hi Everton, >>> >> > >>> >> > Below are the answers : >>> >> > >>> >> > 1) "ip pim ssm" is enabled on node1 ra_sta0 as well as node2 ra_sta0. 
>>> >> > >>> >> > 2) I do see in wireshark trace that ra_sta0 on both nodes 1 and 2 are >>> >> > receiving PIMv2 "Hello" packets however they are addressed to 
>>> >> > 224.0.0.13. >>> >> > >>> >> > 3) Don't see any error logs on nodes 1 and 2. Below is the output of >>> >> > "show >>> >> > ip pim hello" on both nodes 1 and 2. Please notice the "Rfail" 
>>> >> > counters. >>> >> > >>> >> > node1# show ip pim hello >>> >> > Interface Address Period Timer StatStart Recv Rfail Send >>> >> > Sfail 
>>> >> > ra_ap0 192.168.4.20 00:30 00:05 29:57:50 0 3496 3595 >>> >> > 0 >>> >> > ra_sta0 192.168.3.20 00:30 00:04 29:57:50 3496 3496 3595 
>>> >> > 0 >>> >> > node1# >>> >> > >>> >> > node2# show ip pim hello >>> >> > Interface Address Period Timer StatStart Recv Rfail Send 
>>> >> > Sfail >>> >> > ra_ap0 192.168.5.10 00:30 00:04 29:56:48 0 3590 3593 >>> >> > 0 >>> >> > ra_sta0 192.168.3.10 00:30 00:07 29:56:48 3590 3590 3593 
>>> >> > 0 >>> >> > node2# >>> >> > >>> >> > >>> >> > Thanks, >>> >> > >>> >> > On Wed, Nov 11, 2009 at 6:04 AM, Everton Marques 
>>> >> > <<a href="mailto:***@gmail.com">***@gmail.com</a>> >>> >> > wrote: >>> >> >> >>> >> >> Hi, >>> >> >> 
>>> >> >> I think the problem is node2 fails to bring up the node1 as pim >>> >> >> neighbor >>> >> >> on ra_sta0, since node1 is missing from node2 "show ip pim 
>>> >> >> neighbor". >>> >> >> >>> >> >> Can you please double check the following? >>> >> >> >>> >> >> 1) "ip pim ssm" is enabled on node1 ra_sta0 ? 
>>> >> >> 2) node2 is receiving pim hello packets from node1 on ra_sta0 ? >>> >> >> 3) node2 pimd is logging any error/warning ? look for messages about >>> >> >> packets from node1, specially hello packets. 
>>> >> >> >>> >> >> Thanks, >>> >> >> Everton >>> >> >> >>> >> >> On Wed, Nov 11, 2009 at 4:48 AM, Yoda geek <<a href="mailto:***@gmail.com">***@gmail.com</a>> 
>>> >> >> wrote: >>> >> >> > Below is the output as requested >>> >> >> > >>> >> >> > >>> >> >> > User Access Verification 
>>> >> >> > >>> >> >> > Password: >>> >> >> > >>> >> >> > node2> enable >>> >> >> > 
>>> >> >> > Password: >>> >> >> > >>> >> >> > node2# show ip igmp interface >>> >> >> > >>> >> >> > Interface Address ifIndex Socket Uptime Multi Broad MLoop AllMu 
>>> >> >> > Prmsc >>> >> >> > Del >>> >> >> > >>> >> >> > ra_ap0 192.168.5.10 5 9 00:34:40 yes yes yes no no no >>> >> >> > 
>>> >> >> > node2# show ip igmp interface group >>> >> >> > >>> >> >> > Interface Address Group Mode Timer Srcs V Uptime >>> >> >> > 
>>> >> >> > ra_ap0 192.168.5.10 224.0.0.13 EXCL 00:03:55 0 3 00:34:48 >>> >> >> > >>> >> >> > ra_ap0 192.168.5.10 224.0.0.22 EXCL 00:03:55 0 3 00:34:48 
>>> >> >> > >>> >> >> > ra_ap0 192.168.5.10 239.255.255.250 EXCL 00:03:59 0 3 00:02:17 >>> >> >> > >>> >> >> > node2# show ip igmp group sources 
>>> >> >> > >>> >> >> > Interface Address Group Source Timer Fwd Uptime >>> >> >> > >>> >> >> > node2# show ip igmp sources pim designated-router 
>>> >> >> > >>> >> >> > NonPri: Number of neighbors missing DR Priority hello option >>> >> >> > >>> >> >> > Interface Address DR Uptime Elections NonPri 
>>> >> >> > >>> >> >> > ra_ap0 192.168.5.10 192.168.5.10 00:35:16 1 0 >>> >> >> > >>> >> >> > ra_sta0 192.168.3.10 192.168.3.10 00:35:16 1 0 
>>> >> >> > >>> >> >> > node2# show ip pim designated-router hello >>> >> >> > >>> >> >> > Interface Address Period Timer StatStart Recv Rfail Send Sfail 
>>> >> >> > >>> >> >> > ra_ap0 192.168.5.10 00:30 00:08 00:35:23 0 70 71 0 >>> >> >> > >>> >> >> > ra_sta0 192.168.3.10 00:30 00:10 00:35:23 70 70 71 0 
>>> >> >> > >>> >> >> > node2# show ip pim hello interface >>> >> >> > >>> >> >> > Interface Address ifIndex Socket Uptime Multi Broad MLoop AllMu 
>>> >> >> > Prmsc >>> >> >> > Del >>> >> >> > >>> >> >> > ra_ap0 192.168.5.10 5 10 00:35:30 yes yes no no no no >>> >> >> > 
>>> >> >> > ra_sta0 192.168.3.10 6 11 00:35:30 yes yes no no no no >>> >> >> > >>> >> >> > node2# show ip pim interface local-membership >>> >> >> > 
>>> >> >> > Interface Address Source Group Membership >>> >> >> > >>> >> >> > node2# show ip pim local-membership join >>> >> >> > 
>>> >> >> > Interface Address Source Group State Uptime Expire Prune >>> >> >> > >>> >> >> > node2# show ip pim join neighbor >>> >> >> > 
>>> >> >> > Recv flags: H=holdtime L=lan_prune_delay P=dr_priority >>> >> >> > G=generation_id >>> >> >> > A=address_list >>> >> >> > 
>>> >> >> > T=can_disable_join_suppression >>> >> >> > >>> >> >> > Interface Address Neighbor Uptime Timer Holdt DrPri GenId Recv >>> >> >> > 
>>> >> >> > node2# show ip pim neighbor rpf >>> >> >> > >>> >> >> > RPF Cache Refresh Delay: 10000 msecs >>> >> >> > 
>>> >> >> > RPF Cache Refresh Timer: 0 msecs >>> >> >> > >>> >> >> > RPF Cache Refresh Requests: 6 >>> >> >> > >>> >> >> > RPF Cache Refresh Events: 3 
>>> >> >> > >>> >> >> > RPF Cache Refresh Last: 00:34:24 >>> >> >> > >>> >> >> > Source Group RpfIface RpfAddress RibNextHop Metric Pref 
>>> >> >> > >>> >> >> > node2# show ip pim rpf upstream >>> >> >> > >>> >> >> > Source Group State Uptime JoinTimer RefCnt 
>>> >> >> > >>> >> >> > node2# show ip pim upstream-join-desired >>> >> >> > >>> >> >> > Interface Source Group LostAssert Joins PimInclude JoinDesired 
>>> >> >> > EvalJD >>> >> >> > >>> >> >> > node2# show ip pim upstream-join-desired rpf >>> >> >> > >>> >> >> > Source Group RpfIface RibNextHop RpfAddress 
>>> >> >> > >>> >> >> > node2# show ip pim upstream-rpf route 192.168.4.60 >>> >> >> > >>> >> >> > Address NextHop Interface Metric Preference 
>>> >> >> > >>> >> >> > 192.168.4.60 192.168.3.20 ra_sta0 1 0 >>> >> >> > >>> >> >> > node2# q >>> >> >> > 
>>> >> >> > On Tue, Nov 3, 2009 at 7:51 AM, Everton Marques >>> >> >> > <<a href="mailto:***@gmail.com">***@gmail.com</a>> >>> >> >> > wrote: 
>>> >> >> >> >>> >> >> >> Hi, >>> >> >> >> >>> >> >> >> Can you send the following commands from node2 ? 
>>> >> >> >> >>> >> >> >> show ip igmp interface >>> >> >> >> show ip igmp group >>> >> >> >> show ip igmp sources 
>>> >> >> >> show ip pim designated-router >>> >> >> >> show ip pim hello >>> >> >> >> show ip pim interface >>> >> >> >> show ip pim local-membership 
>>> >> >> >> show ip pim join >>> >> >> >> show ip pim neighbor >>> >> >> >> show ip pim rpf >>> >> >> >> show ip pim upstream 
>>> >> >> >> show ip pim upstream-join-desired >>> >> >> >> show ip pim upstream-rpf >>> >> >> >> show ip route 192.168.4.60 >>> >> >> >> 
>>> >> >> >> Thanks, >>> >> >> >> Everton >>> >> >> >> >>> >> >> >> On Mon, Nov 2, 2009 at 5:44 AM, Yoda geek 
>>> >> >> >> <<a href="mailto:***@gmail.com">***@gmail.com</a>> >>> >> >> >> wrote: >>> >> >> >> > Hi Everton, 
>>> >> >> >> > >>> >> >> >> > I added the entry "ip pim ssm" on ra_ap0 as you suggested. I >>> >> >> >> > still 
>>> >> >> >> > don't >>> >> >> >> > see join request coming into the source. Below is what the >>> >> >> >> > configuration 
>>> >> >> >> > looks like on the individual nodes: >>> >> >> >> > >>> >> >> >> > Node 1 pimd.conf >>> >> >> >> > ------------------------- 
>>> >> >> >> > ! >>> >> >> >> > ! Zebra configuration saved from vty >>> >> >> >> > ! 2009/08/08 05:03:23 >>> >> >> >> > ! 
>>> >> >> >> > hostname node1 >>> >> >> >> > password zebra >>> >> >> >> > enable password zebra >>> >> >> >> > log stdout 
>>> >> >> >> > ! >>> >> >> >> > interface eth0 >>> >> >> >> > ! >>> >> >> >> > interface eth1 
>>> >> >> >> > ! >>> >> >> >> > interface lo >>> >> >> >> > ! >>> >> >> >> > interface ra_ap0 
>>> >> >> >> > ip pim ssm >>> >> >> >> > ip igmp query-interval 125 >>> >> >> >> > ip igmp query-max-response-time-dsec 100 
>>> >> >> >> > ! >>> >> >> >> > interface ra_sta0 >>> >> >> >> > ip pim ssm >>> >> >> >> > ip igmp query-interval 125 
>>> >> >> >> > ip igmp query-max-response-time-dsec 100 >>> >> >> >> > ! >>> >> >> >> > ! >>> >> >> >> > ip multicast-routing 
>>> >> >> >> > ! >>> >> >> >> > line vty >>> >> >> >> > ! >>> >> >> >> > >>> >> >> >> > 
>>> >> >> >> > Node 2 pimd.conf >>> >> >> >> > ------------------------- >>> >> >> >> > ! >>> >> >> >> > ! Zebra configuration saved from vty 
>>> >> >> >> > ! 2009/08/09 22:38:12 >>> >> >> >> > ! >>> >> >> >> > hostname node2 >>> >> >> >> > password zebra 
>>> >> >> >> > enable password zebra >>> >> >> >> > log stdout >>> >> >> >> > ! >>> >> >> >> > interface br-lan 
>>> >> >> >> > ! >>> >> >> >> > interface eth0 >>> >> >> >> > ! >>> >> >> >> > interface eth1 
>>> >> >> >> > ! >>> >> >> >> > interface lo >>> >> >> >> > ! >>> >> >> >> > interface ra_ap0 
>>> >> >> >> > ip pim ssm >>> >> >> >> > ip igmp >>> >> >> >> > ip igmp query-interval 125 >>> >> >> >> > ip igmp query-max-response-time-dsec 100 
>>> >> >> >> > ip igmp join 239.255.255.250 192.168.4.60 >>> >> >> >> > ! >>> >> >> >> > interface ra_sta0 >>> >> >> >> > ip pim ssm 
>>> >> >> >> > ip igmp query-interval 125 >>> >> >> >> > ip igmp query-max-response-time-dsec 100 >>> >> >> >> > ! >>> >> >> >> > ! 
>>> >> >> >> > ip multicast-routing >>> >> >> >> > ! >>> >> >> >> > line vty >>> >> >> >> > ! 
>>> >> >> >> > On Sun, Nov 1, 2009 at 12:44 PM, Everton Marques >>> >> >> >> > <<a href="mailto:***@gmail.com">***@gmail.com</a>> 
>>> >> >> >> > wrote: >>> >> >> >> >> >>> >> >> >> >> Hi, >>> >> >> >> >> >>> >> >> >> >> Yes, pimd should route the join request towards the source. 
>>> >> >> >> >> >>> >> >> >> >> However, you need to enable "ip pim ssm" on ra_ap0 as well. >>> >> >> >> >> If you enable only "ip igmp" on a interface, pimd won't inject 
>>> >> >> >> >> IGMP-learnt membership into the pim protocol. >>> >> >> >> >> >>> >> >> >> >> Cheers, >>> >> >> >> >> Everton 
>>> >> >> >> >> >>> >> >> >> >> On Sun, Nov 1, 2009 at 7:02 AM, Yoda geek >>> >> >> >> >> <<a href="mailto:***@gmail.com">***@gmail.com</a>> 
>>> >> >> >> >> wrote: >>> >> >> >> >> > Hi Everton, >>> >> >> >> >> > >>> >> >> >> >> > Thanks for the suggestions. I made the changes to the config 
>>> >> >> >> >> > files >>> >> >> >> >> > on >>> >> >> >> >> > both >>> >> >> >> >> > nodes as you suggested. Since it is not possible for me to 
>>> >> >> >> >> > force >>> >> >> >> >> > the >>> >> >> >> >> > client >>> >> >> >> >> > to do a source specific join I added the following line at 
>>> >> >> >> >> > interface >>> >> >> >> >> > ra_ap0 >>> >> >> >> >> > on node 2 where the client is attached: 
>>> >> >> >> >> > >>> >> >> >> >> > interface ra_ap0 >>> >> >> >> >> > ip igmp >>> >> >> >> >> > ip igmp query-interval 125 
>>> >> >> >> >> > ip igmp query-max-response-time-dsec 100 >>> >> >> >> >> > ip igmp join 239.255.255.250 192.168.4.60 >>> >> >> >> >> > 
>>> >> >> >> >> > I do see the source-specific IGMPv3 join group >>> >> >> >> >> > 239.255.255.250 >>> >> >> >> >> > for 
>>> >> >> >> >> > source >>> >> >> >> >> > 192.168.4.60 which is addressed to 224.0.0.22 on the side of >>> >> >> >> >> > node2. 
>>> >> >> >> >> > However >>> >> >> >> >> > this join request never makes it to node 1 where the source >>> >> >> >> >> > is 
>>> >> >> >> >> > located >>> >> >> >> >> > on >>> >> >> >> >> > ra_ap0. >>> >> >> >> >> > Shouldn't the pimd route this join request to the node where 
>>> >> >> >> >> > the >>> >> >> >> >> > source >>> >> >> >> >> > is >>> >> >> >> >> > attached ? 
>>> >> >> >> >> > >>> >> >> >> >> > Thanks, >>> >> >> >> >> > >>> >> >> >> >> > 
>>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > On Mon, Oct 26, 2009 at 6:44 AM, Everton Marques >>> >> >> >> >> > <<a href="mailto:***@gmail.com">***@gmail.com</a>> 
>>> >> >> >> >> > wrote: >>> >> >> >> >> >> >>> >> >> >> >> >> Hi, >>> >> >> >> >> >> 
>>> >> >> >> >> >> You did not mention whether you got a source-specific >>> >> >> >> >> >> IGMPv3 >>> >> >> >> >> >> join 
>>> >> >> >> >> >> to >>> >> >> >> >> >> the >>> >> >> >> >> >> channel (S,G)=(192.168.4.60,239.255.255.250). Please notice 
>>> >> >> >> >> >> qpimd >>> >> >> >> >> >> is >>> >> >> >> >> >> unable to program the multicast forwarding cache with 
>>> >> >> >> >> >> non-source-specific >>> >> >> >> >> >> groups. Usually the key issue is to instruct the receiver >>> >> >> >> >> >> application 
>>> >> >> >> >> >> to >>> >> >> >> >> >> join the source-specific channel (S,G). >>> >> >> >> >> >> 
>>> >> >> >> >> >> Regarding the config, the basic rule is: >>> >> >> >> >> >> 1) Enable "ip pim ssm" everywhere (on every interface that 
>>> >> >> >> >> >> should >>> >> >> >> >> >> pass >>> >> >> >> >> >> mcast). >>> >> >> >> >> >> 2) Enable both "ip pim ssm" and "ip igmp" on interfaces 
>>> >> >> >> >> >> attached >>> >> >> >> >> >> to >>> >> >> >> >> >> the receivers (IGMPv3 hosts). 
>>> >> >> >> >> >> >>> >> >> >> >> >> An even simpler config rule to remember is to enable both >>> >> >> >> >> >> commands 
>>> >> >> >> >> >> everywhere. They should not cause any harm. >>> >> >> >> >> >> >>> >> >> >> >> >> Hence, if your mcast receiver is attached to Node 2 at 
>>> >> >> >> >> >> ra_ap0, I >>> >> >> >> >> >> think >>> >> >> >> >> >> you will >>> >> >> >> >> >> need at least the following config: 
>>> >> >> >> >> >> >>> >> >> >> >> >> ! >>> >> >> >> >> >> ! Node 1 >>> >> >> >> >> >> ! 
>>> >> >> >> >> >> interface ra_ap0 >>> >> >> >> >> >> ip pim ssm >>> >> >> >> >> >> interface ra_sta0 
>>> >> >> >> >> >> ip pim ssm >>> >> >> >> >> >> >>> >> >> >> >> >> ! >>> >> >> >> >> >> ! Node 2 
>>> >> >> >> >> >> ! >>> >> >> >> >> >> interface ra_ap0 >>> >> >> >> >> >> ip pim ssm >>> >> >> >> >> >> ip igmp 
>>> >> >> >> >> >> interface ra_sta0 >>> >> >> >> >> >> ip pim ssm >>> >> >> >> >> >> >>> >> >> >> >> >> Hope this helps, 
>>> >> >> >> >> >> Everton >>> >> >> >> >> >> >>> >> >> >> >> >> On Mon, Oct 26, 2009 at 4:42 AM, Yoda geek 
>>> >> >> >> >> >> <<a href="mailto:***@gmail.com">***@gmail.com</a>> >>> >> >> >> >> >> wrote: >>> >> >> >> >> >> > Hi Everton & Fellow qpimd users, 
>>> >> >> >> >> >> > >>> >> >> >> >> >> > We're trying to stream multicast video traffic between a >>> >> >> >> >> >> > Tversity 
>>> >> >> >> >> >> > server >>> >> >> >> >> >> > and >>> >> >> >> >> >> > a multicast client separated by 2 nodes (node1 and 
>>> >> >> >> >> >> > node2). >>> >> >> >> >> >> > Each >>> >> >> >> >> >> > node >>> >> >> >> >> >> > is 
>>> >> >> >> >> >> > running quagga suite (version 0.99.15) along with qpimd >>> >> >> >> >> >> > (version >>> >> >> >> >> >> > 0.158) 
>>> >> >> >> >> >> > running on top of Linux 2.6.26. >>> >> >> >> >> >> > Node 1 has 3 network interfaces - eth0, ap0 and ra_sta0 >>> >> >> >> >> >> > Node 2 has 2 network interfaces - ra_sta0 and ra_ap0 
>>> >> >> >> >> >> > The Tversity server talks to interface ra_ap0 on Node 1 >>> >> >> >> >> >> > and >>> >> >> >> >> >> > the 
>>> >> >> >> >> >> > multicast >>> >> >> >> >> >> > client talks to interface ra_ap0 on Node 2 >>> >> >> >> >> >> > Nodes 1 and 2 talk with each other over their ra_sta0 
>>> >> >> >> >> >> > interfaces >>> >> >> >> >> >> > >>> >> >> >> >> >> > Below is a graphical depiction : 
>>> >> >> >> >> >> > >>> >> >> >> >> >> > Tversity server -----------ra_ap0--> Node 1 >>> >> >> >> >> >> > --ra_sta0-----------------ra_sta0-->Node 
>>> >> >> >> >> >> > 2-----ra_ap0------------------------> Video Client >>> >> >> >> >> >> > =========== ====================== 
>>> >> >> >> >> >> > ====================== ============= >>> >> >> >> >> >> > >>> >> >> >> >> >> > 
>>> >> >> >> >> >> > Node 1 pimd.conf file >>> >> >> >> >> >> > ================== >>> >> >> >> >> >> > ! 
>>> >> >> >> >> >> > ! Zebra configuration saved from vty >>> >> >> >> >> >> > ! 2009/08/01 20:26:06 >>> >> >> >> >> >> > ! 
>>> >> >> >> >> >> > hostname node1 >>> >> >> >> >> >> > password zebra >>> >> >> >> >> >> > enable password zebra 
>>> >> >> >> >> >> > log stdout >>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface eth0 
>>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface eth1 >>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface lo 
>>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface ra_ap0 >>> >> >> >> >> >> > ip pim ssm 
>>> >> >> >> >> >> > ip igmp >>> >> >> >> >> >> > ip igmp query-interval 125 >>> >> >> >> >> >> > ip igmp query-max-response-time-dsec 100 
>>> >> >> >> >> >> > ip igmp join 239.255.255.250 192.168.4.60 >>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface ra_sta0 
>>> >> >> >> >> >> > ip igmp >>> >> >> >> >> >> > ip igmp query-interval 125 >>> >> >> >> >> >> > ip igmp query-max-response-time-dsec 100 
>>> >> >> >> >> >> > ! >>> >> >> >> >> >> > ! >>> >> >> >> >> >> > ip multicast-routing 
>>> >> >> >> >> >> > ! >>> >> >> >> >> >> > line vty >>> >> >> >> >> >> > ! >>> >> >> >> >> >> > 
>>> >> >> >> >> >> > Node 2 pimd.conf configuration file >>> >> >> >> >> >> > ============================ >>> >> >> >> >> >> > ! 
>>> >> >> >> >> >> > ! Zebra configuration saved from vty >>> >> >> >> >> >> > ! 2009/08/02 21:54:14 >>> >> >> >> >> >> > ! 
>>> >> >> >> >> >> > hostname node2 >>> >> >> >> >> >> > password zebra >>> >> >> >> >> >> > enable password zebra 
>>> >> >> >> >> >> > log stdout >>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface eth0 
>>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface eth1 >>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface lo 
>>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface ra_ap0 >>> >> >> >> >> >> > ip igmp 
>>> >> >> >> >> >> > ip igmp query-interval 125 >>> >> >> >> >> >> > ip igmp query-max-response-time-dsec 100 >>> >> >> >> >> >> > ip igmp join 239.255.255.250 192.168.4.60 
>>> >> >> >> >> >> > ! >>> >> >> >> >> >> > interface ra_sta0 >>> >> >> >> >> >> > ip igmp 
>>> >> >> >> >> >> > ip igmp query-interval 125 >>> >> >> >> >> >> > ip igmp query-max-response-time-dsec 100 >>> >> >> >> >> >> > ! 
>>> >> >> >> >> >> > ! >>> >> >> >> >> >> > ip multicast-routing >>> >> >> >> >> >> > ! 
>>> >> >> >> >> >> > line vty >>> >> >> >> >> >> > ! >>> >> >> >> >> >> > >>> >> >> >> >> >> >