search

troglobit / pimd

PIM-SM/SSM multicast routing for UNIX and Linux
http://troglobit.com/projects/pimd/
BSD 3-Clause "New" or "Revised" License
202 stars 90 forks source link

Support for reloading pimd.conf without disturbing established flows #72

Open kcao3 opened 8 years ago

kcao3 commented 8 years ago

Hello, I have a question about PIMD in operation. I am currently running PIMD (version 2.3.0) on a linux host machine. I would like to know once the pimd daemon has been started and running and if a new network device/interface is created on this same machine, WITHOUT RESTART is there a way that the running PIMD daemon can detect the new network interface? In other words, once the PIMD application is started, is there a way that it can pick up this new network interface WITHOUT RESTART?

troglobit commented 8 years ago

No.

kcao3 commented 8 years ago

@troglobit Thank you for responding to my question.

troglobit commented 8 years ago

Unfortunately not the answer neither I or you would like :disappointed:

Problem is that when interfaces come and go at runtime the multicast router must update the UNIX "VIFs", that is virtual interfaces. An abstraction used by the kernel when setting up multicast routes. Maintaining this, across multiple UNIX/Linux variants is a non-trivial task.

Patches are welcome though!

On Linux, and for the case of a DHCP/PPP/PPPoE interface not yet having an IP address, this is fixable and something I've already done for SMCRoute, released recently in SMCRoute v2.1.0. But without knowing more about your particular use-case I cannot help further.

Sorry.

kcao3 commented 8 years ago

Hi @troglobit,

The network interface in my use case is the GRE tunnel interface like the following:

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

In my use case, the Linux host where I am running PIMD is also hosting a RESTful service. A remote REST client can make a REST call to this service, which in turn to create a tunnel endpoint on this server side. Once the tunnel is up, the remote client can receive multicast traffic over the newly created tunnel, which is forwarded by PIMD. My PIMD "server" can support multiple clients. Currently, when receiving a new tunnel create request, my REST service can send a HUP SIGNAL to PIMD, which is in turn restarting the pimd daemon and reloading its configuration. However, while PIMD is starting, all multicast streaming over existing tunnels are disrupted for a while before resuming to their normal operation. It would be great if there is a way to avoid the user disruption while restarting PIMD.

kcao3 commented 8 years ago

The use case that I described above is very similar to the use case described in issue #21 . The current problem is that while pimd is starting, it appears that it reloads its configuration and drops existing traffic flows.

troglobit commented 8 years ago

Yes, issue #21 is very similar to what you describe, which I'm also very sympathetic to. When pimd is restarted it drops the multicast routing socket which removes all VIFs in the kernel, which leads to loss of multicast traffic. There is unfortunately no workaround for this.

Adding support for dynamically adding/removing interfaces is not a simple task.

jbrown8380 commented 4 years ago

Would this be the same answer with respect to the "altnet masklen 24" directives? This statement typically gets put in the phyint section of the pimd.conf file and so I assume it would have the same limitation. I'd like to be able to add/remove altnet directives to the running pimd daemon without having to reload the config; thereby disrupting established multicast traffic flows. Thanks.

troglobit commented 4 years ago

@jbrown8380 Correct. The same limitations apply here as well.