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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 >> > <[email protected]> >> > 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 <[email protected]> >> >> 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 >> >> > <[email protected]> >> >> > 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 <[email protected]> >> >> >> 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 >> >> >> > ! >> >> >> > >> >> >> > From the above configuration you can see that interface ra_ap0 on >> >> >> > node 1 >> >> >> > is >> >> >> > configured to be multicast source (ip pim ssm). >> >> >> > We do see some multicast join requests in wireshark from both the >> >> >> > server >> >> >> > and >> >> >> > the client however no data flow. Initially we started >> >> >> > qpimd without >> >> >> > the entry "igmp join ..." on either client side node or server >> >> >> > side >> >> >> > node. >> >> >> > Looking at node 1 configuration through "show ip igmp groups" we >> >> >> > didn't >> >> >> > see >> >> >> > the group membership for "239.255.255.250" while this group >> >> >> > membership >> >> >> > was >> >> >> > observed on node 2. I put this group membership on both nodes to >> >> >> > force >> >> >> > them >> >> >> > to join this multicast group - however without success. >> >> >> > >> >> >> > Just to give you a background - when both client and server are >> >> >> > talking >> >> >> > to >> >> >> > same node - say node 2 and same interface ra_ap0 (without qpimd >> >> >> > running) >> >> >> > multicast video gets served flawlessly from Tversity server to >> >> >> > client >> >> >> > through the node. >> >> >> > But with the 2 node setup we aren't able to see the video streams >> >> >> > go >> >> >> > through >> >> >> > to the client. >> >> >> > >> >> >> > Could you please review the above configuration for errors or >> >> >> > have >> >> >> > any >> >> >> > suggestions to reseolve this issue ? Any help would be greatly >> >> >> > appreciated. >> >> >> > >> >> >> > Thanks, >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > > >
