Code Monkey home page Code Monkey logo

pimd's Introduction

PIM-SM/SSM Multicast Routing for UNIX

License Badge GitHub Status Coverity Status

Table of Contents

Introduction

pimd is a lightweight, stand-alone PIM-SM/SSM multicast routing daemon available under the free 3-clause BSD license. This is the restored original version from University of Southern California, by Ahmed Helmy, Rusty Eddy and Pavlin Ivanov Radoslavov.

Today pimd is maintained at GitHub. This is the preferred way to download releases, access the GIT sources, report bugs, and send patches or pull requests. Official release tarballs at the homepage and at the GitHub project's release directory.

pimd is developed on Linux and should work as-is out of the box on all major distributions. Other UNIX variants; NetBSD, FreeBSD, and Illumos, may also work, but do not receive the same amount of testing.

pimd ships with a useful pimctl tool, compatible with all PIM daemons from the same family: pimd, pimd-dense, pim6sd. It can be a very helpful little tool when debugging and learning PIM setups. The pimctl API is documented in the file src/ipc.c, in case you want to use socat to talk to pimd over its UNIX domain socket:

echo "help" |socat - UNIX-CONNECT:/var/run/pimd.sock

For a summary of changes for each release, see the ChangeLog.

Configuration

The configuration is kept in the file /etc/pimd.conf, the order of the statements are in some cases important.

PIM-SM is a designed to be a protocol independent multicast routing protocol. As such it relies on unicast protocols like, e.g, OSPF, RIP, or static routing entries to figure out the reverse path to multicast sources. This information is necessary in setups with more than one route between a multicast sender and a receiver to figure out which PIM router should be the active forwarder.

However, pimd currently cannot retrieve the unicast routing distance (preference) and metric of routes from the system, not from the kernel nor a route manager like zebra. Hence, pimd currently needs to be setup statically on each router using the desired distance and metric for each active interface. If either the distance and/or the metric is missing in an interface configuration, the following two defaults will be used:

default-route-distance   <1-255>     default: 101
default-route-metric     <1-1024>    default: 1024

By default pimd starts up on all interfaces it can find, using the above defaults. To configure individual interfaces use:

phyint <address | ifname> ...

You can reference the interface via either its local IPv4 address or its name, e.g., eth0. Some common interface settings are:

  • disable: Disable pimd on this interface, i.e., do not send or listen for PIM-SM traffic

  • dr-priority <1-4294967294>: The DR Priority option, sent in all all PIM Hello messages. Used instead of the IP address in all DR elections, if all PIM routers in LAN advertise it. The higher, the better, default 1.

  • distance <1-255>: The interface's admin distance value (also confusingly referred to as metric preference in the RFC) in PIM Assert messages. Used with metric to elect the active multicast forwarding router. Defaults to default-route-distance

  • metric <1-1024>: The cost for traversing this router. Used with the preference value above. Defaults to default-route-metric

More interface settings are available, see the pimd(8) manual page for the full details.

The most notable feature of PIM-SM is that multicast is distributed from so called Rendezvous Points (RP). Each RP handles distribution of one or more multicast groups, pimd can be configured to advertise itself as a candidate RP rp-candidate, and request to be static RP rp-address for one or more multicast groups.

rp-address <address> [<group>[/<LENGTH> | masklen <LENGTH]

The rp-address setting is the same as the Cisco ip pim rp-address setting to configure static Rendezvous Points. The first argument can be an IPv4 address or a multicast group address. The default group and prefix length is 224.0.0.0/16. Static RP's always have priority 1.

rp-candidate [address | ifname] [interval <10-16383>] [priority <0-255>] \
             [group-prefix <group>[</LENGTH> | masklen <LENGTH>]]

The Rendezvous Point candidate, or CRP, setting is the same as the Cisco ip pim rp-candidate setting. Use it to control which interface that should be used in RP elections.

  • address | ifname: Optional local IPv4 address, or interface name to acquire address from. The default is to use the highest active IP address.

  • interval <10-16383>: The CRP advertisement interval, in seconds. Default: 60 seconds

  • priority <0-255>: How important this CRP is compared to others. The lower the value here, the more important the CRP. Like Cisco, pimd defaults to priority 0 when this is left out

In the CRP messages sent out by pimd, one or more multicast groups can be advertised using the following syntax.

group-prefix <group>[</LENGTH> | masklen <LENGTH>]

Each group-prefix setting defines one multicast group and an optional mask length, which defaults to 16 if left out. A maximum of 255 multicast group prefix records is possible for the CRP.

To keep track of all Rendezvous Points in a PIM-SM domain there exists a feature called Bootstrap Router. The elected BSR in a PIM-SM domain periodically announces the RP set in Bootstrap messages. For details on PIM BSR operation, see RFC 5059.

bsr-candidate [address | ifname] [priority <0-255>] [interval <10-26214>]

The configuration of a Candidate BootStrap Router (CBSR) is very similar to that of CRP. If either the address or the interface name is left out pimd uses the highest active IP address. If the priority is omitted, pimd (like Cisco) defaults to priority 0. If the interval is omitted, it defaults to the RFC value of 60 seconds.

In a PIM-SM domain there can be two, or more, paths from a designated router (DR) for a multicast sender to reach a receiver. When receivers begin joining multicast groups all data is received via the shared tree (RPT) from each Rendezvous Point (RP). This is often not an optimal route, so when the volume starts exceeding a configurable threshold, on either the last-hop router or the RP itself, the router will attempt to switch to the shortest path tree (SPT) from the multicast source to the receiver.

In versions of pimd prior to 2.2.0 this threshold was confusingly split in two different settings, one for the DR and one for the RP. These settings are still supported, for compatibility reasons and documented in the man-page, but it is strongly recommended to change to the new syntax instead:

spt-threshold [rate <KBPS> | packets <NUM> | infinity] [interval <5-60>]

Only slightly different from the Cisco ip pim spt-threshold setting, pimd can trigger a switch to SPT on a rate or number of packets and you can also tweak the poll interval. It's recommended to keep the interval in the tens of seconds, the default is 100 sec. The default threshold is set to zero packets, which will cause a switch over to the SPT after the first multicast packet is received.

Example

# Interface eth0 is disabled, i.e., pimd will not run there.
phyint eth0 disable

# On this LAN we have a lower numeric IP than other PIM routers
# but we want to take care of forwarding all PIM messages.
phyint eth1 dr-priority 10

# Partake in BSR elections on eth1
bsr-candidate eth1

# Offer to be an RP for all of 224.0.0.0/4
rp-candidate eth1
group-prefix 224.0.0.0 masklen 4

# This is the built-in defaults, switch to SPT on first packet
spt-threshold packets 0 interval 100

Running pimd

Having set up the configuration file, you are ready to run pimd. As usual, it is recommended that you start it manually first, to make sure everything works as expected, before adding it to your system's startup scripts, with any startup flags it might need.

pimd [-hnrsv] [-f file] [-d subsys1[,...,subsysN]] [-l level]
  • -n: Run in foreground, with logs to stdout (for systemd and finit)
  • -s: Use syslog, default unless -n
  • -c file: Utilize the specified configuration file rather than the default, /etc/pimd.conf
  • -d [subsys1,...,subsysN]: Subsystems to enable debug for when running the daemon. Optional argument, if left out, all subsystems are enabled. Type pimd -h for a full list of subsystems
  • -l level: Log level, one of none, error, warning, notice, info, or debug. Default is notice

Example:

pimd -f /cfg/pimd.conf

When running multiple instances of pimd, make sure to use the -I ident argument, otherwise the PID and IPC socket files will be overwritten and the syslog will also be hard to follow. Note, -I changes the default .conf filename pimd looks for as well, a complete identity change.

Enabling Debug

Remember to set the correct log level when enabling debug messages, usually you need -l debug, and -s to force messages to syslog when running in the foreground (-n).

pimd -d igmp_proto,pim_jp,kernel,pim_register -l debug -n -s

Troubleshooting Checklist

  1. Check the TTL of incoming multicast. Remember, the TTL of the multicast stream must be >1 to be routed. Or rather, > than then ttl-threshold of the inbound phyint

  2. If you see Permission denied in your logs, you are most likely having firewall, or SELinux, problems

  3. For PIM-SM, make sure you have a Rendezvous-Point (RP) in your network. Check rp-candidate (CRP) and bsr-candidate (CBSR) settings in your pimd.conf, or rp-address if you prefer the static RP approach

  4. Check the Linux rp_filter setting. Many Linux systems have the "strict" setting enabled, "loose" can work but may cause problems in some setups. We recommend disabling it entirely

  5. PIM is protocol independent so you must have unicast routeing in place already for pimd to work. Use ping to verify connectivity between multicast sender and receiver

Monitoring

To see the virtual interface table, including neighboring PIM routers, and the multicast routing table:

pimctl show interfaces
pimctl show neighbor
pimctl show mrt
...

The default command is pimctl show pim. To watch it continually (notice the -c flag to watch(1) to tell it to interpret the ANSI escape sequences):

watch -cd pimctl

See the pimctl help usage text for more commands (available only when a running PIM daemon is available), or the pimctl(8) man page.

Also worth mentioning, pimd logs important events to the system log, in particular at startup when it parses the pimd.conf configuration file.

Large Setups

pimd is limited to the number of MAXVIFS interfaces listed in the kernel headers. In Linux see /usr/include/linux/mroute.h.

To overcome this limitation, adjust the kernel #define to, e.g., 1280, and configure pimd --with-max-vifs=1280. Please note, this has only been tested with Linux and will likely not work with other kernels!

With this many interfaces the kernel may run out of memory to let pimd to enable IGMP on all interfaces. In Linux, use sysctl to tweak the following settings:

sysctl -w net.core.optmem_max=327680
sysctl -w net.ipv4.igmp_max_memberships=5120

Build & Install

The configure script and Makefile supports de facto standard settings and environment variables such as --prefix=PATH and DESTDIR= for the install process. E.g., to install pimd to /usr instead of the default /usr/local, but redirect install to a package directory in /tmp:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make
make DESTDIR=/tmp/pimd-2.3.2-1 install-strip

Building from GIT

If you want to contribute, or simply just try out the latest but unreleased features, then you need to know a few things about the GNU build system:

  • configure.ac and a per-directory Makefile.am are key files
  • configure and Makefile.in are generated from autogen.sh
  • Makefile is generated by configure script

To build from GIT you first need to clone the repository and run the autogen.sh script. This requires automake and autoconf to be installed on your system.

git clone https://github.com/troglobit/pimd.git
cd pimd/
./autogen.sh
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var && make

GIT sources are a moving target and are not recommended for production systems, unless you know what you are doing!

Contributing

pimd is maintained by Joachim Wiberg at GitHub. If you find bugs, have feature requests, or want to contribute fixes or features, check out the code from GitHub:

git clone https://github.com/troglobit/pimd
cd pimd

See the file CONTRIBUTING.md for further details.

Origin & References

Part of this program has been derived from mrouted. The mrouted program is covered by the 3-clause BSD license in the accompanying file named LICENSE.mrouted.

The mrouted program is COPYRIGHT 2002 by The Board of Trustees of Leland Stanford Junior University.

pimd's People

Contributors

acksys avatar apoikos avatar atessmer avatar bobek avatar cameronnemo avatar gclawes avatar geekmug avatar idismmxiv avatar josvarix avatar jp-t avatar louisatgh avatar nskeeper avatar oeboema avatar soar0603 avatar stormshield-damiend avatar stormshield-rlibaert avatar stormshield-sylvainm avatar tmo-github avatar troglobit avatar valrast avatar viharrai avatar vincentbernat avatar vitoni avatar wgc1212 avatar xdxu avatar yurkovskyy avatar zenvirta avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pimd's Issues

pimd's Configuration

Hi,

I've enabled multicasting in the linux kernel. I could run pimd with the default configuration (without any modification in its .conf file).

Now, I'm having some trouble in configuring pimd for my purpose. I need to connect two private networks using pimd. I have two clusters and I need to enable multicast between them.

Each cluster has a management node (router) that is the gateway for the internet. Thus, this node is a NAT server.

In order to have communication between a node in cluster A and a node in cluster B, the communication channel must pass through both management nodes.

I'm trying to configure pimd in this scenario. I need to have it forwarding multicast beween the two clusters. However, as far as I've seen, pimd "forwards" multicast from a subnet to another subnet. In my case, I need pimd forwarding from a subnet to another router (pimd) that forwards to another subnet.

Is that (create a multicast tunnel) possible? If yes, how should I configure pimd to achieve such multicast tunneling?

Regards,
Robson

Providing RedHat stuff for this project

Hello,

I am big fan of this multicast daemon for several years. Recently I found this successor on git hub with lot of new features (including igmpv3) and so on, so I am very happy that this project still lives in community (and thanks for your work!) :)

I am using it on RH platforms for years and now I have tried to rebuild pimd with your sourcetree (and I did it without any problems). I also wanted to help to improve this project so I am providing RPM SPEC file and initscript for this daemon which are compatible with RedHat-like systems (RHEL, Centos, fedora) so this software can be simply deployed on another platforms.
If you are interesting in those files, here are available:

init script - http://pastebin.com/vrefXZe6
rpm spec file - http://pastebin.com/d9Y5VhFW

feel free to use/modify it.

thank you

michal

PIMD

Hi,

I am a user of pimd version 2.1.8 and I have a clarification regarding the configuration of pimd. By default pimd runs on all interfaces and we could disable it on particular interfaces by using phyint interface command in conf file However this disables IGMP on that interface too which I don't want. I want pimd to run only on 1 interface of the router and IGMP on all the interfaces. May I know how to achieve this ?

Thank You,
Mahant
[email protected]

corrupted debug message

Receiving the following message:

Jun 15 13:58:28 ip-192-168-16-147 pimd[7785]: 13:58:28.401 RECV    30 bytes PIM v2 Hello              from 10.252.63.0     to 1...2.93.0

The 1...2.93.0 is the IP of the receiving interface (10.252.93.0). This only happens when pimd received a packet via local socket. Potential bug.

pimd (git version r7655b67) fails to build from source on Debian testing

Current pimd version r7655b67 in the git repository fails to compile for two reasons.

In the makefile, no include path is specified which is necessary for the source tree include directory containing the required header file netinet/pim.h

In the makefile, CFLAGS includes -Werror which means that with gcc-4.6, compilation of any file containing an unused variable will terminate with the unused variable error.

Furthermore the first declaration of CFLAGS in the makefile is CFLAGS =, rather than CFLAGS += which means that the makefile ignores any CFLAG enviromental variable set with the string

"-I <path_to_src>/include -Wno-error=unused-but-set-variable"

in order to correct the deficiences of the makefile.

kernerl patches for pimd

hi, i wonder if you have these two kernel patches to run pimd:
pimkern-freebsd-4.6.patch and netstat-freebsd-4.6.patch
or the patch files you mentioned : ip_mroute.{c,h} and ip.c,
I've tried so hard to find them ,but came nothing.
please tell me you have!!!

Linux kernel warns: 'mroute: pending queue full' -- pimd not responding?

Receiving the following log messages:

May 19 20:02:24 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries
May 19 20:02:24 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries
May 19 20:02:30 ip-192-168-16-66 kernel: net_ratelimit: 343 callbacks suppressed
May 19 20:02:30 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries
...
May 19 20:02:30 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries
May 19 20:02:36 ip-192-168-16-66 kernel: net_ratelimit: 118 callbacks suppressed
May 19 20:02:36 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries

Opened this issue to track the progress.

[PATCH] fix rp_address register path

Hey,

so I found a bug in the receive_pim_register() code where it seems the RP check is broken... It seems the code only looks at the my_cand_rp_address which is not set when using the rp_address configuration. Everything works fine with auto-RP mode though. This issue completely breaks the register path since the JOIN(S,G) is never sent back...

I tested the following patch and things seem fine now:

---
 pim_proto.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/pim_proto.c b/pim_proto.c
index 4ee3ff2..671725c 100644
--- a/pim_proto.c
+++ b/pim_proto.c
@@ -541,8 +541,8 @@ int receive_pim_register(u_int32 reg_src, u_int32 reg_dst, char *pim_message, si
     }
 
     /* XXX: not in the spec: check if I am the RP for that group */
