Closed troglobit closed 8 years ago
It's not a blocking problem, the RC script in charge of starting this deamon can check the presence of the pimd.conf.
Providing more information about the "unexistant configuration file" behavior:
[root@pim-router]~# rm /usr/local/etc/pimd.conf
[root@pim-router]~# pimd -d
debug level 0xffffffff (dvmrp_detail,dvmrp_prunes,dvmrp_routes,dvmrp_neighbors,dvmrp_timers,igmp_proto,igmp_timers,igmp_members,trace,timeout,packets,interfaces,kernel,cache,rsrr,pim_detail,pim_hello,pim_register,pim_join_prune,pim_bootstrap,pim_asserts,pim_cand_rp,pim_routes,pim_timers,pim_rpf)
06:29:08.205 pimd version 2.3.2-beta1 starting ...
06:29:08.205 Got 262144 byte send buffer size in 0 iterations
06:29:08.205 Got 262144 byte recv buffer size in 0 iterations
06:29:08.205 Got 262144 byte send buffer size in 0 iterations
06:29:08.205 Got 262144 byte recv buffer size in 0 iterations
06:29:08.205 Getting vifs from kernel
06:29:08.205 Installing em0 (10.0.12.2 on subnet 10.0.12/24) as vif #0 - rate 0
06:29:08.205 Installing em1 (10.0.23.2 on subnet 10.0.23/24) as vif #1 - rate 0
06:29:08.205 Getting vifs from /usr/local/etc/pimd.conf
=> No warning message about a "not found" file
06:29:08.206 Interface em0 comes up; vif #0 now in service
06:29:08.207 query_groups(): Sending IGMP v3 query on em0
06:29:08.207 Send IGMP Membership Query from 10.0.12.2 to 224.0.0.1
06:29:08.207 SENT 36 bytes IGMP Membership Query from 10.0.12.2 to 224.0.0.1
06:29:08.207 SENT 46 bytes PIM v2 Hello from 10.0.12.2 to 224.0.0.13
06:29:08.207 Interface em1 comes up; vif #1 now in service
06:29:08.208 query_groups(): Sending IGMP v3 query on em1
06:29:08.208 Send IGMP Membership Query from 10.0.23.2 to 224.0.0.1
06:29:08.208 SENT 36 bytes IGMP Membership Query from 10.0.23.2 to 224.0.0.1
06:29:08.208 SENT 46 bytes PIM v2 Hello from 10.0.23.2 to 224.0.0.13
06:29:08.208 Interface register_vif0 comes up; vif #2 now in service
=> With no configuration file it enable PIM on all interfaces (em0 and em1 here): great, this mean without configuration file it should be working.
(...)
Virtual Interface Table ======================================================
Vif Local Address Subnet Thresh Flags Neighbors
--- --------------- ------------------ ------ --------- -----------------
0 10.0.12.2 10.0.12/24 1 DR NO-NBR
1 10.0.23.2 10.0.23/24 1 DR NO-NBR
2 10.0.12.2 register_vif0 1
Vif SSM Group Sources
Multicast Routing Table ======================================================
--------------------------------- (*,*,G) ------------------------------------
Number of Groups: 0
Number of Cache MIRRORs: 0
------------------------------------------------------------------------------
Candidate Rendezvous-Point Set ===============================================
RP address Incoming Group Prefix Priority Holdtime
--------------- -------- ------------------ -------- ---------------------
------------------------------------------------------------------------------
Current BSR address: 0.0.0.0
=> But there is nothing configured as Rendezvous-point (no canditate rp, no BSR)… then the "default" empty configuration prevent to route mcast.
If we start a mcsat sender at one interface (em0 here), pimd didn't update its mcast routing table:
06:46:38.189 Cache miss, src 10.0.12.1, dst 239.1.1.1, iif 0
06:46:38.190 create group entry, group 239.1.1.1
06:46:39.692 Cache miss, src 10.0.12.1, dst 239.1.1.1, iif 0
06:46:39.693 create group entry, group 239.1.1.1
06:46:41.183 Cache miss, src 10.0.12.1, dst 239.1.1.1, iif 0
06:46:41.184 create group entry, group 239.1.1.1
Virtual Interface Table ======================================================
Vif Local Address Subnet Thresh Flags Neighbors
--- --------------- ------------------ ------ --------- -----------------
0 10.0.12.2 10.0.12/24 1 DR NO-NBR
1 10.0.23.2 10.0.23/24 1 DR NO-NBR
2 10.0.12.2 register_vif0 1
Vif SSM Group Sources
Multicast Routing Table ======================================================
--------------------------------- (*,*,G) ------------------------------------
Number of Groups: 0
Number of Cache MIRRORs: 0
------------------------------------------------------------------------------
Candidate Rendezvous-Point Set ===============================================
RP address Incoming Group Prefix Priority Holdtime
--------------- -------- ------------------ -------- ---------------------
------------------------------------------------------------------------------
Current BSR address: 0.0.0.0
06:46:42.686 Cache miss, src 10.0.12.1, dst 239.1.1.1, iif 0
06:46:42.687 create group entry, group 239.1.1.1
And the operating system mcast routing table didn't know about the correct In-Vif/Out-vif to use:
[root@pim-router]~# netstat -g
IPv4 Virtual Interface Table
Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out
0 1 10.0.12.2 0 0
1 1 10.0.23.2 0 0
2 1 10.0.12.2 0 0
IPv4 Multicast Forwarding Table
Origin Group Packets In-Vif Out-Vifs:Ttls
10.0.12.1 239.1.1.1 0 65535
IPv6 Multicast Interface Table is empty
IPv6 Multicast Forwarding Table is empty
=> here the In-Vif should be set to number 0 and out vif to 1.
Thank you for the thorough follow-up! This will be very useful tracking this buglet down :)
… and if course it should be possible to run pimd without a .conf file! :)
@ocochard I've looked into this a bit further now. It seems pimd has actually been designed to not act as an RP or BSR candidate by default. This is also in line with what Cisco does by default.
http://www.cisco.com/c/en/us/td/docs/ios/12_2/ipmulti/command/reference/fiprmc_r/1rfmult2.html
However, since we both want pimd to work out-of-the-box when there is no config file I have a proposal:
1) Keep things as-is, no RP/BSR candidate if settings are missing from config file (as today) 2) If no config file is found, warn to log but set up sane defaults, i.e. as RP and BSR candidate
Commit c99c7f9, part of v2.3.2-rc2, should work a lot better with no config file, without breaking Cisco compat defaults.
Nope, does not work. Tested with a very simple setup:
Sender -----> R1 <----> R2 <----> R3 ------> Receiver
^ ^ ^
\ \ `-------------------------- OpenBSD
\ `----------------------------------- Linux
`-------------------------------------------- Linux
No luck. Must look into this again before release.
False alarm! After much trouble shooting the problem I had (apart from forwarding taking aaaages to start) was IP address collision in my virtual multicast test bed :smile: :+1:
@ocochard reports in issue #57: