pimd 0.0.2 package defects/anomalies



  • I've been having significant trouble with the new pimd package, and took the time to discover why, monitoring debug output carefully.
    I learned a few things:

    1. The PIMD package list of interfaces includes interfaces that pimd itself doesn't allow. For example, "re1"... I had to carefully edit my list to exclude the interfaces PIMD can't handle.

    2. When pimd fires up, it pulls in *and enables every interface it can find in the kernel. Because of this, it doesn't seem to matter if I choose "default enable" or "default disable" -- EVERY interface is enabled by default, and I must list-and-disable any interfaces I don't want enabled. (This means in practice we're all actually using "default enable".)

    3. Also because of #2, a default static RP default is initially set up that just causes trouble. By carefully correcting the entire config file, this was eliminated:
      Local static RP: 169.254.0.1, group 232.0.0.0/8

    I'm not done getting things right, but working around these sure helped :)

    Pete


  • Rebel Alliance Developer Netgate

    1. What specific interfaces does PIMD fail on for you? I am not aware of any issues with realtek (reX) but I could see issues with some virtual types.

    2. You need to set Default bind on the General tab to Bind to None if you only want PIMD to latch onto specific interfaces you set. The behavior of the Interface binding setting on the Interfaces tab entries depends on that.



  • @jimp said in pimd 0.0.2 package defects/anomalies:

    1. What specific interfaces does PIMD fail on for you? I am not aware of any issues with realtek (reX) but I could see issues with some virtual types.

    I took the time to dig in on this, because I've been forever a bit confused on just what interfaces I even need to define :)

    BACKGROUND
    0) I do and did have Default Bind set to Bind to None. As you'll see, it doesn't necessarily help (and I may have found at least part of the bug ;) )

    1. I have two HW ifc's, re0 (LAN - VLAN trunked) and re1 (WAN, via pppoe, specified as VLAN 201 by the ISP)
    2. Thus, for my WAN there are three levels of interface:
      • re1 (raw hardware)
      • re1.201 (VLAN tagged)
      • pppoe0 (PPP interface)
    3. For my LAN there's two levels: raw re0 and the re0.NN VLAN's.
    4. I also have OpenVPN (ovpns1)

    OBSERVATIONS

    A) At the time of the above report:

    • I had interfaces defined for re0, re1.201, and ovpns1 (I didn't define one for re1)
    • On startup, PIMD always reads vif's from the kernel, and tries to bring them up. (this WITH Default Bind of None.)
    • pimd was seeing, and failing for: re1, ovpns1, and re1.201 ("Invalid phyint address")

    B) Outside of pimd, having vif's re0 and re1.201 defined has not caused issues elsewhere in pfsense. I've now removed them and pimd no longer tries to bring up re1 or re1.201.

    C) Even with the above cleaned up... if I try to bring up interface ovpns1 (Bind Always Enable), pimd says it is an invalid interface. (FWIW, pimd does not see ovpns1 when it brings up the kernel-defined list of interfaces.)

    Presumably, this means pimd can't handle going across openvpn. Any idea how to enable this? (I used to do that all the time with multicast scanning... it would VERY much help to get this working!)

    D) As reported already, but with more specificity:

    • Not sure why but pimd is defining a "Local static RP: 169.254.0.1, group 232.0.0.0/8"
    • For a while, every N seconds (16?) pimd reports "route to: 169.254.0.1 destination is: 0.0.0.0 gateway is: (my ISP gateway!)" then spits out an error:
      "For src 169.254.0.1, iif is <WAN iif>, next hoprouter is ...: NOT A PIM ROUTER"
    • AND in the log shows this as a Candidate RP: (69.254.0.1, incoming 9, pref 232/8, prio 1, holdtime 65535)
    • A while later, that entry disappears. But the error logs are there anyway for my pleasure ;)
    • Any idea how to configure so 169.254.0.1 is never defined as an RP?

    That just seems el-wrongo :(

    E) Not sure what is causing the following. Doesn't seem to cause harm yet it is anomalous so I'm mentioning it: :)

    • After working through the kernel vifs, and the pimd.conf config...
    • And JUST before first listing the Virtual Ifce Table in the log...
    • pimd is adding one more vif of its own:
      Vif (n+1), Local address: same as Vif 0, Subnet: "register_vif0", Thresh: 1, Flags: (blank)
    • That vif just sits there... I don't find any docs on register_vif0. Do you know?

    THANK YOU for getting this into pfSense!!!
    p


Log in to reply