-    if ((my_cand_rp_address != reg_dst)
-        || (check_mrtentry_rp(mrtentry_ptr, my_cand_rp_address) == FALSE)) {
+    if ((local_address(reg_dst) == NO_VIF) ||
+        (check_mrtentry_rp(mrtentry_ptr, reg_dst) == FALSE)) {
         send_pim_register_stop(reg_dst, reg_src, inner_grp, inner_src);
 
         return TRUE;
-- 

Thanks,
--jp

IGMPv3 not working

Configured all interfaces to use IGPMv3 via procfs. e.g.

echo 3 > /proc/sys/net/ipv4/conf/all/force_igmp_version

note: i changed this value on all interfaces.

On the wire:

[root@ip-192-168-16-66 ~]# tshark -i tun1759 -f "igmp"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'tun1759'
  1   0.000000 10.253.17.59 -> 224.0.0.1    IGMPv2 48 Membership Query, general
1   2   3.642623 10.253.17.59 -> 224.0.0.13   IGMPv2 48 Membership Report group 224.0.0.13
2   3   6.770621 10.253.17.59 -> 224.0.0.22   IGMPv2 48 Membership Report group 224.0.0.22
3   4   9.074621 10.253.17.59 -> 224.0.0.2    IGMPv2 48 Membership Report group 224.0.0.2
4

The issues is that I am still using IGMPv2. Any ideas how to force IGMPv3?

Add systemd service file for pimd

Requesting addition of systemd service file and environments file.

Environments:

cat > /etc/sysconfig/pimd << EOF
# pimd PIM-SM Daemon Environment File
EOF

Service file:

cat > /usr/lib/systemd/system/pimd.service << EOF
[Unit]
Description=pimd PIM-SM Daemon
After=syslog.target network.target
ConditionPathExists=/etc/pimd.conf

[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/pimd
ExecStart=/usr/local/sbin/pimd -c /etc/pimd.conf -digmp_proto,pim_jp,kernel,pim_register
ExecStop=/usr/local/sbin/pimd -q

[Install]
WantedBy=network.target
EOF

Any thoughts?

Running PIMD and Mrouted together.

I have installed both pimd and mrouted in my Fedora PC successfully. Now i want to run both of them together on different interfaces.
1 interface should run mrouted and other should run pimd.

How can i do that ?

pimd & dlink dgs-3627g

Hello.

I have the next configuration with dlink dgs-3627g and pimd that doesn't
work:

multicast server
| 192.168.100.2/24
|
v 192.168.100.1/24
pimd
| 192.168.77.8/24
|
v 192.168.77.1/24
dgs-3627g
| 192.168.200.1/24
|
v 192.168.200.2/24
client

If i connect a client computer instead of dgs-3627g, everything work well.
But if i insert between pimd and client dgs-3627g multicast doesn't pass
through.
With tcpdump i see that switch send join request, but pimd simply ignore
them (though, a dgs-3627g ip is shown as a neighbor).
So, i doesn't know, is it a misconfiguration, incompabitility or bug.

I get last pimd sources from a git.

patch for using '/' symbol instead of 'masklen' word

Greetings!
My English is not very good, excuse me if I said something wrong.

I think that syntax [ip_addr] masklen [masklen] in configuration file is not very convenient. In my opinion, much better [ip_addr]/[masklen] syntax. I just created a patch for config.c which allows to use any of both of syntaxes: [ip_addr] masklen [masklen] or [ip_addr]/[masklen].
If it is interesting to you, then patch can be downloaded from here: http://gentoo.homelan.lg.ua/distrib/config-use_slash_masklen.patch

With best regards, Alexey Prokopchuk (AP8686-RIPE).

bug about sending bootstrap when configured of c-rp & c-bsr at same router

pim_proto.c L--3169:

int send_pim_cand_rp_adv(void)
{
u_int8 prefix_cnt;
u_int32 grp_mask;
pim_encod_grp_addr_t encod_grp_addr;
u_int8 *data_ptr;

if (!inet_valid_host(curr_bsr_address))
    return FALSE;  /* No BSR yet */

if (curr_bsr_address == my_bsr_address) {
    /* I am the BSR and have to include my own group_prefix stuff */
    prefix_cnt = *cand_rp_adv_message.prefix_cnt_ptr;
    if (prefix_cnt == 0) {
        /* The default 224.0.0.0 and masklen of 4 */
        MASKLEN_TO_MASK(ALL_MCAST_GROUPS_LENGTH, grp_mask);
        add_rp_grp_entry(&cand_rp_list, &grp_mask_list,
                         my_cand_rp_address, my_cand_rp_priority,
                         my_cand_rp_holdtime,
                         htonl(ALL_MCAST_GROUPS_ADDR),
                         my_bsr_hash_mask,
                         grp_mask, curr_bsr_fragment_tag);
        return TRUE;
    }

look carefully at the 7th and 8th arguments of function add_rp_grp_entry, seems they are at each others' place, otherwise the bootstrap message would have the group address of "0.0.0.0":
---------->add_rp_grp_entry(&cand_rp_list, &grp_mask_list,
my_cand_rp_address, my_cand_rp_priority,
my_cand_rp_holdtime,
htonl(ALL_MCAST_GROUPS_ADDR),
grp_mask,
my_bsr_hash_mask, curr_bsr_fragment_tag);

pimd does not work in background under FreeBSD

FreeBSD 9.2-RELEASE amd64
pimd 2.2.0-alpha1

Being started without --debug and --foreground options pimd cant determine bootstrap router so doesn't send RP advertises. The reason is that we call pid=getpid() in routesock.c and use that value later to determine the valid message from routing socket.
But between those operations we do fork() in main.c to daemonize pimd, so it gets new process ID that is different from pid. After that rtm.rtm_pid != pid becomes always true and k_req_incoming() always returns FALSE.

The patch, probably not optimal, follows.
It moves pid determinition from init_routesock() to k_req_incoming().

--- routesock.c 2014-04-13 12:56:38.000000000 +0300
+++ routesock.c 2014-04-14 23:19:34.000000000 +0300
@@ -97,8 +97,6 @@
     int on = 0;
 #endif

-    pid = getpid();
-
     routing_socket = socket(PF_ROUTE, SOCK_RAW, 0);
     if (routing_socket < 0) {
        logit(LOG_ERR, errno, "Failed creating routing socket");
@@ -213,6 +211,8 @@
        return FALSE;
     }

+    pid = getpid();
+
     while (1) {
        rlen = read(routing_socket, &m_rtmsg, sizeof(m_rtmsg));
        if (rlen < 0) {

Fragmentation of register msgs

I have encountered a problem with register messages and am wondering if anyone else has seen the same thing or has any insights.

In my scenario, the problem occurs when the DR receives a full-size frame from a new source and encapsulates it in a register msg for sending to the RP. Due to the encap, the outgoing frame exceeds the MTU of the outgoing interface and the kernel returns error on the sendto() sys call with error EMSGSIZE. It seems that pimd needs to fragment the register msg whenever it exceeds the MTU of the outgoing interface or (better yet) when it exceeds the path MTU to the RP.

Building problem - make: *** No rule to make target `config.mk'. Stop.

Hello,
just trying to use latest pimd master. after unziping and running "make", building stucked with:

$ make
Makefile:29: config.mk: No such file or directory
make: *** No rule to make target `config.mk'. Stop.

as I can see the config.mk was recently removed from git. but the Makefile still points to that file:
...

This magic trick looks like a comment, but works on BSD PMake

include <config.mk>

include config.mk
...

PIM router does not forward traffic received from PIM DR router

@troglobit, there are two routers connected via GRE tunnel: R1 and R2.

R1 is RP.

R2 send multicast packets to the group address of 239.2.2.10:

# mtools_2.2/msend -i 10.254.0.110 -g 239.2.2.10 -p 5001
Now sending to multicast group: 239.2.2.10
Send out msg 1 to 239.2.2.10:5001:
Send out msg 2 to 239.2.2.10:5001:

R1 sees the packets arriving when listening on its tunnel interface:

# ./mreceive -g 239.2.2.10 -p 5001-i 10.254.0.12
Now receiving from multicast group: 239.2.2.10
Receive msg 1 from 10.254.0.110:5001:
Receive msg 2 from 10.254.0.110:5001:

The issue arose when sending traffic to another interface of R1. It does not forward the packet over.

Troubleshooting:

  1. On R2, checked multicast forwarding:
 find  /proc -type f -name "mc_forwarding" -exec awk 'END {print $0 "," FILENAME}' {} \;

1,/proc/sys/net/ipv4/conf/all/mc_forwarding
0,/proc/sys/net/ipv4/conf/default/mc_forwarding
0,/proc/sys/net/ipv4/conf/lo/mc_forwarding
1,/proc/sys/net/ipv4/conf/pimreg/mc_forwarding
1,/proc/sys/net/ipv4/conf/tun1/mc_forwarding

The same on R1:

1,/proc/sys/net/ipv4/conf/all/mc_forwarding
0,/proc/sys/net/ipv4/conf/default/mc_forwarding
0,/proc/sys/net/ipv4/conf/lo/mc_forwarding
1,/proc/sys/net/ipv4/conf/pimreg/mc_forwarding
1,/proc/sys/net/ipv4/conf/tun1/mc_forwarding

Also, checked the following

# expected value is 1
cat /proc/sys/net/ipv4/ip_forward
# expected value is 0
cat /proc/sys/net/ipv4/conf/all/rp_filter
# expects virtual interfaces
cat /proc/net/ip_mr_vif

Other tunnels work fine.

Any ideas?

Default config uses "/etcpimd.conf" instead of "/etc/pimd.conf"

This bit in Makefile is probably the culprit.

sysconfdir   ?= /etc
[...]
CPPFLAGS     += -D_PATH_SYSCONF=\"$(sysconfdir)\"

Compare to pathnames.h:

#ifndef _PATH_SYSCONF
#define _PATH_SYSCONF           "/etc/"
#endif

#define _PATH_PIMD_CONF         _PATH_SYSCONF "pimd.conf"

Note that explicitly setting --sysconfdir=/etc works fine:

        sysconfdir)
            echo "sysconfdir    = $arg/" >> $TMP
            ;;

On a related note, "sysconfidir" in the configure help text is a typo.

pimd slow to add MFC entries

Hi @troglobit,

I'm working with pimd with the following topology:

Four networks: n1, n2, n3, n4. n1 is a management LAN. Multicast sources are on n2. n3 is an OpenVPN TAP tunnel. Multicast receivers are on n4.

RP1 is the rendezvous point, a Cisco router. It is connected to n1 and n2.
SRC is the OpenVPN server, running Ubuntu 14.04. It is connected to n1, n2, and n3.
PI1 is the client, running Raspbian. It is connected to n3 and n4.

SRC and PI1 are running pimd. RP1 is the Rendezvous Point.

Unicast routing protocol is OSPF and appears to be stable.

n1 is 10.153.1.0/24.
n2 is 10.153.255.0/24.
n3 is 10.153.251.0/24.
n4 is 10.153.4.128/27.
n5 is 192.168.88.0/24. n5 is the network that pi1 is connected to for connectivity, but it's not part of the multicast routing topology as the router that connects n5 to n1 is not pim capable, hence the tunnels. It's part of the OSPF area, but the connected route takes precedence over the learned one on PI1 and I've installed a pinhole route to the VPN server. It's a bit of a hack, but these aren't meant to run on n5 anyway, it's just a testing area.

pimd seems to be working properly, except that it takes an extremely long time (anywhere from 5 seconds to 60 seconds) to add the MFC entry to the kernel routing table and start forwarding packets. With two pimd's between n4 and n2, that makes for extremely slow and arbitrary starts to multicast streams. Replacing SRC and PI1 with Cisco gear, the time is on the order of milliseconds (I haven't measured it enough, but it's fast enough that I can't count it in my head and it feels "instant," which implies it's probably less than 100ms).

Everything works fine, so long as I'm willing to wait a long time for my stream to start. igmpproxy works fine and has response speeds similar to the Cisco gear (with occasional blips of up to a few seconds that the Cisco's don't experience), so this seems to be an issue with pimd specifically.

From the debug log, it looks like pimd is resolving everything to the correct interfaces and is building the correct route internally. It just takes too long to update the MFC. The receiving devices often time out before it happens and leave/join, which causes the whole process to start over, and can result in a stream taking many minutes to start.

This is currently a static RP setup with only RP1 as the RP for all the streams. The streams are all in 239.0.1.0/24.

pimd version 2.3.0.

Support disable-vifs in pimd.conf

disable-vifs can make configuration much simpler on systems with a large number of interfaces. Could it be supported directly in pimd.conf?

pimd: FTBFS, compiler warning + -Werror

Hi Joachim,

I have tried to upload new 2.1.2 to Debian. It turned out, that it is not compilable on multiple architectures. It is reported as bug 595584 in Debian. I haven't done any detailed investigation yet, so if you aware of the solution, please push it to the repo. Thanks.

Antonin

Package: pimd Version: 2.1.2-1 Severity: serious

latest pimd FTBFS on all architectures [0] like you can see on s390 [1]:

| CC vif.o
| CC timer.o
| CC mrt.o
|cc1: warnings being treated as errors
|mrt.c: In function 'find_route':
|mrt.c:128: error: 'grpentry_ptr' may be used uninitialized in this function
|make[1]: *** [mrt.o] Error 1
|make[1]: Leaving directory `/build/buildd-pimd_2.1.2-1-s390-pFxWac/pimd-2.1.2'
|make: *** [build-stamp] Error 2
|dpkg-buildpackage: error: debian/rules build gave error exit status 2

[0] https://buildd.debian.org/status/package.php?p=pimd
[1] https://buildd.debian.org/fetch.cgi?pkg=pimd&arch=s390&ver=2.1.2-1&stamp=1283677396&file=log&as=raw

Sebastian

Fixing unused-but-set-variable errors

Hi,

we have a bunch of unused-but-set-variable warning which are causing build failure on Debian ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634393 ) as we are setting -Wall -Werror. I've tried to go through them and remove some of the unsed and mark the ones which are not used but cannot be removed (e.g. in proto structures). Can you please review commits in unused-but-set-variable branch, make changes and eventually merge them into master? I would then build new package for Debian.

Thank you,

Antonin

pimd does not receive PIMv2 Hello

I have a point to point TUN/TAP interface.

While sniffing, I see that my two hosts 10.252.93.0 and 10.252.63.0 receive each other PIMv2 Hello packets.

[root@ip-192-168-16-146 ~]# tshark -i flannel0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'flannel0'
  1   0.000000  10.252.63.0 -> 224.0.0.13   IGMPv2 32 Membership Report group 224.0.0.13
  2   0.480001  10.252.63.0 -> 224.0.0.22   IGMPv2 32 Membership Report group 224.0.0.22
2   3   5.055051  10.252.93.0 -> 224.0.0.13   PIMv2 30 Hello
3   4   9.494298  10.252.63.0 -> 224.0.0.13   PIMv2 30 Hello
4   5  35.085053  10.252.93.0 -> 224.0.0.13   PIMv2 30 Hello
  6  35.085065  10.252.93.0 -> 224.0.0.1    IGMPv2 32 Membership Query, general
6   7  36.865825  10.252.93.0 -> 224.0.0.22   IGMPv2 32 Membership Report group 224.0.0.22
7   8  39.329709  10.252.93.0 -> 224.0.0.2    IGMPv2 32 Membership Report group 224.0.0.2
  9  39.525122  10.252.63.0 -> 224.0.0.13   PIMv2 30 Hello
9  10  39.525188  10.252.63.0 -> 224.0.0.1    IGMPv2 32 Membership Query, general
10  11  44.593635  10.252.93.0 -> 224.0.0.13   IGMPv2 32 Membership Report group 224.0.0.13
11  12  47.552000  10.252.63.0 -> 224.0.0.2    IGMPv2 32 Membership Report group 224.0.0.2
12  13  48.448001  10.252.63.0 -> 224.0.0.22   IGMPv2 32 Membership Report group 224.0.0.22
 14  48.543999  10.252.63.0 -> 224.0.0.13   IGMPv2 32 Membership Report group 224.0.0.13
14  15  65.615259  10.252.93.0 -> 224.0.0.13   PIMv2 30 Hello
15

Relevant interfaces:

[root@ip-192-168-16-146 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP qlen 1000
    link/ether 0a:14:58:92:4d:6f brd ff:ff:ff:ff:ff:ff
    inet 192.168.16.146/24 brd 192.168.16.255 scope global dynamic eth0
       valid_lft 3566sec preferred_lft 3566sec
    inet6 fe80::814:58ff:fe92:4d6f/64 scope link
       valid_lft forever preferred_lft forever
392: flannel0: <POINTOPOINT,MULTICAST,UP,LOWER_UP> mtu 8973 qdisc pfifo_fast state UNKNOWN qlen 500
    link/none
    inet 10.252.63.0/16 scope global flannel0
       valid_lft forever preferred_lft forever
393: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 56:84:7a:fe:97:99 brd ff:ff:ff:ff:ff:ff
    inet 10.252.63.1/24 scope global docker0
       valid_lft forever preferred_lft forever
396: pimreg@NONE: <NOARP,UP,LOWER_UP> mtu 1472 qdisc noqueue state UNKNOWN
    link/pimreg
[root@ip-192-168-16-146 ~]# ip route
default via 192.168.16.1 dev eth0
10.252.0.0/16 dev flannel0  proto kernel  scope link  src 10.252.63.0
10.252.63.0/24 dev docker0  proto kernel  scope link  src 10.252.63.1
192.168.16.0/24 dev eth0  proto kernel  scope link  src 192.168.16.146
[root@ip-192-168-16-146 ~]# ip mroute
[root@ip-192-168-16-146 ~]#

However, at the same time, pimd debug messages do not show PIMv2 Hellos received from the other end of the tunnel.

Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: Virtual Interface Table ======================================================
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: Vif  Local Address    Subnet              Thresh  Flags      Neighbors
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: ---  ---------------  ------------------  ------  ---------  -----------------
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: 0  192.168.16.146   192.168.16               1  DISABLED
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: 1  10.252.63.0      10.252/16                1  PIM        10.252.63.1
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: 2  10.252.63.1      10.252.63/24             1  DR NO-NBR
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: 3  10.252.63.0      register_vif0            1
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: Multicast Routing Table ======================================================
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: --------------------------------- (*,*,G) ------------------------------------
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: Number of Groups: 0
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: Number of Cache MIRRORs: 0
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: ------------------------------------------------------------------------------
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: Candidate Rendezvous-Point Set ===============================================
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: RP address       Incoming  Group Prefix        Priority  Holdtime
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: ---------------  --------  ------------------  --------  ---------------------
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: ------------------------------------------------------------------------------
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: Current BSR address: 0.0.0.0
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: 03:53:11.849 RECV    30 bytes PIM v2 Hello              from 10.252.63.0     to 224.0.0.13
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: 03:53:11.849 RECV    30 bytes PIM v2 Hello              from 10.252.63.1     to 224.0.0.13
Jun 08 03:53:11 ip-192-168-16-146.inf.ise.com pimd[13002]: 03:53:11.849 PIM HELLO holdtime from 10.252.63.1 is 105

For some reason the packets does not reach pimd daemon (although they reach flanneld0 interface. Any ideas?

Issue #22 does not seem to be resolved

I downloaded, compiled 2.2.0 and set it up in a triangle topology of 3 routers with the top node of the triangle configured as the RP. I start traffic and wait for traffic to switch to shortest path tree (first hop router and last hop router left and right hand nodes of the triangle respectively). I then simulate a link
down event between the two nodes and I get same crash and stack trace previously reported for this issue:

#0 0x0805beec in add_jp_entry () 
#1 0x0805739e in age_routes () 
#2 0x0804e670 in timer () 
#3 0x080545d1 in age_callout_queue () 
#4 0x0804ee0f in main () 

Add support for configurable IGMP query interval

hello
just wanted to ask. can be somehow the igmp query changed? currently igmp query (v2) was sent out every ~2 minutes. it is possible to change it somehow? is there any configuration directive - global or per phyint to change this behavior?
thank you

Using loopback interface as RP-candidate

I have a loopback interface with IP address 10.254.0.1

[root@ip-192-168-16-66 ~]# ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 10.254.0.1/32 brd 10.254.0.1 scope global lo:1
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
[root@ip-192-168-16-66 ~]# 

In my pimd.conf, I have the following:

phyint eth0 disable
phyint docker0 disable
phyint 10.254.0.1 preference 255
rp_address 10.254.0.1
cand_rp 10.254.0.1
group_prefix 224.0.0.0 masklen 4

Unfortunately, I receive the following error when starting the service:

May 18 19:58:18 ip-192-168-16-66 pimd[3767]: 19:58:18.144 Getting vifs from /etc/pimd.conf
May 18 19:58:18 ip-192-168-16-66 pimd[3767]: 19:58:18.144 Local static RP: 10.254.0.1, group 224.0.0.0/4
May 18 19:58:18 ip-192-168-16-66 pimd[3767]: 19:58:18.144 warning - /etc/pimd.conf:6 - Cand-RP address '10.254.0.1' is not local, defaulting to 0.0.0.0
May 18 19:58:18 ip-192-168-16-66 pimd[3767]: 19:58:18.144 Local Cand-RP address 0.0.0.0, priority 0, interval 60 sec
May 18 19:58:18 ip-192-168-16-66 pimd[3767]: 19:58:18.144 Adding Cand-RP group prefix 224.0.0.0/4
May 18 19:58:18 ip-192-168-16-66 pimd[3767]: 19:58:18.144 IGMP query interval  : 125 sec
May 18 19:58:18 ip-192-168-16-66 pimd[3767]: 19:58:18.144 IGMP querier timeout : 255 sec
May 18 19:58:18 ip-192-168-16-66 pimd[3767]: 19:58:18.144 Cannot forward: no enabled vifs
May 18 19:58:18 ip-192-168-16-66 systemd[1]: pimd.service: main process exited, code=exited, status=255/n/a
May 18 19:58:18 ip-192-168-16-66 systemd[1]: Unit pimd.service entered failed state.

Please assist.

pimd didn't send announcement on FreeBSD

I've just tried to run pimd between 2 FreeBSD box (10.0-BETA2), and I've got lot's of error messages:

17:10:03.784 warning - sendto from 10.0.23.3 to 224.0.0.13:(error 22): Invalid argument
17:10:03.785 warning - Sendto to 224.0.0.1 on 10.0.34.3:(error 22): Invalid argument
17:10:03.786 warning - sendto from 10.0.34.3 to 224.0.0.13:(error 22): Invalid argument
17:10:48.527 warning - Received packet from 10.0.34.3 shorter (48 bytes) than hdr+data length (24+12264)
17:10:48.527 warning - Received packet from 10.0.23.3 shorter (48 bytes) than hdr+data length (24+12264)
17:10:48.727 warning - Received packet from 10.0.34.3 shorter (48 bytes) than hdr+data length (24+12264)
17:10:48.727 warning - Received packet from 10.0.23.3 shorter (48 bytes) than hdr+data length (24+12264)

17:11:48.877 warning - sendto from 10.0.23.3 to 224.0.0.13:(error 22): Invalid argument
17:11:48.877 warning - sendto from 10.0.34.3 to 224.0.0.13:(error 22): Invalid argument

And the second box don't received any PIM announcement from this first box.

Regards,

Olivier

fail to compile with gcc-4.7.1 using "-Wall -Werror"

if remove "-Wall -Werror", then works fine!
not sure whether should fix the code or the compiler,
thanks.

main.c: In function ‘main’:
main.c:490:5: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
main.c:490:5: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
main.c:493:2: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
main.c:493:2: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
main.c:583:3: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
main.c:583:3: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
main.c:586:7: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
main.c:586:7: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
main.c:613:7: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
main.c:613:7: error: signed and unsigned type in conditional expression [-Werror=sign-compare]
cc1: all warnings being treated as errors
make: *** [main.o] Error 1
make: INTERNAL: Exiting with 8 jobserver tokens available; should be 7!

  • ERROR: net-misc/pimd-9999 failed (compile phase):
  • emake failed
  • If you need support, post the output of emerge --info '=net-misc/pimd-9999',
  • the complete build log and the output of emerge -pqv '=net-misc/pimd-9999'.
  • This ebuild is from an overlay named 'ofree': '/var/lib/layman/ofree/'
  • The complete build log is located at '/var/build/portage/net-misc/pimd-9999/temp/build.log'.
  • The ebuild environment file is located at '/var/build/portage/net-misc/pimd-9999/temp/environment'.

IGMP "Other querier present timer" not implemented

It seems that the "other querier present timer" is not implemented in the IGMP code (See RFC 2236 section 8.5, and section 7). The consequence hereof is that pimd does not resume as a querier if another querier with a lower IP address has been present in the past. With IGMP snooping switches without inbuilt queriers, this may break multicast altogether on the network.

Essentially, a non-querier IGMP router should listen for general queries from other queries, and restart the other querier present timer when it hears one. If the timer times out (other-querier-present-interval = robustness * query-interval + query-response-interval / 2 = 2 * 125 + 10 / 2 = 255 seconds), the IGMP router should switch to querier state and immediate transmit a general query. If it fails to do so, the multicast memberships expires 5 seconds after (group-membership-interval = robustness * query-interval + query-response-interval = 2 * 125 + 10 = 260 seconds).

Tunnel interfaces with multicast

I have a tunnel interface

26: tun1@NONE: <POINTOPOINT,MULTICAST,NOARP,ALLMULTI,UP,LOWER_UP> mtu 1460 qdisc noqueue state UNKNOWN 
    link/gre 10.10.1.1 peer 192.168.16.66
    inet 10.254.0.12 peer 10.254.0.11/32 scope global tun1
       valid_lft forever preferred_lft forever

I can see PIMv2 Hello packet being send out of tun1 interface.

11:35:52.554834 IP ny-rt01 > igmp.mcast.net: igmp v2 report igmp.mcast.net
11:35:54.074839 IP ny-rt01 > pim-routers.mcast.net: igmp v2 report pim-routers.mcast.net
11:35:58.394837 IP ny-rt01 > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
11:36:12.189511 IP ny-rt01 > pim-routers.mcast.net: PIMv2, Hello, length 10
11:36:42.220039 IP ny-rt01 > pim-routers.mcast.net: PIMv2, Hello, length 10

The interface is registered to forward multicast traffic.

# cat /proc/net/ip_mr_vif 
Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
 2 tun1              0       0         0       0 00000 0C00FE0A 0B00FE0A
 3 pimreg            0       0         0       0 00004 0C00FE0A 00000000
#

However, the packets never make it to the physical interface and to the other end of that tunnel. Unicast traffic, i.e. BGP and ICMP, works without any issue.

Any idea why that is happening?

Update pimd to RFC4601

Currently pimd implements RFC2362, which is a previous PIM-SM experimental RFC, plus some changes from early drafts of RFC4601.

All new implementations following RFC4601 should be backwards compatible. This issue has been filed as a reminder to start working out differences and iron out TODOs to reach full RFC4601 compliance.

For details See http://datatracker.ietf.org/doc/rfc4601/ and complementary RFC5059 and RFC5796.

pimd segfaults in igmp_read()

Hello

I am using/testing pimd on centos 6.5 x86_64. But pimd suddently started to segfault. Here I have tried to debug it as much as possible:

$ gdb --args /usr/sbin/pimd -c /etc/pimd.conf -f
Starting program: /usr/sbin/pimd -c /etc/pimd.conf -f
pimd: 12:47:37.659 warning - Ignoring eth6:0, same subnet as eth6
pimd: 12:47:37.659 warning - Ignoring eth6:1, same subnet as eth6
pimd: 12:47:37.659 warning - Ignoring eth6:2, same subnet as eth6
pimd: 12:47:37.659 warning - Ignoring eth6:3, same subnet as eth6
pimd: 12:47:37.660 warning - Ignoring eth6:4, same subnet as eth6
pimd: 12:47:37.660 warning - Ignoring eth6:5, same subnet as eth6
pimd: 12:47:37.660 warning - Ignoring eth6:6, same subnet as eth6
^C
Program received signal SIGINT, Interrupt.
0x0000003c300e15c3 in __select_nocancel () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64
(gdb) b abort
Breakpoint 1 at 0x3c30033f90
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000401fd8 in igmp_read ()
(gdb) bt
#0 0x0000000000401fd8 in igmp_read ()
#1 0x00000000004058bc in main ()

pimd.conf:
rp_address X.X.X.X
phyint eth3.100 disable
phyint eth3.101 disable
phyint eth3.102 disable
phyint eth3.103 disable
phyint eth3.104 disable
phyint eth3.120 disable
phyint eth3.122 disable
phyint eth2.2 disable
phyint eth2.502 disable
phyint eth2.1000 disable
phyint eth1 disable
phyint eth4 disable
phyint eth5 disable
cand_rp time 30 priority 18
cand_bootstrap_router priority 8
group_prefix 224.0.0.0 masklen 4

we are using this centos server as router between corporate subnets and providing upstream internet connectivity. some of interfaces disabled as you can see above.

list of all interfaces:

eth0
eth1
eth4
eth5
eth6
eth2.10
eth2.1000
eth2.11
eth2.12
eth2.2
eth2.502
eth3.100
eth3.101
eth3.102
eth3.103
eth3.104
eth3.120
eth3.122

is something else needed?

thank you

Dynamic add/remove interfaces

Hi

I looking for a feature that allows me to add/remove int on the fly. I would like to connect by ppp to the server and enable IGPM on the ppp int without reloading all config and dropping existing flows. Is is possible to implement ?

Add support for IGMP v3 Membership Reports

Gil Beniamini reports (via mail) having patched up pimd with basic IGMP v3 support.

Issue which lead to investigation:
In one setup multicast stream would start and work for about 5 minutes and stop forever (until pimd is restarted), apparently I found out that PIMd neighbor which was WinXP started with sending iGMPv2 membership_report(==join), but after 2 reports switched to iGMPv3 MEMBERSHIP_REPORT which is not handled by pimd v2.1.8, and so after timeout delete_leaf() is called and receive of multicast by that neighbor is stopped!

Further findings:
pimd v2.1.8 did not support iGMP v3, and if neighbor "node" was sending MEMBERSHIP_REPORT in iGMPv3 ((even if not SSM) for PIM-SM with EXCLUDE "source"), it was not received by pimd and MCAST tree failed to be created as expected
=> need to support iGMPv3 in iGMPv2 compatibility mode (our patch marked with GIL_SUPPORT_IGMPV3, related files vif.c & igmp.c).

ROOT-CAUSE: Why did our neighbor "node" switch to iGMPv3 after ~2 minutes?
In our case on our subnet there is an ADSL-router who sends once every 125sec iGMPv3-Query. When our "pimd" comes up it also sends one iGMPv2-Query and cause our listen/Mcast-Receiver PC to switch to iGMPv2, but once our "pimd" receive iGMPv3-Query from the neighbor ADSL-router it replies but also stop sending it's iGMPv2 Query. After timeout (260sec from last iGMPv2 MEMBERSHIP_REPORT) and when only the ADSL-router V3 Queries are on our subnet, it cause the neighbor Mcast-Receiver PC to switch to iGMPv3 MEMBERSHIP_REPORTS!

This is the root cause to add support for accepting IGMPv3 MEMBERSHIP_REPORT!

I have created a small patch, to enable “pimd” receive iGMPv3 messages, and also handle iGMPv3_MEMBERSHIP_REPORTS with source-exclude to trigger the correct accept_group_report() / accept_leave_message().

Now the above setup is perfectly working.

Crash in (S,G) state when neighbor is lost

I had to add the following code to the bottom of delete_pim_nbr():

 for (cand_rp_ptr = cand_rp_list; cand_rp_ptr != (cand_rp_t *)NULL;
     cand_rp_ptr = cand_rp_ptr->next) {
    for (rp_grp_entry_ptr = cand_rp_ptr->rp_grp_next;
        rp_grp_entry_ptr != (rp_grp_entry_t *)NULL;
        rp_grp_entry_ptr = rp_grp_entry_ptr->rp_grp_next)
        {
       for (grpentry_ptr = rp_grp_entry_ptr->grplink;
           grpentry_ptr != (grpentry_t *)NULL;
           grpentry_ptr = grpentry_ptr->next) {
            mrtentry_srcs = grpentry_ptr->grp_route;
            if (mrtentry_srcs != NULL ) {
              if(mrtentry_srcs->upstream != NULL) {
                  if (mrtentry_srcs->upstream == nbr_delete) {
                     mrtentry_srcs->upstream = NULL;
                  }
              }
         }
    }
}
}

age_routes was crashing because upstream had been freed, then someone else (timer_setTimer) was allocating the freed memory and clobbering the bjpm pointer.
Y-

make throws "has no member named ‘mfcc_rp_addr’" error

Configuring and then compiling:

./configure --enable-scoped-acls --enable-kernel-encap --enable-memory-save --enable-kernel-mfc

and receive the following error:

# make
  CC      kern.o
kern.c: In function ‘k_chg_mfc’:
kern.c:446:7: error: ‘struct mfcctl’ has no member named ‘mfcc_rp_addr’
     mc.mfcc_rp_addr.s_addr = rp_addr;
       ^
make: *** [kern.o] Error 1
#

without --enable-kernel-encap builds just fine.

PIM in a flat network

Hello,

I am trying to use PIM (v2.1.8) in a network where all the links are in the same subnet (with /0 netmask). This is a kind of MANET and nodes can move and connect to any other node. So, we are using flat network with OLSR as the routing protocol. (As of now, this is being simulated using wired network only. Later we will use wireless.)

The problem we face is if multiple Interfaces are there in the same subnet, pimd listens only on one Interface and ignores the rest. Is there any way to overcome this? Thank you.

Regards,
Vignesh

warning - sendto from (error 13): Permission denied

Opening this issue to solve the issue underlying the following error message:

Jun 11 15:08:41 ip-192-168-16-146 pimd[20392]: 15:08:41.124 warning - sendto from 10.252.63.1 to 10.252.63.0:(error 13): Permission denied
Jun 11 15:08:41 ip-192-168-16-146 pimd[20392]: 15:08:41.124 warning - sendto from 10.252.63.1 to 10.252.63.0:(error 13): Permission denied
Jun 11 15:08:41 ip-192-168-16-146 pimd[20392]: warning - sendto from 10.252.63.1 to 10.252.63.0: Permission denied
Jun 11 15:08:41 ip-192-168-16-146 pimd[20392]: warning - sendto from 10.252.63.1 to 10.252.63.0: Permission denied

pimd with `--enable-scoped-acls` FTBS

When compiling pimd-2.2.0 with --enable-scoped-acls, I received the following error:

# ./configure --enable-scoped-acls
# make
  CC      route.o
route.c: In function ‘process_cache_miss’:
route.c:90:14: error: assignment makes integer from pointer without a cast [-Werror]
   (mp)->oifs = NULL;  \
              ^
route.c:906:6: note: in expansion of macro ‘APPLY_SCOPE’
      APPLY_SCOPE(group,mrt);
      ^
route.c:90:14: error: assignment makes integer from pointer without a cast [-Werror]
   (mp)->oifs = NULL;  \
              ^
route.c:938:3: note: in expansion of macro ‘APPLY_SCOPE’
   APPLY_SCOPE(group,mrt);
   ^
cc1: all warnings being treated as errors
make: *** [route.o] Error 1
#

Without the flag, I am able to build it successfully.

# pimd -v
pimd version 2.2.0
#

Please assist.

Multicast routing table not updated on FreeBSD

Here is my simple setup with 2 routers (R2 and R3) when I ask to use igmpv2:

mcast server (em0) --- (em0) R2 (em1) ---- (em1) R3 (em2) ---- (em2) subscriber

[root@R2]~# pimd -v
pimd version 2.3.0

[root@R2]~# cat /usr/local/etc/pimd.conf
cand_rp 10.0.23.2 time 10 priority 1

[root@R3]~# cat /usr/local/etc/pimd.conf
cand_bootstrap_router 10.0.23.3 priority 1

[root@R3]~# pimd -dd
debug level 0x7 (dvmrp_prunes,dvmrp_routes,dvmrp_neighbors)
22:48:45.635 pimd version 2.3.0 starting ...
22:48:45.635 Getting vifs from kernel
22:48:45.636 Installing em1 (10.0.23.3 on subnet 10.0.23/24) as vif #0 - rate 0
22:48:45.636 Installing em2 (10.0.34.3 on subnet 10.0.34/24) as vif #1 - rate 0
22:48:45.636 Getting vifs from /usr/local/etcpimd.conf
22:48:45.639 Interface em1 comes up; vif #0 now in service
22:48:45.643 Interface em2 comes up; vif #1 now in service
22:48:45.647 Interface register_vif0 comes up; vif #2 now in service


[root@R2]~# pimd -dd
debug level 0x7 (dvmrp_prunes,dvmrp_routes,dvmrp_neighbors)
22:48:47.392 pimd version 2.3.0 starting ...
22:48:47.392 Getting vifs from kernel
22:48:47.392 Installing em0 (10.0.12.2 on subnet 10.0.12/24) as vif #0 - rate 0
22:48:47.393 Installing em1 (10.0.23.2 on subnet 10.0.23/24) as vif #1 - rate 0
22:48:47.393 Getting vifs from /usr/local/etcpimd.conf
22:48:47.394 Interface em0 comes up; vif #0 now in service
22:48:47.398 Interface em1 comes up; vif #1 now in service
22:48:47.402 Interface register_vif0 comes up; vif #2 now in service

Then I ask the subscriber to subscribe to an mcast group:

[root@R4]~# mtest
multicast membership test program; enter ? for list of commands
j 239.1.1.1 em2 10.0.12.1
ok

R3 correctly notice this new membership:

22:50:14.242 Switch shortest path (SPT): src 10.0.12.1, group 239.1.1.1
22:50:15.643 Switch shortest path (SPT): src 10.0.12.1, group 239.1.1.1
22:50:20.843 Switch shortest path (SPT): src 10.0.12.1, group 239.1.1.1

But its multicast routes of PIM router R3 are still empty:

[root@R3]~# pimd -r
Virtual Interface Table ======================================================
Vif  Local Address    Subnet              Thresh  Flags      Neighbors
---  ---------------  ------------------  ------  ---------  -----------------
  0  10.0.23.3        10.0.23/24               1  DR PIM     10.0.23.2
  1  10.0.34.3        10.0.34/24               1  DR NO-NBR
  2  10.0.23.3        register_vif0            1

 Vif  SSM Group        Sources

Multicast Routing Table ======================================================
--------------------------------- (*,*,G) ------------------------------------
Number of Groups: 0
Number of Cache MIRRORs: 0
------------------------------------------------------------------------------

=> Should't it display this new mcast group ?

Force sending join/prune when there are no neighbors?

I have a PIM setup that runs over a one-way GRE tunnel with a static RP configured. As far as I know, everything should work, except that pimd never sees Hello from the other end because the tunnel only carries outgoing traffic.

Can pimd be taught to send multicast join/prune messages even though it doesn't see any neighbors?

Add support for Cisco style "ip pim register-source"

Thomas Lau of Tetrion Captial Ltd writes:

On Cisco router I could use ip pim register-source to specific
which source IP / interface should I use to "announce" to neighbor,
but I can't see this option exists on PIMD, may I know how could I
implement this? ​

Add support for DR Priority option in PIM hello messages

When an IOS router sends out PIM hellos, they include a variety of options:

01:50:17.956481 IP (tos 0xc0, ttl 1, id 3442, offset 0, flags [none], proto PIM (103), length 58) 129.241.93.9 > 224.0.0.13: PIMv2, length 38
Hello, cksum 0x7333 (correct)
Hold Time Option (1), length 2, Value: 1m45s
0x0000: 0069
Generation ID Option (20), length 4, Value: 0x9b4bd1df
0x0000: 9b4b d1df
DR Priority Option (19), length 4, Value: 0
0x0000: 0000 0000
State Refresh Capability Option (21), length 4, Value: v1
0x0000: 0100 0000
Unknown Option (65004), length 0, Value:

In particular, the DR Priority Option helps other routers determine which one is the DR for this subnet. However, pimd does not include this option, or barely any at all:

01:50:17.961914 IP (tos 0x0, ttl 1, id 33270, offset 0, flags [none], proto PIM (103), length 30) 129.241.93.30 > 224.0.0.13: PIMv2, length 10
Hello, cksum 0xdf93 (correct)
Hold Time Option (1), length 2, Value: 1m45s
0x0000: 0069

This makes it seemingly always win the election, even when it shouldn't. The included example pimd.conf claims setting preference to 101 should make it lose to other gear, but in practice it seems to have no effect.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.